[concurrency-interest] Running ForkJoin framework on J9 virtual machine

Andrew Haley aph at redhat.com
Fri May 15 07:39:11 EDT 2009

Doug Lea wrote:
> This makes it
> hard for us to put out preliminary (jsr166y) versions
> of upcoming classes that rely on and extend the underlying JVM
> support that cannot be guaranteed to work until (here, Java7) platform
> release.
> There are internal workarounds for this that I could use
> in ForkJoin classes that would cost a little more. But
> without any kind of "#ifdef J9" construction
> available, I don't know how to release these in jsr166y
> form. In the mean time, one workaround that is correct but
> needlessly heavy is to replace setOrderedX methods with
> setXVolatile in sources and rebuild.

For evaluation, surely it's easiest just to produce a native version of
the unsafe methods.  Any VM that has the intrinsics will use them,
and will fall back to the native versions only if they're missing from
the VM.

OK, that's not much use for benchmarking, but it'd work.


More information about the Concurrency-interest mailing list