<div dir="ltr">Hi all,<div><br></div><div>Massive Bikeshed naming comment here - any reason why the interface isn't named GarbageCollector?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Cheers,<br>Martijn</div></div>
<br><div class="gmail_quote">On 24 April 2017 at 07:37, Per Liden <span dir="ltr"><<a href="mailto:per.liden@oracle.com" target="_blank">per.liden@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/20/2017 02:29 PM, Roman Kennke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 20.04.2017 um 14:01 schrieb Per Liden:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2017-04-20 12:05, Aleksey Shipilev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/20/2017 09:37 AM, Kirk Pepperdine wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Good stuff. However, one thing I'm not quite comfortable with is the<br>
introduction of the GC class (and its sub classes). I don't quite<br>
see the<br>
purpose of this interface split-up between GC and CollectedHeap. I view<br>
CollectedHeap as _the_ interface (but yes, it needs some love), and<br>
as a<br>
result I think the the functions you've exposed in the GC class<br>
actually<br>
belongs in CollectedHeap.<br>
</blockquote>
<br>
I thought the name CollectedHeap implied the state of the heap after the<br>
collector has completed. What is the intent of CollectedHeap?<br>
</blockquote>
<br>
No, CollectedHeap is the actual current GC interface. This is the<br>
entry point to<br>
GC as far as the rest of runtime is concerned, see e.g. CollectedHeap*<br>
Universe::create_heap(), etc. Implementing CollectedHeap,<br>
CollectorPolicy, and<br>
BarrierSet are the bare minimum required for GC implementation today. [1]<br>
</blockquote>
<br>
Yep, and I'd like us to move towards tightening down the GC interface to<br>
basically be cleaned up versions of CollectedHeap and BarrierSet.<br>
<br>
CollectorPolicy and some other things that class drags along, like<br>
AdaptiveSizePolicy, are way too collector specific and I don't think<br>
that should be exposed to the rest of the VM.<br>
</blockquote>
<br>
Right, I totally agree with this.<br>
<br>
BTW, another reason for making a new GC interface class instead of<br>
further bloating CollectedHeap as the central interface was that there<br>
is way too much implementation stuff in CollectedHeap. Ideally, I'd like<br>
to have a true interface with no or only trivial implementations for the<br>
declared methods, and most importantly nothing that's only ever needed<br>
by the GC itself (and never called by the runtime). But as I said, I'm<br>
not against a serious refactoring and tightening-up of CollectedHeap<br>
instead.<br>
</blockquote>
<br>
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.<br>
<br>
cheers,<br>
Per<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Roman<br>
<br>
</blockquote>
</blockquote></div><br></div>