Odd interaction between ArrayList$Itr and Escape Analysis

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed Sep 28 17:10:33 UTC 2016


> 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.

> (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

More information about the hotspot-compiler-dev mailing list