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


The logic which handles switchpoints is (as Remi said) built on top of
mutable call sites, which are handled in the JVM here:


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

mlvm-dev mailing list

Reply via email to