rdar://81526335
Created attachment 436463 [details] proposed patch. Let's try this on the EWS.
Created attachment 436465 [details] proposed patch.
Created attachment 436474 [details] proposed patch.
Created attachment 436985 [details] proposed patch.
Comment on attachment 436985 [details] proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=436985&action=review r=me > Source/JavaScriptCore/jit/ExecutableAllocator.cpp:404 > g_jscConfig.startExecutableMemory = tagCodePtr<ExecutableMemoryPtrTag>(reservation.base); > g_jscConfig.endExecutableMemory = tagCodePtr<ExecutableMemoryPtrTag>(reservationEnd); why not remove these, and switch everyone to using some nice standalone functions that return g_config[0] and g_config[1]? > Source/bmalloc/bmalloc/GigacageConfig.h:107 > +constexpr size_t startSlotOfGigacageConfig = 2; maybe it's worth commenting somewhere that the first 2 slots are for the executable bounds?
(In reply to Saam Barati from comment #5) > Comment on attachment 436985 [details] > proposed patch. > > View in context: > https://bugs.webkit.org/attachment.cgi?id=436985&action=review > > r=me > > > Source/JavaScriptCore/jit/ExecutableAllocator.cpp:404 > > g_jscConfig.startExecutableMemory = tagCodePtr<ExecutableMemoryPtrTag>(reservation.base); > > g_jscConfig.endExecutableMemory = tagCodePtr<ExecutableMemoryPtrTag>(reservationEnd); > > why not remove these, and switch everyone to using some nice standalone > functions that return g_config[0] and g_config[1]? I'll try to do this in a separate follow up patch (since this one is already so big). > > Source/bmalloc/bmalloc/GigacageConfig.h:107 > > +constexpr size_t startSlotOfGigacageConfig = 2; > > maybe it's worth commenting somewhere that the first 2 slots are for the > executable bounds? I'll add a comment saying that the first 2 slots are reserve for the use of the ExecutableAllocator.
Thanks for the review. Landed in r281910: <http://trac.webkit.org/r281910>.