220 37754 <57d53169-ecbf-486a-94fd-2a3f60487c3d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Phil Bouchard Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Deterministic C++ memory manager Date: Wed, 11 Apr 2018 20:16:47 -0700 (PDT) Lines: 149 Approved: news@gmane.org Message-ID: <57d53169-ecbf-486a-94fd-2a3f60487c3d@isocpp.org> 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_2592_279537992.1523503007619" X-Trace: blaine.gmane.org 1523502884 7644 195.159.176.226 (12 Apr 2018 03:14:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Apr 2018 03:14:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCAYTFXFZMBBBIE7XPLAKGQE6FZ6X4Q@isocpp.org Thu Apr 12 05:14:40 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f6Sh5-0001rA-7Z for gclcip-std-proposals@m.gmane.org; Thu, 12 Apr 2018 05:14:39 +0200 Original-Received: by mail-vk0-f71.google.com with SMTP id u188sf2505372vke.13 for ; Wed, 11 Apr 2018 20:16:50 -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=nw02li02dgoDWFOa9ajGUdEeTG9VLaDm2t0TVYtxBjE=; b=VWmKVeQRej5T5dwTRv5LP+kf9/lBw0sN7pReZDZ0Uj6Kt1DOCBE7VyjIrreQkR5zTD 6CyevMEM/7vkpA7Ipl7FnGWdDeSUYs1Yday/mGs9Xri+8PsgFX5XfP15bC7GRcfdiNXM pUyZ0XU1+74g5gsfE5J3wUVA0vqEjNIhLjscZnQf3xeKNhYL1qWcM21Rit6kvfXuPpfT yLHh/kxMv2MtA/SL1Knms2+FITW/Zmxnqi9cC6g3reX1rezQ1ryEpCVqFZbk2Mw/4iks AJBqDHzLRhAha0Prr5V0RbQddWRAdLkOGmObHG0h6FpXgqlTkJHjjibNXlj678b+c70v HqEA== 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=nw02li02dgoDWFOa9ajGUdEeTG9VLaDm2t0TVYtxBjE=; b=UXQOPWYQ4iHH1eqxf8gKdmgWJRdUnaUg8O81cbtjX9RLGNJDrzFjbwMgQ4GrQoe92f 6FowXUKnCuFjZa4UlRie96rWkpEh4LyHKeurawbe7dZhxCsAZRusVUZALKCPA3GeO7xd ejiRaUmNWroKS7C43YW/NuDJXqHFUWivbSrKDk8yzQ877W8Z/zmc5hWyR57pbLmf73xw x0HBSWuslqci1GtDcG0Lv/s9WGzgUhCH8NfNEYTU60VPLg5r7dUk0wYuCpk6jArNzLu5 w9sU3yPQujITgwq3GgJnsX9lyJt8QeqVPEM/g9vyzRj+1TDQaXEs9JEFM7ulVzFc6mBI BRBw== 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=nw02li02dgoDWFOa9ajGUdEeTG9VLaDm2t0TVYtxBjE=; b=IXT3r33RDv5q/gB/7CguKLGMQFJawbp/mOXk00csgYMMnJpQrAepSv5zA9N4XY0hll 483hqjFje4iKIPseJvBUOZa0IQ2dhvZFvP0otLDXAiUtdmyCdqv+5h8a/XrjjmRSn8g4 SkFftauHhHZvSTqkJ/S3+H+2SgJGxmaT+u5rglRUsMaHAIyQYP008Vy5bqZPYiC2fp4g NNC6ZpgEwYGHReVD5uh2fwvFVOag3rNB3dZPFlTP1lhWsBNXKB2yqMX3OrhIMV7U4jT5 MFhtJXw8g1Eosq4KFRrwGfvarvwWgYKv48TlFBWQp6A6WLwp0tDhCREThhzMFiPtdYYN rKyA== X-Gm-Message-State: ALQs6tDQq6NS1NOgrBiHaJYyOK3fOJmXKtMJiRIgS9+WJPY0bXl2ZugF zDRvE4qwzex7KjzeW/sCk0EFIg== X-Google-Smtp-Source: AIpwx4/boKlVdeY0g5RnziH51XTeoWAVvFrJrCmIE1qR/ON/0GkiKWaQpgZR8JwgQOMsCfKl8vTKTA== X-Received: by 10.31.61.6 with SMTP id k6mr3674818vka.90.1523503009574; Wed, 11 Apr 2018 20:16:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.16.193 with SMTP id 62ls1332068vkq.16.gmail; Wed, 11 Apr 2018 20:16:48 -0700 (PDT) X-Received: by 10.31.166.79 with SMTP id p76mr839753vke.3.1523503008234; Wed, 11 Apr 2018 20:16:48 -0700 (PDT) In-Reply-To: X-Original-Sender: philippeb8@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:37754 Archived-At: ------=_Part_2592_279537992.1523503007619 Content-Type: multipart/alternative; boundary="----=_Part_2593_979473469.1523503007620" ------=_Part_2593_979473469.1523503007620 Content-Type: text/plain; charset="UTF-8" On Saturday, August 5, 2017 at 12:22:48 PM UTC-4, Phil Bouchard wrote: > > > 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 "deferred_heap" at CppCon 2016. > > > https://internals.rust-lang.org/t/herb-sutter-deferred-heaps-and-pointers/4183 > > Of course everyone has their own implementation of this idea; and there > > are plenty of hybrids, such as "local arena allocators", or mixing in a > > bit of refcounting to get Objective-C's "autorelease pools", or mixing > > in a bit of RCU to get "RCU domains", or whatever. > > Firstly I would like to point out that I came up with the idea long > before Microsoft did (2011 actually). You can easily find references to > my previous attempts in the development Boost mailing list. Back in the > days my library was called: "block_ptr" and "shifted_ptr". > To go back on this subject, root_ptr aka block_ptr aka shifted_ptr actually dates back from 2003! http://boost.sourceforge.net/more/formal_review_schedule.html > Secondly deferred_ptr is not production ready and doesn't support > multithreading mode whereas root_ptr was correctly unit tested and it > does support multithreading mode but I just need to optimize one mutex > (that is currently a static member) to make it even faster. > Thirdly root_ptr injected via the powerful Clang-based Fornux C Leak Detector works well and has been tested with a modified version of libarchive: https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b The modifications involved are very simple but can be repetitive. I think the next step is to standardize meta-data but not the way Mr. Sutter proposes it because like I was saying before, extra parameters will need to be passed to each function and extra member variables will need to be added to each top-level class and compilation unit. This meta-data can be used to get backtraces as well, like previously mentioned somewhere. It is working well with the Fornux C Leak Detector and I will try to share a free version for Linux and Windows in the following months. Thanks for your patience... again. Regards, Phil Bouchard www.fornux.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/57d53169-ecbf-486a-94fd-2a3f60487c3d%40isocpp.org. ------=_Part_2593_979473469.1523503007620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Saturday, August 5, 2017 at 12:22:48 PM UTC-4, = Phil Bouchard wrote:
> You n= ever 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 wh= at=20
> Herb Sutter called a "deferred_heap" at CppCon 2016.
> https://internals.rust-lang.org/t/herb-sutter-deferre= d-heaps-and-pointers/4183
> Of course everyone has their own implementation of this idea; and = there=20
> are plenty of hybrids, such as "local arena allocators",= or mixing in a=20
> bit of refcounting to get Objective-C's "autorelease pool= s", or mixing=20
> in a bit of RCU to get "RCU domains", or whatever.

