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

[Jean Christophe Beyler]

Thanks Tobias and Vladimir,

It passed the submit repo so I pushed it.

Thanks again,
Jc

On Wed, Apr 3, 2019 at 11:42 PM Tobias Hartmann <tobias.hartmann at oracle.com>
wrote:

> Looks good to me too.
>
> Best regards,
> Tobias
>
> On 03.04.19 19:26, Vladimir Kozlov wrote:
> > Looks good. Please, run submit testing before push.
> >
> > Thanks,
> > Vladimir
> >
> > On 4/3/19 10:13 AM, Jean Christophe Beyler wrote:
> >> Hi Vladimir,
> >>
> >> Sounds good to me:
> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8221853/webrev.02/
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221853
> >>
> >> I cleaned it up a bit and renamed it to "update_compile_perf_data" let
> me know what you think,
> >> Jc
> >>
> >>
> >> On Wed, Apr 3, 2019 at 9:37 AM Vladimir Kozlov <
> vladimir.kozlov at oracle.com
> >> <mailto:vladimir.kozlov at oracle.com>> wrote:
> >>
> >>     Hi Jc,
> >>
> >>     I agree with removal of print_last_compiled() method and related
> code.
> >>     But you need to keep part of set_last_compiled() code (guarded by
> UsePerfData) which set
> >> values of CompilerCounters. It
> >>     is used.
> >>
> >>     Thanks,
> >>     Vladimir
> >>
> >>     On 4/3/19 9:05 AM, Jean Christophe Beyler wrote:
> >>      > 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
> >> <mailto:tobias.hartmann at oracle.com>
> >>     <mailto:tobias.hartmann at oracle.com <mailto:
> 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
> >>
> >>
> >>
> >> --
> >>
> >> Thanks,
> >> Jc
>


-- 

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