JEP 193: Enhanced Volatiles

[Remi Forax]

On 03/06/2014 01:24 AM, David Holmes wrote:
> On 6/03/2014 3:22 AM, Remi Forax wrote:
>> On 03/05/2014 06:07 PM, Peter Levart wrote:
>>>
>>> On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
>>>> Brian Goetz wrote:
>>>>
>>>>> I suspect you were expecting this response: we don't add language
>>>>> semantics through annotations.
>>>> Technically, we're not adding language semantics. The JVM is the one
>>>> interpreting the annotations.
>>>
>>> And the JVM is the one implementing the language semantics (together
>>> with javac which feeds the JVM with bytecodes). Language semantcis are
>>> implemented by the combination of javac and JVM. If you say that this
>>> feature does not require any change to javac, you're just saying that
>>> you put all the burden on the JVM, but you *are* implementing the
>>> language semantics using annotations nevertheless...
>>
>> no, it's the other way around. javac maps Java the language to the
>> bytecode semantics.
>> The JVM only execute bytecodes.
>
> But if the JVM acts upon annotations to change how it executes those 
> bytecodes then, as Peter said, the JVM is implementing the language 
> semantics.

no, there is no bytecode in the proposal of Jeroen.
You can see it has an extended way to call in a VM intrinsic, currently 
in Hotspot, you have to provide the class name, the method name and the 
signature to consider a method as an intrinsic. The mechanism proposed 
by Jeroen is a little bit more general.
Moreover, the proposal is interesting because the signature of the 
native method is under the control of the user so unlike Unsafe 
equivalent the signature can be verified when the native method is 
linked making the method safer than their unsafe equivalent.

>
> It is also a bit misleading to say that the JVM only executes 
> bytecodes, as the semantics of those bytecodes were driven by the 
> requirements of the language. javac + jvm do form a team here.

Most of the bytecodes are standard opcodes, but you're right that some 
of them like method calls, instance creation or to a lesser extent 
get[put]Field/get[put]Static have the Java semantics bolt in, that's why 
we have invokedynamic (and Unsafe.get/put) BTW.

>
> David

Rémi

>
>>>
>>>
>>> Regards, Peter
>>
>> cheers,
>> Rémi
>>
>>>
>>>>> I'm not trying to frustrate you; evolving a language with millions of
>>>>> users is really, really hard.  And one of the things that makes it 
>>>>> hard
>>>>> is recognizing our intrinsic conflicts of interest between "what good
>>>>> will this do me" and "what harm will it do others."
>>>> I understand, that's why I want to avoid adding language support for
>>>> this niche/specialist feature.
>>>>
>>>> Regards,
>>>> Jeroen
>>>>
>>>
>>