220 9289 <4334336c-32c3-4984-8bf1-c9442ed85b9a@isocpp.org> article Path: news.gmane.org!not-for-mail From: Andrew Tomazos Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Precise Per-Type Cyclic Garbage Collection (DRAFT 1) Date: Tue, 11 Feb 2014 11:25:49 -0800 (PST) Lines: 180 Approved: news@gmane.org Message-ID: <4334336c-32c3-4984-8bf1-c9442ed85b9a@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4975_28612542.1392146749376" X-Trace: ger.gmane.org 1392146746 22669 80.91.229.3 (11 Feb 2014 19:25:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Feb 2014 19:25:46 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBQHS5GLQKGQEOYUQTQA@isocpp.org Tue Feb 11 20:25:55 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f198.google.com ([209.85.160.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WDIxt-00060V-Ti for gclcip-std-proposals@m.gmane.org; Tue, 11 Feb 2014 20:25:54 +0100 Original-Received: by mail-yk0-f198.google.com with SMTP id 131sf24321807ykp.1 for ; Tue, 11 Feb 2014 11:25:53 -0800 (PST) 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=+5Q0hPWqkMjPycqRgUnuE40vWf940+bPgwCePAQD5IY=; b=n3OmTONLbxthS4qWBSPYNiLewsn0HZggMmSScy8jxo0/5wV+5H6esI5ZQtJrL+KZsy DOcptBBjuu3N4zCDixDQVk7ORVGARSV0pi5Ozs/MQyu1NkMepd1rJT6j7/JVIYiYzICw rnz/16tIGuxZ94hcFrehoggxAa/+pdpg2e21wDF9M0tiLefgMGiAI60xVZgz1Yuu9swk 9E470uVZpWQjF15C8D6ZcipGPww0f3tqhY8EzfDLGh/iZGiaHa9xMfWxBp82gcuu911p GzfzZMoogvcoEJJOf1RYBuemaIBt8Sp7rAdVQ/UtG+oFtn7m+4epK23vwh+1eCW1T6ik gT5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state: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=+5Q0hPWqkMjPycqRgUnuE40vWf940+bPgwCePAQD5IY=; b=YfGdLpV0VgYNOV2VFIbhSk0fXorNlZlxkOmTxA81DHYeTDURiLN/wZSeE7W4+Y3lkU nxFp0WQCRfmz3tEipPuLZzFEl2Qm2EmoBKHJWpfnW7dbK/vARRZu2msqITqnB16104+K R/RT9n0YIbLyMMmeuEAk0L8s2tRGyO5e6iOIz8xvxW5v0hTfnf3T20etLljj6mTWCeUP bkMU3NlqB76VCAsU0VfXxSE/ruhakLeJtRTrvY9WI0CtMoU2TVsZ7SFe/nnqApHXJf4u +AylQDRDypCaoQ9icjvZMT/53pn11HM3y59bXF8+bu7aMLtCFyOIu5v5bNh1pp3d/njP Q6ZA== X-Gm-Message-State: ALoCoQmBma9nzDsfOwP0CP+A1qe2JwZdnokgncjSSYLWtkWYy49uLQrGwiwfC2INh5oqF523e5x1 X-Received: by 10.236.133.82 with SMTP id p58mr51178yhi.37.1392146752981; Tue, 11 Feb 2014 11:25:52 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.81.209 with SMTP id f75ls2552904qgd.48.gmail; Tue, 11 Feb 2014 11:25:50 -0800 (PST) X-Received: by 10.140.34.147 with SMTP id l19mr45081qgl.30.1392146749965; Tue, 11 Feb 2014 11:25:49 -0800 (PST) In-Reply-To: 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:9289 Archived-At: ------=_Part_4975_28612542.1392146749376 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, February 11, 2014 7:34:52 PM UTC+1, Klaim - Jo=C3=ABl Lamotte w= rote: > > 1. This proposal is about a language extension, but seems (if I didn't=20 > miss anything) to ignore C++11 minimal garbage collection hooks > as explained by Stroustrup there:=20 > http://www.stroustrup.com/C++11FAQ.html#gc-abi > Did you take this into account? > Yes. The safely-derived pointer concept is designed for program-wide=20 conservative collection such as the Boehm collector. This proposal is for= =20 nominating specific types for collection by a precise collector.=20 Collecting pointers are even more constrained than safely-derived=20 pointers, and they are better as the constraints on collecting pointers are= =20 enforced at compile-time. =20 > 2. Acronyms are harder to interpret, even in this case. > Instead of 'gc', I would suggest 'collected' (which is the adjective= =20 > you use to describe what the keyword does to the type) > =20 Noted. To be considered. 3. How do you expect generic algorithm developers to work with types which= =20 > can't be manipulated through iterators/ranges? > Integration with collections and algorithms needs some study, but the=20 initial idea is that you use pointer to T rather than T itself. So for=20 example: vector v =3D ...; for (auto x : v) x->do_something(); Clearly this doesn't work easily with user-defined equality, hashing and=20 comparison - this is no different than the situation today with pointers,= =20 unique_ptrs or shared_ptrs. But having said that - since posting the proposal I have come up with a=20 pretty radical idea of how to deal with this, but it is quite difficult to= =20 explain and I need to work through the ramifications. To try to summarize= =20 it (and fail), a collected type will be a "handle" type. It will store its= =20 data members within an unnamed struct, and it will have one "hidden"=20 implicit member that is a pointer to that struct. That way, what we call= =20 in the original proposal a collecting pointer (foo*) will now be the=20 collected type itself (foo), and what was the collected type (foo) is now= =20 an unnamed struct. Within its member functions, the this pointer is set to= =20 the implicit pointer member for looking up data members. So from within=20 the class specifier it will look like you are defining a normal type and=20 you can use it mostly as normal, but when you copy construct it, it will be= =20 a handle to the same instance. The collection graph is then traced the=20 same way, except using these implicit pointer members and unnamed structs,= =20 rather than the collecting pointers and collected types. I have to double= =20 check that this isn't completely insane, and if you couldn't follow what I= =20 just said, I don't blame you. 4. Did you consider attaching the garbage collecting logic to specific=20 > instances instead of types? > Yes. It doesn't seem to work as well. If the entire type is nominated,=20 things seem to work out much cleaner. --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_4975_28612542.1392146749376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, February 11, 2014 7:34:52 PM UTC+1, Klaim - Jo= =C3=ABl Lamotte wrote:
1. This proposal is about a language extension, but seems (if= I didn't miss anything) to ignore C++11 minimal garbage collection hooks



=

Clearly this doesn't work easily with user-defined equa= lity, hashing and comparison - this is no different than the situation toda= y with pointers, unique_ptrs or shared_ptrs.

But h= aving said that - since posting the proposal I have come up with a pretty r= adical idea of how to deal with this, but it is quite difficult to explain = and I need to work through the ramifications.  To try to summarize it = (and fail), a collected type will be a "handle" type.  It will store i= ts data members within an unnamed struct, and it will have one "hidden" imp= licit member that is a pointer to that struct.  That way, what we call= in the original proposal a collecting pointer (foo*) will now be the colle= cted type itself (foo), and what was the collected type (foo) is now an unn= amed struct.  Within its member functions, the this pointer is set to = the implicit pointer member for looking up data members.  So from with= in the class specifier it will look like you are defining a normal type and= you can use it mostly as normal, but when you copy construct it, it will b= e a handle to the same instance.  The collection graph is then traced = the same way, except using these implicit pointer members and unnamed struc= ts, rather than the collecting pointers and collected types.  I have t= o double check that this isn't completely insane, and if you couldn't follo= w what I just said, I don't blame you.

4. Did you consider atta= ching the garbage collecting logic to specific instances instead of types?<= /div>

Yes.  It doesn't seem to w= ork as well.  If the entire type is nominated, things seem to work out= much cleaner.

--
 
---
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_4975_28612542.1392146749376-- .