Firstly I would like to point out that I came up with the idea long=20
before Microsoft did (2011 actually). You can easily find references to= =20
my previous attempts in the development Boost mailing list. Back in the= =20
days my library was called: "block_ptr" and "shifted_ptr= ".

To go back on this subject, root_ptr a= ka block_ptr aka shifted_ptr actually dates back from 2003!
http://boost= ..sourceforge.net/more/formal_review_schedule.html
=C2=A0
Secondly deferred_ptr is not = production ready and doesn't support=20
multithreading mode whereas root_ptr was correctly unit tested and it= =20
does support multithreading mode but I just need to optimize one mutex= =20
(that is currently a static member) to make it even faster.

Thirdly root_ptr injected via the powe= rful Clang-based Fornux C Leak Detector works well and has been tested with= a modified version of libarchive:
https://github.com/philippeb8/libarch= ive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b

The modifications involved are very simple but can be repetitive.

I think the next step is to standardize meta-data but= not the way Mr. Sutter proposes it because like I was saying before, extra= parameters will need to be passed to each function and extra member variab= les will need to be added to each top-level class and compilation unit. Thi= s meta-data can be used to get backtraces as well, like previously mentione= d somewhere.

It is working well with the Fornux C = Leak Detector and I will try to share a free version for Linux and Windows = in the following months. Thanks for your patience... again.

<= /div>

Regards,
Phil Bouchard
www.for= nux.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/57d53169-ecbf-486a-94fd-2a3f60487c3d= %40isocpp.org.
------=_Part_2593_979473469.1523503007620-- ------=_Part_2592_279537992.1523503007619-- .