220 33597 article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Deterministic C++ memory manager Date: Fri, 4 Aug 2017 15:40:45 -0700 (PDT) Lines: 191 Approved: news@gmane.org Message-ID: References: <68af3311-d2d7-42ff-8cfd-f8bcdc20bf0c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1267_1575998725.1501886445773" X-Trace: blaine.gmane.org 1501886449 24643 195.159.176.226 (4 Aug 2017 22:40:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 4 Aug 2017 22:40:49 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIO534TZQCRUBARIURTK@isocpp.org Sat Aug 05 00:40:44 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddlGr-0005zn-JA for gclcip-std-proposals@m.gmane.org; Sat, 05 Aug 2017 00:40:41 +0200 Original-Received: by mail-pf0-f198.google.com with SMTP id r187sf30607188pfr.8 for ; Fri, 04 Aug 2017 15:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=px2CbMIwV3NSs2PZJUJFe/I8GyH33K58EDMPZF8OY7g=; b=IX7jp7N9+UZHfKKU3WtLMAHpMh9WFnDJU7IPKT23mlxVKkeCyTW2oJHgtyDvo2Bblt z0M+OBixwts9zx/OwYlxLWK/14mFUlr43chrhZ5UGRUKitCSGf7Ir/MPjlar9W/P7yZX 6rtVlUa0lL9MT+FZocnJHGW3+UzMO6hg91cnn1k7mqYXqIfsefTyg2dnQttjd2+ftI+h 11wmRp9j2GkkaVrrQYWg8Vu2fWkBw7Kyjb/n1/JzTusRz4thN7r+nIjkA2mNHD4aqaVt 1+ys00lwJPKP2DNNF90ODXxDlgBccqc84GBaq+nb5kNXY2htesvwHoKwJDd6EBL2Qm/d lLPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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; bh=px2CbMIwV3NSs2PZJUJFe/I8GyH33K58EDMPZF8OY7g=; b=ZbbtN3xkDgqbUyjCYLt6wOjc4YoDtR215x3r1K1eoZ8L5LKbdDiM2all8rTK2hZIex /GoS0KtUIsPplxCW9kXa0TsedWL75z/U8sQfniDKA5mAK7E49oVHHtA6njFqUV26d3RM nR2Fd1CJWvVel0hv9RbTkTRz96XGAipmLPj8HoyOU8Gfxpjrk6o6nUYM703IQMQetzzP IpHy5b1w421jOG77FS2OI3ZO6wDCsAKiarY0rw0HqJC6KJ4vaJIyRtKNMc1Z2hn2hkCZ wks7mpsx/OIs6UzqVWPYv7qJnGVh4WQjInEqwcLPxs1xonG8MPih8FBPhxzLmFBNZ875 HR/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=px2CbMIwV3NSs2PZJUJFe/I8GyH33K58EDMPZF8OY7g=; b=h5YQOvh9f3lBp2ROnCZpA8zfPSCu2kgzIpPkxGUPR9HAfUiq/B5NZZw6nYS0/bzY4h g94XJC8MVOAcPfGls88Cn2QFahtVwxrf5/tpOU7x73k5N+uEJtcX12CSzkF++3YznJtx RV8YiUmsFuLNbhIN53WQB+nXsyLCVt3e3SLed4unVIMmA7BKWF5YxXsPeFwJeAjJBzd6 YdlkZfEnBK4F7TvfHnNxmCQWhvkqFtKmf2Z0WCjxMuKdxm8L1LvIdSFgyFdcA3cnz93F rG6Bz9lKa28SMg1ueQv3rEYHAFVrovgakv98hoSsugI7B/JyUASHlERID2sBKadu+12B fLzw== X-Gm-Message-State: AIVw111w0FEyv7sFTD3o7SBjNuCCvdisn7DFHLcdabKvTBgBn5DQzCV5 G1m3jwkTADJCMi8i X-Received: by 10.99.168.14 with SMTP id o14mr2640530pgf.147.1501886447523; Fri, 04 Aug 2017 15:40:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.175.23 with SMTP id t23ls147761ite.13.canary-gmail; Fri, 04 Aug 2017 15:40:46 -0700 (PDT) X-Received: by 10.31.148.19 with SMTP id w19mr20212vkd.17.1501886446216; Fri, 04 Aug 2017 15:40:46 -0700 (PDT) In-Reply-To: <68af3311-d2d7-42ff-8cfd-f8bcdc20bf0c@isocpp.org> X-Original-Sender: arthur.j.odwyer@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:33597 Archived-At: ------=_Part_1267_1575998725.1501886445773 Content-Type: multipart/alternative; boundary="----=_Part_1268_1264855013.1501886445773" ------=_Part_1268_1264855013.1501886445773 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, August 4, 2017 at 1:07:31 PM UTC-7, Phil Bouchard wrote: > > Hi ISO C++,=20 > > I have developed a deterministic memory manager in C++ and I was wonderin= g=20 > if ISO C++ would be interested to hear more about it. > > For the moment I have included my solution in a brand new language I call= =20 > "BB++" because I need to add functionality that C++ doesn't yet have such= =20 > as: > - to add instances of an object implicitly as each scope; > - to add implicit references to these objects in top-level classes > - to overload 'operator .' > - to use 'auto' for member variables instead of 'decltype' > - to add metadata of the classes in order to propagate the proxy=20 > associated to the pointers within those classes > > The homepage of my project is: > https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp > > And I have a 17 minutes presentation available here: > https://youtu.be/GrNDYWyasxg > > Please let me know if this is the type of research you are interested in.= =20 > The work is a step away from being production ready. It has to be noted= =20 > that Root.Ptr is already faster than Shared.Ptr in multithreaded mode. > It would help if you could edit down that YouTube video to cut all the dead= =20 air; it's 17 minutes of which the relevant 5 minutes is scattered around=20 separated by painful silent sections. Even at 200% playback speed, it's a= =20 slog. Certainly for your present purposes, *nothing* prior to 6m22s is relevant.= =20 (Anyone who cares already knows how mark-and-sweep and refcounting work,=20 and doesn't need a tutorial on the subject.) You never show code or diagrams for root_ptr in the video, but from the=20 usage example and caveats, I infer that it is (almost?) exactly what Herb= =20 Sutter called a "deferred_heap" at CppCon 2016. https://internals.rust-lang.org/t/herb-sutter-deferred-heaps-and-pointers/4= 183 Of course everyone has their own implementation of this idea; and there are= =20 plenty of hybrids, such as "local arena allocators", or mixing in a bit of= =20 refcounting to get Objective-C's "autorelease pools", or mixing in a bit of= =20 RCU to get "RCU domains", or whatever. Starting around 12m45s, the examples seem to be concerned entirely with=20 showing examples of successful escape analysis =E2=80=94 that is, you creat= e a=20 "node_proxy" (a.k.a. deferred_heap) and allocate some objects in that heap,= =20 and then you return a pointer to one of those objects from the current=20 function. Normally this would cause dangling-pointer/use-after-free errors,= =20 but in this case your BB++ language is doing some sort of "escape analysis"= =20 to promote the returned object into the surrounding scope. Some explanation= =20 of this promotion mechanism would be useful, since it's the one thing=20 that's not obvious how to do in today's C++. my $.02, =E2=80=93Arthur --=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/da483e72-1a63-4ea1-80c4-8d63aa018db9%40isocpp.or= g. ------=_Part_1268_1264855013.1501886445773 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, August 4, 2017 at 1:07:31 PM UTC-7, Phil Boucha= rd wrote:
Hi I= SO C++,

