Le 16/05/2011 15:29, Charles Oliver Nutter a écrit : > On Mon, May 16, 2011 at 2:50 AM, Rémi Forax<fo...@univ-mlv.fr> wrote: >> Theoretically, the is no speed difference between a ConstantCallSite >> and a MutableCallSite that at some point never mutate. >> The difference is more that a MutableCallsite has to keep metada >> to trigger a de-optimization and not the ConstantCallSite. >> >> Now, practically, I don't know if hotspot make a difference between them. >> >> Charles, in your case you have two options: >> First, you are able to serialize the literal in the bytecode, the trick is >> that you can see an array of byte as a String, Terence Parr explains that >> 2 or 3 years ago at the JVM Summit. > Yes, I have been using this trick on and off since I started working > on JRuby in 2006...it works, but it still requires unpacking the bytes > and constructing a new byte[] every time, which is quite a bit more > overhead than being able to bind a byte[] or ByteList directly into a > constant MH.
if you combine it with the bootstrap method mecanism, you can do the unpacking once when needed. >> Second, if you know the org.jruby.Ruby instance when generating >> the code, you can cache it and look it up in the BSM. > Well, that's a bridge I'm going to have to cross soon. Because the the > call sites are associated with code at the bytecode level, and the > call sites are not localized to a given JRuby runtime, we will need to > isolate jitted code across JRuby instances. At the moment, we do allow > sharing that code...disallowing that sharing should not be > particularly difficult. > > More difficult, however, will be allowing precompiled code to have > unique call site information for each JRuby runtime. Normally it's all > loaded in the same classloader, so isolating them will be trickier and > require manual intervention. Currently all generated bytecode isolates > call sites by instantiating a cache and associating it with an > instance of the script. Each runtime then has its own instance of the > script, and call sites are isolated. invokedynamic call sites > essentially move call site information to a static level. > > This will affect other languages, I'm sure...so other language > implementers probably should keep it in mind; invokedynamic call sites > are bound on a classloader-global basis. I've this problem with the web part of PHP.reboot: should I have one runtime by HTTP request or one global ? I've started with one runtime by request and switch to one global because it was easier to implement. Clearly the relation between a runtime and the callsites is far from obvious. > - Charlie Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
