[GR-60079] JFR leak profiler span fixes

[roberttoyonaga]

Summary

Back when the original PR was integrated, we noted that there was probably a problem with how each sample's span was allotted, but we decided to match exactly what Hotspot was doing anyway. We were previously setting sample span to be the object allocation size. This is wrong because "span" is meant to represent all the allocations that span a period of time (even the ones that got removed from the queue due to GC). This is meant to have the effect of creating an even sampling representation of allocations over time, ex. if a sample's neighbors are removed from the list it should absorb their span and increase in importance so that its less likely to be removed itself.

Now that the fix is integrated in Hotspot (openjdk/jdk#19334), we should also add the fix in SubstrateVM.

I also fixed how totalInQueue is updated. Previously we weren't actually saving its updated size after adding samples to the queue.

[roberttoyonaga]

Hi @galderz, just mentioning you so it's on your radar.

[christianhaeubl]

Thanks for the fixes, this will be merged in the next few days.

[christianhaeubl]

@roberttoyonaga : this PR causes the following assertion failure in some multi-threaded test cases:

  A  SP 0x000071c8495ffc70 IP 0x00005c9145c4a2b3 size=48    com.oracle.svm.core.jfr.oldobject.JfrOldObjectSampler.remove(JfrOldObjectSampler.java:125)
  A  SP 0x000071c8495ffca0 IP 0x00005c9145c4a4e6 size=48    com.oracle.svm.core.jfr.oldobject.JfrOldObjectSampler.scavenge(JfrOldObjectSampler.java:103)
  A  SP 0x000071c8495ffcd0 IP 0x00005c9145c4a385 size=64    com.oracle.svm.core.jfr.oldobject.JfrOldObjectSampler.sample(JfrOldObjectSampler.java:81)
  i  SP 0x000071c8495ffd10 IP 0x00005c9145c488b9 size=16    com.oracle.svm.core.jfr.oldobject.JfrOldObjectProfiler.sample0(JfrOldObjectProfiler.java:93)
  A  SP 0x000071c8495ffd10 IP 0x00005c9145c488b9 size=16    com.oracle.svm.core.jfr.oldobject.JfrOldObjectProfiler.sample(JfrOldObjectProfiler.java:78)
  i  SP 0x000071c8495ffd20 IP 0x00005c9145ba2d5b size=48    com.oracle.svm.core.genscavenge.ThreadLocalAllocation.sampleSlowPathAllocation(ThreadLocalAllocation.java:552)
  A  SP 0x000071c8495ffd20 IP 0x00005c9145ba2d5b size=48    com.oracle.svm.core.genscavenge.ThreadLocalAllocation.slowPathNewInstance(ThreadLocalAllocation.java:230)

Not directly related to this PR but I am also seeing assertion errors if I only run a subset of the tests, e.g., via mx native-unittest TestOldObjectProfiler:

com.oracle.svm.test.jfr.oldobject.TestOldObjectProfiler#testEvictYoungest
java.lang.AssertionError
	at org.junit.Assert.fail(Assert.java:87)
	at org.junit.Assert.assertTrue(Assert.java:42)
	at org.junit.Assert.assertTrue(Assert.java:53)
	at com.oracle.svm.test.jfr.oldobject.TestOldObjectProfiler.validate(TestOldObjectProfiler.java:217)
	at com.oracle.svm.test.jfr.oldobject.TestOldObjectProfiler.testEvictYoungest(TestOldObjectProfiler.java:120)

Can you look into these failures?

[roberttoyonaga]

Hi @christianhaeubl, yes ok I'll investigate what is happening there

[roberttoyonaga]

@christianhaeubl

I've created PR fixing the issues you identified: #10190

The reason for the assertion failure is an incorrect assumption made by the assertion. The span fix in this PR causes the error to manifest, it was probably hidden before because span was allotted incorrectly.

When running the TestOldObjectProfiler test in isolation, this assertion fails TestOldObjectProfiler.validate(TestOldObjectProfiler.java:217) when it tires to verify the sample's JfrTick allocation time. This only fails when tested in isolation because JfrTicks has not yet been initialized. When running all the tests together with mx native-unittest JFR gets initialized in a prior test.