GtkD wraps all the objects in Gtk. In callbacks like "onDraw", when they are called often, this creates heaps of tiny wrapper objects around huge data from C libraries. Eventually system memory is exhausted and the computer slows down and eats into swap. So should we add a "run garbage collector" button to every application to clean those up? Seems rather silly.

The GC should stick to its own memory and not try to manage resources it doesn't understand. Reference counting applies to external and system resources much better. To date neither the language nor Phobos can ref count classes. And even with library support it is not likely that it will get used widely, because plain classes are so much easier (also on the eyes).

The extent of this is pretty huge. There are many D wrapper libraries that build on classes and mimic what is available for C++ or Python. Issues like this make D appear like a toy language. How would one write a big desktop application when a simple animation can exhaust system memory in seconds ?

-- 
Marco

On Fri, 31 Oct 2014 05:38:48 +0100
Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> GtkD wraps all the objects in Gtk. In callbacks like "onDraw", when they are called often, this creates heaps of tiny wrapper objects around huge data from C libraries. Eventually system memory is exhausted and the computer slows down and eats into swap. So should we add a "run garbage collector" button to every application to clean those up? Seems rather silly.
> 
> The GC should stick to its own memory and not try to manage resources it doesn't understand. Reference counting applies to external and system resources much better. To date neither the language nor Phobos can ref count classes. And even with library support it is not likely that it will get used widely, because plain classes are so much easier (also on the eyes).
> 
> The extent of this is pretty huge. There are many D wrapper libraries that build on classes and mimic what is available for C++ or Python. Issues like this make D appear like a toy language. How would one write a big desktop application when a simple animation can exhaust system memory in seconds ?
why do you blaming GC for what seems to be a library author's fault? that was the library author who chooses to wrap externally-managed objects in GC objects, and creating alot of throwaway classes for that.

alas, we haven't Skynet at the hand to guess what author really wants.

p.s. i was never using GtkD, so i don't know if it's really doing the things you wrote or not, i'm just assuming that you are right.

On Friday, 31 October 2014 at 04:28:47 UTC, Marco Leise wrote:
> How would one write a big desktop application when
> a simple animation can exhaust system memory in seconds ?

Yep, it can be a long way from PoC to a quality implementation. Write GtkD 2.0 with careful approach w.r.t. resource management. Though, reference counting may not be a silver bullet, it still requires you to not forget to clear unneeded resources. And it's of no use if the reference is in an GC-managed object. Also you can still create big resources too eagerly instead of on demand, and hold onto them for longer than needed.

Am Fri, 31 Oct 2014 06:44:48 +0200
schrieb ketmar via Digitalmars-d <digitalmars-d@puremagic.com>:

> On Fri, 31 Oct 2014 05:38:48 +0100
> Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> > GtkD wraps all the objects in Gtk. In callbacks like "onDraw", when they are called often, this creates heaps of tiny wrapper objects around huge data from C libraries. Eventually system memory is exhausted and the computer slows down and eats into swap. So should we add a "run garbage collector" button to every application to clean those up? Seems rather silly.
> > 
> > The GC should stick to its own memory and not try to manage resources it doesn't understand. Reference counting applies to external and system resources much better. To date neither the language nor Phobos can ref count classes. And even with library support it is not likely that it will get used widely, because plain classes are so much easier (also on the eyes).
> > 
> > The extent of this is pretty huge. There are many D wrapper libraries that build on classes and mimic what is available for C++ or Python. Issues like this make D appear like a toy language. How would one write a big desktop application when a simple animation can exhaust system memory in seconds ?
> why do you blaming GC for what seems to be a library author's fault? that was the library author who chooses to wrap externally-managed objects in GC objects, and creating alot of throwaway classes for that.

Can't blame the author when there is no other choice in the language than to use tracing GC with inheritance.

> alas, we haven't Skynet at the hand to guess what author really wants.
> 
> p.s. i was never using GtkD, so i don't know if it's really doing the things you wrote or not, i'm just assuming that you are right.

To be fair there is an overload for addOnDraw that takes a delegate that has a Scoped!Context as parameter, but I cannot use that with delegates marked as nothrow since Scoped's dtor isn't nothrow. Which prompts the question again how to deal with exceptions in dtors. All D delegates called from the C side have to be nothrow though, because neither can druntime deal with GCC's amd64 stack (omit-frame-pointer) nor is the C side necessarily prepared for exceptions.

