Re: More radical ideas about gc and reference counting

2014-05-17 Thread Jerry via Digitalmars-d
Rainer Schuetze writes: > On 14.05.2014 12:56, "Marc Schütz" " wrote: >> On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote: >>> class C { C next; } >>> >>> shared(C) list; >>> >>> C newC() >>> { >>> return new C; // allocated on the local heap? >> >> Yes, because it doesn't say "

Re: More radical ideas about gc and reference counting

2014-05-17 Thread via Digitalmars-d
On Friday, 16 May 2014 at 16:58:38 UTC, Rainer Schuetze wrote: On 14.05.2014 12:56, "Marc Schütz" " wrote: On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote: class C { C next; } shared(C) list; C newC() { return new C; // allocated on the local heap? Yes, because it doesn'

Re: More radical ideas about gc and reference counting

2014-05-16 Thread Rainer Schuetze via Digitalmars-d
On 14.05.2014 12:56, "Marc Schütz" " wrote: On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote: class C { C next; } shared(C) list; C newC() { return new C; // allocated on the local heap? Yes, because it doesn't say "new shared(C)". } void prependToList(C c) { synch

Re: More radical ideas about gc and reference counting

2014-05-15 Thread Dicebot via Digitalmars-d
On Thursday, 15 May 2014 at 06:30:40 UTC, Jacob Carlborg wrote: On 14/05/14 23:47, Dmitry Olshansky wrote: This is curious: http://burntsushi.net/rustdoc/regex/ It seems they have compile time regular expressions too. Yeah looks like my knowledge about their macro system is very outdated.

Re: More radical ideas about gc and reference counting

2014-05-14 Thread Jacob Carlborg via Digitalmars-d
On 14/05/14 23:47, Dmitry Olshansky wrote: This is curious: http://burntsushi.net/rustdoc/regex/ It seems they have compile time regular expressions too. -- /Jacob Carlborg

Re: More radical ideas about gc and reference counting

2014-05-14 Thread Dmitry Olshansky via Digitalmars-d
14-May-2014 17:16, Dicebot пишет: On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote: On 05/13/2014 09:07 PM, Jacob Carlborg wrote: On 2014-05-13 15:56, Dicebot wrote: Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html those are not full-blown AST macros like ones you

Re: More radical ideas about gc and reference counting

2014-05-14 Thread Timon Gehr via Digitalmars-d
On 05/14/2014 06:41 PM, Wyatt wrote: To me, shared is a type modifier that doesn't implicitely convert to anything else without casting. Interesting, maybe this should be clarified better. Having skimmed back over chapter 13 of TDPL, my understanding of its semantics are that it only really

Re: More radical ideas about gc and reference counting

2014-05-14 Thread Wyatt via Digitalmars-d
On Tuesday, 13 May 2014 at 19:56:20 UTC, Rainer Schuetze wrote: I just read the first chapters, and according to that, existing local gcs needs write barriers, so we are back to my second proposal. The implementation in the paper even adds read barriers. At this point, I suspect write barri

Re: More radical ideas about gc and reference counting

2014-05-14 Thread Dicebot via Digitalmars-d
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote: On 05/13/2014 09:07 PM, Jacob Carlborg wrote: On 2014-05-13 15:56, Dicebot wrote: Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html those are not full-blown AST macros like ones you have been proposing, more like hy

Re: More radical ideas about gc and reference counting

2014-05-14 Thread bearophile via Digitalmars-d
Walter Bright: On 5/12/2014 10:25 AM, bearophile wrote: Walter Bright: Unions of pointers are so rare in actual code that treating them conservatively is not a big problem. std.variant.Algebraic is based on on std.variant.VariantN, and on std.variant.VariantN is based on an union, and oft

Re: More radical ideas about gc and reference counting

