Atomic arrays and toArray(), stream(), iterator()

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Atomic arrays and toArray(), stream(), iterator()

Mike Duigou
Is it just an oversight or is there a reason why the array types in the
j.u.c.atomic package, AtomicIntegerArray, AtomicLongArray and
AtomicReferenceArray, do not provide toArray(), stream() or, for
AtomicReferenceArray, iterator() methods? I don't see any obstacles in
implementing the methods but I am surprised that the methods aren't
already there.

Mike
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Martin Buchholz-3
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles.  Both are low-level mechanisms.  Build your own collection class on top!

On Sun, Mar 19, 2017 at 6:10 PM, Mike Duigou <[hidden email]> wrote:
Is it just an oversight or is there a reason why the array types in the j.u.c.atomic package, AtomicIntegerArray, AtomicLongArray and AtomicReferenceArray, do not provide toArray(), stream() or, for AtomicReferenceArray, iterator() methods? I don't see any obstacles in implementing the methods but I am surprised that the methods aren't already there.

Mike
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Joshua Bloch


On Mon, Mar 20, 2017 at 3:16 PM, Martin Buchholz <[hidden email]> wrote:
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles. 

All of j.u.c atomic? That's a strong statement. Isn't an AtomicLong still the tool of choice for generating serial numbers (and the like)? 

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Martin Buchholz-3
AtomicLong is still fine and not going away, but manipulating a VarHandle for a long field
saves a level of indirection and is expected to be a little more efficient.

On Mon, Mar 20, 2017 at 3:52 PM, Joshua Bloch <[hidden email]> wrote:


On Mon, Mar 20, 2017 at 3:16 PM, Martin Buchholz <[hidden email]> wrote:
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles. 

All of j.u.c atomic? That's a strong statement. Isn't an AtomicLong still the tool of choice for generating serial numbers (and the like)? 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Joshua Bloch
The conceptual surface area appears larger. Have you confirmed that the performance justifies this for simple uses such as the one I mentioned (a static long or AtomicLong uses solely for computing serial nubmers)? I'm not just giving you a hard time. This affects the concurrency chapter of Effective Java 3e.


On Mon, Mar 20, 2017 at 4:06 PM, Martin Buchholz <[hidden email]> wrote:
AtomicLong is still fine and not going away, but manipulating a VarHandle for a long field
saves a level of indirection and is expected to be a little more efficient.

On Mon, Mar 20, 2017 at 3:52 PM, Joshua Bloch <[hidden email]> wrote:


On Mon, Mar 20, 2017 at 3:16 PM, Martin Buchholz <[hidden email]> wrote:
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles. 

All of j.u.c atomic? That's a strong statement. Isn't an AtomicLong still the tool of choice for generating serial numbers (and the like)? 



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Benjamin Manes
I think for common case usages, one should still prefer the atomic classes. For custom data structures, e.g. a cache's entry, the VarHandles API is preferable for greater flexibility and lower memory overhead.

On Mon, Mar 20, 2017 at 4:14 PM Joshua Bloch <[hidden email]> wrote:
The conceptual surface area appears larger. Have you confirmed that the performance justifies this for simple uses such as the one I mentioned (a static long or AtomicLong uses solely for computing serial nubmers)? I'm not just giving you a hard time. This affects the concurrency chapter of Effective Java 3e.


On Mon, Mar 20, 2017 at 4:06 PM, Martin Buchholz <[hidden email]> wrote:
AtomicLong is still fine and not going away, but manipulating a VarHandle for a long field
saves a level of indirection and is expected to be a little more efficient.

On Mon, Mar 20, 2017 at 3:52 PM, Joshua Bloch <[hidden email]> wrote:


On Mon, Mar 20, 2017 at 3:16 PM, Martin Buchholz <[hidden email]> wrote:
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles. 

All of j.u.c atomic? That's a strong statement. Isn't an AtomicLong still the tool of choice for generating serial numbers (and the like)? 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Joshua Bloch
Ben,

