RFR: 8280761: UseCompressedOops should be set after limit_heap_by_allocatable_memory [v2]

[Albert Mingkun Yang]

On Fri, 8 Apr 2022 07:35:17 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

>> test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java line 62:
>> 
>>> 60: 
>>> 61:     String cmd = ProcessTools.getCommandLine(ProcessTools.createTestJvm(args.toArray(String[]::new)));
>>> 62:     ProcessBuilder pb = new ProcessBuilder("sh", "-c", "ulimit -v 10485760;" + cmd);
>> 
>> The `ulimit -v` parameter should be passed in as well like `MaxRAM`. Then, from the calling context, one can see whether coop should be enabled or not.
>
> Thank you for your review.
> 
>> I don't understand why `MaxRAMPercentage` or `UseCompressedOops` are relevant to this fix/bug.
> 
> I forgot to remove this comment when I copied form TestMaxRAMFlags.java.
> I fixed this comment.
> 
>> The `ulimit -v` parameter should be passed in as well like `MaxRAM`. Then, from the calling context, one can see whether coop should be enabled or not.
> 
> This bug appears when ulimit -v is specified and MaxRAM is set bigger value. So I think it does not need that
> ulimit -v parameter let be variable.

It's not about whether it's constant or variable.

In this context, it's unclear why coop is enabled.


// Args: MaxRAM , MaxRAMPercentage, forcecoop, expect coop
checkFlag(32 * oneG, 100, false, true);


`checkFlag` should not sneak in logic altering the coop value.

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

PR: https://git.openjdk.java.net/jdk/pull/7938