Re: GC question

2017-02-08 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Saturday, 4 February 2017 at 15:23:53 UTC, Adam D. Ruppe wrote: On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote: - Automatic but conservative. Can leak at any time. All GCs are prone to leak, including precise ones. The point of garbage collection is not to prevent leaks, but rath

Re: GC question

2017-02-05 Thread Cym13 via Digitalmars-d-learn
On Sunday, 5 February 2017 at 04:22:30 UTC, rikki cattermole wrote: On 05/02/2017 5:02 PM, thedeemon wrote: snip It may look so from a distance. But in my experience it's not that bad. In most software I did in D it did not matter really (it's either 64-bit or short lived programs) and the co

Re: GC question

2017-02-04 Thread rikki cattermole via Digitalmars-d-learn
On 05/02/2017 5:02 PM, thedeemon wrote: snip It may look so from a distance. But in my experience it's not that bad. In most software I did in D it did not matter really (it's either 64-bit or short lived programs) and the control D gives to choose how to deal with everything makes it all quite

Re: GC question

2017-02-04 Thread thedeemon via Digitalmars-d-learn
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote: - Automatic but conservative. Can leak at any time. You have to implement manual management (managed heaps) to avoid leaks. Leaks are hard to find as any heap value may be causing it. By "managed heap" I just meant the GC heap, the one

Re: GC question

2017-02-04 Thread osa1 via Digitalmars-d-learn
All GCs are prone to leak, including precise ones. The point of garbage collection is not to prevent leaks, but rather to prevent use-after-free bugs. Of course I can have leaks in a GC environment, but having non-deterministic leaks is another thing, and I'd rather make sure to delete my ref

Re: GC question

2017-02-04 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote: - Automatic but conservative. Can leak at any time. All GCs are prone to leak, including precise ones. The point of garbage collection is not to prevent leaks, but rather to prevent use-after-free bugs. Granted, the D 32 bit GC is mo

Re: GC question

2017-02-04 Thread Kagamin via Digitalmars-d-learn
On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote: I'm surprised that D was able to come this far with this. It's used mostly for server software. Things are moving to 64 bit, so this will be less of an issue.

Re: GC question

2017-02-04 Thread osa1 via Digitalmars-d-learn
On Saturday, 4 February 2017 at 11:09:21 UTC, thedeemon wrote: On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC rather than a precise one, I've never worked with a conservative GC bef

Re: GC question

2017-02-04 Thread thedeemon via Digitalmars-d-learn
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC rather than a precise one, I've never worked with a conservative GC before. Are there any disallowed memory operations? Can I break thi

Re: GC question

2017-02-03 Thread Dsby via Digitalmars-d-learn
On Friday, 3 February 2017 at 11:36:26 UTC, osa1 wrote: On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote: Leaks are likely in 32-bit processes and unlikely in 64-bit processes. See e.g. https://issues.dlang.org/show_bug.cgi?id=15723 This looks pretty bad. I think I'll consider someth

Re: GC question

2017-02-03 Thread osa1 via Digitalmars-d-learn
On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote: Leaks are likely in 32-bit processes and unlikely in 64-bit processes. See e.g. https://issues.dlang.org/show_bug.cgi?id=15723 This looks pretty bad. I think I'll consider something else until D's memory management story gets better.

Re: GC question

2017-02-03 Thread Kagamin via Digitalmars-d-learn
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: Are there any disallowed memory operations? Currently can't touch GC from destructor during collection. Another concern is interoperability with C-allocated memory: GC knows nothing about C heap. How often does it leak? Leaks are

Re: GC question

2017-02-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Wednesday, 1 February 2017 at 09:50:42 UTC, osa1 wrote: Thanks for the answer. Could you elaborate on the lacklustre part? It's fine if I have to do manual memory management, but I don't want any leaks. Ideally I'd have a precise GC + RAII style resource management when needed. Rust, Go, J

Re: GC question

2017-02-01 Thread osa1 via Digitalmars-d-learn
On Wednesday, 1 February 2017 at 09:40:17 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC rather than a precise one, I've never worked with a conserva

Re: GC question

2017-02-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC rather than a precise one, I've never worked with a conservative GC before. The GC isn't competitive with the ones you find in GC lan

GC question

2017-01-31 Thread osa1 via Digitalmars-d-learn
Hi all, I was looking at D as the next language to use in my hobby projects, but the "conservative GC" part in the language spec (http://dlang.org/spec/garbage.html) looks a bit concerning. I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC ra