> 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:
> (3) Non-nested locks for ConditionVariables. This would have been tough
> EXCEPT such access already exists in the Unsafe class. Naturally we
> must inflate such locks on the spot (as the backing stack store will
> disappear when we exit), but this is OK because the expected usage
> for these locks is to actually block.
> 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:
> (3) Non-nested locks for ConditionVariables. This would have been tough
> EXCEPT such access already exists in the Unsafe class. Naturally we
> must inflate such locks on the spot (as the backing stack store will
> disappear when we exit), but this is OK because the expected usage
> for these locks is to actually block.
- duplicates
-
JDK-4904703 Need support for JSR-166 in VM
-
- Resolved
-