JEP 193: Enhanced Volatiles
forax at univ-mlv.fr
Thu Mar 6 09:22:49 UTC 2014
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
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.
>>> Regards, Peter
>>>>> 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
>>>>> 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.
More information about the core-libs-dev