On Tue, 10 Mar 2026 11:59:06 GMT, Paul Hübner <[email protected]> wrote:

>> Hi all,
>> 
>> This adds some more debug prints to various internals.
>> 
>> When printing an `InstanceKlass`, the kind is now shown. For example:
>> 
>> InstanceKlass (kind=1): java.lang.Integer {0x00001ff00022c318}
>> 
>> 
>> The `InlineKlass::Members` are also printed. For example (note that to get 
>> individual array entries `WizardMode` must be enabled):
>> 
>>  - ---- inline type members:
>>  - extended signature registers:      Array<T>(0x00000001330002f8)
>> 0 : SigEntry: type=18 offset=0 null_marker=0 Symbol: 'java/lang/Integer' 
>> count 65535
>> 1 : SigEntry: type=10 offset=16 null_marker=0 Symbol: 'value' count 65535
>> 2 : SigEntry: type=14 offset=24 null_marker=0 Symbol: 'java/lang/Integer' 
>> count 65535
>>  - return registers:                  Array<T>(0x0000000133000348)
>> 0 : (c_rarg0,c_rarg0)
>> 1 : (c_rarg7,BAD!)
>>  - pack handler:                      0x0000000119b21238
>>  - pack handler (jobject):            0x0000000119b21140
>>  - unpack handler:                    0x0000000119b21244
>>  - null reset offset:                 128
>>  - payload offset:                    16
>>  - payload size (bytes):              8
>>  - payload alignment:                 8
>>  - null-free non-atomic size (bytes): 4
>>  - null-free non-atomic alignment:    4
>>  - null-free atomic size (bytes):     4
>>  - nullable atomic size (bytes):      8
>>  - nullable non-atomic size (bytes):  5
>>  - null marker offset:                20
>> 
>> 
>> Fields now indicate their field flags. Non-static fields indicate (a) when 
>> they are flat and (b) their layout when flat.  For example:
>> 
>>  - ---- non-static fields (1 words):
>>  - private final value flat 'inner' (fields 0x00000006) 'LAValue;' @12 
>> LayoutKind: NULLABLE_NON_ATOMIC_FLAT
>> 
>> 
>> Arrays already have plenty of flattening information that can be printed.
>> 
>> Testing: tiers 1-3.
>
> Paul Hübner has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Remove commented out line.

This patch is showing a bug in the way the AccessFlags are printed (the bug is 
not in this patch, but this patch is using the buggy code):

` - ---- static fields (6 words):
 - private static final value 'FS' (fields 0x00000000) 'Ljava/io/FileSystem;' 
@120 
 - public static final value 'separatorChar' (fields 0x00000000) 'C' @160 
 - public static final value 'separator' (fields 0x00000000) 
'Ljava/lang/String;' @124 
 - public static final value 'pathSeparatorChar' (fields 0x00000000) 'C' @162 
 - public static final value 'pathSeparator' (fields 0x00000000) 
'Ljava/lang/String;' @128 
 - private static final value 'UNSAFE' (fields 0x00000000) 
'Ljdk/internal/misc/Unsafe;' @132 
 - private static final value 'PATH_OFFSET' (fields 0x00000000) 'J' @136 
 - private static final value 'PREFIX_LENGTH_OFFSET' (fields 0x00000000) 'J' 
@144 
 - private static final value 'serialVersionUID' (fields 0x00000008) 'J' @152 
 - static final synthetic value '$assertionsDisabled' (fields 0x00000000) 'Z' 
@164 
 - ---- non-static fields (4 words):
 - private final transient value 'prefixLength' (fields 0x00000000) 'I' @12 
 - private final value 'path' (fields 0x00000000) 'Ljava/lang/String;' @16 
 - private transient value 'status' (fields 0x00000000) 
'Ljava/io/File$PathStatus;' @20 
 - private volatile transient value 'filePath' (fields 0x00000000) 
'Ljava/nio/file/Path;' @24 `

All fields are marked as 'value' when obviously, none of them are storing 
values from value classes!
The culprit is in  `AccessFlags::print_on(outputStream* st)`:

`if (Arguments::is_valhalla_enabled()) {
    if (is_identity_class()) st->print("identity ");
    if (!is_identity_class()) st->print("value "  );
  }`
  
This piece of code was added considering class AccessFlags and not field 
AccessFlags. ACC_IDENTITY has value 0x20, and no field flag is using this 
value, leading the code above to always print "value ".

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

PR Comment: https://git.openjdk.org/valhalla/pull/2208#issuecomment-4057626976

Reply via email to