220 39692 <6acf3e14-579e-45d4-9a6f-9a548adf2c08@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts about relocation Date: Fri, 10 Aug 2018 14:25:33 -0700 (PDT) Lines: 388 Approved: news@gmane.org Message-ID: <6acf3e14-579e-45d4-9a6f-9a548adf2c08@isocpp.org> References: <19d8d86c-f4cf-47a9-bb42-9e2ba06dccab@isocpp.org> <1533933584.894944.1470306312.0E21362C@webmail.messagingengine.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_920_1203399263.1533936333382" X-Trace: blaine.gmane.org 1533936210 9876 195.159.176.226 (10 Aug 2018 21:23:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2018 21:23:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBTUFXDNQKGQEEZ536LI@isocpp.org Fri Aug 10 23:23:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f72.google.com ([209.85.161.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1foEsW-0002RQ-G8 for gclcip-std-proposals@m.gmane.org; Fri, 10 Aug 2018 23:23:24 +0200 Original-Received: by mail-yw1-f72.google.com with SMTP id z78-v6sf14394074ywa.23 for ; Fri, 10 Aug 2018 14:25:35 -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=aXuXhDhOp9R1LkHNF09c4alatQAVLgsyHnB484y/iJg=; b=cPQ0n2W1a2jAZ7J/wkMZEJSivxSoHS6XYWU9ZoZBivnOA5sMDe9Zu+XTUjcBlRY9O+ hOZTJYb9cXlZfN1fGfhRhzec+3s6Sq0qoHP6Zvbf0WEjeP20kS7mCXxYrpIG00Uv/CBD UOKdYa3D9CjNF7kRK61i+wWna1bFKZmRlZ6V9CKQDV096BBK1RSkN9oRi8WN5YuwknGO H9A/1i2EKu5H1ytYyUL25JZ7zy/bvpf+OIQlE8zEY8JNKCgqhN0notn+YzNYoFfZJJ3U +m0nimVmd3fgstqz6Pc2C6MuJEPIm7MwSUyxzyORjWjNqYfiFCz59+O3jVxJUkJRpY6Z /79Q== 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=aXuXhDhOp9R1LkHNF09c4alatQAVLgsyHnB484y/iJg=; b=j6qMwn1vsBGosOrNCk/DqoFb14ua7MTfnNXhvbTYMndCim+QyGyTLf0PVX3VlysgXt cVOgi/1pH6ooHxuPter0/tiVp8bhg4C0hqXJ3zbaxXUsQbib/3ltBS9l/+siKWtOAjfo bwrSrs3XSj3kbQbHk+mV+VGy/MaQu3kC00U+OtYOA/5mMs0fyoxWH7mDepQ51fjyNkyy 6aM4Vkww69kHyXNgAgjCeEs8EFcNG6FnS+FW3RYt1nSQE/9D1kfuTe9ReiL1cG2jSNuT HEjGxRxCvKNMBXtjdGWMfUY7uiFJJqOHjM/inJ5N8oIVGFYMZ9xVh8Ku6gmyXmBXu+GT D2nA== 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=aXuXhDhOp9R1LkHNF09c4alatQAVLgsyHnB484y/iJg=; b=bEyG26sUMmt30mxlwvm/Mjw42xvouEpzXBvv1k+og7jjKnqmlt9ECQ57uOxVGerN1E GzjEZgnZIVAywC4+ul5gAqzYdFtQPq3saP1p3Zl7sGlpQRFdOtXkZviPPTs0GOWu/4/x WQWhh9/seVbXcUCRxvYGNd9bzhtEHjsDOBGQvt5lOG9nFfK5ofOlpoF1sDivjYy1iVu2 oyx/Sjh4VI2rEJwJ+T/KBZ1/6OhKiobai4Pjd7vgl3nD3H53ew5/giGO22NE0n7RiRcD 2Noe1EgCZ4BJuD/XKMAnSX2XDYp5/+m4os0FSGwntS4dyEsEsmWv6giUAIrECGKfYbVW okew== X-Gm-Message-State: AOUpUlFTVQQhcyMfSkHk/hfYLk8exdT9BbCxNWih4fFpcrLc2rwiyeMT e5RLShcc4IzlrJqv9x1cfJ+qRw== X-Google-Smtp-Source: AA+uWPxJPDR9tRFTRFx9VtanIbTsm3c7/LaN4Izl1HWLPSg67p3hsrSVEDf8dP9/J8Yvc+gCOFjH0Q== X-Received: by 2002:a25:6e86:: with SMTP id j128-v6mr2194573ybc.29.1533936334928; Fri, 10 Aug 2018 14:25:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:6d44:: with SMTP id i65-v6ls1967915ybc.8.gmail; Fri, 10 Aug 2018 14:25:34 -0700 (PDT) X-Received: by 2002:a25:ba44:: with SMTP id z4-v6mr96203ybj.7.1533936333846; Fri, 10 Aug 2018 14:25:33 -0700 (PDT) In-Reply-To: <1533933584.894944.1470306312.0E21362C@webmail.messagingengine.com> X-Original-Sender: jmckesson@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:39692 Archived-At: ------=_Part_920_1203399263.1533936333382 Content-Type: multipart/alternative; boundary="----=_Part_921_242881540.1533936333383" ------=_Part_921_242881540.1533936333383 Content-Type: text/plain; charset="UTF-8" On Friday, August 10, 2018 at 4:39:48 PM UTC-4, Henry Miller wrote: > > On Fri, Aug 10, 2018, at 11:41 AM, floria...@gmail.com > wrote: > > I was playing with memory allocations, what it is possible to do and how > it is implemented. > It made me think about relocations, so here is the result of my reflection. > > > "Relocation" definition: > An object is relocated when its address changes. > This does not necessarily implies a copy of its bytes. > > > When it can occur: > This could happen if a call to realloc is performed. > This could also happen as a compiler optimization > > > What about memory compaction? This would be the most interesting and > useful case to me. Memory fragmentation is an unfortunate reality that I > sometimes fight. > > > How it can be integrated to the language: > Relocation cannot be a constructor: no new object is created. > Relocation cannot be an assignment operator: Only one object is involved. > > So here is what I propose: > Every type has a relocation operator that takes a pointer and returning > void (let's call it operator relocate to ease the explanation, but I have > no strong opinion on the syntax). > This operator is called just after the object address has changed (for > whatever reason), and the pointer argument represents the old address of > the object (which is now an invalid address). > > This operator can be deleted or defaulted. > The operator relocate is trivial iif: > > - it is not user-provided (that is, it is implicitly-defined or > defaulted) > - T has no virtual member functions > - T has no virtual base classes > - the operator relocate selected for every direct base of T is trivial > - the operator relocate selected for every non-static class type (or > array of class type) member of T is trivial > > A trivial operator relocate is basically a noop. > > > No syntax is proposed to call relocation (apart from object.operator > relocate(p)). > > > An operator relocate shall not change the state of the object if the new > address is the same as the old address, even if the operator is not trivial. > > It also cannot be virtual (you shall relocate only object through their > true type). > > > I propose that throwing relocation is allowed, but discouraged (but if > this is problematic, I see no strong reason to keep throwing relocation). > > > Small example: > > > > struct Bar; > struct Foo { > Bar* bar; > }; > > struct Bar { > Foo* foo; // foo.bar is always equals to this > > Bar() : foo(new Foo{this}) {} > ~Bar() { > delete foo; > } > > // copy is deleted > Bar(const Bar&) = delete; > Bar& operator=(const Bar&) = delete; > > // move needs to set the foo.bar to this object > Bar(Bar&& other) : foo(other.foo) { > other.foo = nullptr; > foo.bar = this; > } > Bar& operator=(Bar&& other) { > swap(foo, other.foo); > foo.bar = this; > other.foo.bar = &other; > return *this; > } > > // If address has changed, reset the foo.bar to point to the new > location of the object > void operator relocate(void*) { > foo.bar = this; > } > }; > > > > Your example code is undefined behavior. If some other thread access > bar::foo after the reallocation and before bar::relocate gets to the fix up > line your program goes boom. > How would that be different from any other data race? Presumably, relocating an object is accessing it. So if two threads are accessing the same object at the same time, it's a data race: UB. If you need to thread relocation with other accesses, it should be on you to provide it. Even atomic pointer fixup operation wouldn't be enough, because you can have more than one pointer in an object to fix up. -- 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/6acf3e14-579e-45d4-9a6f-9a548adf2c08%40isocpp.org. ------=_Part_921_242881540.1533936333383 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, August 10, 2018 at 4:39:48 PM UTC-4, Henry Mill= er wrote:
On Fri, Aug 10, 2018, at 11:41 AM, floria...@gmail.com wrote:
<= /div>
I was playing with memory allocations, what it is possible to do and how i= t is implemented.
It made me think about relocations, so her= e is the result of my reflection.


