series of switchpoints or better

[Jochen Theodorou]

On 05.10.2016 22:22, John Rose wrote:
[...]
> For the classic devirtualization trick, the JVM uses something that
> works like a cross between a switchpoint per super-class and a
> switchpoint per method:  When you load a new sub-class, each of its
> supers S is walked, causing a search for any devirtualized methods S.m
> in any compiled code.  A compiled code blob ("nmethod") contains a list
> of dependencies which might (under suitable conditions) require it to be
> discarded and recompiled.  This list can contain something like "S.m was
> devirtualized and hasn't been overridden yet", or something else like
> "switchpoint x has not been triggered yet".
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/08492e67bf32/src/share/vm/code/codeCache.cpp#l1180
>
> The logic which handles switchpoints is (as Remi said) built on top of
> mutable call sites, which are handled in the JVM here:
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/08492e67bf32/src/share/vm/code/dependencies.cpp#l1740
>
> I'm always glad when this stuff works like it's supposed to.  It
> emboldens me to try more!

I see... the problem is actually similar, only that I do not have to do 
something like that on a per "subclass added" event, but on a per 
"method crud operation" event. And instead of going up to check for a 
devirtualization, I have to actually propagate the change to all meta 
classes of subclasses... and interface implementation (if the change was 
made to an interface). So far I was thinking of making this lazy... but 
maybe I should actually mark the classes as "dirty" eagerly... sorry... 
not part of the discussion I guess ;)

bye Jochen