[jmm-dev] Optimizing external actions in the JMM
Nitsan Wakart
nitsanw at yahoo.com
Tue Jul 12 08:06:11 UTC 2016
>> The thing is you define:
>> "external action that... always returns 42 and has no other effect"
> I didn't mean to say that it "always returns 42 and has no other
> effect" by the spec, but that the compiler knows it "always returns 42
> and has no other effect" by some external knowledge it has about `f`
> (and perhaps the environment).
If the JIT compiler KNOWS, then it knows, job done. Same way it knows Math.pow is not external.
>> - Unsafe.get*(long address)/Unsafe.get*(null, long address): don't fullfil 1
> Under this interpretation the Unsafe.get*() intrinsics have a corner
> case -- if they're being called on a mmapped file (or uninitialized
> memory, even) then the value returned by them is not specified by the
> memory model (to be precise: whether a certain value returned by the
> call is correct is not decidable in the JMM). This hints that they
> need to be modeled as external actions; moreover, I think that (1)
> really means "*may* be observable" and not "*has to be* observable".
Where behaviour is undefined, it is down to precedent and sensibility... How is a 'read' "observable outside the execution"? Consider the following code:
----
long address = Unsafe.allocate(1024);
int i = 1;
Unsafe.putInt(address,i);
return Unsafe.getInt(address) == i; // might as well return true;
-----
More information about the jmm-dev
mailing list