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

[David Holmes]

On 12/10/2012 2:21 PM, David Holmes wrote:
> Hi Nils,
>
> There are a number of existing bugs/RFEs in this area - not sure we
> needed yet another.
>
> On 11/10/2012 10:55 PM, Nils Loodin wrote:
>> Hey guys.
>>
>> Your comments on this issue are great! So here's another version that
>> uses an enum instead of std::nothrow_t trickery!
>>
>> http://cr.openjdk.java.net/~nloodin/8000617/webrev.03/
>
> I dislike the std::nothrow usage that NMT introduced (there aren't even

Apologies it wasn't NMT that introduced this - it is a bit older than 
that: April 2011. See
https://jbs.oracle.com/bugs/browse/JDK-7036747

and some comments in

https://jbs.oracle.com/bugs/browse/JDK-4719004

Till then we had avoided any use of C++ std:: stuff - particularly 
anything related to the exception mechanism, which we don't use at all.

> any exceptions involved!) but introducing a completely different
> mechanism seems counter-productive. I prefer the "alloc fail strategy"
> approach but would like to see this solved holistically, replacing
> std::nothrow. Given there exist bigger RFE's to have the VM handle all
> OOM situations gracefully rather than just aborting, I'd rather not see
> just another point-patch put in place.

The bigger problem is probably still too big to really handle - so 
either copy what we already introduced for CHeapObj to ResourceObj for 
consistency, or replace both with something better.

Cheers,
David
-----

> For the record I found the original proposal extremely confusing:
> nothrow_constant vs throw_constant.
>
> Sorry.
>
> David
> -----
>
>> Regards,
>> Nils Loodin
>>
>>
>>
>>
>> On 10/11/2012 01:21 PM, Dmitry Samersoff wrote:
>>> Keith,
>>>
>>> Personally, I would prefer explicit AllocWithoutThrow(...) function.
>>>
>>> -Dmitry
>>>
>>>
>>>
>>> On 2012-10-11 03:40, Keith McGuigan wrote:
>>>>
>>>> Personally, I don't have strong feelings on how this is implemented,
>>>> other than it should be done in a way that's maintainable going forward
>>>> and easily understandable by future generations of hotspot developers.
>>>> With this in mind, the only potential solution that I don't like is
>>>> using a boolean with naked true/false values as discriminators.
>>>>
>>>> Using some sort of "failure mode" parameter is the natural way to do
>>>> this, whether it be enums, std::nothrow_t, or whatever. Since
>>>> std::nothrow_t already has a type and one value, and is already present
>>>> in the few places we're interested in, it seemed easy to simple just
>>>> add
>>>> a new value to use. However if this ends up being confusing because
>>>> this is not the normal use of std::notype_t, then fine, we can do
>>>> something else.
>>>>
>>>> --
>>>> - Keith
>>>
>>>
>>