RFR: 8318586: Explicitly handle upcall stub allocation failure [v3]

[Jorn Vernee]

On Fri, 27 Oct 2023 08:52:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> OOME is pretty much understood to be possible anywhere, given it is a VirtualMachineError. We often do not document it explicitly. The risk with documenting it is that it gives the impression that other methods, which don't document it, can never throw it. A rough grep for `@throws OutOfMemoryError` reveals only 15 classes in java.base that explicitly document this.
>
> That said, I also agree with @dholmes-ora - e.g. I'm not sure how much OOME is important to document here, since it reflects an internal state of the JVM, rather than something the client can do something about.
> 
> E.g. if you create an allocator with `SegmentAllocator::slicingAllocator`, at some point you are going to run out of space in the underlying segment, so it makes sense to report failures (and to document why that happens). But in this case the documentation is going to be very vague, and I don't think it provides a lot of value.

Ok. I figured it was similar to Unsafe::allocateMemory, which also documents to OOME. But then again, the user is not directly interested in memory in this case.

I"ll remove these `@throws` tags then

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1374303739