RFR: 8367131: Test com/sun/jdi/ThreadMemoryLeakTest.java fails on 32 bits

Sergey Bylokhov serb at openjdk.org
Tue Sep 9 22:47:26 UTC 2025


On Tue, 9 Sep 2025 22:42:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> On 32-bit systems, the ThreadMemoryLeakTest can be run as is. The option vm.opt.final.UseCompressedOops must be guarded by vm.bits == 64; otherwise, an error occurs.
>> 
>> Tested on:
>>  - 64-bit: with and without -Xcomp, -Xint, -Xmixed, and with/without -+UseCompressedOops
>>  - 32-bit: with and without -Xcomp, -Xint, -Xmixed
>
> test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 31:
> 
>> 29:  * @comment Don't allow -Xcomp or -Xint as they impact memory useage and number of iterations.
>> 30:  *          Require compressed oops because not doing so increases memory usage.
>> 31:  * @requires (vm.compMode == "Xmixed") & ((vm.bits == 64 & vm.opt.final.UseCompressedOops) | vm.bits == 32)
> 
> would
> `@requires (vm.compMode == "Xmixed") & (vm.bits == 32 | vm.opt.final.UseCompressedOops)`
> works? (not sure if jtreg is going to evaluate coops mode lazy in this case)

"bits == 64 & vm.opt.final.UseCompressedOops" is a common pattern used in testbase, so I just followed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27177#discussion_r2334988523


More information about the serviceability-dev mailing list