Closed
Bug 517858
Opened 15 years ago
Closed 15 years ago
Mark stack overflow handling
Categories
(Tamarin Graveyard :: Garbage Collection (mmGC), defect)
Tamarin Graveyard
Garbage Collection (mmGC)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: lhansen, Assigned: lhansen)
Details
Attachments
(1 file, 2 obsolete files)
7.61 KB,
patch
|
rulohani
:
review+
|
Details | Diff | Splinter Review |
Mark stack overflow handling appears to have non-termination problems on a fast linux box in the presence of the patch for bug #495049.
Assignee | ||
Comment 1•15 years ago
|
||
The large object list was scanned once for each small-object size class, but that's wrong: it should be scanned just once.
Assignee | ||
Comment 2•15 years ago
|
||
A bit cleaner. Tested.
Attachment #401824 -
Attachment is obsolete: true
Attachment #401856 -
Flags: review?(rulohani)
Assignee | ||
Comment 3•15 years ago
|
||
(In reply to comment #2) > Created an attachment (id=401856) [details] > Patch, v2 > > A bit cleaner. Tested. pushed pending review: redux changeset: 2566:7ddd7b17ad76
Comment 4•15 years ago
|
||
Looks clean.
Assignee | ||
Updated•15 years ago
|
Attachment #401856 -
Flags: review?(rulohani) → review+
Assignee | ||
Updated•15 years ago
|
Attachment #401856 -
Attachment is obsolete: true
Assignee | ||
Comment 5•15 years ago
|
||
The mark stack has one method, PushSegment, that allocates memory. That method was set up so that it could fail to allocate memory, but in two cases the failure was not handled properly by the caller: during initialization of the stack, and during transfer of a segment from one stack to the other, where the yielding stack must sometimes allocate a new segment to establish invariants. This patch cleans that up: failure to allocate during setup is an OOM fault, and failure to allocate on transfer is recoverable and signals the error back to the caller, which makes use of it. As a consquence, there's some minor refactoring and cleanup elsewhere in the code: the code for forcing a sweep at shutdown (GC::ForceSweep) has been rewritten and factored out of the sweeper as well as out of GC::~GC, and as a result the sweeper can have invariants about the mark and barrier stacks being empty at all times. The rewrite simplifies the handling of the oom fault in the mark stacks, because that fault propagates into the GC code at fewer points.
Attachment #402052 -
Flags: review?(rulohani)
Assignee | ||
Comment 6•15 years ago
|
||
(In reply to comment #5) > Created an attachment (id=402052) [details] > Deal properly with OOM in the mark stack Pushed pending review: redux changeset: 2582:62b153e02d97
Updated•15 years ago
|
Attachment #402052 -
Flags: review?(rulohani) → review+
Assignee | ||
Updated•15 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 7•15 years ago
|
||
Resolved fixed engineering / work item that has been pushed. Setting status to verified.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•