Thanks for the report. I'm curious if you've observed this to happen? From a quick scan of the code, it does look like a real problem.
The risk is mitigated somewhat because there is a slop factor added to each of the paged spaces with variable-sized objects (and it isn't an issue for the ones with fixed size objects). Still, it seems like a bug we should fix. I've filed http://code.google.com/p/v8/issues/detail?id=407 to track it. If you do have a snapshot that exhibits the problem, a simple workaround might be to add more slop to the code, old_data, and old_pointer spaces, either in the snapshot at serialization time or else to the page lists at deserialization time. On Wed, Jul 22, 2009 at 8:10 PM, v8hope <[email protected]> wrote: > > I meant the length of page_list could be smaller than size actually > needed. > > > > > deserializer is using the original heap page size in header to create > > the page_list. The length of page_list could be smaller than the > > original heap space. Later it causes following assertion fail in > > ResolvePaged(): > > ASSERT(page_index < page_list->length()); > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