"Relo= cation" definition:
An object = is relocated when its address changes.
This does not necessarily implies a copy o= f its bytes.


When it ca= n occur:
This could= happen if a call to realloc is performed.
This could also happen as a compiler optim= ization

What about memory compaction? This would b= e the most interesting and useful case to me. Memory fragmentation is an un= fortunate reality that I sometimes fight.=C2=A0


How it can= be integrated to the language:
Relocation= cannot be a constructor: no new object is created.
Relocation cannot be an assignment operato= r: Only one object is involved.

So here is what I propose:
Every type has a relocation operator that = takes a pointer and returning void (let's call it operator relocate to ease the exp= lanation, but I have no strong opinion on the syntax).
This operator is called just after the obj= ect address has changed (for whatever reason), and the pointer argument rep= resents the old address of the object (which is now an invalid address).

This operator can be deleted or defaulted.=
The operator relocate is trivial iif:
  • it is not user-provided (that is, it is = implicitly-defined or defaulted)
  • T has no virtual member functions
  • T has n= o virtual base classes
  • the operator relocate selected for every direc= t base of T is trivial
  • the operator relocate selected fo= r every non-static class type (or array of class type) member of T is trivial

A trivial operator relocate is basically a noop.


No syntax is proposed to call relocation (apart = from object.o= perator relocate(p)).


<= p style=3D"margin-left:40px">An operator relocate shall not change the state of t= he object if the new address is the same as the old address, even if the op= erator is not trivial.

It also cannot = be virtual (you shall relocate only object through their true type).


I prop= ose that throwing relocation is allowed, but discouraged (but if this is pr= oblematic, I see no strong reason to keep throwing relocation).

<= br>

Small example:



struct Bar;=
struct Foo = {
=C2=A0 Bar* bar;
};

struct Bar {=
=C2=A0 Foo* foo;= // foo.bar is always equals to thi= s

=C2=A0 Bar() = : foo(new Foo{this}) {}
=C2=A0 ~Bar<= /span>() {
=C2=A0 =C2=A0 delete foo;
=C2= =A0 }

=C2=A0 // copy is deleted
=C2=A0 Bar(const Bar<= /span>&) =3D delet= e;
=C2=A0 Bar& operator=3D(const Bar&) =3D delete;
=C2=A0 // move needs to set the foo.bar to this object
= =C2=A0 Bar(Bar&& other) : foo(other.foo<= /span>) {
=C2=A0 =C2=A0 other.foo =3D nullptr;
=C2=A0 =C2=A0 f= oo.bar =3D this= ;
=C2=A0 }
=C2=A0 Bar& oper= ator=3D(Bar&&a= mp; other) {
= =C2=A0 =C2=A0 swap(foo= , other.foo);
= =C2=A0 =C2=A0 foo.bar = =3D this;
=C2=A0 =C2=A0 other.foo.bar = =3D &other;
=C2=A0 =C2=A0 return <= /span>*this;
=C2=A0 }

=C2=A0 // If address = has changed, reset the foo.bar to point to the new location of the object=C2=A0 void operator relocate(void*) = {
=C2=A0 =C2=A0 foo= ..bar =3D this;<= /span>
=C2=A0 }
};=



Your example code is undefined behavior. I= f some other thread access bar::foo after the reallocation and before bar::= relocate gets to the fix up line your program goes boom.

How would that be different from any other da= ta race? Presumably, relocating an object is accessing it. So if two thread= s are accessing the same object at the same time, it's a data race: UB.=

If you need to thread relocation with other a= ccesses, it should be on you to provide it. Even atomic pointer fixup opera= tion wouldn't be enough, because you can have more than one pointer in = an object to fix up.

--
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/6acf3e14-579e-45d4-9a6f-9a548adf2c08= %40isocpp.org.
------=_Part_921_242881540.1533936333383-- ------=_Part_920_1203399263.1533936333382-- .