220 27955 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicolas Capens Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Specifier to cause the destructor to be called at last use instead of end of scope Date: Thu, 25 Aug 2016 21:24:27 +0000 Lines: 358 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11403430693178053aec06e7 X-Trace: blaine.gmane.org 1472160285 17282 195.159.176.226 (25 Aug 2016 21:24:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 25 Aug 2016 21:24:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6MN3XGLYIJNRH5XUCRUBGGK66EU@isocpp.org Thu Aug 25 23:24:40 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bd28c-0003xp-Ud for gclcip-std-proposals@m.gmane.org; Thu, 25 Aug 2016 23:24:39 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id x131sf8685484ite.1 for ; Thu, 25 Aug 2016 14:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=SMnXWODQrrlnnYcsT37eudpHHcYm5nQRzXEpzy9f1UQ=; b=fhFAF97d+mMZhjfHhYD4aSQVpt3lBJIjAtv/5vb84w7SgYc2VFk7sxfdfcCEqQbwp1 UI4O2C1GIWumb71b3M8H58hDh97TLKBSPrgch8hHa4QMMiAU+YDdf5YIljaH4G4r8hv0 29WrN4q8+yLnK+jC9i2p+3wVuEF8HpR+D/x6aBSfXcFnfggNLzz7iMb13hJDRgN1gWWO ycafUSrbIioL+yg+VpIR7/U/uVxKtIncn8Pn3Nh9oGVLFJHfTtl5uwbxHBJQucHiCHyy wlqtNEmjAnwsSk7MXNLWsDvucjbfeD4x+Gc4powWegn333gBoeWTuZGqjEuc9SuaTmOU lk1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SMnXWODQrrlnnYcsT37eudpHHcYm5nQRzXEpzy9f1UQ=; b=PBcslGm6xhrwZO35vWnM8kDMfzn7KCCxiW7p97uFxZ05QtxrQcdVUD9Fbzx/vqhReE FYF/Jt4VAAY/208vvDW74RuelEaX307nI09msGvNkVinkG43zVMZMCVzSZsqU8paq1Ec QanOpyTYGZrm81jhg82Mw8wWwIRNBKuaYyWIu2Lp3oRGu8AIBTm8GBIfgCN+QqbyJAIY jQnKmg+0bmRQxwNj4+JGbanA8W91cSHUb5q6XU/Vmxw/DPWPhY7VpGidz/o8eXqq2xAp JCAhqXJKiXoBzyeefLJxJQZgnbg0Zz3DJsP7V+kmtYCVHmFrO9vc3KTwlQqVpl78Cpfn bs5Q== X-Gm-Message-State: AE9vXwMFkN3Mkdskgas1QFD9g67apGMNTmkP3T1flqJfEBmBcP8z82TR5VBCjWxK176kCw== X-Received: by 10.36.189.143 with SMTP id x137mr254769ite.12.1472160279293; Thu, 25 Aug 2016 14:24:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.26.33 with SMTP id a30ls1818603ote.39.gmail; Thu, 25 Aug 2016 14:24:38 -0700 (PDT) X-Received: by 10.237.39.34 with SMTP id n31mr12874212qtd.55.1472160278319; Thu, 25 Aug 2016 14:24:38 -0700 (PDT) Original-Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com. [2607:f8b0:400d:c0d::22f]) by mx.google.com with ESMTPS id h82si11940131qke.74.2016.08.25.14.24.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Aug 2016 14:24:38 -0700 (PDT) Received-SPF: pass (google.com: domain of nicolas.capens@gmail.com designates 2607:f8b0:400d:c0d::22f as permitted sender) client-ip=2607:f8b0:400d:c0d::22f; Original-Received: by mail-qt0-x22f.google.com with SMTP id u25so29270032qtb.1 for ; Thu, 25 Aug 2016 14:24:38 -0700 (PDT) X-Received: by 10.200.35.169 with SMTP id q38mr13025006qtq.4.1472160277801; Thu, 25 Aug 2016 14:24:37 -0700 (PDT) In-Reply-To: X-Original-Sender: Nicolas.Capens@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of nicolas.capens@gmail.com designates 2607:f8b0:400d:c0d::22f as permitted sender) smtp.mailfrom=nicolas.capens@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:27955 Archived-At: --001a11403430693178053aec06e7 Content-Type: text/plain; charset=UTF-8 Thanks all for the initial feedback! It's clear to me now that I haven't defined "last use" very well, and giving it an accurate definition based on my limited knowledge of compiler lingo is going to be tricky. So let me take a step back and describe what real-world issues I'm trying to solve. The first example is one where I'd like the heap memory managed by an object to get freed at the same point where a scalar variable's register would be made available for a different variable: class Matrix { public: Matrix(size_t rows, size_t columns); auto ~Matrix(); // Eager destructor ... private: double *m; }; { Matrix a(10'000, 10'000) = ...; Matrix b(10'000, 10'000) = ...; Matrix c(10'000, 10'000) = ...; a += b; // Last use of b, destruct before the next line a += c; } The alternative of using explicit destruction is really inconvenient: { Matrix a(10'000, 10'000) = ...; Matrix b(10'000, 10'000) = ...; Matrix c(10'000, 10'000) = ...; a += b; b.~Matrix(); a += c; } As is reducing the scope: { Matrix a(10'000, 10'000) = ...; { Matrix b(10'000, 10'000) = ...; a += b; } Matrix c(10'000, 10'000) = ...; a += c; } It might not look that horrible when we're only dealing with one variable that can be destructed eagerly, but it quickly gets unmanageable to manually optimize code like this when using additional variables and longer expressions. So I wish to be able to convey to the compiler that my Matrix class is self-contained and can in have its destructor called before the end of the object's scope. Obviously it would be a bad idea to allow anyone to retrieve the Matrix::m pointer. If you want to keep access to the object's content, you'd need to keep a reference to the object itself. It would be unreasonable to require the compiler to determine if we're obtaining references to the object's innards and use that to extend its lifetime. But taking a reference to the object itself can easily be determined, just like is done with scalar variables to extend their liveness range. A second use case I have for this is to reduce the run-time optimization work of an EDSL used for JIT-compiling code: Reactor . The types that are used *represent* scalar variables (e.g. Int represents int), but have a complex implementation to keep track of the operations performed on them to later be used to generate code from. If the static C++ compiler called their destructor on their last use as the scalar they represent, optimizing the run-time generated code could be quicker. As for an example of optimizing mutex locking, take a class which takes exclusive ownership of a stream so you can write contiguous data to it: { Streamer s(stream); s.write("200"); s.write(" OK"); // Last use, call destructor which releases exclusive ownership so another thread can write something. do_something_else_before_end_of_scope(); } Of course in this trivial case you might just write "200 OK" in one go, but imagine a much lager stream of data that is composed of an unknown number of parts. There would be an overhead from allocating and reallocating storage for the whole. Also, if the reader of the stream can handle partial data then we don't want to delay streaming out the parts. So I hope this illustrates what I'm after. I'm convinced there's an unambiguous definition of "last use" that can provide us with the desired behavior in all of the above examples, without undue burden on the compiler's analysis. I think liveness analysis when treating the object as a scalar would give us all we need. One question I have though is whether liveness analysis of scalars is a "solved problem"? In other words are all optimizing compilers capable of producing equivalent, deterministic liveness analysis? If not, I still think a *conservative* eager destructor would be a great thing to have to optimize the above use cases. I don't think determinism is strictly necessary, since compilers already produce code that can behave differently depending on optimizations. Thanks again! - Nicolas On Thu, Aug 25, 2016 at 6:37 AM, Viacheslav Usov wrote: > On Wed, Aug 24, 2016 at 8:51 PM, wrote: > > > I'd like to propose a new kind of destructor that gets called after a > local object's last use, instead of at the end of its scope. > > "Destruct after last use" is generally known as "garbage collection". > There is no known deterministic solution to this general problem. This is > what many other comments have been about. You can only make this > deterministic if you provide some narrow definition of "last use". C++ has > such a narrow definition for local objects, it is the automatic scope > rules, simple and hugely successful. The question, then, is whether we > really need another competing definition, and whether we really gain much > with that additional complexity. > > Note I'm not assuming you would propose a non-deterministic definition. > > > The syntax for this could be an annotation of the destructor > declaration with a keyword, symbol, or attribute. For example, "auto > ~Object();", "volatile ~Object();", "~~Object();", or "[[eager]] > ~Object();". > > The assumption that one can decorate a *class* definition with "destruct > after last use" seems overly optimistic to me. Letting the users of the > class decorate the *object* definition as such seems more reasonable. > > Cheers, > V. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc/unsubscribe > . > To unsubscribe from this group and all its topics, send an email 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/CAA7YVg3dJT3LY_L5Eg%3DZNgfqqyOcX9P%3DJVv_pXTEx6xxsoGOdg%40mail.gmail.com > > . > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAE7XuEWr7eyyjmqURnMwQf1pvyvHeMATM1MDjRY%3D25WuGy5Z%3Dw%40mail.gmail.com. --001a11403430693178053aec06e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks all for the initial feedback! It's clear to me = now that I haven't defined "last use" very well, and giving i= t an accurate definition based on my limited knowledge of compiler lingo is= going to be tricky.

