[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