Le 03/08/2009 00:39, Attila Szegedi a écrit : > On 2009.07.29., at 0:33, Attila Szegedi wrote: > > >> 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. >> > > Okay, I solved this. In keeping with the principle that the whole > concern of inline caching should be owned by the call site, not the > linker, I reduced the linker to a resolver of the method handle and > the guard. I introduced a special CallSite abstract subclass named > "RelinkableCallSite" that receives them and contains an abstract > method responsible for actual linking and/or caching; I also provided > a concrete "MonomorphicCallSite" subclass of "RelinkableCallSite" that > implements a MIC. Since it's the language runtime that creates the > call site anyway, it can choose to use whatever call site subclass it > wishes - if its designer is unhappy with the MonomorphicCallSite I > provided, he's free to write his own with whatever inline caching > strategy he wants. >
I think that the MOP runtime should manage the callsite not the language runtime because another language runtime will want to insert information into that call site too. The MOP runtime should manage the JSR292 callsite and provide a kind of local callsite for each linker i.e each language should see its part of the method handle tree and be able to modify it without destroying/disturbing all other parts. > I'm quite happy with how it turned out; I avoided placing constraints > on language runtime implementations where none were needed. New code > available under<https://sourceforge.net/projects/dynalang/develop>, > with README being the most up-to-date document > at<http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/invoke/README.txt?revision=159&view=markup > > if you wish to take a look. I'm off to bed now :-) > I have to go to bed too :) > Attila. > Rémi --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
