On Sun, Apr 25, 2010 at 5:05 PM, Jochen Theodorou <[email protected]> wrote: > This depends on what exactly you need. For Groovy I was thinking about > something like this: > > - guard in a invocation > if (invalid) { > replace this callsite > } else { > target.invoke > } > > - after meta class change > for (callsite : relevantCallsites) { callsite.invalid = true } > > bootstrap would still be something like the above. Since "invalid" is a > boolean I don't have to fear partially initialized objects and since I don't > need instant publication of the new value, I can let the change ride piggy > back on another memory barrier. That means the call site will be recognized > as invalid eventually at a later time. > > But in this pattern I have the next problem. If the call site is not > immutable, then I have again to use synchronization or something similar and > the total win is again zero.
JRuby used to actively invalidate call sites, but the synchronization issues were a major headache. I didn't spend a lot of time researching it, but it did not appear to be possible to invalidate a mutable call site without introducing some kind of lock, which is obviously not an option for a fast call site. The JDK7 way could work, however, if the invalidation resulted in a call site being totally inaccessible. In-flight code would use it as though it had not been invalidated, and new calls would re-bootstrap. But it still comes down to a primary question: * How quickly do you want all threads to see that a callsite is invalid? In JRuby right now it's expected that you are not going to be doing method table changes (class mutation) across running threads. So the poll from the callsite to the class is non-volatile. It's possible for a thread to not see that a class has changed right away (or following the memory model to the letter...it might never see it) if the change happens in another thread and nothing causes the appropriate flags to propagate to the current thread. It is, at some level, "piggy-backing" on other memory barriers. If you need the change to be visible immediately, I don't see any other way with Java5/6 than using volatiles. - 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.
