RFR: 8241828: JFR: Some streaming tests require a larger heap size with ZGC

Erik Gahlin erik.gahlin at oracle.com
Tue Mar 31 10:46:13 UTC 2020



> On 31 Mar 2020, at 11:03, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> On 2020-03-31 10:43, Erik Gahlin wrote:
>> Doesn’t look good.
>> One problem is that TestChunkGap has TestFilledChunks in @run main. If you change it to TestChunkGap, that test should be fine.
> 
> OK. So we found an old bug lurking here. It's not the first time I see this kind of bugs. It would be nice if we could detect those @run copy-n-paste bugs.

I agree. 

If you omit the class in @run, jtreg should use the main method in the file. If there are multiple main methods, it should fail stating that it must be specified. 

> 
>> When it comes to TestFilledChunk, I can now see how this can happen due to events being sorted by default and the high rate events are emitted, You could try to sett s.setSorted(false), and it should be fine as well.
>>  63         try (EventStream s = EventStream.openRepository()) {
>>  64             try (Recording r1 = new Recording()) {
>> +65 s.setSorted(false);
>>  66                 s.setStartTime(Instant.EPOCH);
> 
> That seems to be the code in TestChunkGap, that now (after the fix above) works OK with ZGC. Do you have a similar fix for TestFilledCunk?

The above fix is for TestFilledChunk.

TestChunkGap should work after the change of @run, at least it does for me locally. 

Erik

> 
> Thanks,
> StefanK
> 
>> Thanks
>> Erik
>>> On 31 Mar 2020, at 10:08, Stefan Karlsson <stefan.karlsson at oracle.com <mailto:stefan.karlsson at oracle.com>> wrote:
>>> 
>>> Did some extra testing on TestChunkGap and G1:
>>> 
>>> With compressed oops:
>>> -Xmx300m : OOME
>>> -Xmx350m : Barely passes
>>> 
>>> Without compressed oops:
>>> -Xmx450m : OOME
>>> -Xmx500m : Passes
>>> 
>>> I issued a 'jcmd GC.class_histogram' in the middle of the run and got:
>>> 
>>> num     #instances         #bytes  class name (module)
>>> -------------------------------------------------------
>>>   1:       2473067      158635784  [Ljava.lang.Object; (java.base at 15-internal)
>>>   2:       2463224      118234752  jdk.jfr.consumer.RecordedEvent (jdk.jfr at 15-internal)
>>>   3:       4894598      117470352  java.lang.Integer (java.base at 15-internal)
>>>   4:           157       39960680  [Ljdk.jfr.consumer.RecordedEvent; (jdk.jfr at 15-internal)
>>>   5:        369731       18447144  [B (java.base at 15-internal)
>>>   6:        368815       11802080  java.lang.String (java.base at 15-internal)
>>>   7:           331         584344  [I (java.base at 15-internal)
>>> ...
>>> 
>>> Does this look right?
>>> 
>>> StefanK
>>> 
>>> On 2020-03-30 22:03, Erik Gahlin wrote:
>>>> Seems strange that the test would require over 512 MB. I would expect the TestChunkGap not to use a live set of more than 25 MB. The test only emits three events.
>>>> TestFilledChunks is easier to understand as it may emit millions of events. Still it must be a bug in JFR then, because it should not keep them around.
>>>> Erik
>>>>> On 30 Mar 2020, at 19:24, mikhailo.seledtsov at oracle.com <mailto:mikhailo.seledtsov at oracle.com> <mailto:mikhailo.seledtsov at oracle.com> wrote:
>>>>> 
>>>>> Hi Stefan,
>>>>> 
>>>>> I would recommend adding "@requires os.maxMemory > " to the test, to make sure that test does not execute on a host/node that does not have sufficient memory. E.g. "@requires os.maxMemory > 1G"
>>>>> 
>>>>> Otherwise the change looks good to me.
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Misha
>>>>> 
>>>>> On 3/30/20 4:07 AM, Stefan Karlsson wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> Please review this small patch to increase the max heap size of a couple of JFR streaming tests.
>>>>>> 
>>>>>> https://cr.openjdk.java.net/~stefank/8241828/webrev.01/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8241828
>>>>>> 
>>>>>> The default heap size is 512m when these tests are run. G1 uses almost 500m, but ZGC needs a bit more. I propose that we set the max heap size to 768m.
>>>>>> 
>>>>>> Thanks,
>>>>>> StefanK



More information about the hotspot-jfr-dev mailing list