Quantcast

GC interface update

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

GC interface update

Roman Kennke-6
I spent some more time working on the GC interface prototype and wanted
to share it with you:

http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
<http://cr.openjdk.java.net/%7Erkennke/gc-interface/webrev.02/>

Notable changes:

- It's now based on JDK10 (specifically,
http://hg.openjdk.java.net/jdk10/hs/hotspot changeset 12853:d276073fda85)
- I focused on better CMS isolation:
  - Most CMS specific stuff from GenCollectedHeap now resides in
specific subclass CMSHeap
  - Same for CardTableModRefBSForCTRS -> CMSBarrierSet
  - Factored everything related to always_do_update_barrier_set into CMS
subclasses

The JEP is still in 'submitted' state. Would be good to have it moved to
'candidate' at least, so that it gets a number?

https://bugs.openjdk.java.net/browse/JDK-8163329

Does anybody know a good place where I could put a whole forest to
develop this in?

As always, any feedback is welcome.

Best regards,
Roman


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Roman Kennke-6
Am 12.04.2017 um 16:54 schrieb Aleksey Shipilev:
> On 04/12/2017 04:46 PM, Roman Kennke wrote:
>> The JEP is still in 'submitted' state. Would be good to have it moved to
>> 'candidate' at least, so that it gets a number?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8163329
> As per JEP Process, if you are ready for JEP to be evaluated, you can transit it
> to Submitted state.
It is already 'submitted' but it seems stuck there ...
>> Does anybody know a good place where I could put a whole forest to
>> develop this in?
> I think JDK 10 Sandbox under the named branch:
>   http://cr.openjdk.java.net/~chegar/docs/sandbox.html
>   http://hg.openjdk.java.net/jdk10/sandbox/branches
Cool, thanks! That's what I was looking for.

Roman


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

kirk@kodewerk.com
Hi Roman,

Huge amount of work in here so well done.

Sorry for my question… In my initial scan I didn’t see globals.hpp. Is is not the case that the configurations would be pulled out of that file?

Kind regards,
Kirk

> On Apr 12, 2017, at 4:57 PM, Roman Kennke <[hidden email]> wrote:
>
> Am 12.04.2017 um 16:54 schrieb Aleksey Shipilev:
>> On 04/12/2017 04:46 PM, Roman Kennke wrote:
>>> The JEP is still in 'submitted' state. Would be good to have it moved to
>>> 'candidate' at least, so that it gets a number?
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8163329
>> As per JEP Process, if you are ready for JEP to be evaluated, you can transit it
>> to Submitted state.
> It is already 'submitted' but it seems stuck there ...
>>> Does anybody know a good place where I could put a whole forest to
>>> develop this in?
>> I think JDK 10 Sandbox under the named branch:
>>  http://cr.openjdk.java.net/~chegar/docs/sandbox.html
>>  http://hg.openjdk.java.net/jdk10/sandbox/branches
> Cool, thanks! That's what I was looking for.
>
> Roman
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Roman Kennke-6

> Hi Roman,
>
> Huge amount of work in here so well done.
>
> Sorry for my question… In my initial scan I didn’t see globals.hpp. Is is not the case that the configurations would be pulled out of that file?
Yes. Haven't done that yet :-)

Roman



signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

kirk@kodewerk.com

> On Apr 12, 2017, at 6:48 PM, Roman Kennke <[hidden email]> wrote:
>
>
>> Hi Roman,
>>
>> Huge amount of work in here so well done.
>>
>> Sorry for my question… In my initial scan I didn’t see globals.hpp. Is is not the case that the configurations would be pulled out of that file?
> Yes. Haven't done that yet :-)

Awesome… so far my (unofficial) review isn’t showing anything of interest.. which is good news. The design looks very clean.

Kind regards,
Kirk

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Roman Kennke-6
In reply to this post by Roman Kennke-6
>> Does anybody know a good place where I could put a whole forest to
>> develop this in?
> I think JDK 10 Sandbox under the named branch:
>   http://cr.openjdk.java.net/~chegar/docs/sandbox.html
>   http://hg.openjdk.java.net/jdk10/sandbox/branches

Okidoki, I created the JDK-8163329-branch in the JDK10-sandbox repo:

http://hg.openjdk.java.net/jdk10/sandbox/branches

And pushed the existing prototype code to it. I'll do all further
development in there, and of course everybody is invited to participate.

Roman



signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Christian Thalinger-4
In reply to this post by Roman Kennke-6
Two or three JavaOnes ago Jon Masa (where is he anyway? ;-) 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?

