Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v8: backport 45e2628d and d6fb6de7 from upstream #6384

Closed
wants to merge 2 commits into from

Conversation

laverdet
Copy link
Contributor

Checklist
  • tests and code linting passes (ia32 + x64)
  • the commit message follows commit guidelines
Affected core subsystem(s)

v8

Description of change

Backports two commits from v8 upstream, 45e2628d + d6fb6de7. The first commit is not strictly required to fix the issue, but large changes were made to the switch block parser and a clean merge is very desirable in cases like these.

This fixes an issue with scoping in switch blocks which will cause a full server crash. An example of code which can trigger this bug follows:

"use strict";
switch (1) {
    case 2:
        let foo;
}
foo.bar;

This affects both the v4.x and v5.x branches. master is unaffected since its v8 version already includes those changes. I'm not 100% sure I'm PR'ing to the right branch, so I held off on doing v4.x. If y'all give me the go ahead I can get a PR out for v4.x as well.

Original commit message:

    Add a separate scope for switch

    The ES2015 specification for switch statements 13.12.11 specifies that
    they get their own lexical scope. This patch introduces such a scope
    through a complex desugaring in terms of blocks, done so that Crankshaft
    does not have to be updated to support multiple constructs providing
    scopes.

    Recommitting this patch after a bug fix in Crankshaft to allow a
    desugaring with certain elements missing a source location:
    https://codereview.chromium.org/1313443002

    BUG=v8:4377
    LOG=Y
    R=adamk

    Review URL: https://codereview.chromium.org/1309163003

    Cr-Commit-Position: refs/heads/master@{nodejs#30340}
Original commit message:

    Ensure hole checks take place in switch statement scopes

    Switch statements introduce their own scope for cases, but this scope
    is not necessarily executed in order, as the following function shows:

      switch (x) {
        case 1:
          let y = 1;
        case 2:
          y = 2;
        case 3:
          print(y);
      }

    If x = 2 or x = 3, the code should throw a ReferenceError. However,
    FullCodeGen's hole check elimination used the simple algorithm of
    assuming that if the initializer was in the same scope, then it was
    reached before the use, and therefore the hole check could be
    eliminated.

    This patch adds an extra bit to scopes, to track if they may
    nonlinearly. The parser marks the scope that switch introduces as
    nonlinear. FullCodeGen does not eliminate the hole check from
    a scope which is nonlinear. This patch refactors FullCodeGen to
    put the hole check elimination in one place, rather than in each
    backend.

    BUG=v8:3926
    LOG=Y
    R=adamk

    Review URL: https://codereview.chromium.org/1312613003

    Cr-Commit-Position: refs/heads/master@{nodejs#30453}
@mscdex mscdex added v8 engine Issues and PRs related to the V8 dependency. v5.x labels Apr 26, 2016
@jasnell jasnell changed the title V5.x v8: backport 45e2628d and d6fb6de7 from upstream Apr 26, 2016
@jasnell
Copy link
Member

jasnell commented Apr 26, 2016

took the liberty to update the PR title to be more descriptive of the changed proposed.

@bnoordhuis
Copy link
Member

@nodejs/release Are we still doing v5 releases now that v6 is out? If not, there is not much point in reviewing and/or landing this.

@jasnell
Copy link
Member

jasnell commented May 2, 2016

It's possible, yes. We've been saying that v5 will be supported for up to two months after v6, largely to give people time to transition just in case any significant regressions or security issues come up. Really, tho, it's going to depend on whether anyone steps up to backport stuff and drive the release.

@laverdet
Copy link
Contributor Author

laverdet commented May 2, 2016

If you guys aren't cutting anymore v5 updates it's moot. I wasn't aware how close we were to v6, though this affects v4 as well. Like I mentioned in the comment above I can port this to v4 since I'm already familiar with this code and the test cases. Let me know if you want me to move forward on that front.

@bnoordhuis
Copy link
Member

Backporting to v4 sounds like a good idea.

@mhdawson How much work is it to extend the test matrix for V8's test suite beyond x64?

@mhdawson
Copy link
Member

mhdawson commented May 2, 2016

As covered in nodejs/build#387 it depends on what we want to extend it to. For some platforms the issue having the right hardware available. From the discussion it sounds like you'd want ia32. @jbergstroem is there a machine with 8G memory that is ia32 ?

@jbergstroem
Copy link
Member

@mhdawson nope; it most often doesn't make sense to run 32-bit installs with more than 4G ram but I reckon kernels with PAE would handle it. Should I look at setting this up? Are google testing this?

@bnoordhuis
Copy link
Member

From the discussion it sounds like you'd want ia32.

And ARM + optionally PPC.

@mhdawson
Copy link
Member

mhdawson commented May 9, 2016

PPC is already running, ARM I tried but the hardware was just not reliable/capable enough

@mhdawson
Copy link
Member

mhdawson commented May 9, 2016

Google does test 32 bit - https://build.chromium.org/p/client.v8/console. I believe the builds under "linux" would be 32 bit. I doubt that they test on 32 bit with more than 4G though, so its possible that for 32 bit the tests run differently so if you point me at one that has 4G I'll add it and see what happens.

@MylesBorins
Copy link
Contributor

As v5.x is now eol I am going to close this. Please feel free to let me know if this was inappropriate

@MylesBorins MylesBorins closed this Jul 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v8 engine Issues and PRs related to the V8 dependency.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants