On Apr 20, 1:08 pm, Charles Oliver Nutter <[email protected]> wrote: > On Tue, Apr 20, 2010 at 3:19 AM, Jochen Theodorou <[email protected]> wrote: > > since quite a while I am looking for the best approach to tackle the Groovy > > speed problem, but it seems I will not be able to fully solve the problem > > without solving my concurrency problem. > > > My problem is more or less the following. A method call is done using the > > data of a meta class, which is mostly like a caching structure, that can be > > recreated unless certain conditions are met, that we don't need to know for > > now. For each method call I need to check on this meta class. And here part > > of the problem starts. How to get that object? > > Can you explain in terms of the Groovy codebase what you mean by "the > Groovy speed problem"? I may be able to explain what we have done in > JRuby for similar situations. > > - Charlie >
I think the problem he's described is a general one, and the true #1 problem for dynamic languages on the JVM (vs the stuff JSR 292 deals with), and will remain a problem for JSR 292. Being dynamic, we all support some notion of: defining some function/method foo defining some function/method bar that calls foo allowing the user to redefine foo, either via repl interaction or runtime code loading users expecting bar to use the new definition of foo Thus we all, being in userland, have to go through a volatile or worse (on every call) in order to make such changes and ensure they are visible to all threads. It seems to me like we all could use some sort of global, cache- flushing safepoint call to make after these code updates (since they are so infrequent, especially in production), so our normal call paths could avoid the overhead (and inlining suppression) of volatiles. If you have any clever way around this in JRuby, please share. Thanks, Rich -- 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.
