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