On Oct 5, 2016, at 7:00 AM, Charles Oliver Nutter <head...@headius.com> wrote:
>
> I will say that using SwitchPoints is FAR better than our alternative
> mechanism: pinging the (meta)class each time and checking a serial number.
This makes my day! That's exactly what SwitchPoints are designed to deliver.
They are intended to hook into the same mechanism the JVM uses to invalidate
code that has out-of-date devirtualized methods. (I.e., when you load the
second definition overriding a method, you might cause some call sites to
recompile. That stuff is too good not to share with language implementors.)
> Or I can do one switchpoint for all methodhandles in the system, which makes
> me wonder if after a meta class change the callsite ever gets Jitted again.
> The later performance penalty is actually also not very attractive to me.
>
> We have fought to keep the JIT from giving up on us, and I believe that as of
> today you can invalidate call sites forever and the JIT will still recompile
> them (within memory, code cache, and other limits of course).
I'm glad of that. It has been a fight to tuned everything up just so. Can you
say (or blog) more about what you had to tweak to keep the JIT happen? That
may help other users, and/or help us make the JIT less irritable.
> However, you'll be invalidating every call site for every modification. If
> the system eventually settles, that's fine. If it doesn't, you're going to be
> stuck with cold call site performance most of the time.
>
> So what is the way to go here? Or is there an even better way?
>
> I strongly recommend the switchpoint-per-class granularity (or finer, like
> switchpoint-per-class-and-method-name, which I am playing with now).
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
<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
<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!
— John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
