Request for review: JEP: GC Interface: Better isolation of GC implementations

Roman Kennke rkennke at redhat.com
Wed Nov 23 09:11:26 UTC 2016


Hi Erik,


> Thanks for the updated webrev. I like what you are doing here. I
> think 
> it looks very ambitious and I like it. The current GC "interface"
> has 
> been in our fridge a bit too long and probably passed its expiry date
> by 
> a bit.

;-)


> I will commit to helping out with this GC interface. I have some
> ideas 
> involving GC barrier C++ templates. Thought I would share some
> thoughts. 
> The general theme is combining attributes such as build time
> attributes 
> (e.g. Shenandoah built or not), JVM runtime attributes (e.g.
> compressed 
> oops or not), access attributes (e.g. memory ordering constraints), 
> access GC attributes (e.g. is this a weak reference), possibly
> caller 
> contexts (e.g. is this called by GC or mutator), into a neat way for 
> users of the barriers, while providing best possible performance. 
> Instead these things tend to be split into different orthogonal
> concerns 
> instead.
> 
> There is currently a separate load acquire, one for volatiles, and 
> compressed oops is dealt with separately and write barriers
> separately 
> again. And the fact that Reference.get uses pre-write barriers
> because 
> they happen to be SATB marking barriers even though they have nothing
> to 
> do with actually writing gives me a horrible feeling. Yuck! In
> certain 
> cases like oop_iterate macros we try to catch single dynamic context 
> attributes such as whether compressed oops is used early to amortize 
> those barrier costs over multiple loads. But I would like to 
> (eventually) catch more such context info and hence want that
> context 
> decorating the barriers represented explicitly in a unified way
> using 
> templates. By enriching the barrier contexts, the aim is for the GC 
> interface to be more generic, be simple to use, while keeping the
> best 
> possible performance.

Sounds great. Would really like to see how you would realize it.

> I will take your patch for a spin and see if I can add some template 
> magic in there. I hope you like the idea!

Absolutely!

Cheers,
Roman



More information about the hotspot-gc-dev mailing list