On Sat, 3 Apr 2021 04:09:53 GMT, Hui Shi <h...@openjdk.org> wrote:
>> …ue to large TLAB size
>>
>> serviceability/jvmti/HeapMonitor tests intermittently fail when using
>> PS/Serial GC, original test has implicit assumptions on TLAB size and
>> depends on allocate fix amount of objects to consume TLAB and trigger object
>> sampling. These tests will fail if TLAB is above 20M (this can easily happen
>> when using PS/Serial GC and heap is large), when allocation can not consume
>> current TLAB and _byte_until_sample.
>>
>> Fix in tests is adding an explicit GC to consume current TLAB.
>> Running on 256G memory machine, make run-test CONF=release
>> TEST="test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/"
>> 'JTREG=JOBS=12;VM_OPTIONS=-XX:ActiveProcessorCount=1'
>>
>> before fix: 6 or 7 tests in 20 tests intermittently fail
>> after fix: no failure in 100 runs release/fastdebug
>>
>> This might also fix https://bugs.openjdk.java.net/browse/JDK-8225313
>
> Hui Shi has updated the pull request incrementally with one additional commit
> since the last revision:
>
> clarify comments
Changes requested by cjplummer (Reviewer).
test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java
line 169:
> 167: // Trigger GC then loop around an allocation loop and wait until
> Object Sampling
> 168: // is enabled for every later allocation. It takes two steps:
> 169: // 1. Consume current TLAB, whose size can be varies with heap/GC
> configuration
"whose size can vary"
test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java
line 175:
> 173: System.gc();
> 174: // Step2 loop allocation consume "bytes until sample", each
> iteration allocate
> 175: // about 1600KB, 10 iterations can definitly consume initial "bytes
> until sample"
// Step2 loop allocation consumes "bytes until sample". Each iteration allocates
// about 1600KB, so 10 iterations will definitely consume initial "bytes
until sample"
-------------
PR: https://git.openjdk.java.net/jdk/pull/3265
