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

[Jonathan Gibbons]

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.

1. _No `kulla` label_: that's an issue that should be investigated and fixed.  For my part, I saw the PR but assumed that @lahodaj would address it, as the engineer primarily responsible for the test.

2. While I read and accept @lahodaj 's comment that he is OK with the fix, in general it should _not_ be assumed that the solution to all out-of-memory errors is to provide more memory.   At least in part, it should be examined to see why the test is running out of memory, even if the proximate cause is to change the GC.

There is a history that I would now consider an anti-pattern of LangTools tests running on monotonically increasing data sets. I know, because I wrote some of them, back in the day.  The (anti-)pattern is to run a test on all available data files, for some value of "available" which is typically "all source files (in the `src` directory) or "all test files" (such as in the `test/langtools` directory. 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 have been (Oracle-internal) discussions about managing the "size" of tests, whether that is time-size or memory-size, and this test is another candidate for those discussions. (@jddarcy)

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

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