RFR: jsr166 jdk9 integration wave 12

Paul Sandoz paul.sandoz at oracle.com
Fri Nov 18 17:45:24 UTC 2016


I encourage you to look at the experiments in the valhalla repository.

Such as:

  http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/780c8eba356a/src/java.base/share/classes/java/anyutil/ArrayDeque.java <http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/780c8eba356a/src/java.base/share/classes/java/anyutil/ArrayDeque.java>

I have no objections to the current change but i expect it to change back at some point, and there will be other changes needed as you point out, but perhaps not as major as you think in some cases, and others perhaps more so, especially to take advantage of value-type optimized data structures.

Paul.

> On 18 Nov 2016, at 08:57, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Fri, Nov 18, 2016 at 5:02 AM, Doug Lea <dl at cs.oswego.edu <mailto:dl at cs.oswego.edu>> wrote:
> On 11/18/2016 02:28 AM, Remi Forax wrote:
> Martin,
> for ArrayDeque, when you start to have methods like
>   @SuppressWarnings("unchecked")
>    static final <E> E elementAt(Object[] es, int i) {
>        return (E) es[i];
>    }
> 
> I think it's a better idea to type the field elements as a E[] instead of Object[].
> Historically, using Object(] instead of E[] was preferred because it's a kind of 'more true' at runtime,
> but it will be less true with anyfied generics and as we can see if it leads to introduce method like elementAt, using E[] will make the code more readable.
> 
> 
> We always use Object[] in cases where anyfication isn't possible
> (without further code rework) because we rely on null as a distinct
> value. Elsewhere we do use E[].
> 
> I've always considered using E[] a bigger cheat than the elementAt method, due to the expectation that if reification was ever implemented, then E[] would simply be wrong in a ClassCastException sort of way.
> 
> I will be surprised if anyfication can be made to work on collection classes without major rewrites.  When working with elements that are references, there is a need to null out slots that are no longer used for the benefit of the GC, as well as a special value to mark the slot as free.  Sometimes logically removing an element means CASing the reference to null.



More information about the core-libs-dev mailing list