JDK-8308050 : Renaissance dotty fails after JDK-8292275
  • Type: Bug
  • Component: tools
  • Affected Version: 21
  • Priority: P3
  • Status: Closed
  • Resolution: Withdrawn
  • OS: generic
  • CPU: generic
  • Submitted: 2023-05-15
  • Updated: 2023-05-15
  • Resolved: 2023-05-15
Related Reports
Relates :  
Description
Steps to reproduce the problem:
1. Build release on aarch64/x86 linux platform.
2. Run Renaissance dotty: $ java -jar renaissance-gpl-0.14.2.jar -r 1 dotty

Error message:
====== dotty (scala) [default], iteration 0 started ======
GC before operation: completed in 10.957 ms, heap usage 15.466 MB -> 5.648 MB.
dotty-error: error while loading ElementType,
class file /modules/java.base/java/lang/annotation/ElementType.class is broken, reading aborted with class java.lang.RuntimeException
bad constant pool index: 0 at pos: 1220
====== dotty (scala) [default], iteration 0 failed (ValidationException) ======
Benchmark 'dotty' failed result validation:
compilation errors: expected 0 but got 1
The following benchmarks failed: dotty
Comments
Same issue has already been reported by Renaissance project: https://github.com/renaissance-benchmarks/renaissance/issues/384
15-05-2023

I have just checked pending issues of Renaissance and looks like this has been reported already here: https://github.com/renaissance-benchmarks/renaissance/issues/384 From the discussion, seems that this is an issue for Dotty. I think it's better to track the problem there and I will close this issue. Thanks.
15-05-2023

More specifically, the exception seems to be coming from here: https://github.com/lampepfl/dotty/blob/22b22596ef5e67f786fb32f5f8652146d6bb0ba0/compiler/src/dotty/tools/dotc/core/classfile/ClassfileParser.scala#L1366 I would suspect that the Dotty classfile parser is not prepared to handle a zero (0) in the name_index of the MethdoParameters attribute, which seems to be in violation of the JVMS.
15-05-2023

I understand the issue can only be reproduced after JDK-8292275. But w/o knowing where the exception comes from (e.g. JDK or Scala), it is hard to understand how to proceed. Looking at the JDK code, while there are similarly phrased error messages, I cannot find one that has the exact format described in the original report - e.g.: " bad constant pool index: 0 at pos: 1220 " Which seems to suggest that some external library is being used by Dotty to parse classfile - if that's the case, I don't think there should be any bug against the JDK?
15-05-2023

[~mcimadamore] Not sure whether it's a javac compiler issue or not. It's a simple guess from the reported error message which mentions "class file /modules/java.base/java/lang/annotation/ElementType.class is broken". But my local tests show that this issue did happen after JDK-8292275.
15-05-2023

Are we sure this is a bug in the javac compiler? After reviewing the associated issue, PR and CSR, it seems that 8292275 is simply generating more MethodParameters attribute. Since the name of the attribute is only reified when javac is ran with the "-parameters" flag, the patch in the PR stores a constant pool index of zero (0) if names are not reified. This seems consistent with the definition of MethodParameters in JVMS: " parameters[] Each entry in the parameters array contains the following pair of items: name_index The value of the name_index item must either be zero or a valid index into the constant_pool table. If the value of the name_index item is zero, then this parameters element indicates a formal parameter with no name. If the value of the name_index item is nonzero, the constant_pool entry at that index must be a CONSTANT_Utf8_info structure representing a valid unqualified name denoting a formal parameter (ยง4.2.2). " Is it possible that dotty is using a classfile processor outside the JDK which does not handle the case where the name in a MethodParameters attribute is set to zero?
15-05-2023