[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFR: 8330275: Crash in XMark::follow_array [v6]
From:       Stefan Karlsson <stefank () openjdk ! org>
Date:       2024-05-13 10:06:17
Message-ID: 5UNz9xRBR7ZN44DF3siVI2XKEUr-q1GUovaTo3xXDWY=.848e3fc8-e24c-4512-a724-0adbf2c03d9e () github ! com
[Download RAW message or body]

On Wed, 8 May 2024 16:34:07 GMT, Ashutosh Mehra <asmehra@openjdk.org> wrote:

> > This PR addresses the issue in ZGC where the number of address offset bits can go \
> > beyond the limit imposed by the encoding scheme in mark stack, thereby causing \
> > the encoding to fail. Encoding of partial array offset in mark stack requires \
> > that the max address bit be no more than 46 bit. ~~But the current mechanism to \
> > probe maximum address offset bits on aarch64, riscv and ppc platforms can return \
> > value larger that 44 bits. This patch sets the maximum address offset bits to \
> > 44.~~ 
> > ~~I have updated the generational mode to avoid subtracting 3 bits from the \
> > maximum address offset bit probed by the system, as the generational mode does \
> > not use multi-mapping.~~ 
> > ~~I have also updated the code to set MarkPartialArrayMinSizeShift dynamically \
> > depending on the number of address offset bits used. This would avoid running \
> > into such problem again if in future maximum address offset bits is increased \
> > beyond 44.~~ 
> > ~~For some reason (that I can't comprehend from the code) the existing \
> > implementation for probing the max addressable bit for ppc in non-generation ZGC \
> > is very different from other platforms and from generational mode as well. I have \
> > kept the existing implementation as is and just fixed it to ensure it does not \
> > return value greater than 44 bits.~~ 
> > Testing: ~~test/hotspot/jtreg/gc/z and test/hotspot/jtreg/gc/x on x86~~ tier1, \
> > tier2 and tier3 on aarch64 using fastdebug build with options \
> > JTREG="EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt;JAVA_OPTIONS=-XX:+UseZGC \
> > -XX:+ZVerifyOops;JOBS=4"  (as per the suggestion in \
> > [JDK-8330275](https://bugs.openjdk.org/browse/JDK-8330275?focusedId=14667864&page= \
> > com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14667864))
> >  
> > Update: Striked out the changes that are not relevant now that it is only doing a \
> > point fix for aarch64
> 
> Ashutosh Mehra has updated the pull request incrementally with one additional \
> commit since the last revision: 
> Restore the comment around max addressable memory but leave out actual numbers that \
> can be confusing 
> Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

src/hotspot/cpu/aarch64/gc/z/zAddress_aarch64.cpp line 41:

> 39: // Default value if probing is not implemented for a certain platform
> 40: // Max address bit is restricted by implicit assumptions in the code, for \
>                 instance
> 41: // the bit layout of XForwardingEntry or Partial array entry (see \
> XMarkStackEntry) in mark stack

This comment was copy-n-pasted without updating the names to ZForwardingEntry and \
ZMarkStackEntry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18941#discussion_r1598214359


[prev in list] [next in list] [prev in thread] [next in thread]