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