Question about trace-IDs

[Roman Kennke]

Hi Markus,



> Thanks for noticing some staleness here - remnants from having used
> different atomic increment logic(s) in the past.
> 
> You can initialize all counters to 0, and also let LAST_TYPE_ID be
> used as-is without the + 1.
> 

Thanks for confirming this!

While I'm at it, I could also replace the helper method atomic_inc()
and its uses with Atomic::add() which has the advantage that it uses
CPU instructions for atomic-add instead of a CAS-loop when the CPU has
such an instruction. WDYT?

Roman


> Thanks
> Markus
> 
> -----Original Message-----
> From: Roman Kennke <rkennke at redhat.com> 
> Sent: den 21 september 2020 12:39
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: Question about trace-IDs
> 
> Hello all,
> 
> While studying the code around JFR trace-IDs, I came about something
> that I find a little odd: trace-IDs for modules, packages and class-
> loaders start at 2, while trace-IDs for threads start at 1 (and
> classes at LAST_TYPE_ID+1). The static counters (for modules,
> packages and
> classloaders) are initialized at 1, and the first call to
> atomic_inc() increments this to 2 and this is the first value used. I
> understand that 0 is the uninitialized value, but don't see that 1
> has any special meaning.
> 
> See for example here:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp#L65
> 
> vs
> 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp#L60
> 
> Would it hurt to start counting trace-IDs for packages, modules and
> classloaders at 1 too? (If not, I'd like to submit a patch - I'm
> happy about something simple as my first contributions to JFR ;-) ).
> 
> Cheers,
> Roman
>