[RESUMED] RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated

[Thomas Schatzl]

Hi,

On Wed, 2016-06-22 at 14:34 -0400, Derek White wrote:
> Hi Thomas,
> 
> Thanks for the comments! Questions below...
> 
> 
[...]
> Maybe this only causes problems when the object is allocated in
> > > the
> > > old gen (perhaps because it is large).  Is there some other path
> > > for
> > > large arrays, so we don't have a barrier for every array
> > > allocation?
> > > I hope I'm missing something...
> > I do not know for CMS, but G1's humongous objects do have a
> > storestore barrier at the correct place (and it should have the
> > corresponding at the reader side). These are the only direct old
> > gen allocations G1 ever does.
>
> Where is this barrier used? I thought the header setting was done up
> at CollectedHeap::array_allocate(), outside of G1 code?

CollectedHeap::array_allocate() is not used for humongous objects, but
G1CollectedHeap::humongous_obj_allocate().

> > In any case, as soon as CMS uses this method for old gen
> > allocation, it needs to have the necessary barriers (obviously).
> I think for CMS, reading and writing are protected by the 
> cms_space->freelistLock(). For example,
> the CMS sweeper holds the freelistLock. The Java thread trying to 
> allocate requests, then gets the freelistLock(), and the sweeper 
> re-aquires the freelistLock() before resuming the sweep (and
> reading).
> 
> So I'd think that there are plenty of fences for CMS?

I would imagine that the exact ordering of the reads of these variables
is important, not necessarily that before or after there are fences.

Additional fences may only decrease the occurrences of this issue.

Of course, if it is the case that both threads synchronize on the free
list lock for allocation and reading respectively in the old gen, the
code is fine.

Thanks,
  Thomas