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

> Hi David,
> 
> On Feb 10, 2015, at 1:02 PM, David Holmes <david.hol...@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.hol...@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.
> 

Reply via email to