I don’t understand your transformation. foo is certainly a class member. I
thought bar was a local variable, thus inaccessible to anything outside the
method and thread being executed. Your transformation makes them look like
they are the same kind of thing?
I’m also not quite sure where the “rematerialization” chuck mentions is
happening, although I don’t know what it is exactly. I’m also not seeing why
this transformation couldn’t be done by a JIT compiler rather than the cpu.
My uneducated mental model of the original is
int foo (memory)
load foo into register r1
if r1 == 0 {
write 42 into r1
store r1 to foo
}
load foo into register r2
return r2
so the optimizer thinks, hmm, lets do all the loads at once to increase the
chances that the cache won’t have to be reloaded…. flip a coin and pick r2 to
load first….. hmm, we might be changing the value so we’ll update r2 if we do.
int foo (memory)
load foo into register r2
load foo into register r1
if r1 == 0 {
write 42 into r1
// better update r2 also
copy r1 into r2
store r1 to foo
}
return r2
Is there some reason the JIT compiler can’t do this transformation? I don’t
see how in-processor optimizations apply nor do I see how LLVM rules apply. I
thought JIT behavior was only controlled by what the JLS said.
Still hoping to learn more…
david jencks
> On Sep 16, 2015, at 4:50 AM, Mark Thomas <ma...@apache.org> wrote:
>
> On 16/09/2015 06:38, David Jencks wrote:
>> At this point I tend to agree with Ylong and Jeremy. I’m very far
>> from being an expert but I thought 14.2 meant that the result of
>> execution of a single thread had to be the same as if it executed the
>> given instructions in the order supplied. I didn’t think it meant it
>> had to execute those particular instructions, I thought it could pick
>> whatever instructions it wanted as long as the result would be the
>> same as if the given instructions were executed in the given order.
>> If there’s only one thread, Jeremy’s transformed code obviously
>> produces the same result as the original. To me saying it ‘has
>> different logic” and “has a timing window” might be true but don’t
>> directly mean that if violates the ch. 14 semantics.
>>
>> Hoping to learn more….
>
> Same here. I'm finding this discussion extremely useful. I'm not trying
> to find reasons to dismiss or minimise the bugs reported by RV-Predict.
> You'll notice that, with one exception that I currently believe is a
> false positive, that all the bugs have been fixed. And if the basis for
> declaring that issue false positive is found to be faulty it will get
> fixed too.
>
> I am trying to better understand a) exactly what the issue is and b) how
> likely the issue is. That requires an understanding of both the theory
> (JLS/JMM) and how the theory is applied in practice to produce a JVM.
>
> To re-cap. The assertion is that
>
> ===
>
> String foo;
>
> doSomething() {
> if (foo == null) {
> foo = calculateNewValue();
> }
> return foo;
> }
>
> ===
>
> can be transformed (by the complier?) to
>
> ===
>
> String foo;
> String bar;
>
> doSomething() {
> bar = foo;
> if (foo == null) {
> foo = calculateNewValue();
> bar = foo;
> }
> return bar;
> }
>
> ===
>
> Ignoring re-ordering this transformation creates an obvious concurrency
> issue (foo is changed from null to non-null after its value is copied to
> bar and before foo is tested for null).
>
> The questions I have are:
>
> 1. Is such a transformation legal? I assume the answer is yes but I've
> been struggling to find the language in the JLS that permits this. Is it
> 17.4 "An implementation is free to produce any code it likes, as long as
> all resulting executions of a program produce a result that can be
> predicted by the memory model."?
>
> 2. Why would something make a transformation like this? This brings us
> back to the question of theoretical issues vs. practical issues which
> helps us judge the severity of any given issue.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
