First cut at a card table for Shenandoah

[Roman Kennke]

On Thu, 2020-07-23 at 12:31 +0200, Thomas Schatzl wrote:
> Hi,
> 
> On 22.07.20 22:59, Roman Kennke wrote:
> > I am not very familiar with all this stuff.
> > 
> > You should check if the C2 optimizations for card-table-barriers
> > kick
> > in. IIRC, there was something that elides those barriers on stores
> > into
> > new objects altogether, which make up the majority of stores.
> > 
> 
>    if you are talking about eliding write barriers for new objects 
> because they are "always" allocated in young gen, and no
> generational 
> collector is interested in young->old references, there is no such
> thing 
> afaik.
> 
> No collector guarantees this "always" property: e.g. CMS may
> directly 
> decide to put new objects into old gen for a few reasons, and for 
> parallel (and g1) it e.g. can happen that a gc right after
> allocating 
> that object (when e.g. transitioning from native slow-path code)
> will 
> move that object into old gen. Or simply when the object is large.
> 
> See e.g. https://bugs.openjdk.java.net/browse/JDK-8191342
> 
> That would still require the compiler to only apply that optimization
> if 
> it can prove that the object is "small enough" to fit into young gen
> in 
> any case (it is probably easy to get conservative enough values for
> that 
> from somewhere).
> 

Thanks Thomas for clarification! :-)

Roman