On Fri, 2 Feb 2024 04:47:22 GMT, Quan Anh Mai <qa...@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
