[12] 8206403: ByteArrayOutputStream hugeCapacity method can return invalid capacity

[Roger Riggs]

Hi Brian,

A followup on the issues raised by Martin.

The original issue[1] was that the resize by doubling approach failed to 
take advantage
of nearly 1G of potential buffer space.
The new issue is raised against getting the last additional 2-6 bytes of 
buffer space before
the hitting the VM's implementation limit.

I don't think its worth the effort to try to ensure those last few bytes 
are available before throwing OOM.
Reconsidering, I would close the issue as WillNotFix for the reason that 
the application is
encountering an implementation limit.

Regards, Roger


[1] https://bugs.openjdk.java.net/browse/JDK-8055949

On 7/24/18 10:26 AM, Roger Riggs wrote:
> Hi Brian,
>
> The update looks fine.
>
> Roger
>
>
> On 7/23/18 5:49 PM, Brian Burkhalter wrote:
>> Hi Roger,
>>
>> Updated version: http://cr.openjdk.java.net/~bpb/8206403/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Ebpb/8206403/webrev.01/>
>>
>> On Jul 23, 2018, at 2:10 PM, Roger Riggs <Roger.Riggs at Oracle.com 
>> <mailto:Roger.Riggs at Oracle.com>> wrote:
>>
>>> You might want to add an @requires of 8Gb or whatever so the test 
>>> only runs on a system it can succeed on.
>>
>> Re-tested and changed to @requires 2g and dropped the @ignore.
>>
>>> I don't see the @randomness in the test.  (Other than perhaps 
>>> available heap).
>>
>> That was vestigial from copying the header from elsewhere.
>>
>>> ByteArrayOutputStream:121: A message indicating the nature of the 
>>> error would be useful.
>>
>> There was no message in the original file but I concur that one is 
>> better so I added one.
>>
>>> In the test, I don't think you need to fill the array, writing 0 is 
>>> just as good as 0xff.
>>
>> Changed.
>>
>> Thanks for the review.
>>
>> Brian
>