On 10/02/2015 10:46 PM, Paul Sandoz 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.
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.
Spec allows for it but it can't happen for the same reason as unpark()
as it is based on Object monitors which can't vanish while in use.
David
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.