> On Apr 12, 2017, at 4:46 AM, Roman Kennke <[hidden email]> wrote:
>
> I spent some more time working on the GC interface prototype and wanted
> to share it with you:
>
> http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
> <http://cr.openjdk.java.net/%7Erkennke/gc-interface/webrev.02/>
>
> Notable changes:
>
> - It's now based on JDK10 (specifically,
> http://hg.openjdk.java.net/jdk10/hs/hotspot changeset 12853:d276073fda85)
> - I focused on better CMS isolation:
>  - Most CMS specific stuff from GenCollectedHeap now resides in
> specific subclass CMSHeap
>  - Same for CardTableModRefBSForCTRS -> CMSBarrierSet
>  - Factored everything related to always_do_update_barrier_set into CMS
> subclasses
>
> The JEP is still in 'submitted' state. Would be good to have it moved to
> 'candidate' at least, so that it gets a number?
>
> https://bugs.openjdk.java.net/browse/JDK-8163329
>
> Does anybody know a good place where I could put a whole forest to
> develop this in?
>
> As always, any feedback is welcome.
>
> Best regards,
> Roman
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Roman Kennke-6
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?

>  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.

I'm thinking to have sub-interfaces, e.g. C2GCSupport and C1GCSupport
provided by the GC interface main class. Those guys must know about both
their respective compiler interfaces (e.g. Node, GraphKit, etc) and
their GC. The compiler would then simply call something like
GC::gc()->c1_support()->pre_barrier(...) instead of switching on the
barrier-type and assuming knowledge about the particular GCs. Same goes
for jvmci I think, but haven't put much thought on it yet. In fact, it
would be helpful to know what you, as a compiler guy, would ideally use
as GC interface. ?

Roman


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

kirk@kodewerk.com

> On Apr 12, 2017, at 9:10 PM, Roman Kennke <[hidden email]> 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.

Kind regards,
Kirk



>
> I'm thinking to have sub-interfaces, e.g. C2GCSupport and C1GCSupport
> provided by the GC interface main class. Those guys must know about both
> their respective compiler interfaces (e.g. Node, GraphKit, etc) and
> their GC. The compiler would then simply call something like
> GC::gc()->c1_support()->pre_barrier(...) instead of switching on the
> barrier-type and assuming knowledge about the particular GCs. Same goes
> for jvmci I think, but haven't put much thought on it yet. In fact, it
> would be helpful to know what you, as a compiler guy, would ideally use
> as GC interface. ?
>
> Roman
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Roman Kennke-6
Am 12.04.2017 um 21:54 schrieb Kirk Pepperdine:

>> On Apr 12, 2017, at 9:10 PM, Roman Kennke <[hidden email]> 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..)

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.

Roman


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Christian Thalinger-4

> On Apr 12, 2017, at 10:18 AM, Roman Kennke <[hidden email]> wrote:
>
> Am 12.04.2017 um 21:54 schrieb Kirk Pepperdine:
>>> On Apr 12, 2017, at 9:10 PM, Roman Kennke <[hidden email]> 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.
>
> Roman
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Per Liden
In reply to this post by Roman Kennke-6
Hi Roman,

On 2017-04-12 16:46, Roman Kennke wrote:

> I spent some more time working on the GC interface prototype and wanted
> to share it with you:
>
> http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
> <http://cr.openjdk.java.net/%7Erkennke/gc-interface/webrev.02/>
>
> Notable changes:
>
> - It's now based on JDK10 (specifically,
> http://hg.openjdk.java.net/jdk10/hs/hotspot changeset 12853:d276073fda85)
> - I focused on better CMS isolation:
>   - Most CMS specific stuff from GenCollectedHeap now resides in
> specific subclass CMSHeap
>   - Same for CardTableModRefBSForCTRS -> CMSBarrierSet
>   - Factored everything related to always_do_update_barrier_set into CMS
> subclasses

Good stuff. However, one thing I'm not quite comfortable with is the
introduction of the GC class (and its sub classes). I don't quite see
the purpose of this interface split-up between GC and CollectedHeap. I
view CollectedHeap as _the_ interface (but yes, it needs some love), and
as a result I think the the functions you've exposed in the GC class
actually belongs in CollectedHeap.

cheers,
Per

>
> The JEP is still in 'submitted' state. Would be good to have it moved to
> 'candidate' at least, so that it gets a number?
>
> https://bugs.openjdk.java.net/browse/JDK-8163329
>
> Does anybody know a good place where I could put a whole forest to
> develop this in?
>
> As always, any feedback is welcome.
>
> Best regards,
> Roman
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

kirk.pepperdine@gmail.com

