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

[Chris Hegarty]

On 10 Feb 2015, at 12:46, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi David,
> 
> On Feb 10, 2015, at 1:02 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> Hi Paul,
>> 
>> When we added j.u.c there was reluctance to add these methods to Thread - this was the normal policy (for the time) of don't touch the core classes. So LockSupport is the public API and Unsafe was chosen as the implementation as it is a de-facto interface to the VM from JDK code rather then defining explicit native methods (I must admit I'm unsure why we went this route rather than simply hooking into jvm.cpp with JVM_park/JVM_unpark. I think in many ways it was/is just easier to call an Unsafe method and define a new unsafe.cpp native call. Plus we had a bunch of other Unsafe API's being used from j.u.c.)
>> 
>> So we can't just move things from LockSupport to Thread as we'd need to deprecate first etc etc.
> 
> I was thinking that the implementation of LockSupport could be updated to use any new stuff we could add to java.lang.{*, Thread}.
> 
> I am trying to tease apart the internal dependencies that 166 classes have on the platform. In the case of LockSupport there are two, Unsafe and Thread.
> 
> 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.

>> 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 ?

-Chris.

>> Aside: this is where the infamous "spurious wakeup" from park() can arise. If you just randomly unpark() a Thread there is nothing to guarantee that the thread doesn't terminate and free its native resources while you are working on it. But the ParkEvents are type-stable-memory, so even if the event has been disassociated from the target thread you can still call unpark() as it is never freed. However if that ParkEvent has since been reused by another thread, then that thread will encounter a "spurious wakeup" if it calls park().
>> 
> 
> I see, and can the same happen for Object.wait as well? I gather so from the documentation.
> 
> 
> On Feb 10, 2015, at 1:04 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Oh I just realized/remembered why we use Unsafe for this - it is because of the potential for intrinsics.
> 
> I can certainly imagine it's convenient place to put things in that regard.
> 
> Paul.
>