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

[Keith McGuigan]

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