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

[Vladimir Kozlov]

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