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.ri...@oracle.com
<mailto:roger.ri...@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
