On Fri, Dec 3, 2010 at 12:21 PM, John Rose <[email protected]> wrote: > With closures, if you are desperate to keep one entry point, you can play > around with thread-local values to pass in the data links: > static Object p = #localPutsProcBodyUsingTL; > static ThreadLocal reg42 = new JRubyRegister(); > { reg42.set(i); x.each(p); } > The problem here is you have to prove non-interference on your virtual > register and deal any spills and fills. Maybe you end up with a try/finally > to spill and refill the previous value. Also, this level of "dirty" > optimization steps on the toes of the JIT's optimizer, which is also trying > to map values into (lower-level) registers.
So am I hearing that if we explicitly put those shared values into a thread-local, EA will be able to see that while it "escapes" it only escapes to thread-local state, and elide the object completely? The rest of your idea (the caveats) lost me, unfortunately :) > That's a different problem, but in general managing your own dynamic call > site is a good idea *if* you know something language-specific about the site > that the JVM won't be able to figure out. Yes, in general I'm focusing primarily on just wiring up calls with a light-as-possible guard and direct dispatch, both on indy and via runtime optimization (the "dynopt" work I posted about before). There might be some value, as in Hotspot, to make it possible to optimize two distinct targets, but it's not on my roadmap at the moment. Of course, if GWTs could be chained this way without any penalty other than an N-long series of additional guard checks, it would potentially make addressing N-polymorphic situations feasible enough to try :) - Charlie -- 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.
