RFR: 8210753: Make ThreadLocalAllocBuffer::resize() public
per.liden at oracle.com
Fri Sep 14 16:08:55 UTC 2018
On 09/14/2018 05:12 PM, JC Beyler wrote:
> Hi Per,
> I noticed when working on this code that I always disliked the resize
> method naming: really what it is doing is calculating the next size for
> a given TLAB to be done when the tlab is full. I don't think we'd
> automatically want to rename the resize method but it is only called
> once currently so changing its name could be done here easily and any
> reader would understand that tlab.resize() does not resize; it merely
> calculates the next size.
> Were you to consider it, I think calculate_next_size would seem to be
> more appropriate (and we could remove the comment in the first line of
> the method since now it is redundant with the name of the method).
> Anyway, whatever you do decide, it looks good to me (not a reviewer though),
I see your point. However, there are never any active TLABs (they have
all been retired) when resize() is called by the GC, so it can only
refer to the size of the next allocated TLAB. That might not be super
obvious, but I think I'd prefer to keep the name, since it has a history
and I think this well understood among the GC folks.
Thanks for reviewing!
> On Fri, Sep 14, 2018 at 4:53 AM Per Liden <per.liden at oracle.com
> <mailto:per.liden at oracle.com>> wrote:
> Thanks Erik!
> On 09/14/2018 01:47 PM, Per Liden wrote:
> > Make ThreadLocalAllocBuffer::resize() public to allow a GC to resize
> > TLABs in parallel. With resize() public I propose that we remove
> > ThreadLocalAllocBuffer::resize_all_tlabs() and let
> > CollectedHeap::resize_all_tlabs() iterate over the threads, just
> > CollectedHeap::ensure_parsability() does.
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210753
> > Webrev: http://cr.openjdk.java.net/~pliden/8210753/webrev.0
> > /Per
More information about the hotspot-gc-dev