[webkit-changes] [WebKit/WebKit] 1135be: [JSC] Allow SpecEmpty only when GetClosureVar from...

[Yusuke Suzuki]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 1135bec30752857ee903c83143af853d88eba103
      https://github.com/WebKit/WebKit/commit/1135bec30752857ee903c83143af853d88eba103
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-06-30 (Fri, 30 Jun 2023)

  Changed paths:
    M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp

  Log Message:
  -----------
  [JSC] Allow SpecEmpty only when GetClosureVar from ResolvedClosureVar is used
https://bugs.webkit.org/show_bug.cgi?id=258714
rdar://111553671

Reviewed by Mark Lam.

ResolvedClosureVar is not used normally. It is very special internal ResolveType, mainly used for generators and private fields.
In these variables, it can happen that we use JSEmpty as a result of op_get_from_scope (which becomes a TDZ error in normal ClosureVar).
One example of this is op_iterator_open's m_next location, which can become JSEmpty. And if it is captured by a generator, then op_get_from_scope
should see JSEmpty. The problem is that ValueProfile never tells about JSEmpty since it sees no value is stored when JSEmpty is stored.
As a result, we emit ForceOSRExit in DFG since SpecNone is reported.
We workaround this very special internal use case by explicitly setting SpecEmpty when ValueProfile tells this is SpecNone for ResolvedClosureVar op_get_from_scope,
not to cause repeated OSR exit observed in JetStream2/Basic.

* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):

Canonical link: https://commits.webkit.org/265645@main