RFR (XS) 8209802: JFR failed to build when certain garbage collectors are disabled (original) (raw)

Thomas Schatzl thomas.schatzl at oracle.com
Thu Nov 8 08:15:15 UTC 2018

Hi Derek,

some comment in JIRA I accidentally came across that may be helfpul:

On Thu, 2018-11-01 at 16:05 -0700, Derek Thomson wrote:

>

[...]

Thanks for the review! Comments inline. And new webrev at http://cr.openjdk.java.net/~jcbeyler/8209802/webrev.01/ [...] > - in jfr.cpp, I would prefer the ifdef's completely removed the > TRACEREQUESTFUNC(G1HeapRegionInformation), if possible. > Otherwise, I think it is better to remove starting from the body of > this method.

Sorry, did you mean jfrPeriodic.cpp? In which case not sure what method you mean here. Can you clarify for me please? > - in jfrType.cpp the question is if compiling without g1 could

Yes.

> remove the entire declaration of G1HeapRegionTypeConstant. > > Cc'ing hotspot-jfr-dev at openjdk.java.net as the jfr devs might have > an idea how to accomplish that.

Sure.

There has been an answer how to do this (I believe :)) in the comment for this CR at https://bugs.openjdk.java.net/browse/JDK-8209802?focusedCommentId=14221326&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14221326

"The preferred way is to have the JFR type constant registrations repatriated to their natural origin. The registration mechanism now supports dynamic registrations, where it originally only had static means to register.

The ZGC JFR type constants can be referred to as precedents, see:

ZStatisticsCounterTypeConstant ZStatisticsSamplerTypeConstant "

Hth (and does not confuse too much), Thomas

More information about the hotspot-gc-dev mailing list