> On Apr 18, 2017, at 2:01 PM, Per Liden <[hidden email]> wrote:
>
> Hi Roman,
>
> On 2017-04-12 16:46, Roman Kennke wrote:
>> I spent some more time working on the GC interface prototype and wanted
>> to share it with you:
>>
>> http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
>> <http://cr.openjdk.java.net/%7Erkennke/gc-interface/webrev.02/>
>>
>> Notable changes:
>>
>> - It's now based on JDK10 (specifically,
>> http://hg.openjdk.java.net/jdk10/hs/hotspot changeset 12853:d276073fda85)
>> - I focused on better CMS isolation:
>>  - Most CMS specific stuff from GenCollectedHeap now resides in
>> specific subclass CMSHeap
>>  - Same for CardTableModRefBSForCTRS -> CMSBarrierSet
>>  - Factored everything related to always_do_update_barrier_set into CMS
>> subclasses
>
> Good stuff. However, one thing I'm not quite comfortable with is the introduction of the GC class (and its sub classes). I don't quite see the purpose of this interface split-up between GC and CollectedHeap. I view CollectedHeap as _the_ interface (but yes, it needs some love), and as a result I think the the functions you've exposed in the GC class actually belongs in CollectedHeap.

I thought the name CollectedHeap implied the state of the heap after the collector has completed. What is the intent of CollectedHeap?

Kind regards,
Kirk

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Aleksey Shipilev-4
On 04/20/2017 09:37 AM, Kirk Pepperdine wrote:
>> Good stuff. However, one thing I'm not quite comfortable with is the
>> introduction of the GC class (and its sub classes). I don't quite see the
>> purpose of this interface split-up between GC and CollectedHeap. I view
>> CollectedHeap as _the_ interface (but yes, it needs some love), and as a
>> result I think the the functions you've exposed in the GC class actually
>> belongs in CollectedHeap.
>
> I thought the name CollectedHeap implied the state of the heap after the
> collector has completed. What is the intent of CollectedHeap?

No, CollectedHeap is the actual current GC interface. This is the entry point to
GC as far as the rest of runtime is concerned, see e.g. CollectedHeap*
Universe::create_heap(), etc. Implementing CollectedHeap, CollectorPolicy, and
BarrierSet are the bare minimum required for GC implementation today. [1]

-Aleksey

[1]
http://hg.openjdk.java.net/jdk10/sandbox/hotspot/file/c503fa980f8a/src/share/vm/gc/epsilon


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Roman Kennke-6
In reply to this post by Per Liden
Am 18.04.2017 um 14:01 schrieb Per Liden:

> Hi Roman,
>
> On 2017-04-12 16:46, Roman Kennke wrote:
>> I spent some more time working on the GC interface prototype and wanted
>> to share it with you:
>>
>> http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
>> <http://cr.openjdk.java.net/%7Erkennke/gc-interface/webrev.02/>
>>
>> Notable changes:
>>
>> - It's now based on JDK10 (specifically,
>> http://hg.openjdk.java.net/jdk10/hs/hotspot changeset 12853:d276073fda85)
>> - I focused on better CMS isolation:
>>   - Most CMS specific stuff from GenCollectedHeap now resides in
>> specific subclass CMSHeap
>>   - Same for CardTableModRefBSForCTRS -> CMSBarrierSet
>>   - Factored everything related to always_do_update_barrier_set into CMS
>> subclasses
>
> Good stuff. However, one thing I'm not quite comfortable with is the
> introduction of the GC class (and its sub classes). I don't quite see
> the purpose of this interface split-up between GC and CollectedHeap. I
> view CollectedHeap as _the_ interface (but yes, it needs some love), and
> as a result I think the the functions you've exposed in the GC class
> actually belongs in CollectedHeap.
Well yes, I was thinking about that too. CollectedHeap currently is
_the_ central interface. However, I already found it quite crammed.
Plus, there are other 'interfaces' that make up the 'GC interface', e.g.
BarrierSet, CollectorPolicy, and some other stuff (that I listed in the
JEP), and I thought I'd rather create a new hub-kindof interface that
manages all those sub-interfaces. I am not against putting all this into
CollectedHeap (and hopefully, cleaning up CollectedHeap too). I found it
cleaner the way I did it though.

Roman


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Per Liden
In reply to this post by Aleksey Shipilev-4
On 2017-04-20 12:05, Aleksey Shipilev wrote:

