P4
If a Leyden AOT code archive built using some configured (or defaulted) heap limit is used by with a different configured (or defaulted) heap limit then memory errors may result. Currently, this only applies when using G1GC but the problem relates to a detail of all current region based GCs.
The GC write barrier code for G1 includes a shift which translates an address within a region to a card index in the region table. The shift is parameterized by a region grain size embedded as an immediate operand. The grain size is derived from the region size which, in turn, is derived from the heap maximum size. So, a constant embedded as an operand at AOT build time may be rendered inappropriate by a change of heap size.
n.b. a workaround for this problem is to fix the region size using command line argument -XX:G1HeapRegionSize=<NNN> (where <NNN> might be e.g. 1M, 2M etc).
The GC write barrier code for G1 includes a shift which translates an address within a region to a card index in the region table. The shift is parameterized by a region grain size embedded as an immediate operand. The grain size is derived from the region size which, in turn, is derived from the heap maximum size. So, a constant embedded as an operand at AOT build time may be rendered inappropriate by a change of heap size.
n.b. a workaround for this problem is to fix the region size using command line argument -XX:G1HeapRegionSize=<NNN> (where <NNN> might be e.g. 1M, 2M etc).