Chuck, On 9/15/15 3:06 PM, Caldarale, Charles R wrote: >> From: Yilong Li [mailto:yilong...@runtimeverification.com] >> Subject: Re: RV-Predict bugs > >>> True, but as Mark previously pointed out, no one cares. All that happens >>> in that case is the object is redundantly created and then garbage >>> collected later; no damage. > >> No, it's not right. It's possible (although very unlikely) that this method >> could return null and results in a null pointer exception later. > > Again, that cannot happen; see below. > >> Intra-thread semantics says that event 3 (the first read of the field >> hashCode) happens before event 4 (the second read of field hashCode) but it >> has no effect on the value event 4 can see (because event 3 is also a read >> rather than a write). > > You're mixing up inter- and intra-thread semantics and completely > ignoring the write to hashCode when the initially observed value is > zero. Intra-thread semantics require that operations occur in > program order, so the initial zero (or null) check results in a > non-zero (or non-null) write to the field of interest; control flow > cannot be ignored here. If your supposition were correct, a compiler > (or CPU) would be free to migrate actions dependent on a conditional > block to a spot prior to that conditional block - clearly that is > nonsense.
I haven't read much about this in many years, but when I was reading everything surrounding the whole DCL debacle years ago, I discovered that within a synchronized block, the JIT is allowed to re-order statements if it determines it is safe to do so -- and that statements that occur before the memory barrier must not be interleaved with statements inside the block, and likewise, nothing after the block can be moved "inside" that block. I'm not sure what that means these days (years later, with changes to the JMM (which are presumably backward-compatible) and lots of other things) and I'm not sure if/how that affects code that has no synchronized block. But it seems reasonable that the JIT would be allowed to perform some otherwise "conditional" code execution *before* the condition is actually evaluated, as long as that code doesn't have any side-effects (such as assignment of the return value of, say, hashCode() or StringManager.getString()). The JIT is free to "waste" the CPUs time on a bet that the conditional branch will be reached, but can discard that work if the conditional branch is skipped. I'm sure the rules for "side-effects" include calling methods not yet proven to have any side-effects which might be a giant rathole that nobody has decided to jump into, and therefore method calls are always considered "side effects" just to keep things safe and simple. -chris
signature.asc
Description: OpenPGP digital signature
