RFR (S) 8221853: Data race in compile broker (set_last_compile)

[Jean Christophe Beyler]

Hi Tobias,

Sounds good to me, here is a webrev that removes it entirely:

Webrev: http://cr.openjdk.java.net/~jcbeyler/8221853/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8221853

Let me know what you think,
Jc

On Wed, Apr 3, 2019 at 4:17 AM Tobias Hartmann <tobias.hartmann at oracle.com>
wrote:

> 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
>


-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190403/2d1ca566/attachment.html>