> On 04/20/2017 09:37 AM, Kirk Pepperdine wrote:
>>> Good stuff. However, one thing I'm not quite comfortable with is the
>>> introduction of the GC class (and its sub classes). I don't quite see the
>>> purpose of this interface split-up between GC and CollectedHeap. I view
>>> CollectedHeap as _the_ interface (but yes, it needs some love), and as a
>>> result I think the the functions you've exposed in the GC class actually
>>> belongs in CollectedHeap.
>>
>> I thought the name CollectedHeap implied the state of the heap after the
>> collector has completed. What is the intent of CollectedHeap?
>
> No, CollectedHeap is the actual current GC interface. This is the entry point to
> GC as far as the rest of runtime is concerned, see e.g. CollectedHeap*
> Universe::create_heap(), etc. Implementing CollectedHeap, CollectorPolicy, and
> BarrierSet are the bare minimum required for GC implementation today. [1]

Yep, and I'd like us to move towards tightening down the GC interface to
basically be cleaned up versions of CollectedHeap and BarrierSet.

CollectorPolicy and some other things that class drags along, like
AdaptiveSizePolicy, are way too collector specific and I don't think
that should be exposed to the rest of the VM. A GC policy is in my mind
inherently tied to the algorithms used by a specific GC. Attempts to
expose some "general" policy is bound to fail and I think the current
CollectorPolicy sort of shows that. The policy stuff is thankfully
rarely used by non-GC code, which makes thing easier. I'd like to move
the things that still makes sense in CollectorPolicy over to
CollectedHeap and the rest should become internal to the specific GCs
that need it. Various people have in the past done some good work to
move us in this direction, but we're not here yet.

cheers,
Per

>
> -Aleksey
>
> [1]
> http://hg.openjdk.java.net/jdk10/sandbox/hotspot/file/c503fa980f8a/src/share/vm/gc/epsilon
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

kirk.pepperdine@gmail.com
In reply to this post by Aleksey Shipilev-4

> On Apr 20, 2017, at 12:05 PM, Aleksey Shipilev <[hidden email]> wrote:
>
> On 04/20/2017 09:37 AM, Kirk Pepperdine wrote:
>>> Good stuff. However, one thing I'm not quite comfortable with is the
>>> introduction of the GC class (and its sub classes). I don't quite see the
>>> purpose of this interface split-up between GC and CollectedHeap. I view
>>> CollectedHeap as _the_ interface (but yes, it needs some love), and as a
>>> result I think the the functions you've exposed in the GC class actually
>>> belongs in CollectedHeap.
>>
>> I thought the name CollectedHeap implied the state of the heap after the
>> collector has completed. What is the intent of CollectedHeap?
>
> No, CollectedHeap is the actual current GC interface. This is the entry point to
> GC as far as the rest of runtime is concerned, see e.g. CollectedHeap*
> Universe::create_heap(), etc. Implementing CollectedHeap, CollectorPolicy, and
> BarrierSet are the bare minimum required for GC implementation today. [1]

Hi Aleksey,

Thanks for the explanation but I think my comment still stands.

Kind regards,
Kirk

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

kirk.pepperdine@gmail.com
In reply to this post by Roman Kennke-6

> On Apr 20, 2017, at 1:42 PM, Roman Kennke <[hidden email]> wrote:
>
> Am 18.04.2017 um 14:01 schrieb Per Liden:
>> Hi Roman,
>>
>> On 2017-04-12 16:46, Roman Kennke wrote:
>>> I spent some more time working on the GC interface prototype and wanted
>>> to share it with you:
>>>
>>> http://cr.openjdk.java.net/~rkennke/gc-interface/webrev.02/
>>> <http://cr.openjdk.java.net/%7Erkennke/gc-interface/webrev.02/>
>>>
>>> Notable changes:
>>>
>>> - It's now based on JDK10 (specifically,
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot changeset 12853:d276073fda85)
>>> - I focused on better CMS isolation:
>>>  - Most CMS specific stuff from GenCollectedHeap now resides in
>>> specific subclass CMSHeap
>>>  - Same for CardTableModRefBSForCTRS -> CMSBarrierSet
>>>  - Factored everything related to always_do_update_barrier_set into CMS
>>> subclasses
>>
>> Good stuff. However, one thing I'm not quite comfortable with is the
>> introduction of the GC class (and its sub classes). I don't quite see
>> the purpose of this interface split-up between GC and CollectedHeap. I
>> view CollectedHeap as _the_ interface (but yes, it needs some love), and
>> as a result I think the the functions you've exposed in the GC class
>> actually belongs in CollectedHeap.
>
> Well yes, I was thinking about that too. CollectedHeap currently is
> _the_ central interface. However, I already found it quite crammed.
> Plus, there are other 'interfaces' that make up the 'GC interface', e.g.
> BarrierSet, CollectorPolicy, and some other stuff (that I listed in the
> JEP), and I thought I'd rather create a new hub-kindof interface that
> manages all those sub-interfaces. I am not against putting all this into
> CollectedHeap (and hopefully, cleaning up CollectedHeap too). I found it
> cleaner the way I did it though.

