May be:
..., then a new internal array becomes allocated and refilled with greater
capacity.
... to give a hint, that this action may be expensive.
-Ulf
Am 05.05.2015 um 19:47 schrieb Aleksey Shipilev:
Hi again,
Here is a new webrev:
http://cr.openjdk.java.net/~shade/8076759/webrev.01/
Pruned the implementation details from expandCapacity Javadoc, and about
to submit a CCC for it.
Thanks,
-Aleksey.
On 05.05.2015 16:33, Roger Riggs wrote:
Hi Aleksey,
Thanks for checking the rounding alternative.
As for the CCC, since the implementation details are in the javadoc
then it will be needed either to remove the details or to update them.
I'd be inclined to try to remove them since they are there primarily for
performance.
Thanks, Roger
On 5/5/2015 4:31 AM, Aleksey Shipilev wrote:
Hi Roger,
On 05/01/2015 08:19 PM, Roger Riggs wrote:
Is there any additional benefit by rounding up the next multiple of 4
or 8.
That would avoid a few wasted bytes at the end of the buffer modulo the
allocation size.
It does not seem to help any further. Tried "plus32-round8", as in:
http://cr.openjdk.java.net/~shade/8076759/patches.txt
...and it performs similar to "plus32":
http://cr.openjdk.java.net/~shade/8076759/data-foot.png
http://cr.openjdk.java.net/~shade/8076759/data-perf.png
Otherwise, looks fine to me also.
I actually wonder if my change in ensureCapacity Javadoc requires a CCC?
On that topic, I also tempted to remove the implementation details from
the Javadoc there, since it does not play well with "describe what you
will do, not how would you do it".
Thanks,
-Aleksey.
