Bug 242579 – VM should embed Interpreter.

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Lam]

1. The Interpreter class is empty for release non-cloop builds.
2. There is always a 1:1 pairing between VM and Interpreter.

So, there's no point in malloc'ing the Interpreter separately.

[Mark Lam]

Pull request: https://github.com/WebKit/WebKit/pull/2281

[EWS]

Committed 252338@main (16e1928aae2e): <https://commits.webkit.org/252338@main>

Reviewed commits have been landed. Closing PR #2281 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/96817609>

[Michael Catanzaro]

fyi, this broke the cloop build. It's a shame we don't have an EWS for it. Follow-up incoming.

[Mark Lam]

(In reply to Michael Catanzaro from comment #4)
> fyi, this broke the cloop build. It's a shame we don't have an EWS for it.
> Follow-up incoming.

How did this break the CLoop?  I deliberately tested for it.  The jsc-i386 bot builds CLoop AFAIK.  When I checked (before landing), all was well.

Please share your details about what actually broke.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #4)
> Follow-up incoming.

This will probably be tomorrow. It should just be:

diff --git a/Source/JavaScriptCore/CMakeLists.txt b/Source/JavaScriptCore/CMakeLists.txt
index aef0678e66f3..ee5d8a509284 100644
--- a/Source/JavaScriptCore/CMakeLists.txt
+++ b/Source/JavaScriptCore/CMakeLists.txt
@@ -840,6 +840,7 @@ set(JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS
     interpreter/CallFrame.h
     interpreter/CallFrameInlines.h
     interpreter/CalleeBits.h
+    interpreter/CLoopStack.h
     interpreter/EntryFrame.h
     interpreter/FrameTracers.h
     interpreter/Interpreter.h

but I need to confirm, and am testing something else right now.

[Michael Catanzaro]

(In reply to Mark Lam from comment #5)
> Please share your details about what actually broke.

In file included from /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/PrivateHeaders/JavaScriptCore/VM.h:41,
                 from /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/PrivateHeaders/JavaScriptCore/ExceptionScope.h:28,
                 from /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/PrivateHeaders/JavaScriptCore/CatchScope.h:28,
                 from /home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/PrivateHeaders/JavaScriptCore/JSCJSValueInlines.h:28,
                 from /home/mcatanzaro/Projects/WebKit/Tools/TestWebKitAPI/Tests/JavaScriptCore/PropertySlot.cpp:28:
/home/mcatanzaro/Projects/WebKit/WebKitBuild/JSCOnly/JavaScriptCore/PrivateHeaders/JavaScriptCore/Interpreter.h:39:10: fatal error: CLoopStack.h: No such file or directory
   39 | #include "CLoopStack.h"
      |          ^~~~~~~~~~~~~~
compilation terminated.

[Michael Catanzaro]

(In reply to Mark Lam from comment #5)
> How did this break the CLoop?  I deliberately tested for it.  The jsc-i386
> bot builds CLoop AFAIK.  When I checked (before landing), all was well.

Maybe it doesn't build TestWebKitAPI?

[Mark Lam]

(In reply to Michael Catanzaro from comment #8)
> (In reply to Mark Lam from comment #5)
> > How did this break the CLoop?  I deliberately tested for it.  The jsc-i386
> > bot builds CLoop AFAIK.  When I checked (before landing), all was well.
> 
> Maybe it doesn't build TestWebKitAPI?

Yeah, it's a jsc build bot.  Locally, I also only tested building jsc.  Is this build failure manifesting when building TestWebKitAPI?

[Michael Catanzaro]

Yes, the problem is the header is not available to TestWebKitAPI.

My patch works... I'll submit a PR.

[Michael Catanzaro]

Re-opening for pull request https://github.com/WebKit/WebKit/pull/2349

[EWS]

Committed 252400@main (40e49bb53218): <https://commits.webkit.org/252400@main>

Reviewed commits have been landed. Closing PR #2349 and removing active labels.