8332106: VerifyError when using switch pattern in this(...) or super(...)

[lahodaj]

Considering code like:

public class Test {

    public Test(int i) {
    }

    public Test(Object o) {
        this(o instanceof R(String s) ? s.length() : -1);
    }

    public static void main(String... args) {}

    record R(String s) {}
}

Running this crashes:

$ java .../Test.java
Exception in thread "main" java.lang.VerifyError: Stack map does not match the one at exception handler 36
Exception Details:
  Location:
    Test.<init>(Ljava/lang/Object;)V @36: astore_2
  Reason:
    Type uninitializedThis (current frame, locals[0]) is not assignable to 'Test' (stack map, locals[0])
  Current Frame:
    bci: @14
    flags: { flagThisUninit }
    locals: { uninitializedThis, 'java/lang/Object', top, 'Test$R' }
    stack: { 'java/lang/Throwable' }
  Stackmap Frame:
    bci: @36
    flags: { }
    locals: { 'Test', 'java/lang/Object' }
    stack: { 'java/lang/Throwable' }
  Bytecode:
    0000000: 2a2b c100 0799 0018 2bc0 0007 4e2d b600
    0000010: 093a 0419 044d 2cb6 000d a700 0402 b700
    0000020: 13a7 0011 4dbb 001a 592c b600 1c2c b700
    0000030: 1fbf b1                                
  Exception Handler Table:
    bci [14, 17] => handler: 36
  Stackmap Table:
    same_locals_1_stack_item_frame(@29,UninitializedThis)
    full_frame(@30,{UninitializedThis,Object[#2]},{UninitializedThis,Integer})
    full_frame(@36,{Object[#20],Object[#2]},{Object[#24]})
    same_frame(@50)

        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:534)
        at java.base/java.lang.Class.forName(Class.java:513)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:432)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:208)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:135)

The reason is that there is a synthetic catch generated wrapping the record accessors inside the pattern matching. The range where the exception this catch is catching is before the real this(...) invokespecial, and hence the this is still an "uninitialized this". But the code for the catch is generated at the end of the constructor, when this is already initialized, and javac generates the stack maps as if this was initialized.

In general, the pattern matching code can be both before and after the this has been initialized. But, I don't think a stack map frame can be generated for the handler originating in places with both "uninitialized this " and (initialized) this.

The proposal here is to generate one set of the catch handlers for the state with "uninitialized this", and another for (initialized) this, if needed.

---

Progress

• [x] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8332106: VerifyError when using switch pattern in this(...) or super(...) (Bug - P2)

Reviewers

• Aggelos Biboudis (@biboudis - Committer)
• Vicente Romero (@vicente-romero-oracle - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19217/head:pull/19217
$ git checkout pull/19217

Update a local copy of the PR:
$ git checkout pull/19217
$ git pull https://git.openjdk.org/jdk.git pull/19217/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19217

View PR using the GUI difftool:
$ git pr show -t 19217

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19217.diff

Webrev

Link to Webrev Comment

[bridgekeeper[bot]]

:wave: Welcome back jlahoda! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk[bot]]

@lahodaj This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8332106: VerifyError when using switch pattern in this(...) or super(...)

Reviewed-by: abimpoudis, vromero

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 114 new commits pushed to the master branch:

• c2180d141ccca0e396ee9a0cd3044c4428b963d5: 8315767: InetAddress: constructing objects from BSD literal addresses
• 2a11e0da026066191e4d4f30b9daca986c484630: 8332743: Update comment related to JDK-8320522
• 6829d9ac67fb131462d3ef1c4bdfaa07df5d6be6: 8332122: [nmt] Totals for malloc should show total peak
• 9d332e6591334a71335da65a4dd7b2ed0482b6cb: 8307193: Several Swing jtreg tests use class.forName on L&F classes
• 98f6a80852383dcbdad7292b7d269a8547d54d45: 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM
• 3d4185a9ce482cc655a4c67f39cb2682b02ae4fe: 8332739: Problemlist compiler/codecache/CheckLargePages until JDK-8332654 is fixed
• c4557a7b0db5b55585b4caa7cdec81e1c1093cbc: 8332463: Byte conditional pattern case element dominates short constant case element
• d59c12fe1041a1f61f68408241a9aa4d96ac4fd2: 8329718: Incorrect @since tags in elements in jdk.compiler and java.compiler
• b4d14540851d792b5366a3723abcea1264a5737c: 8332740: [BACKOUT] JDK-8331081 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version
• 37c477856d543163b60dd2b85a5e6ac35a752211: 8332096: hotspot-ide-project fails with this-escape
• ... and 104 more: https://git.openjdk.org/jdk/compare/1484153c1a092cefc20270b35aa1e508280843a4...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk[bot]]

@lahodaj The following label will be automatically applied to this pull request:

• compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge[bot]]

Webrevs

• 02: Full - Incremental (c10940dd)
• 01: Full - Incremental (9dacde8b)
• 00: Full (3015dfd2)

[lahodaj]

/integrate

[openjdk[bot]]

Going to push as commit af056c1676dab3b0b35666a8259db60f9bbf824e. Since your change was applied there have been 133 commits pushed to the master branch:

• da3001daf79bf943d6194d9fd60250d519b9680d: 8331975: Enable case-insensitive check in ccache and keytab entry lookup
• 424eb60dedb332237b8ec97e9da6bd95442c0083: 8331683: Clean up GetCarrierThread
• 9b1d6d66b8297d53c6b96b9e2f9bd69af90ab8fb: 8316328: Test jdk/jfr/event/oldobject/TestSanityDefault.java times out for some heap sizes
• f8a3e4e428f7d3e62177bdf148fe25e22d3ee2bf: 8328998: Encoding support for Intel APX extended general-purpose registers
• ddd73b458355bffeaa8e0e5017c27d6c6af2dc94: 8332082: Shenandoah: Use consistent tests to determine when pre-write barrier is active
• 0a9d1f8c89e946d99f01549515f6044e53992168: 8332749: Broken link in MemorySegment.Scope.html
• c9a7b9772d96d9a4825d9da2aacc277534282860: 8332829: [BACKOUT] C2: crash in compiled code because of dependency on removed range check CastIIs
• 7fd9d6c760c66d3e2f4034cf1a6b1b583ff829a9: 8332340: Add JavacBench as a test case for CDS
• 417d174aa1b7bd3b5755e5f2352d9bbe6ce6f183: 8331348: Some incremental builds deposit files in the make directory
• 303ac9f270f567d821d156f3a9d4f4c070f43f95: 8332671: Logging for pretouching thread stacks shows wrong memory range
• ... and 123 more: https://git.openjdk.org/jdk/compare/1484153c1a092cefc20270b35aa1e508280843a4...master

Your commit was automatically rebased without conflicts.

[openjdk[bot]]

@lahodaj Pushed as commit af056c1676dab3b0b35666a8259db60f9bbf824e.

:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.