That's what I assumed, but I'll give Martin a chance to respond :)

Josh

On Mon, Mar 20, 2017 at 4:18 PM, Benjamin Manes <[hidden email]> wrote:
I think for common case usages, one should still prefer the atomic classes. For custom data structures, e.g. a cache's entry, the VarHandles API is preferable for greater flexibility and lower memory overhead.

On Mon, Mar 20, 2017 at 4:14 PM Joshua Bloch <[hidden email]> wrote:
The conceptual surface area appears larger. Have you confirmed that the performance justifies this for simple uses such as the one I mentioned (a static long or AtomicLong uses solely for computing serial nubmers)? I'm not just giving you a hard time. This affects the concurrency chapter of Effective Java 3e.


On Mon, Mar 20, 2017 at 4:06 PM, Martin Buchholz <[hidden email]> wrote:
AtomicLong is still fine and not going away, but manipulating a VarHandle for a long field
saves a level of indirection and is expected to be a little more efficient.

On Mon, Mar 20, 2017 at 3:52 PM, Joshua Bloch <[hidden email]> wrote:


On Mon, Mar 20, 2017 at 3:16 PM, Martin Buchholz <[hidden email]> wrote:
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles. 

All of j.u.c atomic? That's a strong statement. Isn't an AtomicLong still the tool of choice for generating serial numbers (and the like)? 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Remi Forax
In reply to this post by Martin Buchholz-3
Hi Martin,
i think there is an Arrayish interface with several default methods implemented by all plain old Java arrays as part of valhalla.

I think it's currently scheduled for 11 when generics over primitives will be integrated.

Rémi


De: "Martin Buchholz" <[hidden email]>
À: "Mike Duigou" <[hidden email]>
Cc: "Concurrency Interest" <[hidden email]>
Envoyé: Lundi 20 Mars 2017 23:16:26
Objet: Re: [concurrency-interest] Atomic arrays and toArray(), stream(),        iterator()
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles.  Both are low-level mechanisms.  Build your own collection class on top!

On Sun, Mar 19, 2017 at 6:10 PM, Mike Duigou <[hidden email]> wrote:
Is it just an oversight or is there a reason why the array types in the j.u.c.atomic package, AtomicIntegerArray, AtomicLongArray and AtomicReferenceArray, do not provide toArray(), stream() or, for AtomicReferenceArray, iterator() methods? I don't see any obstacles in implementing the methods but I am surprised that the methods aren't already there.

Mike
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Remi Forax
In reply to this post by Joshua Bloch
Hi Josh,

[Added Paul in CC as he works on it]

VarHandles are a replacement for all Atomic*FieldUpdaters (fields + array),
- they are faster because the VarHandle API do not uses generics which has a runtime cost, the VM can not trust genrics because they are erased and use a polymorphic signature instead.
- they work on ByteBuffer too
- they allow opaque access (the semantics of volatile before the revision of the JMM)
- they allow real weakCAS semantics and not the Frankenstein weakCAS of the field updater)

Atomic classes are still here, still easier to use than VarHandle, and like before, compared to a VarHandle, they cost a pointer indirection (apart if you inherit from the Atomic class).

regards,
Rémi


De: "jbloch" <[hidden email]>
À: "Benjamin Manes" <[hidden email]>
Cc: "Martin Buchholz" <[hidden email]>, "Mike Duigou" <[hidden email]>, "Concurrency Interest" <[hidden email]>
Envoyé: Mardi 21 Mars 2017 00:24:38
Objet: Re: [concurrency-interest] Atomic arrays and toArray(), stream(),        iterator()
Ben,
That's what I assumed, but I'll give Martin a chance to respond :)

Josh

On Mon, Mar 20, 2017 at 4:18 PM, Benjamin Manes <[hidden email]> wrote:
I think for common case usages, one should still prefer the atomic classes. For custom data structures, e.g. a cache's entry, the VarHandles API is preferable for greater flexibility and lower memory overhead.

