Change how TR_IPBCDataCallGraph entries are persisted into SCC

[mpirvu]

Before this change, each TR_IPBCDataCallGraph entry that is persisted can contain
up to 3 ROMClasses and their associates sampling frequencies. When loading from
SCC we need to convert from a ROMClass to a RAMClass. This is done with the
help of the matchRAMclassFromROMclass() frontend method, which first tries
the classloader of the method being compiled and then the bootstrap classloader.
If none of these attempts is successfull, we store NULL into the IProfiler entry
which is created from the SCC entry.

In this commit we change the mechanism to convert from a ROMClass to a RAMClass,
to match the mechanism that is used in AOT relocation records. Specifically, the
new code is using the mechanism that associates a classloader with the first class
that is loaded by that class loader (see ClassLoaderTable.cpp).
Thus, the IProfiler entry stored in SCC needs to contain two values now:
(1) The classchain for the class that is being traked and
(2) The classchain for the first class loaded by the classloader that loaded the class
being tracked.
Since in the new implementation we store more information, we will only track one
target class instead of 3.

This change is improving the throughput of some applications that rely on IProfiler
information stored in SCC.

Depends on eclipse-omr/omr#6638

Signed-off-by: Marius Pirvu mpirvu@ca.ibm.com

[dsouzai]

Overall looks ok to me.

Do you think it's worth having the verbose logging be printed to the vlog? As it stands, the only way to get this info is to rebuild.

[dsouzai]

Suggested change

	fprintf(stderr, "loadFromPersistentCopy: Cannot convert ROMClass to RAMClass. Cannot get the class chain of ROMMethod\n");
	fprintf(stderr, "loadFromPersistentCopy: Cannot convert ROMClass to RAMClass. Cannot get the class chain of ROMClass\n");

[dsouzai]

Also looks like there's a missing copyright update.

[mpirvu]

Fixed copyright message.
I don't have a feel for how often we are going to use those verbose messages. I would need to add a new verbose option in OMR before continuing with this PR.

[mpirvu]

Addressed review comments

[dsouzai]

jenkins test sanity.functional all jdk17

[mpirvu]

Tests have passed

[AlexeyKhrabrov]

The test failure with the "Shared cache pointer out of bounds" assertion reported in #15609 appears to be the same race condition as discussed in #12405 and #12550. TR_J9SharedCache::offsetInSharedCacheFromPointer() is not safe to call for the result of a recent call to rememberClass(). I think this should be fixed.