{"id":1065,"date":"2013-07-05T01:00:00","date_gmt":"2013-07-05T00:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1065"},"modified":"2015-02-19T20:36:31","modified_gmt":"2015-02-19T20:36:31","slug":"garbage-collection-is-harmful","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1065","title":{"rendered":"Garbage Collection is Harmful"},"content":{"rendered":"

I don\u00e2\u20ac\u2122t like garbage collection.<\/p>\n

Fundamentally, my problem with languages that have a garbage collected memory model is this: memory is not the only resource<\/em>.<\/p>\n

Resource Acquisiation is Initialisation. RAII as it\u00e2\u20ac\u2122s often abbreviated to. RAII and object oriented languages go together beautifully because the language does the heavy lifting with its automatic calling of constructors and, more particularly, destructors.<\/p>\n

Garbage collection encourages you to write non-object-oriented code in your fancy object oriented language, and worse, it doesn\u00e2\u20ac\u2122t remove the need for you to manage resources anyway. Garbage collection only works on memory. When the resource isn\u00e2\u20ac\u2122t memory, like, mutex\u00e2\u20ac\u2122s, texture buffers, file handles, network sockets, you still<\/em> have to manage the resource yourself, and you also end up needing a pseudo-destructor.<\/p>\n

class<\/span> FileObject {\n    public<\/span> FileObject( name ) {\n        open<\/span>(name);\n    }\n\n    \/\/ There is no destructor in Java, finalize() is closest<\/span>\n    @Override<\/span>\n    protected<\/span> finalize<\/span>() throws<\/span> Throwable {\n        try<\/span> {\n            close<\/span>();\n        } finally<\/span> {\n            super<\/span>.finalize<\/span>();\n        }\n    }\n\n    public<\/span> void<\/span> close<\/span>();\n    public<\/span> void<\/span> open<\/span>();\n    \/\/ ... read, write, the rest ...<\/span>\n};\n\nvoid<\/span> someFunction<\/span>() {\n    \/\/ Let's say uniquefile.txt can't be opened more than once at any<\/span>\n    \/\/ one time<\/span>\n    FileObject openOnce = new<\/span> FileObject("uniquefile.txt"<\/span>);\n    \/\/ use<\/span>\n    openOnce.read<\/span>();\n\n    \/\/ ... tidy up ...<\/span>\n}<\/code><\/pre>\n
So, what do we do for tidying up? \u00e2\u20ac\u0153Garbage collection\u00e2\u20ac\u009d you might cry, \u00e2\u20ac\u0153someFunction()<\/code> will finish, openOnce<\/code> will go out of scope, making its reference count go to zero, the garbage collector will call the destructor, which will call close()<\/code>\u00e2\u20ac\u009d. You wish that\u00e2\u20ac\u2122s what happens. It\u00e2\u20ac\u2122s not though.<\/p>\n
The problem is this: the garbage collector doesn\u00e2\u20ac\u2122t run in-thread, when openOnce<\/code> has its reference count reduced to zero, that\u00e2\u20ac\u2122s all<\/em> that happens. Or rather, all that is guaranteed to happen. In fact, it\u00e2\u20ac\u2122s identical to simply calling openOnce = null;<\/code>. This is about as close as Java has to a delete<\/code>; but the destructor isn\u00e2\u20ac\u2122t<\/em> called instantly.<\/p>\n
The garbage collector thread will eventually get around to destructing the object, and the file will be closed. In the meantime, if someone else opens \u00e2\u20ac\u0153uniquefile.txt<\/code>\u00e2\u20ac\u009d, we will have broken our \u00e2\u20ac\u0153only one handle at a time\u00e2\u20ac\u009d rule for this resource. We\u00e2\u20ac\u2122re forced then to use our pseudo-constructor, in this case close()<\/code>.<\/p>\n
void<\/span> someFunction<\/span>() {\n    \/\/ Let's say uniquefile.txt can't be opened more than once at any<\/span>\n    \/\/ one time<\/span>\n    FileObject openOnce = new<\/span> FileObject("uniquefile.txt"<\/span>);\n    \/\/ use<\/span>\n    openOnce.read<\/span>();\n\n    openOnce.close<\/span>();\n}<\/code><\/pre>\n
For me then, the question is, why bother with garbage collection?. In all but the simplest of resources (memory), we\u00e2\u20ac\u2122re going to have to call a destructor anyway. (Python has exactly the same problems<\/a> because the destructor is a bit hazy, and has been forced to introduce more complexity with its \u00e2\u20ac\u02dcwith<\/code>\u00e2\u20ac\u2122 keyword for creating \u00e2\u20ac\u0153contexts\u00e2\u20ac\u009d).<\/p>\n
This ties in quite closely with my earlier article<\/a>, where I covered the principle that a properly written resource-managing object with constructor and destructor will, effectively, automatically garbage collect. There\u00e2\u20ac\u2122s little evidence to suggest that garbage collection is, these days, any kind of massive resource drain. Perversely though, it means you have to care more<\/em> about the lifetime of your non-memory resources than you would in a non-GC language.<\/p>\n
It\u00e2\u20ac\u2122s particularly obvious when you see the hoops Python is slowly adding that get jumped through to deal with all the problems that GC creates. The following \u00e2\u20ac\u0153special\u00e2\u20ac\u009d members of objects exist all to avoid the supposed complexity of construction\/destruction.<\/p>\n