RFR(M/L): 7115356: assert(!m->was_never_executed()) failed

David Chase david.r.chase at oracle.com
Wed Sep 17 16:34:30 UTC 2014


Is the hypothesized race described anywhere?  I went and read the bug report and did not
see any explanation for what race we thought we saw, and also couldn’t convince myself
that the new code might not be vulnerable to the same (or similar) races.

For example
  { _counter += count_increment; }
might race badly with
_counter = counter;

as in

a: temp = _counter
b: _counter = counter
a: _counter = temp + count_increment

and the write by b is lost.

David


On 2014-09-17, at 10:05 AM, Nils Eliasson <nils.eliasson at oracle.com> wrote:

> Hi,
> 
> Please review this change. It started out as a bug fix and grew with some refactoring of invocationCounter.cpp/hpp and its uses.
> 
> The original problem was that an assert in compilationPolicy failed because a value that was just set could not be observed. Some code paths read the composite counters a part at a time and may observe and write inconsistent values when several threads are using them. While removing a few unnecessary read and writes of the 'state' field, I noticed the state and Action was actually never used. I removed it all and came up with much simpler code.
> 
> Major refactorizations:
> 1) Rewritten invocationCounter methods to read entire counter, manipulate and then write entire counter. 
> 2) Removed the state, and action - it was never used anywhere.
> 3) Moved invocation counter logic from simpleThresholdPolicy into invocationCounter.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-7115356
> webrev: http://cr.openjdk.java.net/~neliasso/7115356/webrev.06
> 
> This code might affect the logCompilation and replay tools since it changes the output. I will test and fix that before submitting. I will also do some performance testing to make sure I haven't messed up the counters in any way.
> 
> Thanks,
> Nils Eliasson 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140917/fd486ef5/signature.asc>


More information about the hotspot-compiler-dev mailing list