Bug 8139 – Make objects really disposable by addition of "Object finalized" assertion

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-05-24T03:39:44Z
Last change time
2024-12-13T18:00:03Z
Keywords
contracts, diagnostic
Assigned to
No Owner
Creator
Denis Shelomovskii
Moved to GitHub: dmd#18442 →

Comments

Comment #0 by verylonglogin.reg — 2012-05-24T03:39:44Z
Original NG thread: True disposable objects (add "Finalized!" assertion) http://forum.dlang.org/thread/[email protected] First message from NG thread: This idea is too obvious and I suppose I'm the only one not knowing it, but I have never seen it's implementation. Why? The idea: 1. `Object` class has hidden `isAlive` field which is true since construction and up to finalization. 2. Every method asserts that the object is alive first. 3. There is an `finalize` function that just rt_finalize an object in debug mode but can even free memory in release mode. Isn't it no-brainer? Isn't it the only way to debug manual memory management and shared resources without error-prone boilerplate? This is what I missed in C#, where I can dispose an object but I have to manually check the object isn't disposed every time I use it or in every it's method to find where I'm doing something with a disposed object by a mistake. IMHO finding using of dead references is almost as major as not allowing to free memory of alive objects (I mean GC), but GC is often implemented and dead references detection isn't. Strongly require your thoughts.
Comment #1 by alex — 2012-05-24T03:46:56Z
The idea in and of itself is not bad. In fact, it would make debugging wonderfully easy. My only concern is this: Object size. We already store two words of memory in *every single object header*. This means 8 bytes on 32-bit and 16 bytes on 64-bit. Now suppose we added an extra bool field to Object. Not only would the compiler have to be changed to align fields correctly, but it would also result in objects eating 12 bytes on 32-bit and 24 bytes on 64-bit (simply because the GC only power of two allocations or something along those lines). Now, the memory concern is not a problem for a class like this: class A { bool b; short s; } Obviously we don't need word alignment here, and we could probably optimize given that. But consider: class B { A a; } Suddenly that bool field has to suck an entire machine word's worth of space for 'a' to be aligned correctly.
Comment #2 by verylonglogin.reg — 2012-05-24T04:00:11Z
(In reply to comment #1) > Now suppose we added an extra bool field to Object. From Sean Kelly's reply at NG: > rt_finalize currently nulls out the vtbl pointer, which can server as an isAlive flag if desired. Link: http://forum.dlang.org/thread/[email protected]#post-mailman.323.1336157840.24740.digitalmars-d:40puremagic.com
Comment #3 by alex — 2012-05-24T04:00:51Z
In that case, I have no objections to doing this.
Comment #4 by doob — 2012-05-24T05:10:01Z
> From Sean Kelly's reply at NG: > > rt_finalize currently nulls out the vtbl pointer, which can server as an isAlive flag if desired. > > Link: > http://forum.dlang.org/thread/[email protected]#post-mailman.323.1336157840.24740.digitalmars-d:40puremagic.com The vtbl is only needed for virtual methods.
Comment #5 by alex — 2012-05-24T05:11:06Z
It's still set for all objects because it contains a pointer to type info. (The other machine word is the monitor.)
Comment #6 by robert.schadek — 2024-12-13T18:00:03Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18442 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB