Master Thesis on Shenandoah

Christine Flood cflood at redhat.com
Mon Oct 9 13:45:46 UTC 2017


I would recommend that you read:

Barriers Reconsidered, Friendlier Still! by Yang et al
https://pdfs.semanticscholar.org/6ede/fc06b81365ab41b412fb571be3893fe5a9ad.pdf

The information in Table 2 on the cost of conditional read barriers is
especially relevant.   Be very careful of any changes to our read barrier.
We've designed them to be as lightweight as possible.

I'd like to throw a few more ideas out there for you to consider.

1)  If you really want to get rid of the forwarding pointer, implementing a
protected memory region collector as in C4 might make more sense.  Their
read barrier is also one instruction.
c4: The continuously Concurrent Compacting Collector
Tene et al

http://www.newspaper23.com/ripped/2014/10/http-_____-___-_www___-azulsystems___-com__-_sites__-_default__-_files__-_images__-_c4_paper_acm.pdf

2)  I met with Gil Tene at JavaOne and he came very close to convincing me
that we need generational shenandoah.  This would require enabling the card
table barriers that are already there for the other collectors.

3) We currently implement SATB concurrent marking.  The following paper
describes a minimal wavefront which would eliminate a large amount of
floating garbage (objects which are dead but are not found out to be dead
during the current concurrent marking).
Correctness-Preserving Derivation of Concurrent Garbage Collection
Algorithms
Vechev et al
http://www.srl.inf.ethz.ch/papers/pldi06-cgc.pdf


Christine


On Thu, Oct 5, 2017 at 4:29 PM, Dominik Inführ <dominik.infuehr at gmail.com>
wrote:

> Hi,
>
> I am interested in working on Shenandoah as part of my master thesis at the
> University of Technology in Vienna. Aleksey mentioned in his VMM-Talk in
> Prague a possible project: storing the Brooks indirection pointer in the
> object header.
>
> Please let me know if you need more information about me.
>
> Best,
>
> Dominik
>


More information about the shenandoah-dev mailing list