On Mon, Mar 20, 2017 at 4:14 PM Joshua Bloch <[hidden email]> wrote:
The conceptual surface area appears larger. Have you confirmed that the performance justifies this for simple uses such as the one I mentioned (a static long or AtomicLong uses solely for computing serial nubmers)? I'm not just giving you a hard time. This affects the concurrency chapter of Effective Java 3e.


On Mon, Mar 20, 2017 at 4:06 PM, Martin Buchholz <[hidden email]> wrote:
AtomicLong is still fine and not going away, but manipulating a VarHandle for a long field
saves a level of indirection and is expected to be a little more efficient.

On Mon, Mar 20, 2017 at 3:52 PM, Joshua Bloch <[hidden email]> wrote:


On Mon, Mar 20, 2017 at 3:16 PM, Martin Buchholz <[hidden email]> wrote:
There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".

But all of j.u.c.atomic feels largely obsoleted by VarHandles. 

All of j.u.c atomic? That's a strong statement. Isn't an AtomicLong still the tool of choice for generating serial numbers (and the like)? 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Martin Buchholz-3
In reply to this post by Joshua Bloch


On Mon, Mar 20, 2017 at 4:24 PM, Joshua Bloch <[hidden email]> wrote:
Ben,

That's what I assumed, but I'll give Martin a chance to respond :)

I was waiting for Doug or Aleksey to respond! 

The biggest advantage of AtomicLong will always be PORTABILITY.  Each platform iteration takes more years to become ubiquitous than its predecessor, and that will be even more true for jdk9.  VarHandles are for classes that are part of the platform or that value extreme performance more than portability.

OTOH jdk9 AtomicLong is a wrapper around VarHandle.  It's unlikely to be completely free. .... oh I now see Remi has a better answer!

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Joshua Bloch
Yes, all of this makes sense.  Also Doug just called me, and said pretty much the same thing (though he he used some amusing phrase like "repulsively ugly incantation"). So I think we're all on the same page.

Josh

On Mon, Mar 20, 2017 at 4:49 PM, Martin Buchholz <[hidden email]> wrote:


On Mon, Mar 20, 2017 at 4:24 PM, Joshua Bloch <[hidden email]> wrote:
Ben,

That's what I assumed, but I'll give Martin a chance to respond :)

I was waiting for Doug or Aleksey to respond! 

The biggest advantage of AtomicLong will always be PORTABILITY.  Each platform iteration takes more years to become ubiquitous than its predecessor, and that will be even more true for jdk9.  VarHandles are for classes that are part of the platform or that value extreme performance more than portability.

OTOH jdk9 AtomicLong is a wrapper around VarHandle.  It's unlikely to be completely free. .... oh I now see Remi has a better answer!


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Paul Sandoz
In reply to this post by Remi Forax
Hi,

I think Ben makes a fair evaluation. W.r.t the Atomic* classes, not including Atomic*FieldUpdaters as Remi notes below, my recommendation would be to reach for VarHandle if:

1) the Atomic* box is bothersome;
2) some type other than int/long/ref is required; or
3) VarHandle-specific access is required (e.g. bitwise ops).


If we consider the Atomic* box as something that does not need to strongly encapsulate, which i think is more the case now many weaker forms of access are supported, we could make an argument for providing public static final VarHandle instances on each AtomicType as a bridge to support VarHandle-specific access.


Some of the Atomic* classes use VarHandle but others are problematic (such as AtomicInteger/Long) due to circular dependencies in class initializers at start up. I hope to revisit this aspect at some point. (Martin, at one point AtomicLong did wrap VarHandle but i had to revert the changeset due to such circularity issues.)

Hth,
Paul.

