Lambda vs anon class optimization effect on CHA

[Vitaly Davidovich]

On Friday, August 12, 2016, John Rose <john.r.rose at oracle.com> wrote:

> On Aug 10, 2016, at 12:02 PM, Aleksey Shipilev <aleksey.shipilev at gmail.com
> <javascript:_e(%7B%7D,'cvml','aleksey.shipilev at gmail.com');>> wrote:
>
> I would venture to guess that we can wire up CHA to look at what classes
> have been _initialized_ rather than what classes were _resolved_, but
> there is no telling how much bugs would that expose.
>
>
> I agree with both of your points.
>
> Even more sharply:  A class which is never _instantiated_ does not
> contribute
> to the concrete types encountered at virtual call sites.  It can be
> treated as if it
> had been marked ACC_ABSTRACT, until the first instantiation.  (CHA makes
> a distinction between abstract and non-abstract.)
>
Yeah, having the dependency predicated on instantiation would be great.
Any ideas on how to make that work efficiently?

>
> I agree that changing this code might cause bugs.  Here's where I held
> back, FTR:
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/tip/src/share/vm/code/
> dependencies.cpp#l1440
>
> In any case, since loaded classes can transition to initialized, and
> then can be instantiated (if not abstract), there will have to be new
> dependency
> tracking to guard against these transitions, just as we now guard against
> new subclasses getting loaded.
>
> — John
>
So does this issue deserve a JBS entry? Leaving the "instantiation based
dependency" wishlist item alone, do you consider the core issue I
highlighted (and Aleksey explained) worth addressing?

Thanks


-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160815/663b21cf/attachment.html>