So let me take a step back and desc= ribe what real-world issues I'm trying to solve. The first example is o= ne where I'd like the heap memory managed by an object to get freed at = the same point where a scalar variable's register would be made availab= le for a different variable:

=C2=A0 =C2=A0 class Matrix
= =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 pub= lic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = Matrix(size_t rows, size_t columns);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto ~Matrix(); =C2=A0 // Eager destructor<= /font>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 private:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 double *m;
=C2=A0 =C2=A0 };

=C2=A0 = =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Matrix a(10'000, 10'000) =3D ...;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix b(10'000, 10'000)= =3D ...;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Matrix c(10'000, 10'000) =3D ...;
<= font face=3D"monospace">
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 a=C2=A0+=3D b; =C2=A0 // Last use of b, destruct b= efore the next line
=C2=A0 =C2=A0= =C2=A0 =C2=A0 a=C2=A0+=3D c;
=C2= =A0 =C2=A0 =C2=A0}

The alt= ernative of using explicit destruction is really inconvenient:
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix a(10'000, = 10'000) =3D ...;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Matrix b(10'000, 10'000) =3D ...;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix c(10'= 000, 10'000) =3D ...;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a= =C2=A0+=3D b;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 b.~Matrix();
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 a=C2=A0+=3D c;
=C2=A0 =C2=A0 }

