8320220: Compilation of cyclic hierarchy causes infinite recursion #23704

archiecobbs · 2025-02-19T18:15:51Z

This input currently causes an infinite loop:

interface A extends B, C {}
interface B extends A {}
interface C extends A {}

However, less complicated cycles are handled properly.

When a cycle is found, we currently:
(a) Emit a warning; and
(b) Set the symbol's type to the error type.

These two steps are done in Check.noteCyclic().

Step (b) is what normally prevents the infinite loop from happening later in the compilation. But we only do this for the first class in the loop, presumably because it would be too verbose to do (a) for every class in the loop. But that means we're also only doing (b) for the first class in the loop.

In more complicated scenarios like the bug example, that means some classes in the cycle can escape without (b) being applied. But this is incorrect (or, at least, weirdly indeterminate) because a loop is a loop no matter which class you start with.

So the solution is to continue to do (a) only to the first class in the cycle but do (b) for every class in the cycle.

Progress

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

Issue

JDK-8320220: Compilation of cyclic hierarchy causes infinite recursion (Bug - P3)

Reviewers

Vicente Romero (@vicente-romero-oracle - Reviewer)
Jan Lahoda (@lahodaj - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23704

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-02-19T18:16:27Z

👋 Welcome back acobbs! 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 · 2025-02-19T18:17:02Z

@archiecobbs 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:

8320220: Compilation of cyclic hierarchy causes infinite recursion

Reviewed-by: vromero, jlahoda

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 116 new commits pushed to the master branch:

65f79c1: 8347335: ZGC: Use limitless mark stack memory
e410af0: 8342393: Promote commutative vector IR node sharing
f755fad: 8349653: Clarify the docs for MemorySegment::reinterpret
a5c9a4d: 8349032: C2: Parse Predicate refactoring in Loop Unswitching broke fix for JDK-8290850
302bed0: 8350499: Minimal build fails with slowdebug builds
0795d11: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range
05b4812: 8350041: Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static JDK
a891630: 8350480: RISC-V: Relax assertion about registers in C2_MacroAssembler::minmax_fp
5cbd9d1: 8349959: Test CR6740048.java passes unexpectedly missing CR6740048.xsd
25322aa: 8350258: AArch64: Client build fails after JDK-8347917
... and 106 more: https://git.openjdk.org/jdk/compare/ba28119642a7cfa850707a01ce8e589c3a80d416...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 · 2025-02-19T18:17:41Z

@archiecobbs 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 · 2025-02-20T23:50:03Z

Webrevs

00: Full (1ec2d1f2)

vicente-romero-oracle · 2025-02-24T15:21:24Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java

+                log.error(pos, Errors.CyclicInheritance(c));
+                seenClasses.stream()
+                  .filter(s -> !s.type.isErroneous())
+                  .filter(ClassSymbol.class::isInstance)


wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass?

wouldn't a ClassSymbol method be better here like ClassSymbol::isSubClass?
...
this method will invoke Class::isInstance again, probably better to just do (c -> (ClassSymbol)c)?

My goal was to replicate the existing logic, but do it for every class in seenClasses instead of just the current one. But I was not able to prove to myself that every symbol in seenClasses is in fact a ClassSymbol, although that may actually be true in practice. So that's why the code is being careful not to blind casting everything in seenClasses to ClassSymbol.

If you're confident that every symbol in seenClasses is always a ClassSymbol then we can simplify this... but if so, why wasn't seenClasses declared as a Set<ClassSymbol> instead of a Set<Symbol> in the first place? I'm wondering there is some weird (probably invalid) input that could cause that assumption to be violated.

Thanks for taking a look.

Following up on previous comment...

I'm wondering there is some weird (probably invalid) input that could cause that assumption to be violated.

In fact, if we just blindly cast then there are 3 regression test failures. In particular, this input crashes the compiler:

public class Cyclic { static class Outer { class Inner {} } static class Test<X extends Outer> { class InnerTest extends X.Inner { InnerTest(Outer o) {o.super();} } } }

with this error:

Finished building target 'interim-langtools' in configuration 'macosx-aarch64-server-release' An exception has occurred in the compiler (25-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. java.lang.ClassCastException: class com.sun.tools.javac.code.Symbol$TypeVariableSymbol cannot be cast to class com.sun.tools.javac.code.Symbol$ClassSymbol (com.sun.tools.javac.code.Symbol$TypeVariableSymbol and com.sun.tools.javac.code.Symbol$ClassSymbol are in module jdk.compiler.interim of loader 'app') at jdk.compiler.interim/com.sun.tools.javac.comp.Check$CycleChecker.checkSymbol(Check.java:2329) at jdk.compiler.interim/com.sun.tools.javac.comp.Check$CycleChecker.visitIdent(Check.java:2345) at jdk.compiler.interim/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2710) at jdk.compiler.interim/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50) ...

yep I was thinking that tests will tell us if we could go or not with my proposal, nice that we have tests covering this, thanks for trying out

