Summary: | [JSC] indirect eval GC/memory leak | ||
---|---|---|---|
Product: | WebKit | Reporter: | Phillip Mates <pmates> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | fpizlo, joseph.j.griego, saam, webkit-bug-importer, ysuzuki |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Phillip Mates
2021-11-16 11:42:01 PST
(poked around a bit and confirmed that adding `--useCodeCache=false` prevents the crash as long as `jitMemoryReservationSize` is large enough to hold at least one instance of the eval'd code, still reading code though) I change `prune` in runtime/CodeCache.h to just be `m_map.clear()` and it stops crashing. Given this, I believe that the pruning/flushing to disk logic that clears the code cache map, and thus allows for releasing otherwise gc'able executable objects, isn't sensitive to GC/memory needs. Not sure what the best way forward would be. Some random ideas: - use some sort of weak hashmap that allowed for gc'ing objects even if they appear in the code cache map. - couple code cache map with the executable allocator and allow the allocator to clear the map. - tweak the code cache heuristics, such as the workingSetMaxBytes parameter |