> Doug Lea wants the HotSpot work for JSR-166 to not fall off our radar.
> JSR-166 is NOT the New Memory Model, that's already come to pass.
> JSR-166 is bunch of things that build on the New MM to allow highly
> concurrent abstract data types. He needs a reference implementation
> to get the changes approved and "we're it".
>
> In particular he needs:
> (2) TryLocks, under any ol' ABI. He need to be able to test algorithms
> before coming up with some final syntax. For us, it's exposure to
> the lightweight locking test (the FastLockNode in the optimizer).
> We can invent a magic function name which we inline and stick it
> in Unsafe or whatever.
> JSR-166 is NOT the New Memory Model, that's already come to pass.
> JSR-166 is bunch of things that build on the New MM to allow highly
> concurrent abstract data types. He needs a reference implementation
> to get the changes approved and "we're it".
>
> In particular he needs:
> (2) TryLocks, under any ol' ABI. He need to be able to test algorithms
> before coming up with some final syntax. For us, it's exposure to
> the lightweight locking test (the FastLockNode in the optimizer).
> We can invent a magic function name which we inline and stick it
> in Unsafe or whatever.
- duplicates
-
JDK-4904703 Need support for JSR-166 in VM
-
- Resolved
-