On 02/10/2015 08:46 PM, David Holmes wrote:
This time really adding Doug Lea :)
I don't have very strong opinions about this. Placing
park/unpark in Thread was our initial (circa 2000)
proposal, so in that sense it's ideal, and in principle
easily done by relaying LockSupport.{park/unpark} to Thread.
But we have over time also exploited the current setup
in a couple of cases to independently deal with Unsafe
access to park and parkBlockers. These can be changed,
although doing so while remaining performance-neutral
will take some thought. (Which is similar to all the
other cases where we'd like to replace Unsafe usages
with VarHandles etc. I'm trying to keep up the attitude
that this is not merely a nuisance, but an opportunity to
revisit and improve implementations :-)
Logistically, we'll somehow cope: At some point our main 166
sources will need to be split into jdk8 vs jdk9 versions.
-Doug
On 11/02/2015 11:43 AM, David Holmes wrote:
Adding Doug Lea.
On 11/02/2015 12:51 AM, Paul Sandoz wrote:
On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hega...@oracle.com>
wrote:
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.
Yes.
Right and for that reason jsr166 distribution would not want to have to
know whether to use Thread or Unsafe.
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 ?
Yes, j.l.Thread seems like the ideal location :-)
I don't see any point in moving it to Thread now. The public supported
API already exists in LockSupport. As I said you'd have to deprecate it
in 9 with an intent to remove in 10 - assuming you are even allowed to
do that.
The issue is not LockSupport versus Thread, but the use of Unsafe.
David
Paul.