Way to count run-time numbers

David Holmes david.holmes at oracle.com
Mon Feb 5 07:18:44 UTC 2018


On 5/02/2018 4:39 PM, Manas Thakur wrote:
> Hi David,
> 
>>>>> 1. Number of locks acquired
>>>>
>>>> Do you mean Java level monitors or internal VM Mutexes (or Monitors). Do you mean number of distinct lock instances or the number of times a "lock" has succeeded?
>>> I mean the Java level monitors. Essentially, the number of times a ‘monitorenter’ instruction is executed by all threads in the program during execution. Anything is fine: number of times it succeeds or including spinning etc.
>>
>> No, there's nothing that would give that information.
> 
> 
> Oh I see. I don’t know how difficult would that be, but does it sound doable to insert an explicit counter while generating the code, may be just for a specific JIT compiler, say in the Ideal IR of C2? Are you aware of any profiler that could help me?

The JIT folk would have to answer that in detail, but you'd need 
instrumentation in the interpreter as well.

I don't know if JFR may be useful here.

Cheers,
David
-----

> 
>>>>> 2. Number of null-checks inserted
>>>>
>>>> Inserted by what? The Java source compiler may add some explicit null checks, but most are implicit in the semantics of the bytecodes. Then the JIT does what it can to elide unnecessary null-checks.
>>> Sorry; ‘inserted’ should be replaced with ‘executed’. I could find the place (in the OpenJDK source code) where the JIT compiler (C2) removes unnecessary null-checks (explicit as well as implicit in the Bytecode). I would like to count the number of times the remaining ones are executed during execution.
>>
>> Again no. Most compiled "null checks" are not actual tests "if (ptr == NULL)" but rather the code assumes it is not null and then if we hit a SEGV doing the access we determine that it was actually null and so throw NullPointerException.
> 
> 
> Okay; I recall this is how the JVM treats implicit null-checks (optimistically assuming and then reconstructing the stack-trace when there is a SEGV).
> 
> Anyway, thanks for the reply.
> 
> Regards,
> Manas
> 


More information about the hotspot-dev mailing list