If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

ZCT reaping times are not bounded

NEW
Unassigned

Status

Tamarin
Garbage Collection (mmGC)
P3
normal
8 years ago
7 years ago

People

(Reporter: Lars T Hansen, Unassigned)

Tracking

(Blocks: 3 bugs)

unspecified
Q1 12 - Brannan
ARM
Windows Mobile 6 Professional
Dependency tree / graph

Details

(Reporter)

Description

8 years ago
On slow platforms like WinMo the ZCT reaping can actually take more time than a mark increment or the finalization phase of GC, even with moderate heap sizes.  It's possible that the ZCT reap times need to be bounded somehow, like incremental mark pauses are.
(Reporter)

Updated

8 years ago
Blocks: 501916
(Reporter)

Comment 1

8 years ago
With the changes pending in bug #506012 this might now be possible.  It would go like the following.

The reaper would operate like IncrementalMark. It would be given a time slice and it would check the performance counter every k pointers.  If the time slice expires, the pinned objects would be copied from the pinning memory onto the ZCT (there are usually very few of these), any pinned objects in the untouched part of the ZCT would be unpinned, and reaping would terminate normally.  If invoked from the GC the reap budget would be subtracted from the budget of the caller.

If there is a correspondence between how long an element has been in the ZCT and how likely it is that it will be pinned then eg oldest-first reaping might make sense, but there's no particular reason to believe that there is such a correspondence so we'd want evidence for it first.
(Reporter)

Updated

8 years ago
Target Milestone: --- → Future
(Reporter)

Updated

8 years ago
Assignee: lhansen → nobody
Status: ASSIGNED → NEW
(Reporter)

Updated

8 years ago
Priority: -- → P3
Target Milestone: Future → flash10.2

Updated

8 years ago
Whiteboard: PACMAN
(Reporter)

Updated

8 years ago
Whiteboard: PACMAN
(Reporter)

Comment 2

7 years ago
Deferring since RC is likely to go away post-Serrano and the gains for Serrano would be small.
Priority: P3 → --
Target Milestone: flash10.x - Serrano → Future
(Reporter)

Updated

7 years ago
Blocks: 604350
(Reporter)

Updated

7 years ago
Priority: -- → P3
Target Milestone: Future → Q1 12 - Brannan
You need to log in before you can comment on or make changes to this bug.