RFR: 8210753: Make ThreadLocalAllocBuffer::resize() public

[Per Liden]

Hi JC,

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!

cheers,
Per

> Jc
> 
> 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!
> 
>     /Per
> 
>     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
>     like
>      > CollectedHeap::ensure_parsability() does.
>      >
>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8210753
>      > Webrev: http://cr.openjdk.java.net/~pliden/8210753/webrev.0
>      >
>      > /Per
> 
> 
> 
> -- 
> 
> Thanks,
> Jc