Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

[Anthony Vanelverdinghe]

Hi Chris

Point well taken, but being unable to create a native thread is 
definitely a VirtualMachineError, and personally I don't care whether 
the JVM throws an OOME or any other kind of VirtualMachineError in that 
case.

My point was that I don't see how being unable to return a result 
because of a language limitation (i.e. arrays being indexed by integers, 
and thus limited to 2G for byte[]), has anything to do with 
OutOfMemoryError. I believe it would be much more logical to throw a 
recoverable RuntimeException in this case (e.g. 
java.lang.ArrayOverflowException, as an analog of 
java.nio.BufferOverflowException).

Anthony

On 12/03/2017 15:53, Christoph Engelbert wrote:
> Hey Anthony,
>
> The meaning is already overloaded, as "Cannot create native thread"
> is also an OutOfMemoryError and in like 99% of the cases means
> "Linux ran out of filehandles". The chance the OS really couldn't
> allocate a thread for the reason of no main memory available is very
> narrow :)
>
> Chris
>
> Am 3/12/2017 um 3:24 PM schrieb Anthony Vanelverdinghe:
>> Files::readAllBytes is specified to throw an OutOfMemoryError "if
>> an array of the required size cannot be allocated, for example the
>> file is larger that 2G". Now in Java 9, InputStream::readAllBytes
>> does the same.
>>
>> However, this overloads the meaning of OutOfMemoryError: either
>> "the JVM is out of memory" or "the resultant array would require
>> long-based indices".
>>
>> In my opinion, this overloading is problematic, because:
>> - OutOfMemoryError has very clear semantics, and I don't see the
>> link between OOME and the fact that a resultant byte[] would need
>> to be >2G. If I have 5G of free heap space, and try to read a 3G
>> file, I'd expect something like an UnsupportedOperationException,
>> but definitely not an OutOfMemoryError.
>> - the former meaning is an actual Error, whereas the latter is an
>> Exception from which the application can recover.
>> - developers might be tempted to catch the OOME and retry to read
>> the file/input stream in chunks, no matter the cause of the OOME.
>>
>> What was the rationale for using OutOfMemory here? And would it
>> still be possible to change this before Rampdown Phase 2?
>>
>> Kind regards,
>> Anthony
>>
>>