GC interface update
cthalinger at twitter.com
Wed Apr 12 20:55:20 UTC 2017
> On Apr 12, 2017, at 10:18 AM, Roman Kennke <rkennke at redhat.com> wrote:
> Am 12.04.2017 um 21:54 schrieb Kirk Pepperdine:
>>> On Apr 12, 2017, at 9:10 PM, Roman Kennke <rkennke at redhat.com> wrote:
>>> Am 12.04.2017 um 21:02 schrieb Christian Thalinger:
>>>> Two or three JavaOnes ago Jon Masa (where is he anyway? ;-)
>>> I think he retired?
>> He retired just after JavaONE.
>>>> and I discussed JVMCI and a possible GC interface. One issue with compilers is that they need to emit different barrier code for different garbage collectors. You mention this in the JEP.
>>>> Where are you with your thinking on this?
>>> That's a tricky one.
>> You could inject the barrier rules into the compiler? The compiler would also need an interface for this to work.
> I'm currently mostly thinking about C1 and C2. I think JVMCI would be
> similar though. We need some smallish code between the compiler and the
> GC that knows about both, and generates the IR for the corresponding
> compiler and GC. (It becomes even more complicated in the case of the
> interpreter, which requires arch-specific barriers too..)
That smallish code for JVMCI would be a GC barrier API in JVMCI. The JVMCI compiler would then have to implement that interface for all GCs it supports. (Very raw thoughts.)
> There's other issues to think about, like GC/barrier specific class
> definitions, e.g. GC specific Node sub-classes in C2, and GC specific
> compiler optimizations. I have some ideas how to do that, but it's not
> very useful to to think about it on a theoretical basis that much. We'll
> see when we get there I think.
More information about the hotspot-gc-dev