+1 on separating out BarrierSet and CollectorPolicy.

Regards,
Kirk

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Roman Kennke-6
In reply to this post by Per Liden
Am 20.04.2017 um 14:01 schrieb Per Liden:

> On 2017-04-20 12:05, Aleksey Shipilev wrote:
>> On 04/20/2017 09:37 AM, Kirk Pepperdine wrote:
>>>> Good stuff. However, one thing I'm not quite comfortable with is the
>>>> introduction of the GC class (and its sub classes). I don't quite
>>>> see the
>>>> purpose of this interface split-up between GC and CollectedHeap. I view
>>>> CollectedHeap as _the_ interface (but yes, it needs some love), and
>>>> as a
>>>> result I think the the functions you've exposed in the GC class
>>>> actually
>>>> belongs in CollectedHeap.
>>>
>>> I thought the name CollectedHeap implied the state of the heap after the
>>> collector has completed. What is the intent of CollectedHeap?
>>
>> No, CollectedHeap is the actual current GC interface. This is the
>> entry point to
>> GC as far as the rest of runtime is concerned, see e.g. CollectedHeap*
>> Universe::create_heap(), etc. Implementing CollectedHeap,
>> CollectorPolicy, and
>> BarrierSet are the bare minimum required for GC implementation today. [1]
>
> Yep, and I'd like us to move towards tightening down the GC interface to
> basically be cleaned up versions of CollectedHeap and BarrierSet.
>
> CollectorPolicy and some other things that class drags along, like
> AdaptiveSizePolicy, are way too collector specific and I don't think
> that should be exposed to the rest of the VM.
Right, I totally agree with this.

BTW, another reason for making a new GC interface class instead of
further bloating CollectedHeap as the central interface was that there
is way too much implementation stuff in CollectedHeap. Ideally, I'd like
to have a true interface with no or only trivial implementations for the
declared methods, and most importantly nothing that's only ever needed
by the GC itself (and never called by the runtime). But as I said, I'm
not against a serious refactoring and tightening-up of CollectedHeap
instead.

Cheers,
Roman


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GC interface update

Per Liden
On 04/20/2017 02:29 PM, Roman Kennke wrote:

> Am 20.04.2017 um 14:01 schrieb Per Liden:
>> On 2017-04-20 12:05, Aleksey Shipilev wrote:
>>> On 04/20/2017 09:37 AM, Kirk Pepperdine wrote:
>>>>> Good stuff. However, one thing I'm not quite comfortable with is the
>>>>> introduction of the GC class (and its sub classes). I don't quite
>>>>> see the
>>>>> purpose of this interface split-up between GC and CollectedHeap. I view
>>>>> CollectedHeap as _the_ interface (but yes, it needs some love), and
>>>>> as a
>>>>> result I think the the functions you've exposed in the GC class
>>>>> actually
>>>>> belongs in CollectedHeap.
>>>>
>>>> I thought the name CollectedHeap implied the state of the heap after the
>>>> collector has completed. What is the intent of CollectedHeap?
>>>
>>> No, CollectedHeap is the actual current GC interface. This is the
>>> entry point to
>>> GC as far as the rest of runtime is concerned, see e.g. CollectedHeap*
>>> Universe::create_heap(), etc. Implementing CollectedHeap,
>>> CollectorPolicy, and
>>> BarrierSet are the bare minimum required for GC implementation today. [1]
>>
>> Yep, and I'd like us to move towards tightening down the GC interface to
>> basically be cleaned up versions of CollectedHeap and BarrierSet.
>>
>> CollectorPolicy and some other things that class drags along, like
>> AdaptiveSizePolicy, are way too collector specific and I don't think
>> that should be exposed to the rest of the VM.
>
> Right, I totally agree with this.
>
> BTW, another reason for making a new GC interface class instead of
> further bloating CollectedHeap as the central interface was that there
> is way too much implementation stuff in CollectedHeap. Ideally, I'd like
> to have a true interface with no or only trivial implementations for the
> declared methods, and most importantly nothing that's only ever needed
> by the GC itself (and never called by the runtime). But as I said, I'm
> not against a serious refactoring and tightening-up of CollectedHeap
> instead.

Yes, I'd like to keep CollectedHeap as the main interface, but I
completely agree that CollectedHeap currently contains too much
implementation stuff that we probably want to move out.

cheers,
Per

>
> Cheers,
> Roman
>
12
Loading...