Closed Bug 608285 Opened 14 years ago Closed 14 years ago

Make GCFinalizedObject inherit from GCObject

Categories

(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P1)

defect

Tracking

(Not tracked)

VERIFIED WONTFIX
Q3 11 - Serrano

People

(Reporter: treilly, Assigned: treilly)

Details

Attachments

(1 file)

I don't know what to say, I just tried it in a sandbox build and it passed. Maybe it was a bug with msvc pre-VS2008?
Attached patch yeah!Splinter Review
I wonder if this cleans up any of Steven's list stuff...
Assignee: nobody → treilly
Status: NEW → ASSIGNED
Attachment #486927 - Flags: review?(lhansen)
Comment on attachment 486927 [details] [diff] [review] yeah! Out of scope.
Attachment #486927 - Flags: review?(lhansen) → review-
if this gets revisited, I want to see a selftest illustrating that delete on a finalized object that has been casted to a GCObject* still "works", in the sense that the finalizer still gets run. (It may well work, I don't remember enough about how our destruction works.)
> Out of scope. The scope is going for a universal GCMember instead of one in each of GCRoot/GCObject/GCFinalizedObject but there may be other ways to achieve that...
(In reply to comment #3) > if this gets revisited, I want to see a selftest illustrating that delete on a > finalized object that has been casted to a GCObject* still "works", in the > sense that the finalizer still gets run. (It may well work, I don't remember > enough about how our destruction works.) So far as I know from the semantics of C++, the destructor will not be called in that situation if the delete operator is called explicitly, which is the main reason for rejecting the patch. (I apologize for the overly brief message on Friday.) The destructor probably will be called by the garbage collector because the garbage collector does not pay attention to the type but to the header bit. I also worry about what would happen if any data are added to GCObject, either by us in a Debug setting or by the compiler. I don't know what the scope is for that, but the minute a cast from a GCObject to a GCFinalizedObject or vice versa is anything but a no-op, things will fall apart because we cast pointers through void* or uintptr_t values, where no pointer adjustment will be done by the compiler. In any case I do not want to pursue the merging of GCObject and GCFinalizedObject for Serrano unless there's a particularly good reason to do so, I suspect there's a lot of room here for scope creep and bugs, and we're already very busy.
The ability to change a few instances of GCFinalizedObject::GCMember into GCObject::GCMember wasn't deemed valuable enough to pursue this. Another solution might be to eradicate GCRoots and make GCMember a global class only for use from gc objects. Or maybe GCObject and GCFinalizedObject could both inherit from a new base class that provides GCMember.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
bulk verifying resolved !fixed issues
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: