Hi folks, I'm on vacation this and next week, which in practical terms means that I get to hack on things I love to hack on. So, I'm now working on the MOP equivalent that relies on invokedynamic. Both because I have time for it and also because I'm terrified I won't have anything interesting to report for this year's JVM Language Summit :-).
I did encounter something that at first seemed like a problem, but now actually seems like an opportunity, and would like a confirmation I'm correct (or wrong, as the case may be). So, sometime in the past, bootstrap method signature was changed from "Object bootstrap(CallSite callSite, Object receiver, Object... arguments) to "CallSite bootstrap(Object caller, String methodName, MethodType type)". I was actually a bit terrified by this at first. See, the old signature actually allowed me to find the most suitable method to link based on the receiver (is it a POJO? Link to a POJO method handle? Is it a Ruby object? Link to a Ruby MH. Is it a Jython object? Link to a Jython MH, and so on). It basically allowed for a monomorphic inline cache if the final MH was also set as the target, actually composed in an appropriate guardWithTest() where test was "receiver instanceof x" and fallback was a MH that redid the whole linking process. Now I'm faced with the fact that I have none of this with the new bootstrap method signature, as all I have is the MethodType, which reflects the static types of arguments to a particular invokedynamic call site. Consider for a moment a scripting language that compiles to bytecode with invokedynamic. In quite a lot of cases, the static types of all arguments will simply be java.lang.Object, 'cause we can't know at the time we emit the bytecode what will the argument types be. Okay, we might be able - depending on the language - to discern a boolean here and a double there as the argument types, but that's pretty much as far as it gets. That's not much help in dispatch scheme that relies on receiver type. Then I realized that this actually made the bootstrap protocol much more flexible, and it should actually be viewed as an opportunity. Namely, my top-level composite "Dynamic Linker" (which is more or less what the MOP should be named with invokedynamic, or rather we could say that the DL is the means of implementing a MOP) could install a general-purpose MH that will intercept the first call, then dispatch to the appropriate language-specific linker based on the type of "this", and said linker (JRuby, Jython, Rhino, or POJO) then replaces the general-purpose MH as the target of the call site with a language- specific one plus a guard. Well, okay, I could go this direction and not even feel particularly bad about it, except that if I did this, then I'd force all languages into only having a monomorphic inline cache. Wait, you might ask, didn't the old signature of bootstrap methods actually force that anyway? Well, yes, it did, and that's exactly my point - since the new signature allows more flexibility in linkage, wouldn't it be blunt if I now took it away in an inter-language interop protocol? Actually, with this interop protocol, I could mandate CallSite subclasses that have any inline caching strategy - strictly monomorphic, monomorphic escalating into megamorphic, monomorphic evolving into polymorphic, then escalating into megamorphic, and so on. But no matter how I slice it it looks to me like the top-level dynamic linker that composes multiple language-specific linkers will impose inline caching strategy on the individual language linkers. I was entertaining the idea that it might be possible to go to the other extreme, and have the master linker get out of the way instead. Namely, it'd still install the general-purpose MH, but then let the language-specific linker (selected by the type of the actual receiver on the first call) install whatever call site it wishes, that can follow any inline caching strategy. So, if I have two language runtimes in my JVM, A and B, and A creates MIC call sites, and B creates PIC call sites, then the inline caching strategy of the call site will be determined by whichever object is the receiver of the first call at the site - if the object came from runtime A, it's a MIC; if it came from B, it's a PIC. Except, this wouldn't really work, as a PIC call site would actually be defeated by a later linker that installs a MIC. And anyway, we can't recreate the call site, we can just relink its target once it's created for the first time. So the behaviour would be very nondeterministic, and I don't like that, and to boot, this might actually not be possible under current operational semantics of dynamic call sites in the JVM. Either that, or different runtimes would need to know about a finite number of available call site types that are part of the protocol. Which actually brings a third option to the table - have few predefined inline caching strategies as part of the linker protocol, that all language runtimes would know about and be able to respect without stepping on each other's toes. Yes, it's a compromise, and at the moment and don't even see how viable it is, or what would it look like in technical implementation details, but it might work. It's also a good question who gets to decide which call site follows which caching strategy (gut feeling would be to say it's the language runtime of the caller class, of course). Or for now, just accept that a framework for inter-language linking will force the participating languages' linkages into a single inline caching strategy (monomoprhic, or optionally, monomorphic escalating to megamorphic). Does that sound acceptable at least to "big" dynalang stakeholders out there (JRuby, Jython, I'm looking at you. Rhino has no invokedynamic yet, but if it did, I could definitely live with a MIC). Do I worry too much about this? Hope this all made sense :-) Attila. -- twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
