RFR: 8318650: Optimized subword gather for x86 targets. [v11]
Jatin Bhateja
jbhateja at openjdk.org
Fri Feb 2 06:12:02 UTC 2024
On Fri, 2 Feb 2024 04:47:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:
>>> I don't think Lilliput will relax the array alignment to below 4 bytes since the array length needs to be aligned at that.
>>
>> HI @merykitty
>>
>> Lilliput wiki mention about shrinking object header below 4 bytes in future.
>> https://wiki.openjdk.org/display/lilliput#:~:text=Future%20work%3A%2032%20bit%20or%20even%20smaller%20header%3F%20(If%20so%3A%20improve%20field%20layout%20to%20put%20fields%20in%20unused%20bits%20of%20header%20word)
>>
>> On x86 page size always a power of 2, this along with minimum object size alignment in JVM (8 bytes even 4 bytes) should be ok, We are anyway shuffling and extracting the byte / word of interest so any junk data read will be chopped off. But in edge case an overrun may land us into a non accessible address space, so we want to be super safe here. I am also sitting over other solution which is performant.
>
> Hi @jatin-bhateja,
>
> The layout of an array is as follows:
>
> [header] - [length] - [data]
>
> Since `length` is a 4-byte field, which is 4-byte aligned, in the foreseeable future, even if the `header` is shrunk to below 4 bytes, I don't think `data` can be less than 4-byte aligned.
>
> Thanks a lot.
Hi @merykitty ,
As mentioned earlier, JVM commits heap space in multiple of page sizes and granularity at which a double word gather operates is 4 bytes, thus there may not a chance of going beyond a page boundary while reading a double word from a normalized index which will always begin at byte address multiple of doubleword, @sviswa7's concern was around running into subsequent heap object header (instance / array) in case gather array size is non power of two and a double word read access bytes beyond sub-word array. Default ObjectAlignmentInBytes is 8 bytes and I expect it will never be less than 4 bytes as that is the word size for most of the targets.
I am sitting over the performant solution for AVX512 targets.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1475582599
More information about the core-libs-dev
mailing list