From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tneumann@users.sourceforge.net>
Received: from tneumann.de (tneumann.de [IPv6:2a03:4000:6:11cc::1])
 by sourceware.org (Postfix) with ESMTPS id 1AA1239A40C8
 for <gcc@gcc.gnu.org>; Tue, 12 May 2020 07:30:32 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1AA1239A40C8
Received: from [IPv6:2003:ee:af3b:d300:a511:fd91:144f:4ce2]
 (p200300EEAF3BD300A511FD91144F4CE2.dip0.t-ipconnect.de
 [IPv6:2003:ee:af3b:d300:a511:fd91:144f:4ce2])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest
 SHA256) (No client certificate requested)
 by tneumann.de (Postfix) with ESMTPSA id C97CC11F7B7;
 Tue, 12 May 2020 09:30:30 +0200 (CEST)
Subject: Re: performance of exception handling
To: Richard Biener <richard.guenther@gmail.com>
Cc: David Edelsohn <dje.gcc@gmail.com>, Florian Weimer <fweimer@redhat.com>,
 GCC Development <gcc@gcc.gnu.org>
References: <0bbdaab7-c083-e14e-6227-27713dab9657@users.sourceforge.net>
 <874ksmg3fb.fsf@oldenburg2.str.redhat.com>
 <CAGWvnynP2gji-XBVY9=LHWR_5wTp6eXGQsxCRSLU9pzCJM8LZA@mail.gmail.com>
 <71cc7b40-d3c5-58a6-2da4-0b55f2da4e10@users.sourceforge.net>
 <CAFiYyc1eFQCW-aZMetgM3gmh0LBHU_r12pQCCF2yP2W4ga0bwA@mail.gmail.com>
From: Thomas Neumann <tneumann@users.sourceforge.net>
Message-ID: <8cc4bfb6-cf9a-7644-bd69-ba8d328f4dcf@users.sourceforge.net>
Date: Tue, 12 May 2020 09:30:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAFiYyc1eFQCW-aZMetgM3gmh0LBHU_r12pQCCF2yP2W4ga0bwA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, JMQ_SPF_ALL,
 KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2020 07:30:33 -0000

> Some people use exceptions to propagate "low memory" up which
> made me increase the size of the EH emergency pool (which is
> used when malloc cannot even allocate the EH data itself) ...
> 
> So yes, people care.  There absolutely has to be a path in
> unwinding that allocates no (as little as possible) memory.

note that I would not allocate at all in the unwinding path. I would
allocate memory when new frames are registered, but unwinding would be
without any allocations.

Of course there is a trade-off here. We could delay allocating the
lookup structures until the first exception occurs, in order to speed up
programs that never throw any exceptions. But that would effectively
force us to implement a "no memory" fallback, for exactly the reason you
gave, as something like bad_alloc might be the first exception that we
encounter.

Thomas