question about PrintOptoStatistics atomicity

[Vladimir Kozlov]

It was done intentionally because when that code was implemented atomic operations were expensive.
We never intended these counters to be precise - they were used mostly for debugging purpose.
It is up to user how he want to use them - for example using only one C2 thread.
When you collect data for general application you want to execute it with the same parameters as in production. I don't 
think we should enforce any restrictions in VM when PrintOptoStatistics is used.

Regards,
Vladimir K

On 7/15/20 8:31 AM, Liu, Xin wrote:
> Hi,
> 
> 
> I have a question about -XX:+PrintOptoStatistics in c2_globals.hpp.
> 
> It dumps many internal counters in different C2 phases.  I found those counters are all static fields.
> 
> eg.
> 
> http://hg.openjdk.java.net/jdk/jdk/file/4b9ced2b948c/src/hotspot/share/opto/chaitin.cpp#l2297
> 
> http://hg.openjdk.java.net/jdk/jdk/file/4b9ced2b948c/src/hotspot/share/opto/phaseX.hpp#l599
> 
> 
> I notice that all setters of those fields are not atomic. IMHO, hotspot may has more than one c2-compiler-threads running at the same time.
> 
> How does hotspot guarantee those fields are thread-safe? or the flag intends to do statistics in single-thread mode by design?
> 
> 
> If those counters are not atomic, shall we connect this flag to CICompilerCount?
> 
> I think we can constrain the number of c2-compiler-thread to 1 if user set PrintOptoStatistics. Does it make sense?
> 
> 
> thanks,
> 
> --lx
>