On Fri, 13 Feb 2026 16:00:49 GMT, Leonid Mesnik <[email protected]> wrote:
>> 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. > > Thanks for pointer. It is very good example. > But as I said, we need to find single solution for Memory sizes. And more > important is it worth for these tests or such "rough" estimation is enough. I filed https://bugs.openjdk.org/browse/JDK-8377906 to implement the generic solution and mainline and then we can improve it in valhalla. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2099#discussion_r2804998011
