Regarding the wording, I don't think either "implementation limit" or "VM limit"
is correct, at least not in all the cases.
If we were using ArraysSupport.newLength, the error messages are as follows:
1) Actual shortage of heap space. Hotspot generates this:
OutOfMemoryError: Java hea
Hi Jim,
In Unsafe.java: 632: the "Unable to allocate 98494837395: doesn't read
very well.
Please add " bytes" to the end.
I would probably drop "array" from all the messages but at least in the
String* cases.
As Martin notes, the array is an implementation detail.
(And i still prefer "implem
Thank you.
> On Jun 10, 2020, at 2:10 PM, Martin Buchholz wrote:
>
> On Wed, Jun 10, 2020 at 9:35 AM Jim Laskey wrote:
>
>>> ---
>>> It looks like
>>> newCap > oldCap
>>> is always true, so we should delete the test?
>>>if (newCap > oldCap && queue == array)
>>> ---
>>
>> If o
On Wed, Jun 10, 2020 at 9:35 AM Jim Laskey wrote:
> > ---
> > It looks like
> > newCap > oldCap
> > is always true, so we should delete the test?
> > if (newCap > oldCap && queue == array)
> > ---
>
> If oldCap == MAX_ARRAY_SIZE wouldn't newCap == oldCap
newLength's contract is t
> On Jun 10, 2020, at 1:15 PM, Martin Buchholz wrote:
>
> I took a look at PriorityBlockingQueue.
>
> Part of converting to ArraysSupport involves deleting the local orphan
> MAX_ARRAY_SIZE; that needs to be done.
Removed.
>
> ---
> It looks like
> newCap > oldCap
> is always true, so we s
I took a look at PriorityBlockingQueue.
Part of converting to ArraysSupport involves deleting the local orphan
MAX_ARRAY_SIZE; that needs to be done.
---
It looks like
newCap > oldCap
is always true, so we should delete the test?
if (newCap > oldCap && queue == array)
---
In Patt
Will push if no comments by EOB.
> On Jun 8, 2020, at 2:22 PM, Jim Laskey wrote:
>
> Revised to use a consistent error message. Modified AbstractStringBuilder and
> PriorityBlockingQueue to use ArraysSupport.newLength(). Didn't modify
> ByteArrayChannel and UnsyncByteArrayOutputStream since th
