Re: Sometimes constraints are questionable

On 6/5/20 1:48 PM, James Laskey wrote: I’m fixing the two in java.base. The other two are in different modules and would require changes to export. So you can file on those. I've filed https://bugs.openjdk.java.net/browse/JDK-8247373 to enhance the exception message, docs, and to add a t

Re: Sometimes constraints are questionable

I’m fixing the two in java.base. The other two are in different modules and would require changes to export. So you can file on those. 📱 > On Jun 5, 2020, at 5:36 PM, Stuart Marks wrote: > >  > >> On 6/3/20 10:36 AM, Stuart Marks wrote: >> 3) Integer wraparound/overflow during size computat

Re: Sometimes constraints are questionable

On 6/3/20 10:36 AM, Stuart Marks wrote: 3) Integer wraparound/overflow during size computation. AS.newLength generates this:     OutOfMemoryError: Required array length too large (3) is the only case generated by the library. In fact, AS.hugeLength() has oldLength and minGrowth parameters

Re: Sometimes constraints are questionable

On 6/3/20 6:20 AM, Jim Laskey wrote: I absolutely agree with the reasoning. ArraysSupport.newLength() is also probably easier for the compiler to optimize around (no exception.) I guess the only conflict here is to be meaningfully informative. The bug assigned to me (https://bugs.openjdk.ja

Re: Sometimes constraints are questionable

On 6/2/20 11:49 PM, David Holmes wrote: IIUC what you are saying is that MAX_ARRAY_LENGTH is treated as a soft-limit. A request for prefGrowth won't be allowed to exceed it. But if minGrowth takes the length passed it then the code tries to do the allocation that large anyway. If it succeeds we

Re: Sometimes constraints are questionable

Stuart (and Martin), I absolutely agree with the reasoning. ArraysSupport.newLength() is also probably easier for the compiler to optimize around (no exception.) I guess the only conflict here is to be meaningfully informative. The bug assigned to me (https://bugs.openjdk.java.net/browse/JDK-82

Re: Sometimes constraints are questionable

Hi Stuart, On 3/06/2020 8:08 am, Stuart Marks wrote: Hi Jim, This was mentioned previously in this thread but not discussed very much. I suggest you take a look at jdk.internal.util.ArraysSupport.newLength(). Ivan Gerasimov and I worked this over fairly closely last year, and I'm pretty sure

Re: Sometimes constraints are questionable

On Tue, Jun 2, 2020 at 3:09 PM Stuart Marks wrote: > 4) We might want to consider refactoring PriorityBlockingQueue and ArrayDeque > to > use ArraysSupport.newLength, in order to provide a consistent policy for > collections. Other growable-array-based collections (Vector, ArrayList, > PriorityQ

Re: Sometimes constraints are questionable

Hi Jim, This was mentioned previously in this thread but not discussed very much. I suggest you take a look at jdk.internal.util.ArraysSupport.newLength(). Ivan Gerasimov and I worked this over fairly closely last year, and I'm pretty sure it does what Martin is saying, which I also think is t

Re: Sometimes constraints are questionable

My mistake it's ArraysSupport.newLength that's failing here, String::replace pos = Arrays.copyOf(pos, ArraysSupport.newLength(p, 1, p >> 1)); newLength should be causing the exception but it in turn is passing the OOM size on to Arrays.copyOf The logic in ArraysSupport::newLeng

Re: Sometimes constraints are questionable

In the same light the test in String::replace int resultLen; try { resultLen = Math.addExact(valLen, Math.multiplyExact(++p, replLen - targLen)); } catch (ArithmeticException ignored) { throw new OutOfMemoryError("Stri

Re: Sometimes constraints are questionable

Thanks David will run with that, > On May 31, 2020, at 8:34 PM, David Holmes wrote: > > On 31/05/2020 12:29 am, Jim Laskey wrote: >> I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 >> Several classes throw >> OutOfMemoryE

Re: Sometimes constraints are questionable

I'm still not deeply reading the code in java.nio but I see in AbstractStringBuilder * Will not return a capacity greater than * {@code (MAX_ARRAY_SIZE >> coder)} unless the given minimum capacity * is greater than that. My intent was that a garden variety grow method would first g

Re: Sometimes constraints are questionable

On 1/06/2020 9:52 am, Martin Buchholz wrote: On Sun, May 31, 2020 at 4:35 PM David Holmes wrote: Not sure how we could have minCapacity < 0 at this point. It should have been checked before the call to grow, and grow will not make it negative. At least some of the grow methods were designed

Re: Sometimes constraints are questionable

On Sun, May 31, 2020 at 4:35 PM David Holmes wrote: > Not sure how we could have minCapacity < 0 at this point. It should have > been checked before the call to grow, and grow will not make it negative. At least some of the grow methods were designed so that callers did not have to do the checki

Re: Sometimes constraints are questionable

On 31/05/2020 12:29 am, Jim Laskey wrote: I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . I'm wondering why hugeCapacity in src/jdk.zipfs/share/classes/jdk/nio/zipf

Re: Sometimes constraints are questionable

On Sat, May 30, 2020 at 11:11 AM Florian Weimer wrote: > > * Martin Buchholz: > > > I wrote an earlier version of this grow logic, and then it was > > transplanted into other classes. > > > > We strongly suspect that the VM will throw OOME when we try to > > allocate an array beyond MAX_ARRAY_SIZE

Re: Sometimes constraints are questionable

* Martin Buchholz: > I wrote an earlier version of this grow logic, and then it was > transplanted into other classes. > > We strongly suspect that the VM will throw OOME when we try to > allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, > but we also consider the VM behavior a b

Re: Sometimes constraints are questionable

Hi Jim, This kind of code exists in other places too, trying to balance preferred grow sizes with necessary ones and implementation limits.  The rationale and design has been raised several times.  That last time it resulting in consolidating similar code into jdk.internalutil.ArraysUppport.n

Re: Sometimes constraints are questionable

On Sat, May 30, 2020 at 9:53 AM James Laskey wrote: > Understood. Just trying to balance correctness with providing meaningful > exceptions. > The VM should be providing meaningful exceptions. We might get OOME for any int array size. For attempts to allocate more than Integer.MAX_VALUE elemen

Re: Sometimes constraints are questionable

Understood. Just trying to balance correctness with providing meaningful exceptions. I suppose another approach is to let it all go deep and catch the error on the way back and provide the detail then. Not likely win any fans. 📱 > On May 30, 2020, at 12:30 PM, Martin Buchholz wrote: > > I

Re: Sometimes constraints are questionable

I wrote an earlier version of this grow logic, and then it was transplanted into other classes. We strongly suspect that the VM will throw OOME when we try to allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, but we also consider the VM behavior a bug that may eventually get fixe

Sometimes constraints are questionable

I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . I'm wondering why hugeCapacity in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java is defined as