Closed
Bug 1044993
Opened 10 years ago
Closed 10 years ago
Use mark bits to deduplicate the whole cell edges store buffer
Categories
(Core :: JavaScript: GC, defect)
Core
JavaScript: GC
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jonco, Assigned: jonco)
Details
Attachments
(1 file)
7.39 KB,
patch
|
Details | Diff | Splinter Review |
The point of this is to get around having to allocate a hash table while compacting this store buffer, which occurs on minor GC and also when it becomes full. This doesn't improve our scores on any benchmarks but it hopefully reduces the possibility for pathological behaviour if compiled code is creating lots of these entries.
I'm in two minds of whether to land this -- Terrence, what do you think?
Attachment #8463318 -
Flags: feedback?(terrence)
Comment 1•10 years ago
|
||
Sorry for the delay, but I've been giving this a bunch of thought.
I think my conclusion is that all these fiddly optimizations are lipstick on a pig -- we should be addressing the flaws in the architecture instead. The StoreBuffer is the one really slow piece of GGC: every time someone comes to us with a massive slowdown with GGC enabled it has been some dumb thing with barriers.
Currently, even if we hyper-optimize the buffer and use segv overflow detection, we still have read(pbuffer), write(ptr), update(pbuffer), write(pbuffer): 3x sizeof(word) memory traffic. Any strategy we pick will have to do better than that. Processors are more or less faster enough than memory -- even on phones now -- that doing more arithmetic is probably fine.
So let's brainstorm a bit:
Card Marking: if I'm understanding correctly, the purpose of card marking is to reduce the memory overhead of barriers by using a bitmap. Naively a bitmap is going to make the overhead into read(bitmap), write(bitmap): 2x sizeof(word) instead of 3x, so better. Moreover, our cards would be on multiple objects, rather than on multiple slots (as generally assumed), so it's not clear that the overhead of marking through random objects wouldn't swamp the gains anyway. I don't think this can work with our current heap structure.
However, we can use the basic idea: if we want to avoid the read(pbuffer), write(pbuffer), we need to use a bitmap and not a buffer. Secondly, if we want to avoid read(bitmap), we have to use a bytemap. With a bytemap, we could blat a "we wrote to it" flag directly to the right byte. This is generally way too expensive, *but*....
Observation: on 32bit systems, a 24bit chunk means we only have 256 possible chunks: e.g. a byte map of chunks would only be 256bytes. On 64bit we have 47bit addressing, so things are a bit less optimistic, but it would be easy enough to do something different but equivalent there. This would allow us to mark a specific chunk with a single byte write and scan it quickly at GGC time. That leaves selection of individual objects in the chunk. That we could do with the strategy used here of marking the individual object directly in the mark bitmap. This would still require us to read(bitmap), write(bitmap), but unlike card marking, it is equivalent to the whole-object buffer -- e.g. it would actually work with our heap structure at the cost of a single extra 1-byte write to a 4-cacheline structure.
64bit strategy: with 47bit addresses, there are suddenly far fewer chunks than possible chunk addresses, so we have to use a different strategy. My idea here is to write a byte to a well known offset in the chunk trailer to "mark" the chunk, then walk the list of chunks at GGC time to find the marked ones. Actually, this would probably work just as well on 32bit since the chunk list is guaranteed to be short.
Thoughts?
Comment 2•10 years ago
|
||
Comment on attachment 8463318 [details] [diff] [review]
use-mark-bits-for-compaction
Review of attachment 8463318 [details] [diff] [review]:
-----------------------------------------------------------------
I guess this probably isn't worth the complexity if it's not a perf win.
Attachment #8463318 -
Flags: feedback?(terrence)
Assignee | ||
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•