On Tue, 3 Jun 2025 05:51:38 GMT, Radim Vansa <rva...@openjdk.org> wrote:
>> Can you explain somewhere how fields are mapped to this? I assume they're
>> sorted, for some reason I expected the packed table to be {name-cp-index,
>> sig-cp-index, offset-in-fieldstream-for-direct-access}. Does every field
>> get 4 ints ? So why is it packed into ```Array<u1>``` rather than just use
>> ```Array<u4>```? So much packing code that I don't know how anyone could
>> ever debug it.
>
> Yes, in practice these all are of the same size, but in case of the masks (as
> well as in case of arguments in API) I want to stress out that these are 32
> bit numbers. The `unsigned int`s are just 'some not too big number'.
> Is there any general guidance on deciding between `unsigned int` (I suppose
> just `unsigned` is not recommended), `uint32_t` and `u4`?
>
> I was hoping that the comment on line 68 explains the intended use, but I can
> be more verbose and document each method. When the packed table is used for
> fieldinfo, it's { offset-in-fieldstream, index-in-fieldstream }. The
> Comparator implementation can translate offset-in-fieldstream -> { name,
> signature } and then do the comparison. The `index-in-fieldstream` is kind of
> second-class citizen; we need to fill it into `FieldInfo` and it is not
> encoded in the stream, therefore we need to encode it in the packed table.
Reading further, I see what this mapping is and intentionally generalized. I
guess a comment like, the key and value are sized to represent the maximum
value for each and then compacted, or something like that. But maybe I haven't
figured out the packing. Are they increments of u1, u2 or u4 or something in
between?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130268911
