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