Unsafe.park/unpark, j.u.c.LockSupport and Thread

[Paul Sandoz]

On Feb 11, 2015, at 2:43 AM, David Holmes <david.holmes at oracle.com> wrote:

> Adding Doug Lea.
> 
> On 11/02/2015 12:51 AM, Paul Sandoz wrote:
>> On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>> 
>>>> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.
>>> 
>>> Right. And I suspect that the separate distributable of 166, outside of the Java Platform, would not want to have to carry a separate platform specific native library.
>> 
>> Yes.
> 
> Right and for that reason jsr166 distribution would not want to have to know whether to use Thread or Unsafe.
> 

And that's why it should just be the former for the Java 9 platform and beyond.

The general strategy is to reduce dependency on Unsafe, including for 166 classes. The VarHandles effort is part of that strategy to replace Unsafe enhanced access with a public alternative that is safe and just as performant.


>> 
>>> 
>>>>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>>>>> 
>>>> 
>>>> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?
>>> 
>>> Would you be thinking of making the changes public, i.e. new standard API on java.lang.Thread ?
>>> 
>> 
>> Yes, j.l.Thread seems like the ideal location :-)
> 
> I don't see any point in moving it to Thread now. The public supported API already exists in LockSupport.

Yes, but as i said the point is to tease apart the internal dependencies between the platform and LockSupport class. (A simple solution is to copy and rename this class to java.lang.ThreadSupport :-) .)


> The issue is not LockSupport versus Thread, but the use of Unsafe.
> 

It's because LockSupport uses Unsafe to access non-public fields of Thread, and i also want to break that internal dependency.

I presume that LockSupport was created because agreement was not reached to add such core *thread*-based functionality to Thread. I dunno why such agreement was not reached, but so far i am not hearing any compelling technical reasons.

Paul.

<snip>
> As I said you'd have to deprecate it in 9 with an intent to remove in 10 - assuming you are even allowed to do that.
> 

Opinions differ but i think we should be more serious about removing stuff that has been marked deprecated for one major release if the intent to do so is made clear when deprecating.