Fwd: [jvm-l] request for advice: safepoints in the JSR 292 spec

[John Rose]

I started a thread on Google Groups to get more advice on safepoint-based invalidation, which the EG is naming MutableCallSite#sync.

http://groups.google.com/group/jvm-languages/browse_thread/thread/9c9d3e84fc745676#

Please have a look and respond if you have any insights...

-- John

Begin forwarded message:

From: John Rose <john.r.rose at oracle.com>
Date: December 9, 2010 4:01:21 PM PST
To: jvm-languages at googlegroups.com
Subject: [jvm-l] request for advice: safepoints in the JSR 292 spec
Reply-To: jvm-languages at googlegroups.com

Hi everyone.  On behalf of the JSR 292 EG, I'd like to ask for advice from language implementors on a deep point in our specification.

For many months, the JSR 292 EG has been thinking about safepoints as an informal paradigm for thread-safe invalidation of dynamic call sites.  Specifically, we need to define a mechanism to force a global update through a mutable call site, and we want a mechanism that is narrowly targeted.  The narrow targeting is especially important for those of us who write JITs for machines with unusual memory architectures.

...

Here's the draft language for MutableCallSite#sync:
  http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-1209/java/dyn/MutableCallSite.html

So the question of the day is:  Will this really work?  In order to work, the specification has to (a) make logical sense in the terms of the JMM, (b) be reasonably implementable by JVMs, and (c) be useful to programmers.  Indeed, that's a tall order, but I think the above language meets all three requirements.  The JSR 292 EG would deeply appreciate anyone pointing out flaws in this reasoning.

Best wishes,
-- John

P.S.  If this pattern works, we are likely to apply variations of in two other places in the 292 spec, ClassValue and Switcher.  See the draft javadoc for details.  Cliff Click has pointed out that a generalized optimization on volatile variables would have about the same effect.  Perhaps this is what JVMs will be doing routinely in five years, but the 292 API needs this pattern in only a few set places, and so the EG is content to roll it out in a limited way right now.

P.P.S. This is probably the biggest issue which is preventing us from finalizing JSR 292.  Please see the items marked "PROVISIONAL" in the draft javadoc if you are curious about what's left to clean up.  The bleeding edge draft of 292 is always at http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm .

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101209/62cada43/attachment.html