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

Vitaly Davidovich vitalyd at gmail.com
Wed Oct 10 14:10:35 PDT 2012


The reason it looks strange to me (and of course, it could just be me) is
because nothrow_t is, in typical c++ code, always passed to the
non-throwing operator new; I've never seen it be used as a discriminator
*to* throw.  Again, just my 2 pennies though. :)

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

Sent from my phone
On Oct 10, 2012 4:54 PM, "Keith McGuigan" <keith.mcguigan at oracle.com> wrote:

>
> Yeah, I hear what you're saying.  But 'nothrow_t' means "nothrow type".
>  Assigning a value of "dothrow" or "nothrow" to a variable of type "nothrow
> type" makes sense to me -- but I do have a weird viewpoint sometimes.
>
> An enum would work fine too, as far as I'm concerned.  It seems wasteful
> to not reuse the perfectly fine type and value we already have in
> nothrow_t/nothrow, but hey, electrons are cheap...
>
> --
> - Keith
>
> On 10/10/2012 4:46 PM, Vitaly Davidovich wrote:
>
>> Yeah, I figured it was done this way to save on code, it just doesn't
>> look typical/idiomatic I think and hence requires the "dothrow"
>> discriminator; dothrow = nothrow_t looks odd as well.
>>
>> Instead of bool true/false, could use an enum to make it more readable.
>>
>> Cheers guys
>>
>> Sent from my phone
>>
>> On Oct 10, 2012 4:41 PM, "Keith McGuigan" <keith.mcguigan at oracle.com
>> <mailto:keith.mcguigan at oracle.**com <keith.mcguigan at oracle.com>>> wrote:
>>
>>
>>
>>     On 10/10/2012 4:29 PM, Vitaly Davidovich wrote:
>>
>>         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?
>>
>>
>>     The problem with doing it that way is that it's harder to share code
>>     in the implementation of the allocation routines.  Either all of the
>>     routines (all the way down) need to be overloaded (and duplicated),
>>     or you need to both the overloads to call into a common subroutine
>>     which takes some parameter which indicates the throw mode.  It could
>>     be a 'bool', but why not just use a std::nothrow_t instead?  It's
>>     much more descriptive at the callsite for what is actually going on,
>>     rather than a naked 'true' or 'false' which requires one to check
>>     the declaration to see the purpose.
>>
>>     That's essentially what this code is doing:  for the parts that are
>>     common, the nothrow/dothrow values are used as the discriminator.
>>
>>     (Oh and I give this a thumbs-up, Nils, once you get rid of that
>>     leftover line in thread.cpp).
>>
>>     --
>>     - Keith
>>
>>


More information about the hotspot-dev mailing list