On sexta-feira, 24 de mar=C3=A7o de 2017 14:29:44 PDT Sean Middleditch wrot=
e:
> There may very well be a case to be made for non-throwing new as a new
> implementation-specific option, e.g. something like -fnoexcept-new, thoug=
h
> I'm unsure who the target audience for that would be.

And this being a compiler-specific extension, you can already achieve this =
by=20
simply adding this forward declaration somewhere in a header:

 void *operator new(std::size_t) noexcept;

GCC and ICC grok it just fine and remove exceptional codepaths, whereas Cla=
ng=20
"sees" a previous declaration of operator new that conflicts with that. Pla=
y=20
with the compiler selection at
 https://godbolt.org/g/sBokXT

MSVC didn't change its code generation (you need to change the arguments to=
=20
the compiler to -O2 -EHsc).

Just make sure you don't #include <new>. Or convince your compiler vendor t=
o=20
implement this.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3931461.zpjgiNtsP7%40tjmaciei-mobl1.

.

Em quarta-feira, 5 de abril de 2017, =C3=A0s 06:07:05 PDT, Sergey Zubkov es=
creveu:
> Well.. yes, there are benefits to being able to put "noexcept" on many
> functions that might transitively end up allocating something.
> This is viral. In fact, there is precedent: g_malloc from the ubiquitous
> glib terminates on OOM. They have a "try" variant, but numerous libraries
> that use glib just call g_malloc, and that infects a large part of the
> Linux ecosystem. For example, Mozilla does some heroics to survive many
> OOMs, except when the last straw allocation happens to be a g_malloc deep
> in the call stack across several third-party libraries.

The rule of thumb is that you only check for success in large allocations=
=20
(multiple megabytes). Anything small is not worth the test and is best hand=
led=20
by terminating the application. After a failed large allocation, the=20
application can reasonably continue working, assuming that it may allocate=
=20
small amounts as it's required to react to other user events. It may even s=
how=20
an OOM message to the user.

The problem with large allocations is that they can be served by an=20
overcommitted memory map, so they can succeed even if there's no memory lef=
t=20
to back it up. Usually, by the time this happens, the system has been swapp=
ing=20
hard for some time or at least the kernel is aggressively dropping clean pa=
ges=20
and having to swap them back in, so it's either way in a state of such=20
slowness that the user is unlikely to have allowed it to last.

When small allocations start failing, it's highly unlikely that the=20
application can continue working. If the system has been allowed to reach s=
uch=20
a state, your application will be competing with others, so some allocation=
s=20
may succeed and the majority will not. It's also unlikely you will reach th=
e=20
point where you can actually save any data.

And then there's the OOM killer...

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1853850.6IXc3aSH7i%40tjmaciei-mobl1.

.

On 5 April 2017 at 17:55, Thiago Macieira <thiago@macieira.org> wrote:
> Em quarta-feira, 5 de abril de 2017, =C3=A0s 06:07:05 PDT, Sergey Zubkov =
escreveu:
>> Well.. yes, there are benefits to being able to put "noexcept" on many
>> functions that might transitively end up allocating something.
>> This is viral. In fact, there is precedent: g_malloc from the ubiquitous
>> glib terminates on OOM. They have a "try" variant, but numerous librarie=
s
>> that use glib just call g_malloc, and that infects a large part of the
>> Linux ecosystem. For example, Mozilla does some heroics to survive many
>> OOMs, except when the last straw allocation happens to be a g_malloc dee=
p
>> in the call stack across several third-party libraries.
>
> The rule of thumb is that you only check for success in large allocations
> (multiple megabytes). Anything small is not worth the test and is best ha=
ndled
> by terminating the application. After a failed large allocation, the
> application can reasonably continue working, assuming that it may allocat=
e
> small amounts as it's required to react to other user events. It may even=
 show
> an OOM message to the user.
>
> The problem with large allocations is that they can be served by an
> overcommitted memory map, so they can succeed even if there's no memory l=
eft
> to back it up. Usually, by the time this happens, the system has been swa=
pping
> hard for some time or at least the kernel is aggressively dropping clean =
pages
> and having to swap them back in, so it's either way in a state of such
> slowness that the user is unlikely to have allowed it to last.
>
> When small allocations start failing, it's highly unlikely that the
> application can continue working. If the system has been allowed to reach=
 such
> a state, your application will be competing with others, so some allocati=
ons
> may succeed and the majority will not. It's also unlikely you will reach =
the
> point where you can actually save any data.
>
> And then there's the OOM killer...


Even small allocations can sometimes be gracefully recovered from;
they may be caused by
a resource limit set by ulimit. In such cases, the small allocations
do not fail because of
necessarily competing with other applications.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUZV595icstmQJY%3DY1XQWUvkWXrok%2BnaQSwCt-p=
rAPpFoQ%40mail.gmail.com.

.

Em quarta-feira, 5 de abril de 2017, =C3=A0s 08:19:50 PDT, Ville Voutilaine=
n=20
escreveu:
> Even small allocations can sometimes be gracefully recovered from;
> they may be caused by
> a resource limit set by ulimit. In such cases, the small allocations
> do not fail because of
> necessarily competing with other applications.

True, but not always. This is a hard to solve problem in a modern multitask=
ing=20
system with virtual memory. Even if a single process is limited due to a=20
ulimit and not by overall OOM condition, if you're reaching the point where=
=20
small allocations fail, you're already running the risk of being killed by=
=20
SIGBUS because a page that was overcommitted cannot be provided without=20
exceeding the limit.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2833477.orfLXrRnKf%40tjmaciei-mobl1.

.