BacktrackingAllocator.cpp: reduce RANGE_SIZE_CUTOFF to 250000
Categories
(Core :: JavaScript Engine: JIT, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox129 | --- | fixed |
People
(Reporter: jseward, Assigned: jseward)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Bug 1728781 added a test in BacktrackingAllocator::tryMergeReusedRegister that
avoided some worst-case quadratic behaviour, at the (very minor) expense of
forcing a reg-reg copy in the middle of very large live ranges.
In bug 1897427 comment 9 we see a case where even that mechanism doesn't avoid
register allocation lasting for several seconds (possibly above 10). The
simplest fix seem to be to lower the threshold from 1 million to 500 thousand.
That avoids the big delay whilst not penalising large live ranges; a live
range of 500000 is still huge.
For the sake of safety it seems prudent to put the threshold a bit lower, so
as to ensure it kicks in on all architectures and won't need changing yet
again in future. I'm suggesting 250000.
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
Bug 1728781 added a test in BacktrackingAllocator::tryMergeReusedRegister that
avoided some worst-case quadratic behaviour, at the (very minor) expense of
forcing a reg-reg copy in the middle of very large live ranges.
In bug 1897427 comment 9 we see a case where even that mechanism doesn't avoid
register allocation lasting for several seconds (possibly above 10). The
simplest fix seem to be to lower the threshold from 1 million to 500 thousand.
That avoids the big delay whilst not penalising large live ranges; a live
range of 500000 is still huge.
For the sake of safety it seems prudent to put the threshold a bit lower, so
as to ensure it kicks in on all architectures and won't need changing yet
again in future. I'm suggesting 250000.
Comment 3•1 year ago
|
||
| bugherder | ||
Description
•