Request for review: JEP: GC Interface: Better isolation of GC implementations
rkennke at redhat.com
Wed Nov 23 09:11:26 UTC 2016
> Thanks for the updated webrev. I like what you are doing here. I
> it looks very ambitious and I like it. The current GC "interface"
> been in our fridge a bit too long and probably passed its expiry date
> a bit.
> I will commit to helping out with this GC interface. I have some
> involving GC barrier C++ templates. Thought I would share some
> The general theme is combining attributes such as build time
> (e.g. Shenandoah built or not), JVM runtime attributes (e.g.
> oops or not), access attributes (e.g. memory ordering constraints),
> access GC attributes (e.g. is this a weak reference), possibly
> 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
> There is currently a separate load acquire, one for volatiles, and
> compressed oops is dealt with separately and write barriers
> again. And the fact that Reference.get uses pre-write barriers
> they happen to be SATB marking barriers even though they have nothing
> do with actually writing gives me a horrible feeling. Yuck! In
> 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
> decorating the barriers represented explicitly in a unified way
> templates. By enriching the barrier contexts, the aim is for the GC
> interface to be more generic, be simple to use, while keeping the
> 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!
More information about the hotspot-gc-dev