Odd interaction between ArrayList$Itr and Escape Analysis

[Krystal Mok]

On Wed, Sep 28, 2016 at 10:10 AM, Vladimir Ivanov <
vladimir.x.ivanov at oracle.com> wrote:

> Kris,
>
> A null guard is a good way to go. It's basically the same kind of logic
>> that C2 OSR entry already uses. In this case, at a call site, a null
>> guard on the caller-side against an argument whose type is unloaded is
>> one way to do it.
>>
>
> For the case when argument value (null) is a compile-time constant, the
> guard collapses right away. So, it sounds like a good solution.


That's exactly what I'm doing with my other patch. Let me prepare that and
send it out for review sometime this weekend.

Thanks,
Kris


>
>
> (There are of course other alternatives. e.g. If we focus on the
>> callee-side, in a compiler with a mixed top-down / bottom-up inlining
>> heuristics system, the (devirtualized if needed) callee can be inspected
>> first to see if an argument of unloaded type is never used or not. If it
>> is never used, don't even bother inserting the null guard on the
>> caller-side, and just go ahead and inline would be good and safe. C2
>> doesn't have this luxury yet so tackling the problem with a caller-side
>> solution is easier to do.)
>>
>> IMO a nmethod dependency on an "unloaded class" isn't that feasible,
>> since you might not even have a concrete entity to "depend on", and
>> registering symbolic dependencies for "unloaded classes" in general,
>> even though I believe is doable, might be rather tedious.
>>
>
> Agree, it requires a new flavor of nmethod dependency.
>
> Best regards,
> Vladimir Ivanov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160928/0e62a38e/attachment.html>