As is reducing the= scope:

=C2=A0 =C2= =A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0= Matrix a(10'000, 10'000) =3D ...;

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 Matrix b(10'000, 10'000) =3D ...;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a= =C2=A0+=3D b;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix c(10'= ;000, 10'000) =3D ...;=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a=C2=A0+=3D c;
=C2=A0 =C2=A0 }

It might not look that horr= ible when we're only dealing with one variable that can be destructed e= agerly, but it quickly gets unmanageable to manually optimize code like thi= s when using additional variables and longer expressions. So I wish to be a= ble to convey to the compiler that my Matrix class is self-contained and ca= n in have its destructor called before the end of the object's scope.

Obvious= ly it would be a bad idea to allow anyone to retrieve the Matrix::m pointer= .. If you want to keep access to the object's content, you'd need to= keep a reference to the object itself. It would be unreasonable to require= the compiler to determine if we're obtaining references to the object&= #39;s innards and use that to extend its lifetime. But taking a reference t= o the object itself can easily be determined, just like is done with scalar= variables to extend their liveness range.
=
A second use case I have for this is t= o reduce the run-time optimization work of an EDSL used for JIT-compiling c= ode: Reactor. The types that are used=C2=A0represent sc= alar variables (e.g. Int represents int), but have a complex implementation to keep tr= ack of the operations performed on them to later be used to generate code f= rom. If the static C++ compiler called their destructor on their last use a= s the scalar they represent, optimizing the run-time generated code could b= e quicker.

As for an example of optimizing mutex locking, take a class which take= s exclusive ownership of a stream so you can write contiguous data to it:

=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Streamer s(stream);
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 s.write("200");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 s.write(" OK&= quot;); =C2=A0 // Last use, call destructor which releases exclusive owners= hip so another thread can write something.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do_something_el= se_before_end_of_scope();
=C2=A0 =C2=A0 }

<= /div>
Of course in this trivial case you might ju= st write "200 OK" in one go, but imagine a much lager stream of d= ata that is composed of an unknown number of parts. There would be an overh= ead from allocating and reallocating storage for the whole. Also, if the re= ader of the stream can handle partial data then we don't want to delay = streaming out the parts.

So I hope this illustrates what I'm after. I'm c= onvinced there's an unambiguous definition of "last use" that= can provide us with the desired behavior in all of the above examples, wit= hout undue burden on the compiler's analysis. I think liveness analysis= when treating the object as a scalar would give us all we need.

One question I h= ave though is whether liveness analysis of scalars is a "solved proble= m"? In other words are all optimizing compilers capable of producing e= quivalent, deterministic liveness analysis? If not, I still think a cons= ervative eager destructor would be a great thing to have to optimize th= e above use cases. I don't think determinism is strictly necessary, sin= ce compilers already produce code that can behave differently depending on = optimizations.

Thanks again!
- Nicolas

On Thu, Aug 25, 2016 at 6:37 AM, Viacheslav Usov <via.usov@gma= il.com> wrote:
On Wed, Aug 24, 2016 at 8:51 PM, <nicolas.capens@gmail.co= m> wrote:

>=C2=A0I'd like t= o propose a new kind of destructor that gets called after a local object= 9;s last use, instead of at the end of its scope.

"Destruct after last use" is generally known as &= quot;garbage collection". There is no known deterministic solution to = this general problem. This is what many other comments have been about. You= can only make this deterministic if you provide some narrow definition of = "last use". C++ has such a narrow definition for local objects, i= t is the automatic scope rules, simple and hugely successful. The question,= then, is whether we really need another=C2=A0competing=C2=A0definition, an= d whether we really gain much with that additional complexity.

=
Note I= 9;m not assuming you would propose a non-deterministic=C2=A0definition.

> The syntax for this could be an a= nnotation of the destructor declaration with a keyword, symbol, or attribut= e. For example, "auto ~Object();", "volatile ~Object();"= ;, "~~Object();", or "[[eager]] ~Object();".

The = assumption that one can decorate a class definition with "destr= uct after last use" seems overly optimistic to me. Letting the = users of the class decorate the object definition as such seems more= reasonable.

Cheers,
V.
=

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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-p= roposals/CAA7YVg3dJT3LY_L5Eg%3DZNgfqqyOcX9P%3DJVv_pXTEx6xxsoGOdg%40mail.gma= il.com.

--
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-proposa= ls+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/CAE7XuEWr7eyy= jmqURnMwQf1pvyvHeMATM1MDjRY%3D25WuGy5Z%3Dw%40mail.gmail.com.
--001a11403430693178053aec06e7-- .