Question about trace-IDs

[Markus Gronlund]

Hi Roman,

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