I have developed a deterministic memory manager in C++ and I was=20 wondering if ISO C++ would be interested to hear more about it.

For the moment I have included my solution in a brand new language I call=20 "BB++" because I need to add functionality that C++ doesn't y= et have=20 such as:
- to add instances of an object implicitly as each scope;
- = to add implicit references to these objects in top-level classes
- to ov= erload 'operator .'
- to use 'auto' for member variables= instead of 'decltype'
- to add metadata of the classes in order= to propagate the proxy associated to the pointers within those classes

=

The homepage of = my project is:
https://github.com/= philippeb8/root_ptr/tree/bb++/bbpp2cpp

And I have a 17 minutes presentation ava= ilable here:
https://youtu.be/GrNDYWyasxg

Please let me know if this is the type of research you are interested in. The work is a step away from being production ready. It has to be noted th= at Root.Ptr is already faster than Shared.Ptr in multithreaded mode.


It would help if you could edit down th= at YouTube video to cut all the dead air; it's 17 minutes of which the = relevant 5 minutes is scattered around separated by painful silent sections= .. Even at 200% playback speed, it's a slog.
Certainly for you= r present purposes, nothing prior to 6m22s is relevant. (Anyone who = cares already knows how mark-and-sweep and refcounting work, and doesn'= t need a tutorial on the subject.)

You never show = code or diagrams for root_ptr in the video, but from the usage example and = caveats, I infer that it is (almost?) exactly what Herb Sutter called a &qu= ot;deferred_heap" at CppCon 2016.
Of course everyone has their own implementation of this idea; a= nd there are plenty of hybrids, such as "local arena allocators",= or mixing in a bit of refcounting to get Objective-C's "autorelea= se pools", or mixing in a bit of RCU to get "RCU domains", o= r whatever.

Starting around 12m45s, the examples s= eem to be concerned entirely with showing examples of successful escape ana= lysis =E2=80=94 that is, you create a "node_proxy" (a.k.a. deferr= ed_heap) and allocate some objects in that heap, and then you return a poin= ter to one of those objects from the current function. Normally this would = cause dangling-pointer/use-after-free errors, but in this case your BB++ la= nguage is doing some sort of "escape analysis" to promote the ret= urned object into the surrounding scope. Some explanation of this promotion= mechanism would be useful, since it's the one thing that's not obv= ious how to do in today's C++.

my $.02,
<= div>=E2=80=93Arthur

--
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/da483e72-1a63-4ea1-80c4-8d63aa018db9= %40isocpp.org.
------=_Part_1268_1264855013.1501886445773-- ------=_Part_1267_1575998725.1501886445773-- .