First cut at a card table for Shenandoah

[Thomas Schatzl]

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