Deserializer deserializes a filler |
|||
Issue descriptionDescription: - After deserialization we notify the GC to trim the pages of the snapshot, i.e. to get rid of unused memory. - We do that using the high water mark on a page - In debug mode we even do a bit more: We check that when we iterate the page, after the last object there is a filler that corresponds to the high water mark. The problem is that the deserializer sometimes (test case) creates a filler that it doesn't use. If this happens to be the last filler, then the GC thinks the high water mark is off. Repro: Commit: 4ed27fc836acfc3218a5e4ce6d878a513e9df788 PS: http://crrev.com/2307903002#ps120002 gn args: is_component_build = false is_debug = false use_goma = true target_cpu = "x86" dcheck_always_on = true symbol_level = 1 out/Release/cctest --random-seed=-564235616 --ignition-staging --turbo test-serialize/SnapshotCreatorMultipleContexts --nohard-abort --nodead-code-elimination --nofold-constants It might very well be that the deserializer is allowed to leave fillers behind, in that case please just close the bug.
,
Sep 10 2016
This doesnt soubd like an urgent issue. I will try to find out where that filler comes from. In about three weeks :)
,
Sep 10 2016
btw. does the trimming of page happen on every deserialize, or only for the initial deserialize of the heap? The test case indicates that the context snapshot is involved.
,
Nov 8 2017
Yang: Only on initial deserialize. (Yes, I realize that this was more than a year ago ;)) Camillo: The bug that could be related.
,
Nov 17 2017
As it turns out I was doing other unrelated silly things.
,
Nov 17 2017
So... close this issue?
,
Nov 19 2017
I don't think this is actually fixed :) It's just not high priority and nobody looked into why we sometimes seem to end up with fillers after deserialization. Maybe it's just because we overallocate?
,
Nov 19 2017
I couldn't think of a way we would overallocate. We should investigate this sometime. |
|||
►
Sign in to add a comment |
|||
Comment 1 by mlippautz@chromium.org
, Sep 8 2016