RFR: 8322330: JavadocHelperTest.java OOMEs with Parallel GC and ZGC

[Thomas Schatzl]

On Tue, 9 Jan 2024 16:15:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this small fix to increase max heap size for the test to let it pass with GenZGC and Parallel GC as well.
>> 
>> The test has at least 660m of live data, so the default 768m provided by testng is too small for these collectors.
>> 
>> Testing: local testing
>> 
>> Hth,
>>   Thomas
>
> FWIW - I don't mind the change. I think it is more for the GC people if they are fine with some GC requiring more memory than others, or if they want to investigate further. The validity of the javadoc-related test is not affected by this, I think.

>From @lahodaj:

> FWIW - I don't mind the change. I think it is more for the GC people if they are fine with some GC requiring more memory than others, or if they want to investigate further. 

For garbage collection algorithms it is no different to other memory management algorithms to require different amount of slack to operate efficiently or at all.
A very, very old rule of thumb mentions like 30% of total heap capacity should be live set size for optimal operation (there can be huge variances depending on allocation rate and absolute heap capacity). This is a bit low imho, but at 85%+ (>660/768M) there is a large risk that one or the other algorithm just bails out. (To be clear, e.g. Parallel GC and GenZGC can probably be configured to require less, but that would make the change unnecessarily tied to it).

>The validity of the javadoc-related test is not affected by this, I think.

No.

>From @jonathan-gibbons :
> There is a history that I would now consider an anti-pattern of LangTools tests running on monotonically increasing data sets. [...] While the practice will for-sure lead to monotonically increasing run times, we could/should make sure that it doesn't lead to monotonically increasing memory requirements. 

There is also the possibility that this test has never been run with anything but the default collector before (and/or the problem with other collectors never been reported previously), that is, G1, which has very little minimum intrinsic requirements to limp along (jshell has been introduced in java 9, which is incidentally the version when G1 got to be the default collector). The test file has been introduced in 9, but parts of the test only later.

The test also seems to access src.zip ("all java files") which is not fixed, but not sure if it ever e.g. builds a javadoc model of the whole sources in memory. I think not afaict after a very brief look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17304#issuecomment-1884485705