FTR... Comments by Doug. -- John Begin forwarded message:
From: Doug Lea <d...@cs.oswego.edu> Date: October 2, 2010 7:10:47 AM PDT To: John Rose <john.r.r...@oracle.com> Subject: Re: is there a fence for this? On 10/01/10 17:56, John Rose wrote: > I'm beginning to think that both mutable invokedynamic call sites and cached > meta-classes are instances of the same pattern, a "stable value", which the > JVM does not support well. But JSR 292 can supply a new hook, if JSR 166 > does not already. We (JSR166) don't have anything directly applicable. Here are a few thoughts. Feel free to relay any or all of this to jvm-languages list. Memory-model-wise, I suppose you'd classify this as a weird form of "Release consistency": Readers running between releases are allowed to act as if values do not change. Here, the release points correspond to epochs, and we assume that there is some sort of sync so that writers don't interfere with each other upon setting up new epochs. And possibly (but, I suspect, not necessarily) a full all-thread r/w barrier upon epoch advance. But the main twist on release-consistency is that reader-sync may (or may not) entail new code generation. In principle, this could be addressed with scoped fences. (as in the ones at http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html) Note: I suspect that the Fences API won't make Java7. It wasn't in our recent jsr166/openjdk integration. Due to the combination of mismatches with existing JLS ch 17 specs (which would need even more revisions/fixes than they already do) and the continual moral hazard complaints -- i.e., arguments that the world is better off if the only people using them are those who can so do via Unsafe. Scoped fences map pretty well to release consistency (as well as to most others), and so ought to apply here. (As a thought experiment, consider an implementation of even ordinary fences that might involve code regeneration on some forms of updates.) Still, the actual APIs would probably need some adaptation if only because there is no Java notion of the associated scope/epoch. And pragmatically, you'd want these fences to be treated very specially anyway. I think you'd only need one or two forms (not the usual three), mainly (using made-up Epoch type): orderReadsByEpoch(Epoch e); and maybe (but probably left for JVM-internal use only) orderWritesByEpoch(Epoch e) with specs similar to plain orderReads/orderWrites. Interestingly enough, the similarities appear to overlap those wrt "freeze" actions described (with bugs) in JLS sec 17.5 (http://java.sun.com/docs/books/jls/third_edition/html/memory.html) that do not have an independent implementation in any JVM (but could be). "Freezes" are an attempt to provide an account of some final-field oddities. Beware that there are unexpected but allowed behaviors with not-really-final final fields, that may also be shared by epoch-based control. Given the above, "stable" would not be my favorite term for this mode. Also, my experience with trying to use per-variable type-qualifier-like or magic-type/class notions in Java (as in your "StableValue") to map to fences is not very positive. Even "volatile" and "final" are problematic. On the other hand, it is fine, and often preferable to only get fences as parts of special-mode accesses. You implicitly do this in methods like "getStableValue", but doing it only per-access leads to the usual problems we face in not being able to efficiently support l-value operations. (Aside: A different solution to this will probably eventually be part of X10 spec: using flavored blocks for fence control. As in finish { p = x; } f = p.f // volatile-style field read I wish there were some syntax holes for this sort of thing in Java....) Which leads me at the moment to suggest just adding one or two fence-like methods for epochs. -Doug -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-langua...@googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
