[lworld] RFR: 8372261: [lworld] Augment vmTestbase array tests with large flat arrays [v2]
Paul Hübner
phubner at openjdk.org
Fri Feb 13 15:08:39 UTC 2026
On Fri, 13 Feb 2026 08:26:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
>> Please review following fix that add Byte[], Boolean[] and Integer[] arrays to garbageProducers and use them in random(arrays) producers and added few configurations to ArrayJuggle3 using these new producers.
>>
>> Also change some memory objects from primitive arrays to Integer/Byte arrays if preview is enabled to stress flattened arrays.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>
> fixed gp name
Thank you for this work, it'd be great to have more robust value class support! I've left some comments from the perspective of a VM developer. I can't comment on how appropriate these changes are for the vmTestbase codebase, but the changes seem reasonable to me.
test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle3.java line 27:
> 25: * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent]
> 26: */
> 27: /* @test id=BooleanObjArr_medium @key stress randomness @library /vmTestbase /test/lib @run main/othervm -XX:+HeapDumpOnOutOfMemoryError -Xlog:gc=debug:gc.log gc.ArrayJuggle.Juggle3 -gp BooleanObjArr -ms medium */
Do we have the resources to run these boxed arrays when not in preview mode? If not, we might want to `@require java.enablePreview` and `@require !java.enablePreview`.
test/hotspot/jtreg/vmTestbase/nsk/share/gc/Memory.java line 40:
> 38: private static int objectExtraSize = 0;
> 39:
> 40: private static final boolean previewEnabled =
I think there are some more robust ways to check for preview.
* The best way is probably `jdk.internal.misc.PreviewFeatures.isEnabled` which checks if the current VM is preview-enabled. Needs `@modules java.base/jdk.internal.misc`.
* Alternatively, if the above is not possible, `jdk.test.lib.Utils.getTestJavaOpts` which you can check in a Stream for `--enable-preview`. This consolidates all of the `test.vm.opts` and `test.java.opts` for you.
test/hotspot/jtreg/vmTestbase/nsk/share/gc/Memory.java line 139:
> 137: return getReferenceSize();
> 138: }
> 139: return 8;
This comment applies to all `getXXXArrayElementSize` methods. The element size depends on many things, such as the properties of the array (controls flattening decisions and/or layout) and the VM (flattening can be disabled).
For JEP 401, we only consider the nullable atomic layout. Even for this simple case, we should, in my opinion, do the following:
- Check if flattening is enabled. For this, we can use the `WhiteBox` API to get the VM flag values. Some relevant flags may be: `UseArrayFlattening`, `UseFieldFlattening`, `UseNullableValueFlattening`, `UseAtomicValueFlattening`.
- File an RFE to track hardcoding the size, such that we can change it once there are more layouts available.
A more robust solution would be to use `test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/FieldLayoutAnalyzer.java` in order to get more comprehensive layout information.
test/hotspot/jtreg/vmTestbase/nsk/share/gc/Memory.java line 208:
> 206: int length = (int) Math.min((memory - arrayExtraSize) / objectSize,
> 207: Integer.MAX_VALUE);
> 208: return Math.max(length, 0);
In which scenarios do you anticipate to get a negative `length`?
test/hotspot/jtreg/vmTestbase/nsk/share/gc/MemoryObject.java line 49:
> 47: }
> 48: } else {
> 49: storage = new int[0];
This else case wasn't here before right? I'm not sure I follow why we need an empty array.
test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java line 402:
> 400: return new BooleanObjArrayProducer();
> 401: else if (id.equals("IntegerObjArr"))
> 402: return new IntegerObjArrayProducer();
Sanity question: do we also need to consider `h_IntegerObjArr`?
-------------
PR Review: https://git.openjdk.org/valhalla/pull/2099#pullrequestreview-3797580365
PR Review Comment: https://git.openjdk.org/valhalla/pull/2099#discussion_r2804490843
PR Review Comment: https://git.openjdk.org/valhalla/pull/2099#discussion_r2804610132
PR Review Comment: https://git.openjdk.org/valhalla/pull/2099#discussion_r2804658453
PR Review Comment: https://git.openjdk.org/valhalla/pull/2099#discussion_r2804661188
PR Review Comment: https://git.openjdk.org/valhalla/pull/2099#discussion_r2804664777
PR Review Comment: https://git.openjdk.org/valhalla/pull/2099#discussion_r2804548441
More information about the valhalla-dev
mailing list