> On 20 Mar 2017, at 16:47, Remi Forax <[hidden email]> wrote:
>
> Hi Josh,
>
> [Added Paul in CC as he works on it]
>
> VarHandles are a replacement for all Atomic*FieldUpdaters (fields + array),
> - they are faster because the VarHandle API do not uses generics which has a runtime cost, the VM can not trust genrics because they are erased and use a polymorphic signature instead.
> - they work on ByteBuffer too
> - they allow opaque access (the semantics of volatile before the revision of the JMM)
> - they allow real weakCAS semantics and not the Frankenstein weakCAS of the field updater)
>
> Atomic classes are still here, still easier to use than VarHandle, and like before, compared to a VarHandle, they cost a pointer indirection (apart if you inherit from the Atomic class).
>
> regards,
> Rémi
>
> De: "jbloch" <[hidden email]>
> À: "Benjamin Manes" <[hidden email]>
> Cc: "Martin Buchholz" <[hidden email]>, "Mike Duigou" <[hidden email]>, "Concurrency Interest" <[hidden email]>
> Envoyé: Mardi 21 Mars 2017 00:24:38
> Objet: Re: [concurrency-interest] Atomic arrays and toArray(), stream(),        iterator()
> Ben,
> That's what I assumed, but I'll give Martin a chance to respond :)
>
> Josh
>
> On Mon, Mar 20, 2017 at 4:18 PM, Benjamin Manes <[hidden email]> wrote:
> I think for common case usages, one should still prefer the atomic classes. For custom data structures, e.g. a cache's entry, the VarHandles API is preferable for greater flexibility and lower memory overhead.
>
> On Mon, Mar 20, 2017 at 4:14 PM Joshua Bloch <[hidden email]> wrote:
> The conceptual surface area appears larger. Have you confirmed that the performance justifies this for simple uses such as the one I mentioned (a static long or AtomicLong uses solely for computing serial nubmers)? I'm not just giving you a hard time. This affects the concurrency chapter of Effective Java 3e.
>
>
> On Mon, Mar 20, 2017 at 4:06 PM, Martin Buchholz <[hidden email]> wrote:
> AtomicLong is still fine and not going away, but manipulating a VarHandle for a long field
> http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.html#getAndAdd-java.lang.Object...-
> saves a level of indirection and is expected to be a little more efficient.
>
> On Mon, Mar 20, 2017 at 3:52 PM, Joshua Bloch <[hidden email]> wrote:
>
>
> On Mon, Mar 20, 2017 at 3:16 PM, Martin Buchholz <[hidden email]> wrote:
> There's a large number of collection-like methods one could define for atomic arrays - forEach, fill, indexOf, toArray(), etc...
> If we were brave enough to change the Java language, we could do the same for ordinary arrays; it already has a "length" "field".
>
> But all of j.u.c.atomic feels largely obsoleted by VarHandles.
>
> All of j.u.c atomic? That's a strong statement. Isn't an AtomicLong still the tool of choice for generating serial numbers (and the like)?
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Mike Duigou
In reply to this post by Joshua Bloch
For the safe serial number pattern I've become pretty partial to
variations of

final static LongSupplier serialSource = (new
AtomicLong(0))::incrementAndGet;

sometimes with the LongSupplier itself being supplied by a framework. It
is useful that I can safely pass around the LongSupplier while also
delaying invocation until a value is actually needed.

Mike

On 2017-03-20 17:19, Joshua Bloch wrote:

> Yes, all of this makes sense.  Also Doug just called me, and said
> pretty much the same thing (though he he used some amusing phrase like
> "repulsively ugly incantation"). So I think we're all on the same
> page.
>
> Josh
>
> On Mon, Mar 20, 2017 at 4:49 PM, Martin Buchholz <[hidden email]>
> wrote:
>
>> On Mon, Mar 20, 2017 at 4:24 PM, Joshua Bloch <[hidden email]>
>> wrote:
>>
>>> Ben,
>>>
>>> That's what I assumed, but I'll give Martin a chance to respond :)
>>
>> I was waiting for Doug or Aleksey to respond!
>>
>> The biggest advantage of AtomicLong will always be PORTABILITY.
>> Each platform iteration takes more years to become ubiquitous than
>> its predecessor, and that will be even more true for jdk9.
>> VarHandles are for classes that are part of the platform or that
>> value extreme performance more than portability.
>>
>> OTOH jdk9 AtomicLong is a wrapper around VarHandle.  It's unlikely
>> to be completely free. .... oh I now see Remi has a better answer!
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Peter
In reply to this post by Mike Duigou
 
