RFR(XS): 8233416: JFR: assert((((((klass)->trace_id()) & (((1 << 1) << 8) | (JfrTraceIdEpoch::in_use_this_epoch_bit()))) != 0))) failed: invariant

Erik Gahlin erik.gahlin at oracle.com
Thu Nov 7 13:28:43 UTC 2019


Looks good.

Erik

On 2019-11-06 14:58, Markus Gronlund wrote:
> Greetings,
>
> Please review this changeset:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233416
> Webrev: http://cr.openjdk.java.net/~mgronlun/8233416/webrev01/
> Testing: jdk_jfr
>
> Summary:
> In debug builds, an assertion located in the code involved in traceid tagging, USED_THIS_EPOCH(klass), gives intermittent false positives.
> The reason is that the traceid bits are untagged at the point of the initial load (SHOULD_TAG(klass)), and a subsequent load as part of setting updated bits finds the traceid bits to be tagged already.
> The artifact is correctly tagged but the absence of a load barrier allows the bit pattern from the initial load to be compared against the expectation (that is, not loading it again), and the assertion traps.
> More details in the bug.
>
> As we now have a top level predicate SHOULD_TAG(type) which did not exist pre-streaming, instead of adding a DEBUG_ONLY(OrderAccess::loadload();), we remove the check in the set_bits(), delegating this to SHOULD_TAG.
>
> Thanks
> Markus
>


More information about the hotspot-jfr-dev mailing list