2014-05-14 Thread via Digitalmars-d
On Tuesday, 13 May 2014 at 19:50:52 UTC, Rainer Schuetze wrote: On 13.05.2014 13:09, "Marc Schütz" " wrote: On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote: On 12.05.2014 13:53, "Marc Schütz" " wrote: I'm surprised that you didn't include: 3. Thread-local GC, isolated zone

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Tommi via Digitalmars-d
On Tuesday, 13 May 2014 at 21:16:55 UTC, Timon Gehr wrote: On 05/13/2014 09:07 PM, Jacob Carlborg wrote: On 2014-05-13 15:56, Dicebot wrote: Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html those are not full-blown AST macros like ones you have been proposing, more like hy

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Timon Gehr via Digitalmars-d
On 05/13/2014 09:07 PM, Jacob Carlborg wrote: On 2014-05-13 15:56, Dicebot wrote: Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html those are not full-blown AST macros like ones you have been proposing, more like hygienic version of C macros. Hmm, I haven't looked at Rust ma

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Rainer Schuetze via Digitalmars-d
On 13.05.2014 14:20, Wyatt wrote: On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote: This comes up from time to time, but to me it is very blurry how this can work in reality. The paper I linked on Friday [0] presents a collector like this. Are there concerns I've missed that m

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Rainer Schuetze via Digitalmars-d
On 13.05.2014 13:09, "Marc Schütz" " wrote: On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote: On 12.05.2014 13:53, "Marc Schütz" " wrote: I'm surprised that you didn't include: 3. Thread-local GC, isolated zones (restricting where references to objects of a particular heap c

Re: More radical ideas about gc and reference counting

2014-05-13 Thread via Digitalmars-d
On Tuesday, 13 May 2014 at 17:22:19 UTC, Steven Schveighoffer wrote: The idea I had was to make them pause-on-write. This means, when the original process attempts to write to the page, it gets a page-fault, which pauses the thread until the collector is done with it. This causes the same halti

Re: More radical ideas about gc and reference counting

2014-05-13 Thread via Digitalmars-d
On Tuesday, 13 May 2014 at 17:37:05 UTC, Steven Schveighoffer wrote: On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy wrote: "Steven Schveighoffer" wrote in message news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local... If a thread is doing only reads, or is only touching non-Scanned mem

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Jacob Carlborg via Digitalmars-d
On 2014-05-13 15:56, Dicebot wrote: Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html those are not full-blown AST macros like ones you have been proposing, more like hygienic version of C macros. Hmm, I haven't looked at Rust macros that much. -- /Jacob Carlborg

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Daniel Murphy via Digitalmars-d
"Steven Schveighoffer" wrote in message news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local... If a thread is doing only reads, or is only touching non-Scanned memory, it continues. How long do threads usually go without touching the stack?

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Steven Schveighoffer via Digitalmars-d
On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy wrote: "Steven Schveighoffer" wrote in message news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local... If a thread is doing only reads, or is only touching non-Scanned memory, it continues. How long do threads usually go without touchin

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Steven Schveighoffer via Digitalmars-d
On Tue, 13 May 2014 13:37:05 -0400, Steven Schveighoffer wrote: On Tue, 13 May 2014 13:36:17 -0400, Daniel Murphy wrote: "Steven Schveighoffer" wrote in message news:op.xfs6jhp3eav7ka@stevens-macbook-pro-2.local... If a thread is doing only reads, or is only touching non-Scanned m

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Steven Schveighoffer via Digitalmars-d
On Tue, 13 May 2014 12:14:06 -0400, Ola Fosheim Grøstad wrote: On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote: I know this is coming from a position of extreme ignorance, but why do we have to do copy on write? What about pause on write? Not sure how that will help? P

Re: More radical ideas about gc and reference counting

2014-05-13 Thread via Digitalmars-d
On Tuesday, 13 May 2014 at 16:14:07 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote: Not sure how that will help? Pointers may still escape collection? (as in not being traced, leading to freeing live memory)

Re: More radical ideas about gc and reference counting

2014-05-13 Thread via Digitalmars-d
On Tuesday, 13 May 2014 at 14:13:31 UTC, Steven Schveighoffer wrote: I know this is coming from a position of extreme ignorance, but why do we have to do copy on write? What about pause on write? Not sure how that will help? Pointers may still escape collection? (but you get that with transact

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Timon Gehr via Digitalmars-d
On 05/13/2014 03:56 PM, Dicebot wrote: On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote: On 2014-05-12 19:14, Dicebot wrote: It lacks any good static reflection though. And this stuff is damn addictive when you try it of D caliber. It has macros, that basically requires great sup

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Steven Schveighoffer via Digitalmars-d
On Tue, 13 May 2014 02:12:44 -0400, Rainer Schuetze wrote: On 13.05.2014 00:15, Martin Nowak wrote: On 05/11/2014 08:18 PM, Rainer Schuetze wrote: 1. Use a scheme that takes a snapshot of the heap, stack and registers at the moment of collection and do the actual collection in another th

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Dicebot via Digitalmars-d
On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote: On 2014-05-12 19:14, Dicebot wrote: It lacks any good static reflection though. And this stuff is damn addictive when you try it of D caliber. It has macros, that basically requires great support for static reflection to be usabl

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Wyatt via Digitalmars-d
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote: This comes up from time to time, but to me it is very blurry how this can work in reality. The paper I linked on Friday [0] presents a collector like this. Are there concerns I've missed that make that not applicable? Conside

Re: More radical ideas about gc and reference counting

2014-05-13 Thread via Digitalmars-d
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote: On 12.05.2014 13:53, "Marc Schütz" " wrote: I'm surprised that you didn't include: 3. Thread-local GC, isolated zones (restricting where references to objects of a particular heap can be placed), exempting certain threads fro

Re: More radical ideas about gc and reference counting

2014-05-13 Thread via Digitalmars-d
On Tuesday, 13 May 2014 at 06:12:46 UTC, Rainer Schuetze wrote: On 13.05.2014 00:15, Martin Nowak wrote: There is a problem with this scheme, copy-on-write is extremely expensive when a mutation happens. That's one page fault (context switch) + copying a whole page + mapping the new page.

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Rainer Schuetze via Digitalmars-d
On 13.05.2014 00:15, Martin Nowak wrote: On 05/11/2014 08:18 PM, Rainer Schuetze wrote: 1. Use a scheme that takes a snapshot of the heap, stack and registers at the moment of collection and do the actual collection in another thread/process while the application can continue to run. This is

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Rainer Schuetze via Digitalmars-d
On 12.05.2014 13:53, "Marc Schütz" " wrote: I'm surprised that you didn't include: 3. Thread-local GC, isolated zones (restricting where references to objects of a particular heap can be placed), exempting certain threads from GC completely, ... This comes up from time to time, but to me it

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 2:28 PM, Xavier Bigand wrote: All compile time things of D are marvelous. This with the compile time and the language less error prone make me want D. I am not sure I need safety so much. It's nice but not mandatory for any of my projects. The only one which has to be safe is DQuick.

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 2:32 PM, Steven Schveighoffer wrote: It's still forbidden. Andrei wrote a template that will verify this at runtime, but I don't recall its name. Can you cite the spec where it says it's forbidden? Forgotten templates are not a convincing argument. Regardless, Java can use a movin

Re: More radical ideas about gc and reference counting

2014-05-12 Thread via Digitalmars-d
On Monday, 12 May 2014 at 22:27:06 UTC, Kapps wrote: because it's so short. This is quite sufficient for most projects, but perhaps could be tweaked a bit more for certain aspects like gaming, possibly even enabling concurrent collection for generation 0/1, but I'm not sure if this works well o

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Kapps via Digitalmars-d
On Monday, 12 May 2014 at 19:13:50 UTC, Ola Fosheim Grøstad wrote: On Monday, 12 May 2014 at 18:07:51 UTC, Kapps wrote: Depending on how tunable the GC is, I feel like it should be possible to get away with a GC even for soft real-time programs like games. Even if you manage to make it work fo

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Martin Nowak via Digitalmars-d
On 05/11/2014 08:18 PM, Rainer Schuetze wrote: 1. Use a scheme that takes a snapshot of the heap, stack and registers at the moment of collection and do the actual collection in another thread/process while the application can continue to run. This is the way Leandro Lucarellas concurrent GC wor

Re: More radical ideas about gc and reference counting

2014-05-12 Thread via Digitalmars-d
On Monday, 12 May 2014 at 21:22:09 UTC, Steven Schveighoffer wrote: On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad wrote: On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote: On 5/12/2014 7:46 AM, Steven Schveighoffer wrote: pointing at it is roughly 1/256. This problem is j

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Steven Schveighoffer via Digitalmars-d
On Mon, 12 May 2014 17:32:09 -0400, Steven Schveighoffer wrote: The workaround is simply to keep it around, but that's not always a scalable solution. Sorry, actually you can free it. That's the correct workaround. -Steve

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Steven Schveighoffer via Digitalmars-d
On Mon, 12 May 2014 13:52:20 -0400, Walter Bright wrote: On 5/12/2014 7:46 AM, Steven Schveighoffer wrote: It doesn't matter where the false pointers are. The largest issue with false pointers is not how many false pointers there are. It only matters how large the block is that it "points

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Xavier Bigand via Digitalmars-d
Le 12/05/2014 19:14, Dicebot a écrit : On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote: But D is *so close*... and I like it! >_< I have to say that this discussion has certainly left me somewhat intrigued by Rust though. I've never given it a fair go because I find the syn

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Steven Schveighoffer via Digitalmars-d
On Mon, 12 May 2014 14:14:28 -0400, Ola Fosheim Grøstad wrote: On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote: On 5/12/2014 7:46 AM, Steven Schveighoffer wrote: pointing at it is roughly 1/256. This problem is just about eliminated with 64-bit pointers. Not generally true.

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 12:36 PM, Timon Gehr wrote: Do you mean the table is not actually global but passed by parameter, Yes. But note that the distinction between the two is often blurry. Under the hood on some systems, global data is accessed via the equivalent of a hidden parameter.

Re: More radical ideas about gc and reference counting

2014-05-12 Thread bearophile via Digitalmars-d
Andrei Alexandrescu: How did I give the impression it has anything to do with unions? -- Andrei OK, so yours is not an answer to my proposal, nor related to it. Bye, bearophile

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Andrei Alexandrescu via Digitalmars-d
On 5/12/14, 12:59 PM, bearophile wrote: Andrei Alexandrescu: I, too, felt the need of onGC() - actually preGC() - in my allocators implementation. ... A hook that nulls all freelist heads just as the collection process starts would be helpful. How is this going to help increase tracing precis

Re: More radical ideas about gc and reference counting

2014-05-12 Thread bearophile via Digitalmars-d
Andrei Alexandrescu: I, too, felt the need of onGC() - actually preGC() - in my allocators implementation. ... A hook that nulls all freelist heads just as the collection process starts would be helpful. How is this going to help increase tracing precision of unions (and Algebraic built on

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Jacob Carlborg via Digitalmars-d
On 2014-05-12 19:14, Dicebot wrote: It lacks any good static reflection though. And this stuff is damn addictive when you try it of D caliber. It has macros, that basically requires great support for static reflection to be usable. -- /Jacob Carlborg

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Timon Gehr via Digitalmars-d
On 05/12/2014 06:37 PM, Walter Bright wrote: On 5/12/2014 5:15 AM, Timon Gehr wrote: On 05/12/2014 10:54 AM, Walter Bright wrote: On 5/11/2014 10:57 PM, Marco Leise wrote: Am Sun, 11 May 2014 17:50:25 -0700 schrieb Walter Bright : As long as those pointers don't escape. Am I right in that on

Re: More radical ideas about gc and reference counting

2014-05-12 Thread via Digitalmars-d
On Monday, 12 May 2014 at 18:07:51 UTC, Kapps wrote: Depending on how tunable the GC is, I feel like it should be possible to get away with a GC even for soft real-time programs like games. Even if you manage to make it work for game clients you also should make it work for low latency game se

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 13 May 2014 04:07, Kapps via Digitalmars-d wrote: > On Monday, 12 May 2014 at 16:03:28 UTC, Manu via Digitalmars-d > wrote: >> >> How long is a collect liable to take in the event the GC threads need >> >> to collect? Am I likely to lose my service threads for 100s of >> milliseconds at a time?

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Andrei Alexandrescu via Digitalmars-d
On 5/12/14, 11:17 AM, Dmitry Olshansky wrote: 12-May-2014 22:08, Andrei Alexandrescu пишет: On 5/12/14, 10:25 AM, bearophile wrote: A hook that nulls all freelist heads just as the collection process starts would be helpful. One word - weak pointers. Then head of freelist is weak and can be co

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Dmitry Olshansky via Digitalmars-d
12-May-2014 22:08, Andrei Alexandrescu пишет: On 5/12/14, 10:25 AM, bearophile wrote: A hook that nulls all freelist heads just as the collection process starts would be helpful. One word - weak pointers. Then head of freelist is weak and can be collected at whim. Andrei -- Dmitry Ols

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Andrei Alexandrescu via Digitalmars-d
On 5/12/14, 10:25 AM, bearophile wrote: Walter Bright: Unions of pointers are so rare in actual code that treating them conservatively is not a big problem. std.variant.Algebraic is based on on std.variant.VariantN, and on std.variant.VariantN is based on an union, and often you use algebraic

Re: More radical ideas about gc and reference counting

2014-05-12 Thread via Digitalmars-d
On Monday, 12 May 2014 at 17:52:18 UTC, Walter Bright wrote: On 5/12/2014 7:46 AM, Steven Schveighoffer wrote: pointing at it is roughly 1/256. This problem is just about eliminated with 64-bit pointers. Not generally true. This presumes that the heap is not in the lower region of the addres

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Kapps via Digitalmars-d
On Monday, 12 May 2014 at 16:03:28 UTC, Manu via Digitalmars-d wrote: How long is a collect liable to take in the event the GC threads need to collect? Am I likely to lose my service threads for 100s of milliseconds at a time? I'll think on it, but I don't think there's anything practically app

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 13 May 2014 03:44, Walter Bright via Digitalmars-d wrote: > On 5/12/2014 10:31 AM, Manu via Digitalmars-d wrote: >> >> I just searched through my code, and 7 out of 12 unions had pointers. > > > Relative number of objects with unions, not declarations with unions! Ah, well I have 3 different t

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote: It doesn't matter where the false pointers are. The largest issue with false pointers is not how many false pointers there are. It only matters how large the block is that it "points" at. The larger your blocks get, the more likely they are "point

Re: More radical ideas about gc and reference counting

2014-05-12 Thread bearophile via Digitalmars-d
Walter Bright: BTW, the RTinfo can be used to discriminate unions. I don't know if std.variant.VariantN is already using such RTinfo. I don't know much about RTinfo. Bye, bearophile

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 10:25 AM, bearophile wrote: Walter Bright: Unions of pointers are so rare in actual code that treating them conservatively is not a big problem. std.variant.Algebraic is based on on std.variant.VariantN, and on std.variant.VariantN is based on an union, and often you use algebrai

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 10:07 AM, Dicebot wrote: We have already had discussion where I did state that current @nogc implementation is not robust enough and failed to explain the use case for weaker @nogc clearly. Conclusion was that we should return to this topic after Don's DConf talk ;) Sure - next wee

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 10:31 AM, Manu via Digitalmars-d wrote: I just searched through my code, and 7 out of 12 unions had pointers. Relative number of objects with unions, not declarations with unions!

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 13 May 2014 03:14, Dicebot via Digitalmars-d wrote: > On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote: >> >> But D is *so close*... and I like it! >_< >> >> I have to say that this discussion has certainly left me somewhat >> intrigued by Rust though. >> I've never given it

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 13 May 2014 03:17, Walter Bright via Digitalmars-d wrote: > On 5/12/2014 4:35 AM, bearophile wrote: >> >> I suggested to add an optional method named "onGC" to unions that if >> present is >> called at run-time by the GC to know what's the real type of stored data, >> to >> make tracing more pr

Re: More radical ideas about gc and reference counting

2014-05-12 Thread bearophile via Digitalmars-d
Walter Bright: Unions of pointers are so rare in actual code that treating them conservatively is not a big problem. std.variant.Algebraic is based on on std.variant.VariantN, and on std.variant.VariantN is based on an union, and often you use algebraic data types to represent trees and simi

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 4:35 AM, bearophile wrote: I suggested to add an optional method named "onGC" to unions that if present is called at run-time by the GC to know what's the real type of stored data, to make tracing more precise. Unions of pointers are so rare in actual code that treating them conser

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Dicebot via Digitalmars-d
On Monday, 12 May 2014 at 17:03:41 UTC, Manu via Digitalmars-d wrote: But D is *so close*... and I like it! >_< I have to say that this discussion has certainly left me somewhat intrigued by Rust though. I've never given it a fair go because I find the syntax so distasteful and deterring. I

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Dicebot via Digitalmars-d
On Monday, 12 May 2014 at 17:03:18 UTC, Walter Bright wrote: On 5/12/2014 2:12 AM, Dicebot wrote: I think this is more of library writing culture problem than engineering problem. High quality library shouldn't rely on any internal allocations at all, deferring this decision to user code. Other

Re: More radical ideas about gc and reference counting

2014-05-12 Thread via Digitalmars-d
On Monday, 12 May 2014 at 16:16:06 UTC, bearophile wrote: Perhaps the game industry has to start the creation of a language designed for its needs, like the scientific people have done (Julia), the browser ones (Rust), the Web ones have done, etc. With lot of work in less than ten years you can

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 2:12 AM, Dicebot wrote: I think this is more of library writing culture problem than engineering problem. High quality library shouldn't rely on any internal allocations at all, deferring this decision to user code. Otherwise you will eventually have problems, GC or not. Consider m

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 13 May 2014 02:16, bearophile via Digitalmars-d wrote: > Manu: > > >> we are an industry in desperate need of salvation, >> it's LONG overdue, and I want something that actually works well for us, >> not a crappy set of compromises because the >> language has a fundamental incompatibility with

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 5:15 AM, Timon Gehr wrote: On 05/12/2014 10:54 AM, Walter Bright wrote: On 5/11/2014 10:57 PM, Marco Leise wrote: Am Sun, 11 May 2014 17:50:25 -0700 schrieb Walter Bright : As long as those pointers don't escape. Am I right in that one cannot store a borrowed pointer into a globa

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 3:18 AM, Marco Leise wrote: Your were arguing against Michel Fortin's proposal on the surface, when your requirement cannot even be fulfilled theoretically it seems. Lots of people use ARC without a GC. Which could mean that you don't like the idea of replacing D's GC with an AR

Re: More radical ideas about gc and reference counting

2014-05-12 Thread via Digitalmars-d
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote: 2. you can have the non-pausible code running in a thread that is not registered with the gc, so the gc won't pause it. This requires that this thread not allocate gc memory, but it can use gc memory allocated by other threads, as lon

Re: More radical ideas about gc and reference counting

2014-05-12 Thread bearophile via Digitalmars-d
Manu: we are an industry in desperate need of salvation, it's LONG overdue, and I want something that actually works well for us, not a crappy set of compromises because the language has a fundamental incompatibility with my industry :/ Perhaps the game industry has to start the creation of

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 12 May 2014 18:45, Walter Bright via Digitalmars-d wrote: > On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote: >> >> What? You've never offered me a practical solution. > > > I have, you've just rejected them. > > >> What do I do? > > > 1. you can simply do C++ style memory management. shared

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Steven Schveighoffer via Digitalmars-d
On Sun, 11 May 2014 16:33:04 -0400, Walter Bright wrote: On 5/11/2014 2:48 AM, Benjamin Thaut wrote: Mostly percise doesn't help. Its either fully percise or beeing stuck with a impercise mark & sweep. This is not correct. It helps because most of the false pointers will be in the heap

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Steven Schveighoffer via Digitalmars-d
On Mon, 12 May 2014 03:39:12 -0400, Manu via Digitalmars-d wrote: On 12 May 2014 17:24, Dicebot via Digitalmars-d You will like Don's talk this year ;) I'm super-disappointed I can't make it this year! ?!! http://dconf.org/2014/talks/evans.html We were evicted from our house, have to

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Timon Gehr via Digitalmars-d
On 05/12/2014 10:54 AM, Walter Bright wrote: On 5/11/2014 10:57 PM, Marco Leise wrote: Am Sun, 11 May 2014 17:50:25 -0700 schrieb Walter Bright : As long as those pointers don't escape. Am I right in that one cannot store a borrowed pointer into a global data structure? Right, and that's the

Re: More radical ideas about gc and reference counting

2014-05-12 Thread via Digitalmars-d
On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote: For a reasonable GC I currently see 2 possible directions: 1. Use a scheme that takes a snapshot of the heap, stack and registers at the moment of collection and do the actual collection in another thread/process while the applicat

Re: More radical ideas about gc and reference counting

2014-05-12 Thread bearophile via Digitalmars-d
Timon Gehr: (Probably more, actually, because it does not provide precision-unfriendly constructs such as undiscriminated unions.) I suggested to add an optional method named "onGC" to unions that if present is called at run-time by the GC to know what's the real type of stored data, to make

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Timon Gehr via Digitalmars-d
On 05/12/2014 02:50 AM, Walter Bright wrote: On 5/11/2014 1:59 PM, Timon Gehr wrote: On 05/11/2014 10:05 PM, Walter Bright wrote: That's clearly an additional benefit of the borrowed pointer notion. But have you examined generated Rust code for the cost of inc/dec? I haven't, but I don't see an

Re: More radical ideas about gc and reference counting

2014-05-12 Thread John Colvin via Digitalmars-d
On Monday, 12 May 2014 at 10:51:33 UTC, Marco Leise wrote: Time will tell if all "well written" D libraries will be @nogc to move the question of allocations to the user. If there was such a thing as "weakly &nogc" then we would could do this //some library function void foo(OR, IR)(OR o, I

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Marco Leise via Digitalmars-d
Am Mon, 12 May 2014 09:32:58 + schrieb "Paulo Pinto" : > On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote: > > On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote: > >> On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote: > >>> What? You've never offered me a practical solutio

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Tommi via Digitalmars-d
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote: I like this owner/unique, borrow thing. @ is managed (currently reference counted) ~ is owner & is borrow I like it too. But a few notes: 1) The managed pointer @T has been deprecated and you should use the standard library types Gc an

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Marco Leise via Digitalmars-d
Am Mon, 12 May 2014 01:54:58 -0700 schrieb Walter Bright : > On 5/11/2014 10:57 PM, Marco Leise wrote: > > Am Sun, 11 May 2014 17:50:25 -0700 > > schrieb Walter Bright : > > > >> As long as those pointers don't escape. Am I right in that one cannot > >> store a > >> borrowed pointer into a global

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Marco Leise via Digitalmars-d
Am Sun, 11 May 2014 22:11:28 -0700 schrieb Walter Bright : > > But I thought ARC cannot be designed without GC to resolve > > cycles. > > It can be, there are various schemes to deal with that, including "don't > create > cycles". GC is just one of them. > > http://en.wikipedia.org/wiki/Refere

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Paulo Pinto via Digitalmars-d
On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote: On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote: On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote: What? You've never offered me a practical solution. I have, you've just rejected them. What do I do? 1. you can sim

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Dicebot via Digitalmars-d
On Monday, 12 May 2014 at 09:05:39 UTC, John Colvin wrote: On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote: The only solutions to the libraries problem that I can see here require drastic separation of calls to said libraries from any even vaguely time critical code. This is quite r

Re: More radical ideas about gc and reference counting

2014-05-12 Thread John Colvin via Digitalmars-d
On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote: On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote: What? You've never offered me a practical solution. I have, you've just rejected them. What do I do? 1. you can simply do C++ style memory management. shared_ptr<>, etc. 2.

Re: More radical ideas about gc and reference counting

2014-05-12 Thread bearophile via Digitalmars-d
Walter Bright: But I don't see how this could work in Rust. Ask it to competent Rust developers/programmers. Bye, bearophile

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/11/2014 10:57 PM, Marco Leise wrote: Am Sun, 11 May 2014 17:50:25 -0700 schrieb Walter Bright : As long as those pointers don't escape. Am I right in that one cannot store a borrowed pointer into a global data structure? Right, and that's the point and entirely positive-to-do™. This me

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Walter Bright via Digitalmars-d
On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote: What? You've never offered me a practical solution. I have, you've just rejected them. What do I do? 1. you can simply do C++ style memory management. shared_ptr<>, etc. 2. you can have the non-pausible code running in a thread that is

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Tommi via Digitalmars-d
On Monday, 12 May 2014 at 08:10:43 UTC, Tommi wrote: Perhaps: [..] Somewhat surprisingly to me, you can later on change the borrowed pointer in the mutable static 'Test' to point at a mutable static int: struct Test { n: &'static int } static old: int = 111; static mut new: int = 222;

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Tommi via Digitalmars-d
On Monday, 12 May 2014 at 00:50:24 UTC, Walter Bright wrote: On 5/11/2014 1:59 PM, Timon Gehr wrote: Borrowed pointers are not even superficially similar to near*. They are compatible with everything else, because they can store data that was borrowed from anywhere else. As long as those poi

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 12 May 2014 17:24, Dicebot via Digitalmars-d wrote: > On Monday, 12 May 2014 at 07:12:29 UTC, Manu via Digitalmars-d wrote: >> >> You haven't told me how I can use the GC (or whatever memory >> management scheme, I really don't care) in the low frequency code >> (again, read: almost all code ev

Re: More radical ideas about gc and reference counting

2014-05-12 Thread ponce via Digitalmars-d
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote: On 5/11/14, 2:49 PM, ponce wrote: On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote: There is very little use of "@", it's mostly "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they a

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Dicebot via Digitalmars-d
On Monday, 12 May 2014 at 07:12:29 UTC, Manu via Digitalmars-d wrote: You haven't told me how I can use the GC (or whatever memory management scheme, I really don't care) in the low frequency code (again, read: almost all code ever), and not have it interfere with the high frequency code. Yo

Re: More radical ideas about gc and reference counting

2014-05-12 Thread ponce via Digitalmars-d
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote: On 5/11/14, 2:49 PM, ponce wrote: On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote: There is very little use of "@", it's mostly "&" and "~". Heck I didn't find any @ while casually browsing the code. It's like they a

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Rainer Schuetze via Digitalmars-d
On 12.05.2014 06:57, "Ola Fosheim Grøstad" " wrote: On Sunday, 11 May 2014 at 20:45:08 UTC, Rainer Schuetze wrote: On 11.05.2014 22:33, Walter Bright wrote: The Boehm collector cannot move objects around, the D one can. Oh it can? Really? Yes. D, for example, requires that objects not

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Manu via Digitalmars-d
On 12 May 2014 10:50, Walter Bright via Digitalmars-d wrote: > >> They are using Rust to write a safe and performant web browser while >> developing >> the language. > > > Sure. But that browser hasn't been released yet. Consider that I've written > safe and performant code in D, but others tell m

  1   2   3   4   5   >