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