Effect of Shenandoah Barriers on Code Size...

[Roman Kennke]

Am 09.09.2016 7:05 nachm. schrieb Aleksey Shipilev <shade at redhat.com>:
>
> On 09/09/2016 07:49 PM, Christine Flood wrote: 
> > One of the questions I got asked at VMM was "What is the effect of 
> > Shenandoah Barriers on Code Size?" 
> > 
> > It would be nice to have some kind of measurement which we can talk 
> > about. 
>
> I guess we can do two things: 
> a) say about the code size for standalone barriers, in comparison with 
> other collectors -- my recent disassemblies seem to answer that question 
> for C2/x86_64 [1][2], we may do the same for other platforms; 
> b) estimate total increase in code heap size for, say, SPECjvm2008 and 
> Dacapo; 
>
> > My intuition is that it's negligible, but those dang write barriers. 
>
> To be blunt, current Shenandoah's write barriers are not worse than 
> current G1 write barriers, at least in the cases I cared about. 

We share the SATB write barriers with G1 (obj-stores only), plus we have our own (obj- and primitive stores), but we don't need g1's post-barriers (obj-stores only). 

Cheers, Roman


> Thanks, 
> -Aleksey 
>
> [1] 
> http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/reads/ReadBarriersFields.java 
> [2] 
> http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-gc-bench/src/main/java/org/openjdk/shenandoah/writes/WriteBarriers.java