[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: Unsafe.park/unpark, j.u.c.LockSupport and Thread
From:       Doug Lea <dl () cs ! oswego ! edu>
Date:       2015-02-11 11:33:05
Message-ID: 54DB3DF1.5010409 () cs ! oswego ! edu
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]