Thanks, David; that was a good pointer. Turning a volatile field into a normal one is good when it's possible.
For StableValue, I think there needs to be (a) a better guarantee of responsiveness to changes than normal fields provides, and (b) a clear path to optimizing the stable value as if it were "mostly constant" in the same sense that the bodies of not-yet-overridden virtual methods are "mostly constant" today. Does something like StableValue belong in the Fences API, I wonder? -- John On Apr 20, 2010, at 8:56 PM, David Schlosnagle wrote: > 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.
