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

[David Holmes]

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 
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.

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
>>
>>
>