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