220 7339 article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Predynamic Storage Duration Date: Wed, 16 Oct 2013 22:39:12 -0700 (PDT) Lines: 117 Approved: news@gmane.org Message-ID: References: <6fabf6ab-eb9b-42a1-b4a4-deacb2d30ba1@isocpp.org> <4504332.o5vA4BOQ0N@tjmaciei-mobl2> <4504539.WOgnALR3dk@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_278_24444519.1381988352568" X-Trace: ger.gmane.org 1381988351 4230 80.91.229.3 (17 Oct 2013 05:39:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Oct 2013 05:39:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBAPQ7WJAKGQE5SBDF4Y@isocpp.org Thu Oct 17 07:39:16 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VWgIm-0001RK-3e for gclcip-std-proposals@m.gmane.org; Thu, 17 Oct 2013 07:39:16 +0200 Original-Received: by mail-vc0-f199.google.com with SMTP id lf12sf3318252vcb.6 for ; Wed, 16 Oct 2013 22:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=SlELvZjO9entB+gu0hJq0i7m+ochoeevxkAKLLu39CU=; b=FYOlFIQrnw4hyh1Pe2iR6V3vrHyx0yxJJwYHEnmm5kAyoQyS4j19mbSLOsujcCzNCo 8UDSLI3/UsX67hjddNKIA5lj5Av6bBad6yG9DzVBSsS2K4UOMlUJN7pCzJNe7RGYaNPr n2/KozfZjirhyHCAk1oeovgD7/m9D0ovUN0+akYiQcUXnbhbAVZVFe8lQxK6bbm5cdWz S0fbu6/y3vitJ9LeYhni/QaU3qGnr5QkwwElUV9GmVjcPG9JE8j9cajERzA12c6bFaGh LJpVez8I+HottFvhPu9MRn4y/TLOtPyVY2D06mlxb5VXNeIcsVjRok001ZvN2Z0wD2RL zm/g== X-Received: by 10.52.64.177 with SMTP id p17mr2033640vds.3.1381988354846; Wed, 16 Oct 2013 22:39:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.29.6 with SMTP id f6ls793098qeh.3.gmail; Wed, 16 Oct 2013 22:39:13 -0700 (PDT) X-Received: by 10.49.13.40 with SMTP id e8mr26549qec.1.1381988353141; Wed, 16 Oct 2013 22:39:13 -0700 (PDT) In-Reply-To: <4504539.WOgnALR3dk@tjmaciei-mobl2> X-Original-Sender: andrewtomazos@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:7339 Archived-At: ------=_Part_278_24444519.1381988352568 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, October 16, 2013 5:41:02 PM UTC+2, Thiago Macieira wrote: > > it doesn't matter that the "Hello\0" is in .rodata or .preheap; something > needs > to know its address and allocate memory for it. > ..rodata needs to be accessible for the lifetime of the program, the ..preheap section can be unloaded immediately after loading has completed, reclaiming its resources. (If you mix them together it will lock the pages in memory.) The concern is about resource management. If we didn't care about resource usage then making the current normal delete a no-op would still result in a correct program, it would just use extra memory over its lifetime, making the heap into a memory pool. Again, I'm not questioning the benefit of the feature of using operator > new() > in constexpr. I am questioning the "reallocate preheap into real heap at > load- > time". > Such an architecture would use less resources. Placing preheap objects in the heap allows them to be deleted during run-time, reclaiming their resources. If we placed them in .rodata they could not be deleted. Consider the following program: typedef int T; constexpr T* p = new T(3); static_assert(*p == 3); int main() { /* loader() */ first_half(); delete p; second_half(); } In the above, for the duration of second_half() the resources used to back the predynamic object are available for use. This is achieved because preheap objects are loaded into the heap. Note the .preheap section is unloaded by the end of `loader()`. If we allocated it as a static storage duration object as you suggest, the resources would still be occupied for second_half(). -- --- 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 email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_278_24444519.1381988352568 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wednesday, October 16, 2013 5:41:02 PM UTC+2, Thiago Ma= cieira wrote:
it=20 doesn't matter that the "Hello\0" is in .rodata or .preheap; something need= s=20
to know its address and allocate memory for it.
 
.rodata needs to be accessible for the life= time of the program, the .preheap section can be unloaded immediately after= loading has completed, reclaiming its resources.  (If you mix them to= gether it will lock the pages in memory.)  The concern is about resour= ce management.  If we didn't care about resource usage then making the= current normal delete a no-op would still result in a correct program, it = would just use extra memory over its lifetime, making the heap into a memor= y pool.

Again, I'= m not questioning the benefit of the feature of using operator new()=20
in constexpr. I am questioning the "reallocate preheap into real heap a= t load-
time".

Such an architecture would use less resources.&nb= sp; Placing preheap objects in the heap allows them to be deleted during ru= n-time, reclaiming their resources.  If we placed them in .rodata they= could not be deleted.

Consider the following program:

 =    typedef int T;

    constexpr T* p =3D ne= w T(3);

    static_assert(*p =3D=3D 3);

 =    int main()
    {
    =     /* loader() */
      &n= bsp; first_half();
        delete p;<= br>        second_half();
  = ;  }

In the above, for the duration of second_half() the resour= ces used to back the predynamic object are available for use.  This i= s achieved because preheap objects are loaded into the heap.  Note the= .preheap section is unloaded by the end of `loader()`.

If we alloca= ted it as a static storage duration object as you suggest, the resources wo= uld still be occupied for second_half().

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_278_24444519.1381988352568-- .