vicente-romero-oracle · 2025-02-24T15:23:22Z

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java

+                seenClasses.stream()
+                  .filter(s -> !s.type.isErroneous())
+                  .filter(ClassSymbol.class::isInstance)
+                  .map(ClassSymbol.class::cast)


this method will invoke Class::isInstance again, probably better to just do (c -> (ClassSymbol)c)?

this method will invoke Class::isInstance again, probably better to just do (c -> (ClassSymbol)c)?

I was under the impression that with Hotspot, there was no performance difference between ClassSymbol.class::cast and c -> (ClassSymbol)c. Is that not correct?

yep we should be fine here, probably just a matter of personal preference I guess

vicente-romero-oracle

looks sensible

archiecobbs · 2025-02-24T17:26:36Z

Thanks for the review!

lahodaj

FWIW, looks OK to me. It is difficult to estimate if there will be an impact from making the errors for the whole cycle erroneous, but we'll see.

FWIW, I tried to find out an example that wouldn't be fixed by this patch, but I couldn't.

archiecobbs · 2025-02-24T17:44:44Z

It is difficult to estimate if there will be an impact from making the errors for the whole cycle erroneous, but we'll see.

Thanks for taking a look. My hope is that (other than the minor performance hit) this change can only help avoid problems, because when you have a loop, the choice of starting class is fundamentally arbitrary. So if we assume the previous code, which only marked the first class in the loop as erroneous, was correct, then it must have been correct if it started with any other class in the loop (i.e., there is no "order"). Therefore, it must be correct to mark every class in the loop as erroneous 🤞

archiecobbs · 2025-02-25T19:37:57Z

/integrate

openjdk · 2025-02-25T19:39:25Z

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

a3188e0: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll()
d422abc: 8350668: has_extra_module_paths in filemap.cpp may be uninitialized
829d7a8: 8339889: Several compiler tests ignore vm flags and not marked as flagless
0151b15: 8348367: Remove hotspot_not_fast_compiler and hotspot_slow_compiler test groups
c5992ca: 8349533: Refactor validator tests shell files to java
dea7a9f: 8350516: Update model numbers for ECore-based cpus
5023971: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes
08bc59d: 8138614: (spec str) StringBuffer and StringBuilder methods improperly require "new" String to be returned
b17c0b6: 8350585: InlineSecondarySupersTest must be guarded on ppc64 by COMPILER2
62f39bd: 8350636: Potential null-pointer dereference in MallocSiteTable::new_entry
... and 128 more: https://git.openjdk.org/jdk/compare/ba28119642a7cfa850707a01ce8e589c3a80d416...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-02-25T19:39:32Z

@archiecobbs Pushed as commit b78043f.

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

Fix infinite loop in cyclic inheritance scenario.

1ec2d1f

openjdk bot added the compiler compiler-dev@openjdk.org label Feb 19, 2025

archiecobbs marked this pull request as ready for review February 20, 2025 23:46

openjdk bot added the rfr Pull request is ready for review label Feb 20, 2025

vicente-romero-oracle reviewed Feb 24, 2025

View reviewed changes

vicente-romero-oracle approved these changes Feb 24, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Feb 24, 2025

lahodaj approved these changes Feb 24, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Feb 25, 2025

openjdk bot closed this Feb 25, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 25, 2025

8320220: Compilation of cyclic hierarchy causes infinite recursion #23704

8320220: Compilation of cyclic hierarchy causes infinite recursion #23704

Uh oh!

Conversation

archiecobbs commented Feb 19, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Feb 19, 2025

Uh oh!

openjdk bot commented Feb 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Feb 19, 2025

Uh oh!

mlbridge bot commented Feb 20, 2025

Webrevs

Uh oh!

vicente-romero-oracle Feb 24, 2025

Choose a reason for hiding this comment

Uh oh!

archiecobbs Feb 24, 2025

Choose a reason for hiding this comment

Uh oh!

archiecobbs Feb 24, 2025

Choose a reason for hiding this comment

Uh oh!

vicente-romero-oracle Feb 24, 2025

Choose a reason for hiding this comment

Uh oh!

vicente-romero-oracle Feb 24, 2025

Choose a reason for hiding this comment

Uh oh!

archiecobbs Feb 24, 2025

Choose a reason for hiding this comment

Uh oh!

vicente-romero-oracle Feb 24, 2025

Choose a reason for hiding this comment

Uh oh!

vicente-romero-oracle left a comment

Choose a reason for hiding this comment

Uh oh!

archiecobbs commented Feb 24, 2025

Uh oh!

lahodaj left a comment

Choose a reason for hiding this comment

Uh oh!

archiecobbs commented Feb 24, 2025

Uh oh!

archiecobbs commented Feb 25, 2025

Uh oh!

openjdk bot commented Feb 25, 2025

Uh oh!

openjdk bot commented Feb 25, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

archiecobbs commented Feb 19, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Feb 19, 2025 •

edited

Loading