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
