Take 3: 8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding
Thomas Schatzl
thomas.schatzl at oracle.com
Mon Jun 17 20:20:57 UTC 2019
Hi,
On Mon, 2019-06-17 at 16:13 -0400, Kim Barrett wrote:
> > On Jun 17, 2019, at 11:35 AM, Andrew Haley <aph at redhat.com> wrote:
> >
> > On 6/13/19 6:26 PM, Kim Barrett wrote:
> >
> > > set_offset_array_raw looks quite uninterestingly different from
> > > set_offset_array (whose definition is in the .inline.hpp, near
> > > the
> > > definition of offset_array that needed to be changed). Consider
> > > hoisting set_offset_array_raw into set_offset_array, killing off
> > > the
> > > _raw function, and updating the one remaining caller.
> >
> > Previous patch failed testing. We really do need
> > set_offset_array_raw(), not for efficiency but because at the very
> > start the assert invariants do not hold.
> >
> > In this version of the patch set_offset_array_raw() is back and I
> > had to add a couple more const_casts in assertions. Fingers
> > crossed.
> >
> > http://cr.openjdk.java.net/~aph/8225716-3/
>
> It *might* be a (pre-existing) bug that the heap memory range
> predicates don't accept pointer to volatile. But looking at the
> asserts you needed to fix, my reaction is to question their utility,
> and wonder if they should just be removed. What do others think?
>
not seeing that they are particularly useful, so good to just remove
to me too.
Thanks,
Thomas
More information about the hotspot-gc-dev
mailing list