Odd interaction between ArrayList$Itr and Escape Analysis

[Remi Forax]

I've always found that the empty inner classes generated by javac as a kind of hack. 

These classes should be removed in Java 10, thanks to the nestmate attributes. 
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2016-January/000060.html 

The other solution, is to have an empty class in the jdk which is not visible from javac (the class itself can be marked as synthetic), 
so javac can use it without creating method clash. 

and to solve the problem now, the easy solution is to add a package private constructor in ArrayList.Itr, 

private class Itr implements Iterator<E> { int cursor;       // index of next element to return int lastRet = -1; // index of last element returned; -1 if no such int expectedModCount = modCount; 

Itr() { 
// avoid to generate a synthetic accessor constructor 
} 
} 

regards, 
Rémi 

> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> À: "Krystal Mok" <rednaxelafx at gmail.com>
> Cc: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> Envoyé: Lundi 12 Septembre 2016 22:15:41
> Objet: Re: Odd interaction between ArrayList$Itr and Escape Analysis

> On Mon, Sep 12, 2016 at 3:56 PM, Krystal Mok < rednaxelafx at gmail.com > wrote:

>> On Mon, Sep 12, 2016 at 12:38 PM, Vitaly Davidovich < vitalyd at gmail.com > wrote:
>>> It seems odd to me as well why inlining won't force load the missing class(es).
>>> If we're inlining, it means the method itself or the call chain it's part of is
>>> hot - failing to inline can have negative side-effects, like this example. I
>>> suppose there must be a good reason why it doesn't do this though?

>> That's because we can't. The JIT compilers are running on their own threads, and
>> they're not real "Java threads". So they are not allowed to run arbitrary Java
>> code. But Java class loading may involve running arbitrary Java code, e.g. the
>> ClassLoader.loadClass() upcall.
>> Force class loading can be done on the triggering side (for the top-level
>> method), because compilation tasks are triggered from real Java threads, and
>> they're allowed to run arbitrary Java code.

> I see, makes sense. Perhaps there can be an option to turn on loading of
> required types in the entire compilation unit, after all inlining is done (and
> therefore make the unloaded types not be barriers for inlining). I'd personally
> prefer that over having odd performance differences.

>> - Kris

> Thanks Kris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160913/7fa2c66e/attachment.html>