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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
