Rich and Jochen, Part of your needs might be met by Doug Lea's proposed Fences API [1] [2] for JDK7 by allowing an explicit volatile write (with the appropriate memory barriers), without incurring the overhead of a volatile read on each access. This fence could be used when a new method/function is registered, while all the lookups would be regular reference field accesses. The recent discussion of Fences and impacts to the Atomic* classes [3] might also be of interest as well since potential updates to the atomic field updaters could help build the functionality you desire.
[1]: http://cs.oswego.edu/pipermail/concurrency-interest/2009-January/005743.html [2]: http://g.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html [3]: http://cs.oswego.edu/pipermail/concurrency-interest/2010-April/006990.html Thanks, Dave On Tuesday, April 20, 2010, Rich Hickey <[email protected]> wrote: > > > 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. > > -- 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.
