RFR (S) 8221853: Data race in compile broker (set_last_compile)
Tobias Hartmann
tobias.hartmann at oracle.com
Wed Apr 3 11:17:31 UTC 2019
Hi Jc,
I would actually prefer to just remove this unused code if no one objects.
Best regards,
Tobias
On 02.04.19 18:52, Jean Christophe Beyler wrote:
> Hi all,
>
> While working on enabling Java TSAN, one non-goal is that if we let it do its work, it does thread
> sanitizing on the JVM. Though this is a non-goal, I saw this one pop up and wanted to know if you
> would like it cleaned up?
>
> Webrev: http://cr.openjdk.java.net/~jcbeyler/8221853/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8221853
>
> I'm not sure the webrev is the way you'd like to go but from what I can see:
>
> - This is benign as no one was using the data being raced
> - No one calls print_last_compiled, which uses data only set in set_last_compiled
> - Because it is debug, the whole code could be wrapped into non product builds
> - I did add a compile lock for both the printout and the set_last but I could make a new lock
> just for this code instead of using the general compile lock.
>
> Thanks and let me know,
> Jc
More information about the hotspot-compiler-dev
mailing list