[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-compiler-dev
Subject:    RFR: JDK-8236697 Stack overflow with cyclic hierarchy in class file
From:       Adam Sotona <adam.sotona () oracle ! com>
Date:       2020-05-28 14:28:42
Message-ID: 3F9B3770-318A-4827-AD7A-F9D30FC0D79C () oracle ! com
[Download RAW message or body]

Hi,
I would like to ask for help with decision and review fix of JDK-8236697 Stack \
overflow with cyclic hierarchy in class file.

JBS: https://bugs.openjdk.java.net/browse/JDK-8236697

First important information is that the Stack overflow is caused by artificially \
corrupted library class file. The reproducible case described in the issue can be \
significantly simplified and I've transformed it into a test case (a part of the \
patches below).

Now I'm considering three possible options:

Option #1 -  complete detection and reporting of dependency cycles as a part of \
c.s.t.j.code.Types::asSuper by call of c.s.t.j.comp.Check::checkNonCyclic method, \
with positive impact on cycle detection and reporting, with minimal negative impact \
on performance and with negative impact on EagerInterfaceCompletionTest, which does \
not expect that by calling asSuper will be updated error status of all ancestors. \
Here is related patch in webrev: \
http://cr.openjdk.java.net/~asotona/8236697/webrev.00/

Option #2 - minimal necessary cycle detection just to avoid stack overflow, using \
LOCKED flag as a part of c.s.t.j.code.Types::asSuper execution, without any error \
reporting, just to avoid erroneous state, with almost no impact on performance and no \
                detected impact on other parts of javac and tests.
webrev: http://cr.openjdk.java.net/~asotona/8236697/webrev.01/

Option #3 - do not fix it, as artificially corrupted cyclic class file is an extreme \
case, where Stack overflow from javac might be considered as relevant response  
I've run Tier 1, 2 and 3 tests for options #1 and #2 and also javac compilation \
benchmarks comparing javac performance against JDK 15 build 25.

I propose to use option #2, however please let me know your opinion and/or review.

Thanks,
Adam


[prev in list] [next in list] [prev in thread] [next in thread]