[11u] RFR 8224202: Speed up Properties.load

Aleksey Shipilev shade at redhat.com
Wed Aug 21 09:47:18 UTC 2019


On 8/8/19 11:41 PM, Langer, Christoph wrote:
>> Original RFE:
>>   https://bugs.openjdk.java.net/browse/JDK-8224202
>>   http://hg.openjdk.java.net/jdk/jdk/rev/cdb107ca16e6

> Oh boy, it really took me a while to understand what ArraysSupport::newLength is supposed to do.
> And actually, after I think I grasped it, I would think that your inline implementation isn't
> quite correct. [...] This is probably just a theoretical cornercase, though.
Yes.

> The implementation in the sense of ArraysSupport.newLength would be:

...

Okay, that makes more sense. I rewrote that block as:

 569                         int maxLen = Integer.MAX_VALUE - 8; // VM allocation limit
 570                         int newLen = len * 2;
 571                         if (newLen < 0 || newLen > maxLen) { // check for under/overflow
 572                             newLen = maxLen;
 573                         }
 574                         if (newLen <= len) { // still not good? last-ditch attempt then
 575                            if (len != Integer.MAX_VALUE) {
 576                                newLen = len + 1;
 577                            } else {
 578                                throw new OutOfMemoryError("Required array length too large");
 579                            }
 580                         }

Note I fixed the condition at L574 to be up-to-the point: we need to capture the bad case when
resizing did not happen at all, and that is when we do the last-ditch attempt.

Full webrev:
  https://cr.openjdk.java.net/~shade/8224202/webrev.11u.02/

Still passes tier1.

> Alternatively, why not add ArraysSupport::newLength? E.g. backport JDK-8223593 (although maybe 
> aph wouldn't like it ��)?

I would not like it either. Easier to inline the only new use here...

-- 
Thanks,
-Aleksey



More information about the jdk-updates-dev mailing list