-- 
Marco

On Fri, 31 Oct 2014 09:46:54 +0100
Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Can't blame the author when there is no other choice in the language than to use tracing GC with inheritance.
there are alot of choices. i'm succesfully using wrapper classes with reference counting in my i/o streams library, for example. they are GC roots, and they are freed in the same moment when their reference count becomes zero.

> Which prompts the question again how to deal
> with exceptions in dtors.
class dtors should not throw any exceptions. stack-allocated struct dtors can do what they want, just catch that and you'll got "nothrow" function. what's the problem here?

Am Fri, 31 Oct 2014 10:51:04 +0200
schrieb ketmar via Digitalmars-d <digitalmars-d@puremagic.com>:

> On Fri, 31 Oct 2014 09:46:54 +0100
> Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> > Can't blame the author when there is no other choice in the language than to use tracing GC with inheritance.
> there are alot of choices. i'm succesfully using wrapper classes with reference counting in my i/o streams library, for example. they are GC roots, and they are freed in the same moment when their reference count becomes zero.

I meant obvious, clean, idiomatic choices. It's clear that D's expressiveness makes pretty much anything work if you put a week's worth of time into it. What I'm saying is, the language should offer something to use external resources in class hierarchies, because it is a common need. Something that comes with so little friction that you don't think twice.

> > Which prompts the question again how to deal
> > with exceptions in dtors.
> class dtors should not throw any exceptions. stack-allocated struct dtors can do what they want, just catch that and you'll got "nothrow" function. what's the problem here?

E-he, stack sounds nice, but those are in D's "parameter scope". You cannot wrap their destruction in try-catch.

-- 
Marco

On Fri, 31 Oct 2014 10:53:27 +0100
Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Am Fri, 31 Oct 2014 10:51:04 +0200
> schrieb ketmar via Digitalmars-d <digitalmars-d@puremagic.com>:
> 
> > On Fri, 31 Oct 2014 09:46:54 +0100
> > Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > 
> > > Can't blame the author when there is no other choice in the language than to use tracing GC with inheritance.
> > there are alot of choices. i'm succesfully using wrapper classes with reference counting in my i/o streams library, for example. they are GC roots, and they are freed in the same moment when their reference count becomes zero.
> 
> I meant obvious, clean, idiomatic choices. It's clear that D's expressiveness makes pretty much anything work if you put a week's worth of time into it. What I'm saying is, the language should offer something to use external resources in class hierarchies, because it is a common need. Something that comes with so little friction that you don't think twice.

if you have something concrete in mind, write ER or forum post, so we can destroy it. ;-)

> > > Which prompts the question again how to deal
> > > with exceptions in dtors.
> > class dtors should not throw any exceptions. stack-allocated struct dtors can do what they want, just catch that and you'll got "nothrow" function. what's the problem here?
> 
> E-he, stack sounds nice, but those are in D's "parameter scope". You cannot wrap their destruction in try-catch.

there is no problem that can't be solved by introducing one more wrapper. ;-)

On Friday, 31 October 2014 at 09:58:41 UTC, ketmar via Digitalmars-d wrote:
> if you have something concrete in mind, write ER or forum post, so we can destroy it. ;-)

Sure!

- dump the gc

- make uniqe_ptr a language builtin

- ditch c malloc

- make compiler 100% memory management aware

- make thread aware high speed class allocators a builtin

- ditch emplace

- default pointers to non-nullable

- do a complete redesign of phobos

I'm sure there is more…

On Fri, 31 Oct 2014 10:06:50 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 31 October 2014 at 09:58:41 UTC, ketmar via Digitalmars-d wrote:
> > if you have something concrete in mind, write ER or forum post, so we can destroy it. ;-)
> 
> Sure!
> 
> - dump the gc
> 
> - make uniqe_ptr a language builtin
> 
> - ditch c malloc
> 
> - make compiler 100% memory management aware
> 
> - make thread aware high speed class allocators a builtin
> 
> - ditch emplace
> 
> - default pointers to non-nullable
> 
> - do a complete redesign of phobos
> 
> I'm sure there is more…
send your patches! ;-)

On Fri, 31 Oct 2014 10:06:50 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

p.s. and title that "Z", as "the last language you'll need ever. in all meanings." ;-)