Bug 193546

Summary: [JSC] Reduce size of memory used for ShadowChicken
Product: WebKit Reporter: Yusuke Suzuki <ysuzuki>
Component: JavaScriptCoreAssignee: Yusuke Suzuki <ysuzuki>
Status: RESOLVED FIXED    
Severity: Normal CC: ews-watchlist, keith_miller, mark.lam, msaboff, saam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 193606    
Attachments:
Description Flags
Patch
none
WIP none

Yusuke Suzuki
Reported 2019-01-17 11:55:17 PST
ShadowChicken's packet is large. It is 56 bytes. And we allocate 1000 packet storage for ShadowChicken. So ShadowChicken consumes 55K memory while VM is in action.
Attachments
Patch (16.63 KB, patch)
2019-01-28 19:35 PST, Yusuke Suzuki
no flags
WIP (82.21 KB, patch)
2019-02-08 00:29 PST, Yusuke Suzuki
no flags
Yusuke Suzuki
Comment 1 2019-01-19 01:27:28 PST
1. Lazily allocate shadow chicken buffer 2. Reduce the size of packet anyway to reduce the buffer size even if it is allocated.
Yusuke Suzuki
Comment 2 2019-01-28 19:35:12 PST
Mark Lam
Comment 3 2019-01-28 20:18:11 PST
Comment on attachment 360424 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=360424&action=review r=me with suggestions. > Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:13472 > + RELEASE_ASSERT(vm().shadowChicken()); nit: I know this is not a perf critical function, but can we pre-compute and cache vm().shadowChicken() in a local variable above and use the local shadowChicken variable in the 3 places in this function. This more clearly communicates to the compiler that we're expecting the same shadowChicken value. It also matches the idiom in the rest of this patch of fetching shadowChicken first (for the null check cases). > Source/JavaScriptCore/jit/CCallHelpers.cpp:57 > + RELEASE_ASSERT(vm.shadowChicken()); Ditto, precache shadowChicken? > Source/JavaScriptCore/jit/JITOperations.cpp:2885 > + RELEASE_ASSERT(vm.shadowChicken()); Ditto. Precache shadowChicken? > Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1894 > + RELEASE_ASSERT(vm.shadowChicken()); Ditto. Precache shadowChicken? > Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1913 > + RELEASE_ASSERT(vm.shadowChicken()); Ditto. Precache shadowChicken? > Source/JavaScriptCore/tools/JSDollarVM.cpp:2065 > + vm->ensureShadowChicken(); Not that it matters that much because $vm is a debugging tool, but to be completely correct, I think this should be conditional on if (newDebuggerMode == DebuggerOn). In fact, we can even releaseShadowChicken if newDebuggerMode == DebuggerOff (though we've never done that before).
Yusuke Suzuki
Comment 4 2019-01-28 20:29:05 PST
Comment on attachment 360424 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=360424&action=review Thanks! >> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:13472 >> + RELEASE_ASSERT(vm().shadowChicken()); > > nit: I know this is not a perf critical function, but can we pre-compute and cache vm().shadowChicken() in a local variable above and use the local shadowChicken variable in the 3 places in this function. This more clearly communicates to the compiler that we're expecting the same shadowChicken value. It also matches the idiom in the rest of this patch of fetching shadowChicken first (for the null check cases). Make sense. Fixed. >> Source/JavaScriptCore/jit/CCallHelpers.cpp:57 >> + RELEASE_ASSERT(vm.shadowChicken()); > > Ditto, precache shadowChicken? Fixed. >> Source/JavaScriptCore/jit/JITOperations.cpp:2885 >> + RELEASE_ASSERT(vm.shadowChicken()); > > Ditto. Precache shadowChicken? Fixed. >> Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1894 >> + RELEASE_ASSERT(vm.shadowChicken()); > > Ditto. Precache shadowChicken? Fixed. >> Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1913 >> + RELEASE_ASSERT(vm.shadowChicken()); > > Ditto. Precache shadowChicken? Fixed. >> Source/JavaScriptCore/tools/JSDollarVM.cpp:2065 >> + vm->ensureShadowChicken(); > > Not that it matters that much because $vm is a debugging tool, but to be completely correct, I think this should be conditional on if (newDebuggerMode == DebuggerOn). In fact, we can even releaseShadowChicken if newDebuggerMode == DebuggerOff (though we've never done that before). Nice, yeah. Fixed.
Yusuke Suzuki
Comment 5 2019-01-28 20:33:39 PST
Radar WebKit Bug Importer
Comment 6 2019-01-28 20:34:29 PST
Saam Barati
Comment 7 2019-01-31 00:00:33 PST
Comment on attachment 360424 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=360424&action=review > Source/JavaScriptCore/jit/JITExceptions.cpp:56 > + if (auto* shadowChicken = vm->shadowChicken()) Do we ever call setDebugger with JS frames on the stack?
Yusuke Suzuki
Comment 8 2019-01-31 01:53:26 PST
Comment on attachment 360424 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=360424&action=review >> Source/JavaScriptCore/jit/JITExceptions.cpp:56 >> + if (auto* shadowChicken = vm->shadowChicken()) > > Do we ever call setDebugger with JS frames on the stack? I don't think so, but either is fine anyway since if there is no shadowChicken, tail-call log is not recorded.
Yusuke Suzuki
Comment 9 2019-02-08 00:29:01 PST
Reopening to attach new patch.
Yusuke Suzuki
Comment 10 2019-02-08 00:29:02 PST
Saam Barati
Comment 11 2019-02-08 01:18:42 PST
(In reply to Yusuke Suzuki from comment #10) > Created attachment 361495 [details] > WIP What does this have to do with ShadowChicken?
Yusuke Suzuki
Comment 12 2019-02-08 01:26:19 PST
(In reply to Saam Barati from comment #11) > (In reply to Yusuke Suzuki from comment #10) > > Created attachment 361495 [details] > > WIP > > What does this have to do with ShadowChicken? Oooooooops, I uploaded the patch to the wrong issue. The correct issue is https://bugs.webkit.org/show_bug.cgi?id=194375. Thank you for letting me know!
Saam Barati
Comment 13 2019-02-08 10:48:15 PST
*** Bug 194431 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.