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