New issue
Advanced search Search tips

Issue 645095 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Deserializer deserializes a filler

Project Member Reported by mlippautz@chromium.org, Sep 8 2016

Issue description

Description:
- 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.

 
Cc: yangguo@chromium.org
Owner: yangguo@chromium.org
This doesnt soubd like an urgent issue. I will try to find out where that filler comes from. In about three weeks :)
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.
Cc: cbruni@chromium.org
Yang: Only on initial deserialize. (Yes, I realize that this was more than a year ago ;))

Camillo: The bug that could be related.

Comment 5 by cbruni@chromium.org, Nov 17 2017

As it turns out I was doing other unrelated silly things.
So... close this issue?
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?
I couldn't think of a way we would overallocate. We should investigate this sometime.

Sign in to add a comment