Interesting discussion about Atomic's vs VarHandles.  In practise I haven't found an Atomic causing a "hotspot" yet.

I recall some discussion about visibility issues with ByteBuffer, I'd be interested how VarHandles can be used to solve them, with consideration for native code visibility too?

Thanks,

Peter.

Sent from my Samsung device.
 
---- Original message ----
From: Mike Duigou <[hidden email]>
Sent: 21/03/2017 10:34:07 am
To: [hidden email]
Cc: Martin Buchholz <[hidden email]>; Concurrency Interest <[hidden email]>
Subject: Re: [concurrency-interest] Atomic arrays and toArray(), stream(), iterator()

For the safe serial number pattern I've become pretty partial to 
variations of

final static LongSupplier serialSource = (new 
AtomicLong(0))::incrementAndGet;

sometimes with the LongSupplier itself being supplied by a framework. It 
is useful that I can safely pass around the LongSupplier while also 
delaying invocation until a value is actually needed.

Mike

On 2017-03-20 17:19, Joshua Bloch wrote:

> Yes, all of this makes sense.  Also Doug just called me, and said
> pretty much the same thing (though he he used some amusing phrase like
> "repulsively ugly incantation"). So I think we're all on the same
> page.

> Josh

> On Mon, Mar 20, 2017 at 4:49 PM, Martin Buchholz <[hidden email]>
> wrote:

>> On Mon, Mar 20, 2017 at 4:24 PM, Joshua Bloch <[hidden email]>
>> wrote:
>> 
>>> Ben,
>>> 
>>> That's what I assumed, but I'll give Martin a chance to respond :)
>> 
>> I was waiting for Doug or Aleksey to respond!
>> 
>> The biggest advantage of AtomicLong will always be PORTABILITY.
>> Each platform iteration takes more years to become ubiquitous than
>> its predecessor, and that will be even more true for jdk9.
>> VarHandles are for classes that are part of the platform or that
>> value extreme performance more than portability.
>> 
>> OTOH jdk9 AtomicLong is a wrapper around VarHandle.  It's unlikely
>> to be completely free. .... oh I now see Remi has a better answer!
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Atomic arrays and toArray(), stream(), iterator()

Remi Forax
In reply to this post by Martin Buchholz-3
correction to avoid to spread false news,
i say that Arrayish was scheduled for 11 but i was wrong, it's part of valhalla and currently unscheduled.

Rémi



De: "Martin Buchholz" <[hidden email]>
À: "jbloch" <[hidden email]>
Cc: "Mike Duigou" <[hidden email]>, "Concurrency Interest" <[hidden email]>
Envoyé: Mardi 21 Mars 2017 00:49:31
Objet: Re: [concurrency-interest] Atomic arrays and toArray(), stream(),        iterator()


On Mon, Mar 20, 2017 at 4:24 PM, Joshua Bloch <[hidden email]> wrote:
Ben,
That's what I assumed, but I'll give Martin a chance to respond :)

I was waiting for Doug or Aleksey to respond! 

The biggest advantage of AtomicLong will always be PORTABILITY.  Each platform iteration takes more years to become ubiquitous than its predecessor, and that will be even more true for jdk9.  VarHandles are for classes that are part of the platform or that value extreme performance more than portability.

OTOH jdk9 AtomicLong is a wrapper around VarHandle.  It's unlikely to be completely free. .... oh I now see Remi has a better answer!

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Loading...