We previously emit JIT'ed code to set and unset the ScratchBuffer active length around calls into C++ runtime functions. This was needed because the runtime functions may allow GC to run, and GC needs to be able to scan the values stored in the ScratchBuffer. Instead of emitting JIT code to set and unset the active length, we can do it in the runtime function.
<rdar://problem/79325068>
Created attachment 431404 [details] proposed patch.
Comment on attachment 431404 [details] proposed patch. r=me. How do we get the scratch register buffer when writing to it in C++? If it’s not via the m_scratchBuffer member maybe we should have an assert that it’s set?
(In reply to Keith Miller from comment #4) > Comment on attachment 431404 [details] > proposed patch. > > r=me. Thanks. > How do we get the scratch register buffer when writing to it in C++? > If it’s not via the m_scratchBuffer member maybe we should have an assert > that it’s set? ``` inline ActiveScratchBufferScope::ActiveScratchBufferScope(VM& vm, size_t activeScratchBufferSizeInJSValues) : m_scratchBuffer(vm.scratchBufferForSize(activeScratchBufferSizeInJSValues * sizeof(EncodedJSValue))) { // Tell GC mark phase how much of the scratch buffer is active during the call operation this scope is used in. if (m_scratchBuffer) m_scratchBuffer->u.m_activeLength = activeScratchBufferSizeInJSValues * sizeof(EncodedJSValue); } ``` We call vm.scratchBufferForSize() with the exact same size that the JIT calls it with. Hence, we'll always get the same ScratchBuffer. As for accesses to the scratch buffer, if the C++ runtime used to write stuff to the ScratchBuffer, it does so the same way as before i.e. the JIT code would have passed in the buffer as a pointer. I'm not changing anything there.
Landed in r278875: <http://trac.webkit.org/r278875>.