RFR: 8000617: It should be possible to allocate memory without the VM dying.

[John Rose]

On Oct 10, 2012, at 2:10 PM, Vitaly Davidovich wrote:

> John, I think your concerns would be ameliorated if these were separate
> overloads, right?

Yes.  Then the nothrow type is a singleton, whose value is never used (only noted to be present).  I'm kind of surprised that it's a global constant; there was a time when new (nothrow_t()) would have been the prescribed idiom, and that is safer.  But I am quite happily out of the loop on the latest C++ idioms.

Anyway, using "std" set off a small alarm bell for me.  (Keith, you know I'm a retro-C++ kind of guy.  HotSpot has always, and wisely, limited its dependencies on advanced C++ features.)

Seeing the reference comparison "&nothrow_arg == &really_throw_magic_value" set off big alarm bells.  That's what compiles to dirty machine code.  It also relies on parts of C++ that have been poorly specified in the past, i.e., the uniqueness of addressable constants.  All you need is a C++ compiler on some one-off platform to cleverly emit multiple local versions of nothrow and you are dead.

I would prefer to see both things go away, but certainly the latter.

Anything imported from the C++ exceptions world is a *bug* in our source base, not a new cool way of doing things.  We compile with -noex to simplify our ABI entanglements.

I propose that we treat new uses of std::nothrow (in NMT and wherever) as a bug.  Certainly it is not an "all clear" signal to double down on C++ exceptions of any sort.  (Not that anybody is going there yet, but there may be a slippery slope.)

— John