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

[Vitaly Davidovich]

Hi Nils,

In thread.cpp, line 1614 - what's its purpose? Some leftover code?

In allocation.cpp, "dothrow" constant is assigned std::nothrow_t but isn't
nothrow_t for *not* throwing? This constant is then used to actually signal
oom in one of the methods - seems odd.

Also, in ResourceObject::operator new() there's an assertion that nothrow_t
== std::nothrow - what's the purpose? Why would someone use this overload
if they're not looking to skip bad_alloc? What sort of error are you
thinking of here?

Finally, I think the idiomatic way to do this type of stuff is to have a
separate overload of the alloc function that accepts nothrow_t whereas you
seem to have functions that take nothrow_t as a parameter, but then you
check if its the "dothrow" constant inside to see if oom should be
reported.  It seems cleaner to have overloads where the one taking
nothrow_t automatically means don't throw?

Thanks

Sent from my phone
On Oct 10, 2012 4:02 PM, "Nils Loodin" <nils.loodin at oracle.com> wrote:

> Hi all!
>
> When looking to implement a feature where I wanted to do some allocations
> without the vm calling vm_exit_no_memory() when not able to allocate, I
> discovered this wasn't possible with ResourceObj-type obects. (It was
> however implemented in CHeapObj-type objects.
>
> Here's a patch to implement that.
>
> Now we can use (for instance) jcmd on a running production vm without fear
> that we will bring the vm down if the jcmd commands does allocations.
> (The commands themselves have to be implemented with this in mind though.)
>
> Webrev here:
> http://cr.openjdk.java.net/~nloodin/8000617/webrev.01/
>
> Regards,
> Nils Loodin
>