From joe.darcy at oracle.com Mon Jun 3 20:38:51 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 3 Jun 2019 13:38:51 -0700 Subject: JDK 13 RFR of JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection Message-ID: <350f3073-cd9e-6a85-80bb-e42516c21003@oracle.com> Hello, Please review the webrev of changes for ??? JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection ??? http://cr.openjdk.java.net/~darcy/8164819.2/ Some background, several years ago in JDK 9, the toString output of annotations was changed to be usable as the source form of annotations (JDK-8162817: "Annotation toString output not reusable for source input"). Separate from the core reflection implementation of annotations, there are two other representations of that information available through annotation processing in javac from the javax.lang.model.AnnotatedConstruct interface, as AnnotationMirror objects and as? compile-time implementation of annotations in javac. (Annotations are implemented as Proxies of the interface of the annotation type both at runtime in core reflection and in javac.) The two intertwined toString implementations of annotation information in javac are distinct from the one core reflection and differ in how some information is presented. The changes discussed below move the javac and core reflection implementations very close to one another by making changes in each. The actual code changes are small; the lines of test changes are large, but mostly mechanical. The changes to the javac output are made in: src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java The changes to javac's output are: * The string for of class literals, either stand-alone or in an array now properly end in ".class". * For an enum constant, just the constant name is emitted rather than the full class name followed by the enum constant name. This shorter form is also used by javadoc. The changes to the core reflection output are made in: src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java The changes to core reflection output are: * Eliding "value=" when it is not necessary, logic already present for this in the javac implementations. * Changing the formatting of byte values to follow the existing javac convention, "(byte)0x1a" * Adopting the same quoting policy for char and string values as javac. This was accomplished by copying a few small methods from the javac internals; I don't think it is worthwhile to go through the contortions that would be needed to share this small bit of rarely changing code across these modules. * Unconditionally append a trailing "L" to long values, as done by javac. The core reflection changes are directly exercised by updates to: ??? test/jdk/java/lang/annotation/AnnotationToStringTest.java A new compile-time test for javac's implementations using (nearly) the same test inputs is added as test/langtools/tools/javac/processing/model/element/AnnotationToStringTest.java While technically possible, I don't think it would be worth the complexity to try to share the javac and core reflection testing driven by the same test vectors in a single test file. In particular, if changes to one of core reflection and javac altered the annotation output, having tests in each area would help flag the change sooner. The diff of the two flavors of AnnotationToStringTest.java is below and shows that the code to extract the annotations values differs between the javac and runtime API variants, but that the test vectors are the same. The other test updates, especially in the directly test/langtools/tools/javac/processing/model/element/repeatingAnnotations are to change the tests for the new output, especially for when "value=" it is not needed. I'm still working on the exact updates needed for ??? test/langtools/tools/javac/sym/ElementStructureTest.java but I wanted to get the remainder of the work out for review. Thanks, -Joe Diff of test files: diff test/jdk/java/lang/annotation/AnnotationToStringTest.java test/langtools/tools/javac/processing/model/element/AnnotationToStringTest.java 26c26 < ?* @bug 8162817 8168921 --- > ?* @bug 8164819 27a28,30 > ?* @library /tools/javac/lib > ?* @build ? JavacTestingAbstractProcessor AnnotationToStringTest > ?* @compile -processor AnnotationToStringTest -proc:only AnnotationToStringTest.java 30,31c33,34 < // See also the sibling compile-time test < // test/langtools/tools/javac/processing/model/element/AnnotationToStringTest.java --- > // See also the sibling core reflection test > // test/jdk/java/lang/annotation/AnnotationToStringTest.java 35a39,42 > import javax.annotation.processing.*; > import javax.lang.model.AnnotatedConstruct; > import javax.lang.model.element.*; > import javax.lang.model.util.*; 40a48,55 > ?* > ?* Two flavors of comparison are made: > ?* > ?* 1) Against the AnnotationMirror value from getAnnotationMirrors() > ?* > ?* 2) Against the *Annotation* from getAnnotation(Class) > ?* > ?* These have separate but related implementations. 41a57,60 > public class AnnotationToStringTest extends JavacTestingAbstractProcessor { > ? ? public boolean process(Set annotations, > ? ? ? ? ? ? ? ? ? ? ? ? ? ?RoundEnvironment roundEnv) { > ? ? ? ? if (!roundEnv.processingOver()) { 43,45c62,93 < public class AnnotationToStringTest { < ? ? public static void main(String... args) throws Exception { < ? ? ? ? int failures = 0; --- > ? ? ? ? ? ? int failures = 0; > > ? ? ? ? ? ? TypeElement primHostElt = > Objects.requireNonNull(elements.getTypeElement("AnnotationToStringTest.PrimHost")); > > ? ? ? ? ? ? List annotMirrors = primHostElt.getAnnotationMirrors(); > > ? ? ? ? ? ? String expectedString = primHostElt.getAnnotation(MostlyPrimitive.class).toString(); > > ? ? ? ? ? ? failures += check(expectedString, > primHostElt.getAnnotation(ExpectedString.class).value()); > > ? ? ? ? ? ? failures += check(expectedString, > retrieveAnnotationMirrorAsString(primHostElt, > ? ? ? ? ? ? ?"MostlyPrimitive")); > ? ? ? ? ? ? failures += classyTest(); > ? ? ? ? ? ? failures += arrayAnnotationTest(); > > ? ? ? ? ? ? if (failures > 0) > ? ? ? ? ? ? ? ? throw new RuntimeException(failures + " failures"); > ? ? ? ? } > ? ? ? ? return true; > ? ? } > > ? ? /** > ? ? ?* Examine annotation mirrors, find the one that matches > ? ? ?* annotationName, and return its toString value. > ? ? ?*/ > ? ? private String retrieveAnnotationMirrorAsString(AnnotatedConstruct annotated, > ? String annotationName) { > ? ? ? ? return retrieveAnnotationMirror(annotated, annotationName).toString(); > ? ? } 47,50c95,106 < ? ? ? ? failures += check(PrimHost.class.getAnnotation(ExpectedString.class).value(), < PrimHost.class.getAnnotation(MostlyPrimitive.class).toString()); < ? ? ? ? failures += classyTest(); < ? ? ? ? failures += arrayAnnotationTest(); --- > ? ? private String retrieveAnnotationMirrorValue(AnnotatedConstruct annotated, > ?String annotationName) { > ? ? ? ? AnnotationMirror annotationMirror = > ? ? ? ? ? ? retrieveAnnotationMirror(annotated, annotationName); > ? ? ? ? for (var entry : annotationMirror.getElementValues().entrySet()) { > ? ? ? ? ? ? if (entry.getKey().getSimpleName().contentEquals("value")) { > ? ? ? ? ? ? ? ? return entry.getValue().toString(); > ? ? ? ? ? ? } > ? ? ? ? } > ? ? ? ? throw new RuntimeException("Annotation value() method not found: " + > ?annotationMirror.toString()); > ? ? } 52,53c108,119 < ? ? ? ? if (failures > 0) < ? ? ? ? ? ? throw new RuntimeException(failures + " failures"); --- > ? ? private AnnotationMirror retrieveAnnotationMirror(AnnotatedConstruct annotated, > ? ? String annotationName) { > ? ? ? ? for (AnnotationMirror annotationMirror : annotated.getAnnotationMirrors()) { > System.out.println(annotationMirror.getAnnotationType()); > ? ? ? ? ? ? if (annotationMirror > ? ? ? ? ? ? ? ? .getAnnotationType() > ? ? ? ? ? ? ? ? .toString() > ? ? ? ? ? ? ? ? .equals(annotationName) ) { > ? ? ? ? ? ? ? ? return annotationMirror; > ? ? ? ? ? ? } > ? ? ? ? } > ? ? ? ? throw new RuntimeException("Annotation " + annotationName + " not found."); 104c170 < ? ? private static int classyTest() { --- > ? ? private int classyTest() { 106c172,177 < ? ? ? ? for (Field f : AnnotationHost.class.getFields()) { --- > > ? ? ? ? TypeElement annotationHostElt = > Objects.requireNonNull(elements.getTypeElement("AnnotationToStringTest.AnnotationHost")); > > ? ? ? ? for (VariableElement f : ElementFilter.fieldsIn(annotationHostElt.getEnclosedElements())) { > ? ? ? ? ? ? String expected = f.getAnnotation(ExpectedString.class).value(); 107a179 > 109,110c181,184 < ? ? ? ? ? ? failures += check(f.getAnnotation(ExpectedString.class).value(), < ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? a.toString()); --- > ? ? ? ? ? ? failures += check(expected, a.toString()); > > ? ? ? ? ? ? failures += check(expected, > retrieveAnnotationMirrorAsString(f, "Classy") ); 151c225 < ? ? private static int arrayAnnotationTest() { --- > ? ? private int arrayAnnotationTest() { 153,157c227,251 < ? ? ? ? for (Field f : ArrayAnnotationHost.class.getFields()) { < ? ? ? ? ? ? Annotation[] annotations = f.getAnnotations(); < ? ? ? ? ? ? System.out.println(annotations[1]); < ? ? ? ? ? ? failures += check(((ExpectedString)annotations[0]).value(), < annotations[1].toString()); --- > > ? ? ? ? TypeElement arrayAnnotationHostElt = > ? ? ? ? ? ? Objects.requireNonNull(elements > ?.getTypeElement("AnnotationToStringTest.ArrayAnnotationHost")); > > ? ? ? ? for (VariableElement f : > ?ElementFilter.fieldsIn(arrayAnnotationHostElt.getEnclosedElements())) { > ? ? ? ? ? ? var annotations = f.getAnnotationMirrors(); > ? ? ? ? ? ? // String expected = retrieveAnnotationMirrorValue(f, "ExpectedString"); > ? ? ? ? ? ? String expected = f.getAnnotation(ExpectedString.class).value(); > > ? ? ? ? ? ? // Problem with > ? ? ? ? ? ? // Need a de-quote method... > ? ? ? ? ? ? // expected = expected.substring(1, expected.length() - 1); > > ? ? ? ? ? ? ? failures += > ? ? ? ? ? ? ? ? ? check(expected, > annotations.get(1).toString()); > > ? ? ? ? ? ? // Get the array-valued annotation as an annotation > ? ? ? ? ? ? ? failures += > ? ? ? ? ? ? ? ? ? check(expected, > retrieveAnnotationMirrorAsString(f, > ? ? ? ?annotations.get(1) > ? ? ? ?.getAnnotationType().toString())); 176a271 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Jun 3 23:01:56 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 3 Jun 2019 16:01:56 -0700 Subject: JDK 13 RFR of JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection In-Reply-To: <350f3073-cd9e-6a85-80bb-e42516c21003@oracle.com> References: <350f3073-cd9e-6a85-80bb-e42516c21003@oracle.com> Message-ID: <75afcc30-19d2-cc2c-ecdc-6f5830413e78@oracle.com> OK, but with a typo to be fixed in the first file (ArrayBackets) "It would be nice" if we could share the test cases in the new AnnotationToStringTest with an equivalent test for javadoc, but I can't think of a clean way to do that (so far). -- Jon On 06/03/2019 01:38 PM, Joe Darcy wrote: > > Hello, > > Please review the webrev of changes for > > ??? JDK-8164819: Make javac's toString() on annotation objects > consistent with core reflection > http://cr.openjdk.java.net/~darcy/8164819.2/ > > Some background, several years ago in JDK 9, the toString output of > annotations was changed to be usable as the source form of annotations > (JDK-8162817: "Annotation toString output not reusable for source input"). > > Separate from the core reflection implementation of annotations, there > are two other representations of that information available through > annotation processing in javac from the > javax.lang.model.AnnotatedConstruct interface, as AnnotationMirror > objects and as? compile-time implementation of annotations in javac. > (Annotations are implemented as Proxies of the interface of the > annotation type both at runtime in core reflection and in javac.) > > The two intertwined toString implementations of annotation information > in javac are distinct from the one core reflection and differ in how > some information is presented. The changes discussed below move the > javac and core reflection implementations very close to one another by > making changes in each. The actual code changes are small; the lines > of test changes are large, but mostly mechanical. > > The changes to the javac output are made in: > src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java > > The changes to javac's output are: > > * The string for of class literals, either stand-alone or in an array > now properly end in ".class". > * For an enum constant, just the constant name is emitted rather than > the full class name followed by the enum constant name. This shorter > form is also used by javadoc. > > The changes to the core reflection output are made in: > src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java > > The changes to core reflection output are: > > * Eliding "value=" when it is not necessary, logic already present for > this in the javac implementations. > * Changing the formatting of byte values to follow the existing javac > convention, "(byte)0x1a" > * Adopting the same quoting policy for char and string values as > javac. This was accomplished by copying a few small methods from the > javac internals; I don't think it is worthwhile to go through the > contortions that would be needed to share this small bit of rarely > changing code across these modules. > * Unconditionally append a trailing "L" to long values, as done by javac. > > The core reflection changes are directly exercised by updates to: > > ??? test/jdk/java/lang/annotation/AnnotationToStringTest.java > > A new compile-time test for javac's implementations using (nearly) the > same test inputs is added as > > test/langtools/tools/javac/processing/model/element/AnnotationToStringTest.java > > While technically possible, I don't think it would be worth the > complexity to try to share the javac and core reflection testing > driven by the same test vectors in a single test file. In particular, > if changes to one of core reflection and javac altered the annotation > output, having tests in each area would help flag the change sooner. > > The diff of the two flavors of AnnotationToStringTest.java is below > and shows that the code to extract the annotations values differs > between the javac and runtime API variants, but that the test vectors > are the same. > > The other test updates, especially in the directly > test/langtools/tools/javac/processing/model/element/repeatingAnnotations > are to change the tests for the new output, especially for when > "value=" it is not needed. I'm still working on the exact updates > needed for > > ??? test/langtools/tools/javac/sym/ElementStructureTest.java > > but I wanted to get the remainder of the work out for review. > > Thanks, > > -Joe > > Diff of test files: > > diff test/jdk/java/lang/annotation/AnnotationToStringTest.java > test/langtools/tools/javac/processing/model/element/AnnotationToStringTest.java > 26c26 > < ?* @bug 8162817 8168921 > --- > > ?* @bug 8164819 > 27a28,30 > > ?* @library /tools/javac/lib > > ?* @build ? JavacTestingAbstractProcessor AnnotationToStringTest > > ?* @compile -processor AnnotationToStringTest -proc:only > AnnotationToStringTest.java > 30,31c33,34 > < // See also the sibling compile-time test > < // > test/langtools/tools/javac/processing/model/element/AnnotationToStringTest.java > --- > > // See also the sibling core reflection test > > // test/jdk/java/lang/annotation/AnnotationToStringTest.java > 35a39,42 > > import javax.annotation.processing.*; > > import javax.lang.model.AnnotatedConstruct; > > import javax.lang.model.element.*; > > import javax.lang.model.util.*; > 40a48,55 > > ?* > > ?* Two flavors of comparison are made: > > ?* > > ?* 1) Against the AnnotationMirror value from getAnnotationMirrors() > > ?* > > ?* 2) Against the *Annotation* from getAnnotation(Class) > > ?* > > ?* These have separate but related implementations. > 41a57,60 > > public class AnnotationToStringTest extends > JavacTestingAbstractProcessor { > > ? ? public boolean process(Set annotations, > > ? ? ? ? ? ? ? ? ? ? ? ? ? ?RoundEnvironment roundEnv) { > > ? ? ? ? if (!roundEnv.processingOver()) { > 43,45c62,93 > < public class AnnotationToStringTest { > < ? ? public static void main(String... args) throws Exception { > < ? ? ? ? int failures = 0; > --- > > ? ? ? ? ? ? int failures = 0; > > > > ? ? ? ? ? ? TypeElement primHostElt = > > > Objects.requireNonNull(elements.getTypeElement("AnnotationToStringTest.PrimHost")); > > > > ? ? ? ? ? ? List annotMirrors = > primHostElt.getAnnotationMirrors(); > > > > ? ? ? ? ? ? String expectedString = > primHostElt.getAnnotation(MostlyPrimitive.class).toString(); > > > > ? ? ? ? ? ? failures += check(expectedString, > > primHostElt.getAnnotation(ExpectedString.class).value()); > > > > ? ? ? ? ? ? failures += check(expectedString, > > retrieveAnnotationMirrorAsString(primHostElt, > > ? ? ? ? ? ? ? ?"MostlyPrimitive")); > > ? ? ? ? ? ? failures += classyTest(); > > ? ? ? ? ? ? failures += arrayAnnotationTest(); > > > > ? ? ? ? ? ? if (failures > 0) > > ? ? ? ? ? ? ? ? throw new RuntimeException(failures + " failures"); > > ? ? ? ? } > > ? ? ? ? return true; > > ? ? } > > > > ? ? /** > > ? ? ?* Examine annotation mirrors, find the one that matches > > ? ? ?* annotationName, and return its toString value. > > ? ? ?*/ > > ? ? private String > retrieveAnnotationMirrorAsString(AnnotatedConstruct annotated, > > ? ? String annotationName) { > > ? ? ? ? return retrieveAnnotationMirror(annotated, > annotationName).toString(); > > ? ? } > 47,50c95,106 > < ? ? ? ? failures += > check(PrimHost.class.getAnnotation(ExpectedString.class).value(), > < PrimHost.class.getAnnotation(MostlyPrimitive.class).toString()); > < ? ? ? ? failures += classyTest(); > < ? ? ? ? failures += arrayAnnotationTest(); > --- > > ? ? private String retrieveAnnotationMirrorValue(AnnotatedConstruct > annotated, > > ?String annotationName) { > > ? ? ? ? AnnotationMirror annotationMirror = > > ? ? ? ? ? ? retrieveAnnotationMirror(annotated, annotationName); > > ? ? ? ? for (var entry : > annotationMirror.getElementValues().entrySet()) { > > ? ? ? ? ? ? if (entry.getKey().getSimpleName().contentEquals("value")) { > > ? ? ? ? ? ? ? ? return entry.getValue().toString(); > > ? ? ? ? ? ? } > > ? ? ? ? } > > ? ? ? ? throw new RuntimeException("Annotation value() method not > found: " + > > ?annotationMirror.toString()); > > ? ? } > 52,53c108,119 > < ? ? ? ? if (failures > 0) > < ? ? ? ? ? ? throw new RuntimeException(failures + " failures"); > --- > > ? ? private AnnotationMirror > retrieveAnnotationMirror(AnnotatedConstruct annotated, > > ? ? ? String annotationName) { > > ? ? ? ? for (AnnotationMirror annotationMirror : > annotated.getAnnotationMirrors()) { > > System.out.println(annotationMirror.getAnnotationType()); > > ? ? ? ? ? ? if (annotationMirror > > ? ? ? ? ? ? ? ? .getAnnotationType() > > ? ? ? ? ? ? ? ? .toString() > > ? ? ? ? ? ? ? ? .equals(annotationName) ) { > > ? ? ? ? ? ? ? ? return annotationMirror; > > ? ? ? ? ? ? } > > ? ? ? ? } > > ? ? ? ? throw new RuntimeException("Annotation " + annotationName + > " not found."); > 104c170 > < ? ? private static int classyTest() { > --- > > ? ? private int classyTest() { > 106c172,177 > < ? ? ? ? for (Field f : AnnotationHost.class.getFields()) { > --- > > > > ? ? ? ? TypeElement annotationHostElt = > > > Objects.requireNonNull(elements.getTypeElement("AnnotationToStringTest.AnnotationHost")); > > > > ? ? ? ? for (VariableElement f : > ElementFilter.fieldsIn(annotationHostElt.getEnclosedElements())) { > > ? ? ? ? ? ? String expected = > f.getAnnotation(ExpectedString.class).value(); > 107a179 > > > 109,110c181,184 > < ? ? ? ? ? ? failures += > check(f.getAnnotation(ExpectedString.class).value(), > < ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? a.toString()); > --- > > ? ? ? ? ? ? failures += check(expected, a.toString()); > > > > ? ? ? ? ? ? failures += check(expected, > > retrieveAnnotationMirrorAsString(f, "Classy") ); > 151c225 > < ? ? private static int arrayAnnotationTest() { > --- > > ? ? private int arrayAnnotationTest() { > 153,157c227,251 > < ? ? ? ? for (Field f : ArrayAnnotationHost.class.getFields()) { > < ? ? ? ? ? ? Annotation[] annotations = f.getAnnotations(); > < ? ? ? ? ? ? System.out.println(annotations[1]); > < ? ? ? ? ? ? failures += check(((ExpectedString)annotations[0]).value(), > < annotations[1].toString()); > --- > > > > ? ? ? ? TypeElement arrayAnnotationHostElt = > > ? ? ? ? ? ? Objects.requireNonNull(elements > > ?.getTypeElement("AnnotationToStringTest.ArrayAnnotationHost")); > > > > ? ? ? ? for (VariableElement f : > > ?ElementFilter.fieldsIn(arrayAnnotationHostElt.getEnclosedElements())) { > > ? ? ? ? ? ? var annotations = f.getAnnotationMirrors(); > > ? ? ? ? ? ? // String expected = retrieveAnnotationMirrorValue(f, > "ExpectedString"); > > ? ? ? ? ? ? String expected = > f.getAnnotation(ExpectedString.class).value(); > > > > ? ? ? ? ? ? // Problem with > > ? ? ? ? ? ? // Need a de-quote method... > > ? ? ? ? ? ? // expected = expected.substring(1, expected.length() - 1); > > > > ? ? ? ? ? ? ? failures += > > ? ? ? ? ? ? ? ? ? check(expected, > > annotations.get(1).toString()); > > > > ? ? ? ? ? ? // Get the array-valued annotation as an annotation > > ? ? ? ? ? ? ? failures += > > ? ? ? ? ? ? ? ? ? check(expected, > > retrieveAnnotationMirrorAsString(f, > > ? ? ? ? ?annotations.get(1) > > ? ? ? ? ?.getAnnotationType().toString())); > 176a271 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jun 4 16:46:57 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 4 Jun 2019 09:46:57 -0700 Subject: JDK 13 RFR of JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection In-Reply-To: <75afcc30-19d2-cc2c-ecdc-6f5830413e78@oracle.com> References: <350f3073-cd9e-6a85-80bb-e42516c21003@oracle.com> <75afcc30-19d2-cc2c-ecdc-6f5830413e78@oracle.com> Message-ID: Thanks Jon. FYI, updated webrev at ??? http://cr.openjdk.java.net/~darcy/8164819.3/ Diff of patches below. Typo in the AnnotationInvocationHandler.java variable name corrected, ElementStructureTest test update courtesy Jan, and small update to the HotSpot test ConstMethodTest.java to accommodate the changed format. Thanks, -Joe > --- old/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java 2019-06-04 09:26:16.824947998 -0700 > +++ new/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java 2019-06-04 09:26:16.497112000 -0700 45,46c45,55 < @@ -228,7 +236,7 @@ @@ -221,14 +229,14 @@ >?????? */ >????? private static String toSourceString(Class clazz) { >????????? Class finalComponent = clazz; > -??????? StringBuilder arrayBackets = new StringBuilder(); > +??????? StringBuilder arrayBrackets = new StringBuilder(); > >????????? while(finalComponent.isArray()) { >????????????? finalComponent = finalComponent.getComponentType(); > -??????????? arrayBackets.append("[]"); > +??????????? arrayBrackets.append("[]"); 50c59 < +??????? return finalComponent.getName() + arrayBackets.toString() + ".class"; --- > +??????? return finalComponent.getName() + arrayBrackets.toString() + ".class"; < --- old/test/langtools/tools/javac/sym/ElementStructureTest.java 2019-06-03 13:45:14.639762024 -0700 < +++ new/test/langtools/tools/javac/sym/ElementStructureTest.java 2019-06-03 13:45:14.319922012 -0700 < @@ -23,6 +23,7 @@ < --- old/test/langtools/tools/javac/sym/ElementStructureTest.java 2019-06-04 09:26:37.002853999 -0700 > +++ new/test/langtools/tools/javac/sym/ElementStructureTest.java 2019-06-04 09:26:36.683013999 -0700 > @@ -1,5 +1,5 @@ >? /* > - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2019, Oracle and/or its affiliates. All rights reserved. >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >?? * >?? * This code is free software; you can redistribute it and/or modify it > @@ -128,16 +128,16 @@ >????????? (byte) 0xB7, (byte) 0x52, (byte) 0x0F, (byte) 0x68 >????? }; >????? static final byte[] hash7 = new byte[] { > -??????? (byte) 0x6B, (byte) 0xA2, (byte) 0xE9, (byte) 0x8E, > -??????? (byte) 0xE1, (byte) 0x8E, (byte) 0x60, (byte) 0xBE, > -??????? (byte) 0x54, (byte) 0xC4, (byte) 0x33, (byte) 0x3E, > -??????? (byte) 0x0C, (byte) 0x2D, (byte) 0x3A, (byte) 0x7C > + (byte) 0x3C, (byte) 0x03, (byte) 0xEA, (byte) 0x4A, > + (byte) 0x62, (byte) 0xD2, (byte) 0x18, (byte) 0xE5, > + (byte) 0xA5, (byte) 0xC2, (byte) 0xB7, (byte) 0x85, > + (byte) 0x90, (byte) 0xFA, (byte) 0x98, (byte) 0xCD >????? }; >????? static final byte[] hash8 = new byte[] { > -??????? (byte) 0x44, (byte) 0x77, (byte) 0x6E, (byte) 0x52, > -??????? (byte) 0x2B, (byte) 0x16, (byte) 0xD3, (byte) 0x3C, > -??????? (byte) 0x78, (byte) 0x75, (byte) 0xF5, (byte) 0x0A, > -??????? (byte) 0x01, (byte) 0x24, (byte) 0xBD, (byte) 0x2A > + (byte) 0x0B, (byte) 0xEB, (byte) 0x16, (byte) 0xF5, > + (byte) 0x7F, (byte) 0xB0, (byte) 0x18, (byte) 0xF1, > + (byte) 0x78, (byte) 0x11, (byte) 0xED, (byte) 0x30, > + (byte) 0x19, (byte) 0x4D, (byte) 0xDE, (byte) 0x8A >????? }; > >????? final static Map version2Hash = new HashMap<>(); > --- old/test/hotspot/jtreg/runtime/8007320/ConstMethodTest.java 2019-06-04 09:26:37.562573999 -0700 > +++ new/test/hotspot/jtreg/runtime/8007320/ConstMethodTest.java 2019-06-04 09:26:37.242733999 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -122,8 +122,8 @@ > ? ? ? ? ? ? ? ? ?equal(ann.length, 3); > ? ? ? ? ? ? ? ? ?Annotation foo = ann[0][0]; > ? ? ? ? ? ? ? ? ?Annotation bar = ann[1][0]; > - ? ? ? ? ? ? ? ?equal(foo.toString(), "@Named(value=\"aName\")"); > - ? ? ? ? ? ? ? ?equal(bar.toString(), "@Named(value=\"bName\")"); > + ? ? ? ? ? ? ? ?equal(foo.toString(), "@Named(\"aName\")"); > + ? ? ? ? ? ? ? ?equal(bar.toString(), "@Named(\"bName\")"); > ? ? ? ? ? ? ? ? ?check(foo.equals(foo)); > ? ? ? ? ? ? ? ? ?check(bar.equals(bar)); > ? ? ? ? ? ? ? ? ?check(! foo.equals(bar)); On 6/3/2019 4:01 PM, Jonathan Gibbons wrote: > > OK, but with a typo to be fixed in the first file (ArrayBackets) > > "It would be nice" if we could share the test cases in the new > AnnotationToStringTest with an equivalent test for javadoc, but I > can't think of a clean way to do that (so far). > > -- Jon > From jonathan.gibbons at oracle.com Tue Jun 4 18:33:06 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 4 Jun 2019 11:33:06 -0700 Subject: JDK 13 RFR of JDK-8164819: Make javac's toString() on annotation objects consistent with core reflection In-Reply-To: References: <350f3073-cd9e-6a85-80bb-e42516c21003@oracle.com> <75afcc30-19d2-cc2c-ecdc-6f5830413e78@oracle.com> Message-ID: +1 On 06/04/2019 09:46 AM, Joe Darcy wrote: > Thanks Jon. > > FYI, updated webrev at > > ??? http://cr.openjdk.java.net/~darcy/8164819.3/ > > Diff of patches below. Typo in the AnnotationInvocationHandler.java > variable name corrected, ElementStructureTest test update courtesy > Jan, and small update to the HotSpot test ConstMethodTest.java to > accommodate the changed format. > > Thanks, > > -Joe > > > --- > old/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java > 2019-06-04 09:26:16.824947998 -0700 > > +++ > new/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java > 2019-06-04 09:26:16.497112000 -0700 > 45,46c45,55 > < @@ -228,7 +236,7 @@ > --- > > @@ -221,14 +229,14 @@ > >?????? */ > >????? private static String toSourceString(Class clazz) { > >????????? Class finalComponent = clazz; > > -??????? StringBuilder arrayBackets = new StringBuilder(); > > +??????? StringBuilder arrayBrackets = new StringBuilder(); > > > >????????? while(finalComponent.isArray()) { > >????????????? finalComponent = finalComponent.getComponentType(); > > -??????????? arrayBackets.append("[]"); > > +??????????? arrayBrackets.append("[]"); > 50c59 > < +??????? return finalComponent.getName() + arrayBackets.toString() + > ".class"; > --- > > +??????? return finalComponent.getName() + arrayBrackets.toString() > + ".class"; > > > < --- old/test/langtools/tools/javac/sym/ElementStructureTest.java > 2019-06-03 13:45:14.639762024 -0700 > < +++ new/test/langtools/tools/javac/sym/ElementStructureTest.java > 2019-06-03 13:45:14.319922012 -0700 > < @@ -23,6 +23,7 @@ > < > < + * @ignore > elements. > --- > > --- old/test/langtools/tools/javac/sym/ElementStructureTest.java > 2019-06-04 09:26:37.002853999 -0700 > > +++ new/test/langtools/tools/javac/sym/ElementStructureTest.java > 2019-06-04 09:26:36.683013999 -0700 > > @@ -1,5 +1,5 @@ > >? /* > > - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All > rights reserved. > > + * Copyright (c) 2015, 2019, Oracle and/or its affiliates. All > rights reserved. > >?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > >?? * > >?? * This code is free software; you can redistribute it and/or > modify it > > @@ -128,16 +128,16 @@ > >????????? (byte) 0xB7, (byte) 0x52, (byte) 0x0F, (byte) 0x68 > >????? }; > >????? static final byte[] hash7 = new byte[] { > > -??????? (byte) 0x6B, (byte) 0xA2, (byte) 0xE9, (byte) 0x8E, > > -??????? (byte) 0xE1, (byte) 0x8E, (byte) 0x60, (byte) 0xBE, > > -??????? (byte) 0x54, (byte) 0xC4, (byte) 0x33, (byte) 0x3E, > > -??????? (byte) 0x0C, (byte) 0x2D, (byte) 0x3A, (byte) 0x7C > > + (byte) 0x3C, (byte) 0x03, (byte) 0xEA, (byte) 0x4A, > > + (byte) 0x62, (byte) 0xD2, (byte) 0x18, (byte) 0xE5, > > + (byte) 0xA5, (byte) 0xC2, (byte) 0xB7, (byte) 0x85, > > + (byte) 0x90, (byte) 0xFA, (byte) 0x98, (byte) 0xCD > >????? }; > >????? static final byte[] hash8 = new byte[] { > > -??????? (byte) 0x44, (byte) 0x77, (byte) 0x6E, (byte) 0x52, > > -??????? (byte) 0x2B, (byte) 0x16, (byte) 0xD3, (byte) 0x3C, > > -??????? (byte) 0x78, (byte) 0x75, (byte) 0xF5, (byte) 0x0A, > > -??????? (byte) 0x01, (byte) 0x24, (byte) 0xBD, (byte) 0x2A > > + (byte) 0x0B, (byte) 0xEB, (byte) 0x16, (byte) 0xF5, > > + (byte) 0x7F, (byte) 0xB0, (byte) 0x18, (byte) 0xF1, > > + (byte) 0x78, (byte) 0x11, (byte) 0xED, (byte) 0x30, > > + (byte) 0x19, (byte) 0x4D, (byte) 0xDE, (byte) 0x8A > >????? }; > > > >????? final static Map version2Hash = new HashMap<>(); > > > --- old/test/hotspot/jtreg/runtime/8007320/ConstMethodTest.java > 2019-06-04 09:26:37.562573999 -0700 > > +++ new/test/hotspot/jtreg/runtime/8007320/ConstMethodTest.java > 2019-06-04 09:26:37.242733999 -0700 > > @@ -1,5 +1,5 @@ > > ?/* > > - * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All > rights reserved. > > + * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All > rights reserved. > > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > ? * > > ? * This code is free software; you can redistribute it and/or > modify it > > @@ -122,8 +122,8 @@ > > ? ? ? ? ? ? ? ? ?equal(ann.length, 3); > > ? ? ? ? ? ? ? ? ?Annotation foo = ann[0][0]; > > ? ? ? ? ? ? ? ? ?Annotation bar = ann[1][0]; > > - ? ? ? ? ? ? ? ?equal(foo.toString(), "@Named(value=\"aName\")"); > > - ? ? ? ? ? ? ? ?equal(bar.toString(), "@Named(value=\"bName\")"); > > + ? ? ? ? ? ? ? ?equal(foo.toString(), "@Named(\"aName\")"); > > + ? ? ? ? ? ? ? ?equal(bar.toString(), "@Named(\"bName\")"); > > ? ? ? ? ? ? ? ? ?check(foo.equals(foo)); > > ? ? ? ? ? ? ? ? ?check(bar.equals(bar)); > > ? ? ? ? ? ? ? ? ?check(! foo.equals(bar)); > > On 6/3/2019 4:01 PM, Jonathan Gibbons wrote: >> >> OK, but with a typo to be fixed in the first file (ArrayBackets) >> >> "It would be nice" if we could share the test cases in the new >> AnnotationToStringTest with an equivalent test for javadoc, but I >> can't think of a clean way to do that (so far). >> >> -- Jon >> From vicente.romero at oracle.com Tue Jun 4 23:08:29 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 4 Jun 2019 19:08:29 -0400 Subject: RFR: JDK-8216261: Javap ignores default modifier on interfaces Message-ID: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> Please review fix for [1] at [2]. This is an enhancement request asking to make javap show if a method has the default modifier or not. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8216261 [2] http://cr.openjdk.java.net/~vromero/8216261/webrev.00/ From joe.darcy at oracle.com Tue Jun 4 23:20:56 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 04 Jun 2019 16:20:56 -0700 Subject: RFR: JDK-8216261: Javap ignores default modifier on interfaces In-Reply-To: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> References: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> Message-ID: <5CF6FCD8.8070407@oracle.com> Hi Vicente, Why is there a check against both the major and minor version number for default support? Thanks, -Joe On 6/4/2019 4:08 PM, Vicente Romero wrote: > Please review fix for [1] at [2]. This is an enhancement request > asking to make javap show if a method has the default modifier or not. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8216261 > [2] http://cr.openjdk.java.net/~vromero/8216261/webrev.00/ From jonathan.gibbons at oracle.com Tue Jun 4 23:24:26 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 4 Jun 2019 16:24:26 -0700 Subject: RFR: JDK-8216261: Javap ignores default modifier on interfaces In-Reply-To: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> References: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> Message-ID: On 06/04/2019 04:08 PM, Vicente Romero wrote: > Please review fix for [1] at [2]. This is an enhancement request > asking to make javap show if a method has the default modifier or not. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8216261 > [2] http://cr.openjdk.java.net/~vromero/8216261/webrev.00/ The main source change looks OK, The test could be improved: 1. If the test fails, nothing is printed to show what went wrong because a basic assertion of "incorrect output". What was the incorrect output?? It should *always* be the case for *all* tests that a test should try and give as much output as is reasonable when the test fails, to give the person analyzing the test failure as much as possible. 2. (Less important)? Personally, I think it is bad style to construct pathnames with string bashing. (I've been burnt too often!)? Generally it is better to use the File or Path API to construct filenames, and then use .toString(). -- Jon From vicente.romero at oracle.com Wed Jun 5 12:00:08 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Jun 2019 08:00:08 -0400 Subject: RFR: JDK-8216261: Javap ignores default modifier on interfaces In-Reply-To: <5CF6FCD8.8070407@oracle.com> References: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> <5CF6FCD8.8070407@oracle.com> Message-ID: <99495ddb-353d-dad0-f74f-b85d1e12b008@oracle.com> On 6/4/19 7:20 PM, Joseph D. Darcy wrote: > Hi Vicente, > > Why is there a check against both the major and minor version number > for default support? I have just adapted the same code javac is using in [1], Thanks, Vicente [1] http://hg.openjdk.java.net/jdk/jdk/file/ce8bab2c4185/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#l2144 > > Thanks, > > -Joe > > On 6/4/2019 4:08 PM, Vicente Romero wrote: >> Please review fix for [1] at [2]. This is an enhancement request >> asking to make javap show if a method has the default modifier or not. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8216261 >> [2] http://cr.openjdk.java.net/~vromero/8216261/webrev.00/ > From vicente.romero at oracle.com Wed Jun 5 13:43:28 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Jun 2019 09:43:28 -0400 Subject: RFR: JDK-8216261: Javap ignores default modifier on interfaces In-Reply-To: References: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> Message-ID: <21b83c7d-c753-f153-f9e7-90a8a672c952@oracle.com> Hi Jon, Thanks for your comments, what about [1]? Vicente [1] http://cr.openjdk.java.net/~vromero/8216261/webrev.01/ On 6/4/19 7:24 PM, Jonathan Gibbons wrote: > > > On 06/04/2019 04:08 PM, Vicente Romero wrote: >> Please review fix for [1] at [2]. This is an enhancement request >> asking to make javap show if a method has the default modifier or not. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8216261 >> [2] http://cr.openjdk.java.net/~vromero/8216261/webrev.00/ > > The main source change looks OK, > > The test could be improved: > > 1. If the test fails, nothing is printed to show what went wrong > because a basic assertion of "incorrect output". What was the > incorrect output?? It should *always* be the case for *all* tests that > a test should try and give as much output as is reasonable when the > test fails, to give the person analyzing the test failure as much as > possible. > > 2. (Less important)? Personally, I think it is bad style to construct > pathnames with string bashing. (I've been burnt too often!)? Generally > it is better to use the File or Path API to construct filenames, and > then use .toString(). > > -- Jon From jonathan.gibbons at oracle.com Wed Jun 5 13:46:03 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 5 Jun 2019 06:46:03 -0700 Subject: RFR: JDK-8216261: Javap ignores default modifier on interfaces In-Reply-To: <21b83c7d-c753-f153-f9e7-90a8a672c952@oracle.com> References: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> <21b83c7d-c753-f153-f9e7-90a8a672c952@oracle.com> Message-ID: <5b286fe1-c7ee-165d-c1b9-750ad9898290@oracle.com> That's OK, but it might be slightly better to do: 71 String output = new JavapTask(tb) 72 .options("-p", testClassesPath.resolve(this.getClass().getSimpleName() + "$SimpleInterface.class").toString()) 73 .run() + .writeAll() 74 .getOutput(Task.OutputKind.DIRECT); On 6/5/19 6:43 AM, Vicente Romero wrote: > Hi Jon, > > Thanks for your comments, what about [1]? > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8216261/webrev.01/ > > On 6/4/19 7:24 PM, Jonathan Gibbons wrote: >> >> >> On 06/04/2019 04:08 PM, Vicente Romero wrote: >>> Please review fix for [1] at [2]. This is an enhancement request >>> asking to make javap show if a method has the default modifier or not. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8216261 >>> [2] http://cr.openjdk.java.net/~vromero/8216261/webrev.00/ >> >> The main source change looks OK, >> >> The test could be improved: >> >> 1. If the test fails, nothing is printed to show what went wrong >> because a basic assertion of "incorrect output". What was the >> incorrect output?? It should *always* be the case for *all* tests >> that a test should try and give as much output as is reasonable when >> the test fails, to give the person analyzing the test failure as much >> as possible. >> >> 2. (Less important)? Personally, I think it is bad style to construct >> pathnames with string bashing. (I've been burnt too often!)? >> Generally it is better to use the File or Path API to construct >> filenames, and then use .toString(). >> >> -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jun 5 14:33:26 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Jun 2019 10:33:26 -0400 Subject: RFR: JDK-8216261: Javap ignores default modifier on interfaces In-Reply-To: <5b286fe1-c7ee-165d-c1b9-750ad9898290@oracle.com> References: <86bfa7f0-2ed9-3e0b-ef48-a6d7bfe76ce3@oracle.com> <21b83c7d-c753-f153-f9e7-90a8a672c952@oracle.com> <5b286fe1-c7ee-165d-c1b9-750ad9898290@oracle.com> Message-ID: <5dd42de5-7f2b-4bb3-0d37-65e2b4715333@oracle.com> OK I will fix that before pushing, Thanks for the review, Vicente On 6/5/19 9:46 AM, Jonathan Gibbons wrote: > > That's OK, but it might be slightly better to do: > > 71 String output = new JavapTask(tb) > 72 .options("-p", testClassesPath.resolve(this.getClass().getSimpleName() + "$SimpleInterface.class").toString()) > 73 .run() > + .writeAll() > 74 .getOutput(Task.OutputKind.DIRECT); > On 6/5/19 6:43 AM, Vicente Romero wrote: >> Hi Jon, >> >> Thanks for your comments, what about [1]? >> >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8216261/webrev.01/ >> >> On 6/4/19 7:24 PM, Jonathan Gibbons wrote: >>> >>> >>> On 06/04/2019 04:08 PM, Vicente Romero wrote: >>>> Please review fix for [1] at [2]. This is an enhancement request >>>> asking to make javap show if a method has the default modifier or not. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8216261 >>>> [2] http://cr.openjdk.java.net/~vromero/8216261/webrev.00/ >>> >>> The main source change looks OK, >>> >>> The test could be improved: >>> >>> 1. If the test fails, nothing is printed to show what went wrong >>> because a basic assertion of "incorrect output". What was the >>> incorrect output?? It should *always* be the case for *all* tests >>> that a test should try and give as much output as is reasonable when >>> the test fails, to give the person analyzing the test failure as >>> much as possible. >>> >>> 2. (Less important)? Personally, I think it is bad style to >>> construct pathnames with string bashing. (I've been burnt too >>> often!)? Generally it is better to use the File or Path API to >>> construct filenames, and then use .toString(). >>> >>> -- Jon >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Jun 5 18:39:55 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Jun 2019 14:39:55 -0400 Subject: RFR: JDK-8223942: Missing methods in ClientCodeWrapper$WrappedJavaFileManager Message-ID: <50491f09-7abe-a272-e10c-72a0026c575c@oracle.com> Please review fix for [1] at [2]. Some methods in javax.tools.JavaFileManager and javax.tools.StandardJavaFileManager were not overriden by wrapper classes provided at com.sun.tools.javac.api.ClientCodeWrapper. The fix is adding the missing methods plus providing a test to future check issues for the corresponding wrapping classes in the future. The test doesn't cover other wrapping classes. That could be achieve as an additional RFE if needed, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8223942 [2] http://cr.openjdk.java.net/~vromero/8223942/webrev.00/ From jonathan.gibbons at oracle.com Wed Jun 5 18:49:46 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 5 Jun 2019 11:49:46 -0700 Subject: RFR: JDK-8223942: Missing methods in ClientCodeWrapper$WrappedJavaFileManager In-Reply-To: <50491f09-7abe-a272-e10c-72a0026c575c@oracle.com> References: <50491f09-7abe-a272-e10c-72a0026c575c@oracle.com> Message-ID: <4d823733-715e-929e-709c-0da47c6b5928@oracle.com> Mostly excellent, and very clever, with one tiny nit: ? 65???????? Method[] declaredMethods = subClass.getMethods(); The name "declaredMethods" is confusing, because it might be thought to be related to subClass.getDeclaredMethods(), which it is not. I suggest a rename to either "allMethods" or just "methods". -- Jon On 06/05/2019 11:39 AM, Vicente Romero wrote: > Please review fix for [1] at [2]. Some methods in > javax.tools.JavaFileManager and javax.tools.StandardJavaFileManager > were not overriden by wrapper classes provided at > com.sun.tools.javac.api.ClientCodeWrapper. The fix is adding the > missing methods plus providing a test to future check issues for the > corresponding wrapping classes in the future. The test doesn't cover > other wrapping classes. That could be achieve as an additional RFE if > needed, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8223942 > [2] http://cr.openjdk.java.net/~vromero/8223942/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jun 5 21:34:37 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 05 Jun 2019 14:34:37 -0700 Subject: JDK 14 RFR of start of release updates for langtools, including CSRs JDK-8225363 and JDK-8225365 Message-ID: <5CF8356D.6060907@oracle.com> Hello, Per the JDK 13 schedule, its rampdown phase one and fork off of the main line is coming on June 13, 2019. Therefore, the time approaches to prepare jdk/jdk to become JDK 14. Please review the langtools portions of http://cr.openjdk.java.net/~darcy/jdk14-fork.2/ including the two CSRs: JDK-8214547: Add SourceVersion.RELEASE_14 CSR: https://bugs.openjdk.java.net/browse/JDK-8225363 JDK-8214548: Add source 14 and target 14 and release 14 to javac CSR: https://bugs.openjdk.java.net/browse/JDK-8225365 In general, the updates to javac, annotation processing, and langtools tests were as expected and consistent with other recent JDK N -> JDK (N+1) updates. The changes visitor classes were done using a short sed command. (Might be time to reconsider profile support.) Once the next build of JDK 13 is promoted, I'll regenerate the symbols data from the later build and do another round of build and test to flush out any new test failures sensitive to the version update. Thanks, -Joe From vicente.romero at oracle.com Wed Jun 5 23:50:59 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 5 Jun 2019 19:50:59 -0400 Subject: RFR: JDK-8225386: test for JDK-8216261 fails in Windows Message-ID: <62be04e5-c4dc-8216-9a50-8b5a1f0cf091@oracle.com> Please review the fix for [1] at [2]. Windows is not happy with the newline character introduced in a golden String in the fix for JDK-8216261. This fix is validating the output without using new line characters, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8225386 [2] http://cr.openjdk.java.net/~vromero/8225386/webrev.00/ From jonathan.gibbons at oracle.com Wed Jun 5 23:53:47 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 5 Jun 2019 16:53:47 -0700 Subject: RFR: JDK-8225386: test for JDK-8216261 fails in Windows In-Reply-To: <62be04e5-c4dc-8216-9a50-8b5a1f0cf091@oracle.com> References: <62be04e5-c4dc-8216-9a50-8b5a1f0cf091@oracle.com> Message-ID: <694b4036-18bc-a093-fb99-8e30b7f4f502@oracle.com> Looks good to me. -- Jon On 06/05/2019 04:50 PM, Vicente Romero wrote: > Please review the fix for [1] at [2]. Windows is not happy with the > newline character introduced in a golden String in the fix for > JDK-8216261. This fix is validating the output without using new line > characters, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8225386 > [2] http://cr.openjdk.java.net/~vromero/8225386/webrev.00/ From ronshapiro at google.com Thu Jun 6 01:41:48 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 5 Jun 2019 21:41:48 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: Friendly ping - is the first webrev ready for submission? On Thu, May 30, 2019, 7:09 PM Ron Shapiro wrote: > Do you have any other comments on the first webrev? Is there anything else > we need to do to submit that? > > On Wed, May 22, 2019 at 11:00 AM Ron Shapiro > wrote: > >> I think there still would be benefit in that as well, as I'm seeing that >> come up in other contexts (as referenced in the bug). >> >> On Wed, May 22, 2019 at 9:06 AM Jan Lahoda wrote: >> >>> Sorry, I was too busy last few days. >>> >>> I was peeking at some possible improvements, but I think I like Ron's >>> first (.00) patch - that caches what can be cached nicely. >>> >>> Looking at the testcase generated by Ron's reproducer using: >>> python test.py 7 >>> >>> and the (biggest) size of the outcome of: >>> types.membersClosure(site, false).getSymbolsByName(sym.name, cf) >>> >>> seems to be 13700 elements - which means the Scope lookup and iteration >>> runs ~13700 times, so avoiding these additional lookup costs seems like >>> a clear win. >>> >>> I have an idea that might speed up the iterations through deeply nested >>> CompoundScopes, although the effect of that in combination with Ron's is >>> going to be fairly limited, if any, I think. >>> >>> Jan >>> >>> On 22. 05. 19 12:24, Maurizio Cimadamore wrote: >>> > This doesn't work. You are basically relying on the order in which >>> > symbols are entered in the members closure scope. >>> > >>> > In simple example like these: >>> > >>> > class A { >>> > int m(List l) {return 0;} >>> > } >>> > >>> > class B extends A { >>> > int m(List l) {return 0;} >>> > } >>> > >>> > >>> > The logic you proposed will not work. That's because we first see B::m >>> - >>> > and 'symbolByName' is empty at that stage; so we add it there. Then we >>> > do another round and see A::m - but we don't really look there - given >>> > that we first check to see if the symbol we're considering (sym) is >>> > override-equivalent with B::m (the only symbol in symbolByName). And >>> > that happens to be the case, since they are the same symbol. So we >>> exit >>> > the loop, w/o having found any clash. >>> > >>> > In other words, symbolByName would need to also contain A::m for the >>> > code to see the clash - but that never happens; by the time A::m is >>> > added, is already too late. >>> > >>> > >>> > I think caching the result of >>> > >>> > types.membersClosure(site, false).getSymbolsByName(sym.name, cf) >>> > >>> > is a good measure. >>> > >>> > I'm a bit surprised that iteration is so slow (membersClosure is slow >>> to >>> > set up, but once you do it the results are cached). So, rather than >>> > tweaking the algorithm, I think it'd be better to investigate the >>> reason >>> > was to why asking a compound scope iterator is so slow, which then >>> would >>> > yield dividends for the rest of the code as well. >>> > >>> > Maurizio >>> > >>> > >>> > On 21/05/2019 21:21, Maurizio Cimadamore wrote: >>> >> >>> >> I see what you have done - I have to think about it a bit to see if I >>> >> can come up with some counter example. >>> >> >>> >> Thanks >>> >> Maurizio >>> >> >>> >> On 21/05/2019 17:39, Ron Shapiro wrote: >>> >>> Are the checks of the inner loop symmetrical? >>> >>> >>> >>> Currently it's checking m_i against (m_0..n - m_i ). This second >>> >>> webrev below would check it against just (m_0..i-1 ), which albeit >>> >>> still n^2, it divides by a factor of 2. >>> >>> >>> >>> (sorry if the subscripting here doesn't display correctly) >>> >>> >>> >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ >>> >>> >>> >>> This feels conceptually logical to me, but I'm not seeing a >>> >>> measurable change by it. It looks a little bit cleaner to me, but >>> I'm >>> >>> fine with either webrev given the benefits they both bring. >>> >>> >>> >>> I can take a look in another thread about speeding up CompoundScope >>> >>> iteration. >>> >>> >>> >>> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore >>> >>> >> >>> > wrote: >>> >>> >>> >>> >>> >>> On 21/05/2019 12:16, Ron Shapiro wrote: >>> >>>> I still think that something to optimize the actual ScopeImpl >>> >>>> Iterable is a worthwhile endeavor, as that would alleviate the >>> >>>> need to materialize here (and solve hopefully the other issues >>> >>>> I'm seeing), but I was having trouble figuring out how to do >>> >>>> that. This may be a good interim option without much cost. >>> >>> >>> >>> Sure - I'm not opposed to optimizing the iteration process - I >>> >>> was expressing my skepticism w.r.t. making checkOverrideClash >>> >>> simpler/non quadratic. >>> >>> >>> >>> Maurizio >>> >>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore >>> >>>> >> >>>> > wrote: >>> >>>> >>> >>>> I think your fix is a good one. We spent some cycles >>> >>>> optimizing this, a bit odd we have missed this :-) >>> >>>> >>> >>>> I'm very skeptical you can collapse into a single loop, as >>> >>>> this implement the logic in JLS 8.4.8.3 [1] which, as you >>> >>>> can see, is inherently quadratic (for each method, we have >>> >>>> to scan all methods with same name in supertypes to see if >>> >>>> there is an override clash). The algorithm that was there >>> >>>> before wasn't - and it lead to the wrong answers in tricky >>> >>>> cases - so while you can get 80% there with a non-quadratic >>> >>>> algorithm, you will miss issues by doing so. >>> >>>> >>> >>>> One thing that would help would be, instead, to limit the >>> >>>> analysis only in cases where it adds value - for instance, >>> >>>> if your hierarchy is just non-generic classes (as in your >>> >>>> example), then there's no way for you to accidentally >>> >>>> override a 'bridge' method, since no bridges will be >>> >>>> generated! But when looking at this, I couldn't find great >>> >>>> ways to detect these conditions w/o spending more time than >>> >>>> the check itself. >>> >>>> >>> >>>> [1] - >>> >>>> >>> https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 >>> >>>> >>> >>>> Maurizio >>> >>>> >>> >>>> On 20/05/2019 21:58, Ron Shapiro wrote: >>> >>>>> In the real world example, I'm seeing the 40s that was >>> >>>>> previously spent in Check.checkOverrideClashes drop to to >>> >>>>> 9.5s when using this patch. Of that 9.5, 8.9 is spent in >>> >>>>> iterating through the CompoundIterator and calling >>> >>>>> getSymbolsByName. >>> >>>>> >>> >>>>> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro >>> >>>>> > >>> wrote: >>> >>>>> >>> >>>>> This patch, which materializes the duplicate outer and >>> >>>>> inner Iterables first into a list. It removes the >>> >>>>> entire section of the CompoundIterator iteration from >>> >>>>> the profile. >>> >>>>> >>> >>>>> webrev: >>> >>>>> >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >>> >>>>> >>> >>>>> I'm not sure it's the absolutely correct solution as it >>> >>>>> possibly masks an underlying issue. >>> >>>>> >>> >>>>> I'm still seeing some time spent in >>> >>>>> MethodSymbol.overrides, Types.isSubSignature, and >>> >>>>> Types.memberType, all of which happen in the inner >>> >>>>> loop. If we can remove those and collapse the nested >>> >>>>> loops into one, then this solution isn't necessary and >>> >>>>> it would also solve that performance issue. >>> >>>>> >>> >>>>> On Fri, May 17, 2019 at 5:55 PM Ron Shapiro >>> >>>>> > >>> >>>>> wrote: >>> >>>>> >>> >>>>> I still have more to investigate to fully wrap my >>> >>>>> head around it, but I finally found a sample >>> >>>>> program that exhibits this. Filed a bug here: >>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8224161 >>> >>>>> >>> >>>>> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda >>> >>>>> >> >>>>> > wrote: >>> >>>>> >>> >>>>> Hi Ron, >>> >>>>> >>> >>>>> I am afraid it is hard to guess what is the >>> >>>>> problem without some >>> >>>>> testcase. So, at least to me, having a sample >>> >>>>> would be helpful. >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Jan >>> >>>>> >>> >>>>> On 17. 05. 19 0:41, Ron Shapiro wrote: >>> >>>>> > Hi, >>> >>>>> > >>> >>>>> > I'm observing a particularly bizarre >>> >>>>> compilation. It's a single file >>> >>>>> > with annotation processing, and the type that >>> >>>>> is being compiled and >>> >>>>> > processed has ~1000 declared and inherited >>> >>>>> methods combined. The total >>> >>>>> > compilation is 3 minutes, but 65% of the >>> >>>>> entire compilation is spent in >>> >>>>> > 3 methods: >>> >>>>> > >>> >>>>> >>> Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), >>> >>>>> >>> >>>>> > and Resolve.findField(). >>> >>>>> > >>> >>>>> > Looking at profiles, it looks like >>> >>>>> getSymbolsByName() is the major >>> >>>>> > culprit here. I initially thought the reason >>> >>>>> was that there were far too >>> >>>>> > many overloads (this type had >600 >>> >>>>> overloads...) and that that was >>> >>>>> > causing a bad regression for the >>> >>>>> pseudo-hashmap that ScopeImpl uses. >>> >>>>> > However, renaming the methods did not >>> >>>>> alleviate the build pain and these >>> >>>>> > methods continue to be taking long amounts of >>> >>>>> time. >>> >>>>> > >>> >>>>> > I was wondering what could be done to improve >>> >>>>> the performance of this >>> >>>>> > code. It seemed to me that something like a >>> >>>>> Map> >>> >>>>> > could be a reasonable+modern replacement for >>> >>>>> this table, which would >>> >>>>> > naturally have a fast getSymbolsForName() >>> >>>>> implementation. I'm having >>> >>>>> > some trouble implementing it correctly, and I >>> >>>>> believe it's partially >>> >>>>> > related to not fully understanding some of >>> >>>>> the semantics of the class. >>> >>>>> > >>> >>>>> > Does what I wrote make sense to anyone, and >>> >>>>> maybe spark a lightbulb? >>> >>>>> > >>> >>>>> > I'm trying to put together a repro in case >>> >>>>> that helps, but I'm not 100% >>> >>>>> > sure I even understand what the regression >>> >>>>> case is. >>> >>>>> > >>> >>>>> > Thanks for you help! >>> >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jun 6 14:11:39 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 6 Jun 2019 16:11:39 +0200 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: <556fa4eb-cdf2-ef8a-1586-59c4bb67b76f@oracle.com> References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> <6906dd66-0893-f479-d916-e95850059884@oracle.com> <556fa4eb-cdf2-ef8a-1586-59c4bb67b76f@oracle.com> Message-ID: Hi, Based on some more feedback, I've updated the patch with: -a warning about the use of yield in cases where an error would be reported if preview was enabled -improvements to errors reported -renames of a couple of methods, to better reflect what they do Full patch: http://cr.openjdk.java.net/~jlahoda/8223303/webrev.02/ Delta from previous iteration: http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.01.02/ How does this look? Thanks, Jan On 30. 05. 19 16:19, Maurizio Cimadamore wrote: > As for the unification, let's discuss that separately and let's focus on > the first webrev for now. I think what I'd like to see there (if > anything) is also an attempt to unify "findJumpTargetNoError" for both > cases, so that we can use same logic in both visitYield and visitReturn. > > Maurizio > > On 30/05/2019 15:15, Maurizio Cimadamore wrote: >> >> Looks great! You only missed one rename in Resolve: >> >> private Symbol checkVarType(Symbol bestSoFar, Name name) { >> >> I guess that should be checkRestrictedType, or something like it? >> >> Maurizio >> >> On 30/05/2019 14:58, Jan Lahoda wrote: >>> Hi, >>> >>> Thanks for all the comments so far. I've uploaded a new version of >>> the patch here: >>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.01/ >>> delta webrev from the previous state: >>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.00.01/ >>> >>> The changes are: >>> -adjustment to the updated spec, where yield is a restricted >>> identifier (this required generalization of current error messages >>> for var) >>> -placing yield-related elements at the end for changes in >>> com.sun.source, to better reflect alphabet order >>> -simplification of error code from >>> compiler.err.break.complex.value.no.switch.expression? to >>> compiler.err.no.switch.expression. >>> >>> This patch does not include unification of the >>> AttrContext.returnResult/yieldResult, but I've done that here: >>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.unified.attrcontext.result/ >>> >>> >>> There is a small issue in return handling, as return needs to look >>> and the enclosing Envs to see if there is a switch expression or not. >>> But if this looks OK, I can fold it into the main patch. >>> >>> Further feedback is welcome! >>> >>> Thanks, >>> ??? Jan >>> >>> On 28. 05. 19 12:09, Maurizio Cimadamore wrote: >>>> Hi >>>> I thought a bit more about the code (the Attr part) and I have few >>>> more comments: >>>> >>>> * I don't immediately see the need for having another field in >>>> AttrContext. After all we could rename/repurpose the existing >>>> resultInfo. >>>> >>>> * of course, to do that, we need a way to detect whether we're >>>> inside a switch expression, but that should be possible by looking >>>> at the env? Or you could even exploit the check context, after all, >>>> the check context for a case arm is always created in the >>>> switchExpressionContext method. >>>> >>>> * it seems like when you are in visitYield, you should first check >>>> if there's a target for the yield - and if there's not you log an >>>> error. That will also remove some dependencies from yieldResult. >>>> >>>> Of course you can also leave the code as is. It just occurred that >>>> having a separate ResultInfo specifically for yield (or break with >>>> value, as the code was also there before) seemed a bit redundant. >>>> But I can also believe that the current approach leads to more >>>> sensible code. >>>> >>>> >>>> Also, one small comment inline below. >>>> >>>> >>>> On 28/05/2019 10:37, Jan Lahoda wrote: >>>>> On 28. 05. 19 11:11, Maurizio Cimadamore wrote: >>>>>> Looks good. Just few comments/questions: >>>>> >>>>> Thanks! >>>>> >>>>>> >>>>>> * I think the error keys in compiler.properties could use some >>>>>> renaming. e.g. >>>>>> >>>>>> compiler.err.break.complex.value.no.switch.expression -> >>>>>> compiler.err.no.switch.expression >>>>>> compiler.err.break.complex.value.no.switch.expression.qualify -> >>>>>> compiler.err.no.switch.expression.qualify >>>>> >>>>> Sure, will do. >>>>> >>>>>> >>>>>> * what is the new Log.hasErrorOn - and why has Flow been changed >>>>>> to use it? >>>>> >>>>> Consider code like this: >>>>> --- >>>>> public class Y2 { >>>>> ??? private void t() { >>>>> ??????? break; >>>>> ??? } >>>>> } >>>>> --- >>>>> >>>>> When compiled like this: >>>>> javac -XDdev -XDshould-stop.at=FLOW Y2.java >>>> >>>> ah ok - it's the failover logic. I was trying to think of an example >>>> w/o shouldStopAt and could not think of much. >>>> >>>> Thanks >>>> Maurizio >>>> >>>>> It will crash: >>>>> --- >>>>> Y2.java:4: error: break outside switch or loop >>>>> ???????????? break; >>>>> ???????????? ^ >>>>> 1 error >>>>> An exception has occurred in the compiler (11.0.3). Please file a >>>>> bug against the Java compiler via the Java bug reporting page >>>>> (http://bugreport.java.com) after checking the Bug Database >>>>> (http://bugs.java.com) for duplicates. Include your program and the >>>>> following diagnostic in your report. Thank you. >>>>> java.lang.AssertionError >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >>>>> >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >>>>> ??????? at >>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >>>>> ??????? at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>>> ??????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>>> --- >>>>> >>>>> The reason is that javac asserts that it has properly processed the >>>>> exits - but here the original code is broken, and an error has >>>>> already been reported and this given spot, so it seems safe to not >>>>> crash javac here. >>>>> >>>>> Thanks, >>>>> ??? Jan >>>>> >>>>>> >>>>>> Thanks >>>>>> Maurizio >>>>>> >>>>>> >>>>>> It seems like a whitespace got remove here? >>>>>> >>>>>> On 24/05/2019 15:48, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to ask for a review of changes to update javac to follow >>>>>>> the current spec for switch expressions, in particular the break >>>>>>> -> yield change: >>>>>>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >>>>>>> >>>>>>> JBS: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223305 >>>>>>> >>>>>>> Feedback is welcome! >>>>>>> >>>>>>> Thanks, >>>>>>> ?? Jan From ronshapiro at google.com Thu Jun 6 14:26:05 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Thu, 6 Jun 2019 10:26:05 -0400 Subject: Scope's usage of Filter Message-ID: Hi, I'm trying to experiment solutions to https://bugs.openjdk.java.net/browse/JDK-8224161, and the intertwining of Filter in Scope is making it hard for me to (a) understand the code and (b) attempt a refactoring. I feel that the code will be simpler if we extract the filtering logic to Filter.java itself, which can have a Filter.filter(Iterable) method that uses Iterators.createFilterIterator. That seems like an appropriate place to be filtering so that Scope has fewer responsibilities. I was wondering if this idea resonates. If so, I'll send a webrev as a prefactoring. Thanks, Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Thu Jun 6 14:35:49 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 6 Jun 2019 16:35:49 +0200 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: Hi Ron, I think we should run it through the perf tests, just to be sure (and I didn't have time for that yet), but otherwise, I think that simple change looks useful to me. Thanks, Jan On 06. 06. 19 3:41, Ron Shapiro wrote: > Friendly ping - is the first webrev ready for submission? > > On Thu, May 30, 2019, 7:09 PM Ron Shapiro > wrote: > > Do you have any other comments on the first webrev? Is there > anything else we need to do to submit that? > > On Wed, May 22, 2019 at 11:00 AM Ron Shapiro > wrote: > > I think there still would be benefit in that as well, as I'm > seeing that come up in other contexts (as referenced in the bug). > > On Wed, May 22, 2019 at 9:06 AM Jan Lahoda > > wrote: > > Sorry, I was too busy last few days. > > I was peeking at some possible improvements, but I think I > like Ron's > first (.00) patch - that caches what can be cached nicely. > > Looking at the testcase generated by Ron's reproducer using: > python test.py 7 > > and the (biggest) size of the outcome of: > types.membersClosure(site, false).getSymbolsByName(sym.name > , cf) > > seems to be 13700 elements - which means the Scope lookup > and iteration > runs ~13700 times, so avoiding these additional lookup costs > seems like > a clear win. > > I have an idea that might speed up the iterations through > deeply nested > CompoundScopes, although the effect of that in combination > with Ron's is > going to be fairly limited, if any, I think. > > Jan > > On 22. 05. 19 12:24, Maurizio Cimadamore wrote: > > This doesn't work. You are basically relying on the order > in which > > symbols are entered in the members closure scope. > > > > In simple example like these: > > > > class A { > >? ??? int m(List l) {return 0;} > > } > > > > class B extends A { > >? ?? int m(List l) {return 0;} > > } > > > > > > The logic you proposed will not work. That's because we > first see B::m - > > and 'symbolByName' is empty at that stage; so we add it > there. Then we > > do another round and see A::m - but we don't really look > there - given > > that we first check to see if the symbol we're > considering (sym) is > > override-equivalent with B::m (the only symbol in > symbolByName). And > > that happens to be the case, since they are the same > symbol. So we exit > > the loop, w/o having found any clash. > > > > In other words, symbolByName would need to also contain > A::m for the > > code to see the clash - but that never happens; by the > time A::m is > > added, is already too late. > > > > > > I think caching the result of > > > > types.membersClosure(site, > false).getSymbolsByName(sym.name , cf) > > > > is a good measure. > > > > I'm a bit surprised that iteration is so slow > (membersClosure is slow to > > set up, but once you do it the results are cached). So, > rather than > > tweaking the algorithm, I think it'd be better to > investigate the reason > > was to why asking a compound scope iterator is so slow, > which then would > > yield dividends for the rest of the code as well. > > > > Maurizio > > > > > > On 21/05/2019 21:21, Maurizio Cimadamore wrote: > >> > >> I see what you have done - I have to think about it a > bit to see if I > >> can come up with some counter example. > >> > >> Thanks > >> Maurizio > >> > >> On 21/05/2019 17:39, Ron Shapiro wrote: > >>> Are the checks of the inner loop symmetrical? > >>> > >>> Currently it's checking m_i against (m_0..n - m_i ). > This second > >>> webrev below would check it against just?(m_0..i-1 ), > which albeit > >>> still n^2, it divides by a factor of 2. > >>> > >>> (sorry if the subscripting here doesn't display correctly) > >>> > >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ > >>> > >>> This feels conceptually logical to me, but I'm not > seeing a > >>> measurable?change by it. It looks a little bit cleaner > to me, but I'm > >>> fine with either webrev given the benefits they both bring. > >>> > >>> I can take a look in another thread about speeding up > CompoundScope > >>> iteration. > >>> > >>> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore > >>> > >>> >> wrote: > >>> > >>> > >>>? ? ?On 21/05/2019 12:16, Ron Shapiro wrote: > >>>>? ? ?I still think that something to optimize the > actual ScopeImpl > >>>>? ? ?Iterable is a worthwhile endeavor, as that would > alleviate the > >>>>? ? ?need to materialize here (and solve hopefully the > other issues > >>>>? ? ?I'm seeing), but I was having trouble figuring out > how to do > >>>>? ? ?that. This may be a good interim option without > much cost. > >>> > >>>? ? ?Sure - I'm not opposed to optimizing the iteration > process - I > >>>? ? ?was expressing my skepticism w.r.t. making > checkOverrideClash > >>>? ? ?simpler/non quadratic. > >>> > >>>? ? ?Maurizio > >>> > >>>> > >>>> > >>>> > >>>>? ? ?On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore > >>>>? ? ? > >>>>? ? ? >> wrote: > >>>> > >>>>? ? ? ? ?I think your fix is a good one. We spent some > cycles > >>>>? ? ? ? ?optimizing this, a bit odd we have missed this :-) > >>>> > >>>>? ? ? ? ?I'm very skeptical you can collapse into a > single loop, as > >>>>? ? ? ? ?this implement the logic in JLS 8.4.8.3 [1] > which, as you > >>>>? ? ? ? ?can see, is inherently quadratic (for each > method, we have > >>>>? ? ? ? ?to scan all methods with same name in > supertypes to see if > >>>>? ? ? ? ?there is an override clash). The algorithm > that was there > >>>>? ? ? ? ?before wasn't - and it lead to the wrong > answers in tricky > >>>>? ? ? ? ?cases - so while you can get 80% there with a > non-quadratic > >>>>? ? ? ? ?algorithm, you will miss issues by doing so. > >>>> > >>>>? ? ? ? ?One thing that would help would be, instead, > to limit the > >>>>? ? ? ? ?analysis only in cases where it adds value - > for instance, > >>>>? ? ? ? ?if your hierarchy is just non-generic classes > (as in your > >>>>? ? ? ? ?example), then there's no way for you to > accidentally > >>>>? ? ? ? ?override a 'bridge' method, since no bridges > will be > >>>>? ? ? ? ?generated! But when looking at this, I > couldn't find great > >>>>? ? ? ? ?ways to detect these conditions w/o spending > more time than > >>>>? ? ? ? ?the check itself. > >>>> > >>>>? ? ? ? ?[1] - > >>>> > https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 > >>>> > >>>>? ? ? ? ?Maurizio > >>>> > >>>>? ? ? ? ?On 20/05/2019 21:58, Ron Shapiro wrote: > >>>>>? ? ? ? ?In the real world example, I'm seeing the 40s > that was > >>>>>? ? ? ? ?previously spent in > Check.checkOverrideClashes drop to to > >>>>>? ? ? ? ?9.5s when using this patch. Of that 9.5, 8.9 > is spent in > >>>>>? ? ? ? ?iterating through the CompoundIterator and > calling > >>>>>? ? ? ? ?getSymbolsByName. > >>>>> > >>>>>? ? ? ? ?On Mon, May 20, 2019 at 4:34 PM Ron Shapiro > >>>>>? ? ? ? ? >> wrote: > >>>>> > >>>>>? ? ? ? ? ? ?This patch, which materializes the > duplicate outer and > >>>>>? ? ? ? ? ? ?inner Iterables first into a list. It > removes the > >>>>>? ? ? ? ? ? ?entire section of the CompoundIterator > iteration from > >>>>>? ? ? ? ? ? ?the profile. > >>>>> > >>>>>? ? ? ? ? ? ?webrev: > >>>>> > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html > >>>>> > >>>>>? ? ? ? ? ? ?I'm not sure it's the absolutely correct > solution as it > >>>>>? ? ? ? ? ? ?possibly masks an underlying issue. > >>>>> > >>>>>? ? ? ? ? ? ?I'm still seeing some time spent in > >>>>>? ? ? ? ? ? ?MethodSymbol.overrides, > Types.isSubSignature, and > >>>>>? ? ? ? ? ? ?Types.memberType, all of which happen in > the inner > >>>>>? ? ? ? ? ? ?loop. If we can remove those and collapse > the nested > >>>>>? ? ? ? ? ? ?loops into one, then this solution isn't > necessary and > >>>>>? ? ? ? ? ? ?it would also solve that performance issue. > >>>>> > >>>>>? ? ? ? ? ? ?On Fri, May 17, 2019 at 5:55 PM Ron Shapiro > >>>>>? ? ? ? ? ? ? >> > >>>>>? ? ? ? ? ? ?wrote: > >>>>> > >>>>>? ? ? ? ? ? ? ? ?I still have more to investigate to > fully wrap my > >>>>>? ? ? ? ? ? ? ? ?head around it, but I finally found a > sample > >>>>>? ? ? ? ? ? ? ? ?program that exhibits this. Filed a > bug here: > >>>>> https://bugs.openjdk.java.net/browse/JDK-8224161 > >>>>> > >>>>>? ? ? ? ? ? ? ? ?On Fri, May 17, 2019 at 11:21 AM Jan > Lahoda > >>>>>? ? ? ? ? ? ? ? ? > >>>>>? ? ? ? ? ? ? ? ? >> wrote: > >>>>> > >>>>>? ? ? ? ? ? ? ? ? ? ?Hi Ron, > >>>>> > >>>>>? ? ? ? ? ? ? ? ? ? ?I am afraid it is hard to guess > what is the > >>>>>? ? ? ? ? ? ? ? ? ? ?problem without some > >>>>>? ? ? ? ? ? ? ? ? ? ?testcase. So, at least to me, > having a sample > >>>>>? ? ? ? ? ? ? ? ? ? ?would be helpful. > >>>>> > >>>>>? ? ? ? ? ? ? ? ? ? ?Thanks, > >>>>>? ? ? ? ? ? ? ? ? ? ?? ? ?Jan > >>>>> > >>>>>? ? ? ? ? ? ? ? ? ? ?On 17. 05. 19 0:41, Ron Shapiro > wrote: > >>>>>? ? ? ? ? ? ? ? ? ? ?> Hi, > >>>>>? ? ? ? ? ? ? ? ? ? ?> > >>>>>? ? ? ? ? ? ? ? ? ? ?> I'm observing a particularly > bizarre > >>>>>? ? ? ? ? ? ? ? ? ? ?compilation. It's a single file > >>>>>? ? ? ? ? ? ? ? ? ? ?> with annotation processing, and > the type that > >>>>>? ? ? ? ? ? ? ? ? ? ?is being compiled and > >>>>>? ? ? ? ? ? ? ? ? ? ?> processed has ~1000 declared > and inherited > >>>>>? ? ? ? ? ? ? ? ? ? ?methods combined. The total > >>>>>? ? ? ? ? ? ? ? ? ? ?> compilation is 3 minutes, but > 65% of the > >>>>>? ? ? ? ? ? ? ? ? ? ?entire compilation is spent in > >>>>>? ? ? ? ? ? ? ? ? ? ?> 3 methods: > >>>>>? ? ? ? ? ? ? ? ? ? ?> > >>>>> > ?Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), > >>>>> > >>>>>? ? ? ? ? ? ? ? ? ? ?> and?Resolve.findField(). > >>>>>? ? ? ? ? ? ? ? ? ? ?> > >>>>>? ? ? ? ? ? ? ? ? ? ?> Looking at profiles, it looks like > >>>>>? ? ? ? ? ? ? ? ? ? ?getSymbolsByName() is the major > >>>>>? ? ? ? ? ? ? ? ? ? ?> culprit here. I initially > thought the reason > >>>>>? ? ? ? ? ? ? ? ? ? ?was that there were far too > >>>>>? ? ? ? ? ? ? ? ? ? ?> many overloads (this type had >600 > >>>>>? ? ? ? ? ? ? ? ? ? ?overloads...) and that that was > >>>>>? ? ? ? ? ? ? ? ? ? ?> causing a bad regression for the > >>>>>? ? ? ? ? ? ? ? ? ? ?pseudo-hashmap that ScopeImpl uses. > >>>>>? ? ? ? ? ? ? ? ? ? ?> However, renaming the methods > did not > >>>>>? ? ? ? ? ? ? ? ? ? ?alleviate the build pain and these > >>>>>? ? ? ? ? ? ? ? ? ? ?> methods continue to be taking > long amounts of > >>>>>? ? ? ? ? ? ? ? ? ? ?time. > >>>>>? ? ? ? ? ? ? ? ? ? ?> > >>>>>? ? ? ? ? ? ? ? ? ? ?> I was wondering what could be > done to improve > >>>>>? ? ? ? ? ? ? ? ? ? ?the performance of this > >>>>>? ? ? ? ? ? ? ? ? ? ?> code. It seemed to me that > something like a > >>>>>? ? ? ? ? ? ? ? ? ? ?Map> > >>>>>? ? ? ? ? ? ? ? ? ? ?> could be a reasonable+modern > replacement for > >>>>>? ? ? ? ? ? ? ? ? ? ?this table, which would > >>>>>? ? ? ? ? ? ? ? ? ? ?> naturally have a fast > getSymbolsForName() > >>>>>? ? ? ? ? ? ? ? ? ? ?implementation. I'm having > >>>>>? ? ? ? ? ? ? ? ? ? ?> some trouble implementing it > correctly, and I > >>>>>? ? ? ? ? ? ? ? ? ? ?believe it's partially > >>>>>? ? ? ? ? ? ? ? ? ? ?> related to not fully > understanding some of > >>>>>? ? ? ? ? ? ? ? ? ? ?the semantics of the class. > >>>>>? ? ? ? ? ? ? ? ? ? ?> > >>>>>? ? ? ? ? ? ? ? ? ? ?> Does what I wrote make sense to > anyone, and > >>>>>? ? ? ? ? ? ? ? ? ? ?maybe spark a lightbulb? > >>>>>? ? ? ? ? ? ? ? ? ? ?> > >>>>>? ? ? ? ? ? ? ? ? ? ?> I'm trying to put together a > repro in case > >>>>>? ? ? ? ? ? ? ? ? ? ?that helps, but I'm not 100% > >>>>>? ? ? ? ? ? ? ? ? ? ?> sure I even understand what the > regression > >>>>>? ? ? ? ? ? ? ? ? ? ?case is. > >>>>>? ? ? ? ? ? ? ? ? ? ?> > >>>>>? ? ? ? ? ? ? ? ? ? ?> Thanks for you help! > >>>>> > From maurizio.cimadamore at oracle.com Thu Jun 6 17:49:56 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 6 Jun 2019 18:49:56 +0100 Subject: RFR: JDK-8223305: Compiler support for Switch Expressions In-Reply-To: References: <2da5609b-2d85-8722-2738-735621c5473a@oracle.com> <402eda72-0c7b-cd5a-84e1-b57f45ba4e66@oracle.com> <29a44f63-c457-255d-bde2-8f0345620acc@oracle.com> <6906dd66-0893-f479-d916-e95850059884@oracle.com> <556fa4eb-cdf2-ef8a-1586-59c4bb67b76f@oracle.com> Message-ID: <9453bdf1-dc45-1b0d-5713-c9d688f43668@oracle.com> Looks good! Maurizio On 06/06/2019 15:11, Jan Lahoda wrote: > Hi, > > Based on some more feedback, I've updated the patch with: > -a warning about the use of yield in cases where an error would be > reported if preview was enabled > -improvements to errors reported > -renames of a couple of methods, to better reflect what they do > > Full patch: > http://cr.openjdk.java.net/~jlahoda/8223303/webrev.02/ > > Delta from previous iteration: > http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.01.02/ > > How does this look? > > Thanks, > ??? Jan > > On 30. 05. 19 16:19, Maurizio Cimadamore wrote: >> As for the unification, let's discuss that separately and let's focus >> on the first webrev for now. I think what I'd like to see there (if >> anything) is also an attempt to unify "findJumpTargetNoError" for >> both cases, so that we can use same logic in both visitYield and >> visitReturn. >> >> Maurizio >> >> On 30/05/2019 15:15, Maurizio Cimadamore wrote: >>> >>> Looks great! You only missed one rename in Resolve: >>> >>> ????? private Symbol checkVarType(Symbol bestSoFar, Name name) { >>> >>> I guess that should be checkRestrictedType, or something like it? >>> >>> Maurizio >>> >>> On 30/05/2019 14:58, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Thanks for all the comments so far. I've uploaded a new version of >>>> the patch here: >>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.01/ >>>> delta webrev from the previous state: >>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.delta.00.01/ >>>> >>>> The changes are: >>>> -adjustment to the updated spec, where yield is a restricted >>>> identifier (this required generalization of current error messages >>>> for var) >>>> -placing yield-related elements at the end for changes in >>>> com.sun.source, to better reflect alphabet order >>>> -simplification of error code from >>>> compiler.err.break.complex.value.no.switch.expression? to >>>> compiler.err.no.switch.expression. >>>> >>>> This patch does not include unification of the >>>> AttrContext.returnResult/yieldResult, but I've done that here: >>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.unified.attrcontext.result/ >>>> >>>> >>>> There is a small issue in return handling, as return needs to look >>>> and the enclosing Envs to see if there is a switch expression or >>>> not. But if this looks OK, I can fold it into the main patch. >>>> >>>> Further feedback is welcome! >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>> On 28. 05. 19 12:09, Maurizio Cimadamore wrote: >>>>> Hi >>>>> I thought a bit more about the code (the Attr part) and I have few >>>>> more comments: >>>>> >>>>> * I don't immediately see the need for having another field in >>>>> AttrContext. After all we could rename/repurpose the existing >>>>> resultInfo. >>>>> >>>>> * of course, to do that, we need a way to detect whether we're >>>>> inside a switch expression, but that should be possible by looking >>>>> at the env? Or you could even exploit the check context, after >>>>> all, the check context for a case arm is always created in the >>>>> switchExpressionContext method. >>>>> >>>>> * it seems like when you are in visitYield, you should first check >>>>> if there's a target for the yield - and if there's not you log an >>>>> error. That will also remove some dependencies from yieldResult. >>>>> >>>>> Of course you can also leave the code as is. It just occurred that >>>>> having a separate ResultInfo specifically for yield (or break with >>>>> value, as the code was also there before) seemed a bit redundant. >>>>> But I can also believe that the current approach leads to more >>>>> sensible code. >>>>> >>>>> >>>>> Also, one small comment inline below. >>>>> >>>>> >>>>> On 28/05/2019 10:37, Jan Lahoda wrote: >>>>>> On 28. 05. 19 11:11, Maurizio Cimadamore wrote: >>>>>>> Looks good. Just few comments/questions: >>>>>> >>>>>> Thanks! >>>>>> >>>>>>> >>>>>>> * I think the error keys in compiler.properties could use some >>>>>>> renaming. e.g. >>>>>>> >>>>>>> compiler.err.break.complex.value.no.switch.expression -> >>>>>>> compiler.err.no.switch.expression >>>>>>> compiler.err.break.complex.value.no.switch.expression.qualify -> >>>>>>> compiler.err.no.switch.expression.qualify >>>>>> >>>>>> Sure, will do. >>>>>> >>>>>>> >>>>>>> * what is the new Log.hasErrorOn - and why has Flow been changed >>>>>>> to use it? >>>>>> >>>>>> Consider code like this: >>>>>> --- >>>>>> public class Y2 { >>>>>> ??? private void t() { >>>>>> ??????? break; >>>>>> ??? } >>>>>> } >>>>>> --- >>>>>> >>>>>> When compiled like this: >>>>>> javac -XDdev -XDshould-stop.at=FLOW Y2.java >>>>> >>>>> ah ok - it's the failover logic. I was trying to think of an >>>>> example w/o shouldStopAt and could not think of much. >>>>> >>>>> Thanks >>>>> Maurizio >>>>> >>>>>> It will crash: >>>>>> --- >>>>>> Y2.java:4: error: break outside switch or loop >>>>>> ???????????? break; >>>>>> ???????????? ^ >>>>>> 1 error >>>>>> An exception has occurred in the compiler (11.0.3). Please file a >>>>>> bug against the Java compiler via the Java bug reporting page >>>>>> (http://bugreport.java.com) after checking the Bug Database >>>>>> (http://bugs.java.com) for duplicates. Include your program and >>>>>> the following diagnostic in your report. Thank you. >>>>>> java.lang.AssertionError >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitMethodDef(Flow.java:518) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:866) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.visitClassDef(Flow.java:488) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:398) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:759) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Flow$AliveAnalyzer.analyzeTree(Flow.java:751) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:216) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1401) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1375) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973) >>>>>> >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:311) >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:170) >>>>>> ??????? at >>>>>> jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:57) >>>>>> ??????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:43) >>>>>> --- >>>>>> >>>>>> The reason is that javac asserts that it has properly processed >>>>>> the exits - but here the original code is broken, and an error >>>>>> has already been reported and this given spot, so it seems safe >>>>>> to not crash javac here. >>>>>> >>>>>> Thanks, >>>>>> ??? Jan >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Maurizio >>>>>>> >>>>>>> >>>>>>> It seems like a whitespace got remove here? >>>>>>> >>>>>>> On 24/05/2019 15:48, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'd like to ask for a review of changes to update javac to >>>>>>>> follow the current spec for switch expressions, in particular >>>>>>>> the break -> yield change: >>>>>>>> http://cr.openjdk.java.net/~gbierman/jep354-jls-20190524.html >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8223303/webrev.00/ >>>>>>>> >>>>>>>> JBS: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223305 >>>>>>>> >>>>>>>> Feedback is welcome! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> ?? Jan From jnape09 at gmail.com Thu Jun 6 19:31:10 2019 From: jnape09 at gmail.com (John Napier) Date: Thu, 6 Jun 2019 14:31:10 -0500 Subject: Inference Bug related to parametric polymorphism unification Message-ID: Hi all, The following code compiles against oracle64-1.8.0.162 but fails on both openjdk64-11.0.2 and oracle64-12.0.1: public static class Example { public static class Pair implements Map.Entry { private final A a; private final B b; public Pair(A a, B b) { this.a = a; this.b = b; } @Override public A getKey() { return a; } @Override public B getValue() { return b; } @Override public B setValue(B value) { throw new UnsupportedOperationException(); } } public static C destructure(BiFunction fn, Map.Entry entry) { return fn.apply(entry.getKey(), entry.getValue()); } public static void main(String[] args) { Map.Entry entry = new Pair<>("foo", "bar"); // ill-typed String inferred = destructure((x, y) -> x + y, destructure(Pair::new, entry)); // well-typed String ascribed = destructure((x, y) -> x + y, destructure(Pair::new, entry)); } } Before submitting more bugs of this same ilk, albeit with slight variations in occurrence, I must ask: this is not the intentional modern behavior, correct? Inference should still work as illustrated above, right? Cheers, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Thu Jun 6 19:33:04 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 6 Jun 2019 16:33:04 -0300 Subject: RFR: JDK-8225448 String::translateEscapes javadoc has accessibility issues Message-ID: <2A02726E-703C-4FA4-B2C9-E626F9A45A26@oracle.com> Please review these changes. A table in the javadoc for String::translateEscapes was missing some tags. Thank you. Cheers, -- Jim webrev: http://cr.openjdk.java.net/~jlaskey/8225448/webrev-01/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8225448 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jun 6 19:47:35 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 6 Jun 2019 12:47:35 -0700 Subject: RFR: JDK-8225448 String::translateEscapes javadoc has accessibility issues In-Reply-To: <2A02726E-703C-4FA4-B2C9-E626F9A45A26@oracle.com> References: <2A02726E-703C-4FA4-B2C9-E626F9A45A26@oracle.com> Message-ID: <6c5fa2e7-c997-e430-882c-e9bfb7fc8a03@oracle.com> Looks good to me, and to doccheck. -- Jon On 06/06/2019 12:33 PM, Jim Laskey wrote: > Please review these changes. A table in the javadoc for > String::translateEscapes was missing some tags. > > Thank you. > > Cheers, > > -- Jim > > > webrev: > http://cr.openjdk.java.net/~jlaskey/8225448/webrev-01/index.html > > jbs: https://bugs.openjdk.java.net/browse/JDK-8225448 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jun 6 21:52:18 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 6 Jun 2019 14:52:18 -0700 Subject: JDK 13 RFR of JDK-8222369: ExecutableElement.getReceiverType returns null instead of NOTYPE Message-ID: Hello, Please review the fix for ??? JDK-8222369: ExecutableElement.getReceiverType returns null instead of NOTYPE ??? http://cr.openjdk.java.net/~darcy/8222369.0/ In the javac implementation, the getReceiverType method is pulled up to the root of the hierarchy and is defined to return null. The hashing in tools/javac/ElementStructureTest will also need to be adjusted when this fix goes in since that test does factor the result of getReceiver type into its hash. Thanks, -Joe From joe.darcy at oracle.com Fri Jun 7 00:38:05 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 6 Jun 2019 17:38:05 -0700 Subject: JDK 13 RFR of JDK-8225465: Add @jls tags to receiver type methods Message-ID: <07b2021a-b17b-2326-da55-da0fbadf381b@oracle.com> Hello, Receiver types are an obscure corner of the Java language added as part of type annotations. The API methods in core reflection and javax.lang.model that refer to receiver types should cross-reference the relevant JLS sections using @jls javadoc tags. Please review the patch below to add those @jls tags. Thanks, -Joe diff -r 830ca7b43b95 src/java.base/share/classes/java/lang/reflect/Executable.java --- a/src/java.base/share/classes/java/lang/reflect/Executable.java Thu Jun 06 12:24:44 2019 -0300 +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java Thu Jun 06 17:34:22 2019 -0700 @@ -673,6 +673,10 @@ ????? * @return an object representing the receiver type of the method or ????? * constructor represented by this {@code Executable} or {@code null} if ????? * this {@code Executable} can not have a receiver parameter +???? * +???? * @jls 8.4 Method Declarations +???? * @jls 8.4.1 Formal Parameters +???? * @jls 8.8 Constructor Declarations ????? */ ???? public AnnotatedType getAnnotatedReceiverType() { ???????? if (Modifier.isStatic(this.getModifiers())) diff -r 830ca7b43b95 src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java --- a/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java Thu Jun 06 12:24:44 2019 -0300 +++ b/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java Thu Jun 06 17:34:22 2019 -0700 @@ -95,6 +95,10 @@ ????? * ????? * @return the receiver type of this executable ????? * @since 1.8 +???? * +???? * @jls 8.4 Method Declarations +???? * @jls 8.4.1 Formal Parameters +???? * @jls 8.8 Constructor Declarations ????? */ ???? TypeMirror getReceiverType(); diff -r 830ca7b43b95 src/java.compiler/share/classes/javax/lang/model/type/ExecutableType.java --- a/src/java.compiler/share/classes/javax/lang/model/type/ExecutableType.java Thu Jun 06 12:24:44 2019 -0300 +++ b/src/java.compiler/share/classes/javax/lang/model/type/ExecutableType.java Thu Jun 06 17:34:22 2019 -0700 @@ -92,6 +92,10 @@ ????? * ????? * @return the receiver type of this executable ????? * @since 1.8 +???? * +???? * @jls 8.4 Method Declarations +???? * @jls 8.4.1 Formal Parameters +???? * @jls 8.8 Constructor Declarations ????? */ ???? TypeMirror getReceiverType(); From lance.andersen at oracle.com Fri Jun 7 00:39:24 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 6 Jun 2019 20:39:24 -0400 Subject: JDK 13 RFR of JDK-8225465: Add @jls tags to receiver type methods In-Reply-To: <07b2021a-b17b-2326-da55-da0fbadf381b@oracle.com> References: <07b2021a-b17b-2326-da55-da0fbadf381b@oracle.com> Message-ID: <820B4CAD-2A46-4E4D-8ABC-17B4CD1A8A17@oracle.com> +1 > On Jun 6, 2019, at 8:38 PM, Joe Darcy wrote: > > Hello, > > Receiver types are an obscure corner of the Java language added as part of type annotations. The API methods in core reflection and javax.lang.model that refer to receiver types should cross-reference the relevant JLS sections using @jls javadoc tags. > > Please review the patch below to add those @jls tags. > > Thanks, > > -Joe > > > diff -r 830ca7b43b95 src/java.base/share/classes/java/lang/reflect/Executable.java > --- a/src/java.base/share/classes/java/lang/reflect/Executable.java Thu Jun 06 12:24:44 2019 -0300 > +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java Thu Jun 06 17:34:22 2019 -0700 > @@ -673,6 +673,10 @@ > * @return an object representing the receiver type of the method or > * constructor represented by this {@code Executable} or {@code null} if > * this {@code Executable} can not have a receiver parameter > + * > + * @jls 8.4 Method Declarations > + * @jls 8.4.1 Formal Parameters > + * @jls 8.8 Constructor Declarations > */ > public AnnotatedType getAnnotatedReceiverType() { > if (Modifier.isStatic(this.getModifiers())) > diff -r 830ca7b43b95 src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java > --- a/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java Thu Jun 06 12:24:44 2019 -0300 > +++ b/src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java Thu Jun 06 17:34:22 2019 -0700 > @@ -95,6 +95,10 @@ > * > * @return the receiver type of this executable > * @since 1.8 > + * > + * @jls 8.4 Method Declarations > + * @jls 8.4.1 Formal Parameters > + * @jls 8.8 Constructor Declarations > */ > TypeMirror getReceiverType(); > > diff -r 830ca7b43b95 src/java.compiler/share/classes/javax/lang/model/type/ExecutableType.java > --- a/src/java.compiler/share/classes/javax/lang/model/type/ExecutableType.java Thu Jun 06 12:24:44 2019 -0300 > +++ b/src/java.compiler/share/classes/javax/lang/model/type/ExecutableType.java Thu Jun 06 17:34:22 2019 -0700 > @@ -92,6 +92,10 @@ > * > * @return the receiver type of this executable > * @since 1.8 > + * > + * @jls 8.4 Method Declarations > + * @jls 8.4.1 Formal Parameters > + * @jls 8.8 Constructor Declarations > */ > TypeMirror getReceiverType(); > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From ronshapiro at google.com Fri Jun 7 15:54:51 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Fri, 7 Jun 2019 11:54:51 -0400 Subject: RFR 8225482: Refactoring: Remove Filter from Scope.getSymbols(|ByName) signatures Message-ID: Hi, Please review this refactoring to remove Filter from Scope.getSymbols() and Scope.getSymbolsByName(). webrev: http://cr.openjdk.java.net/~ronsh/8225482/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8225482 There is one failing jtreg test, and I'm trying to understand what it is. I'm not sure how to debug it, but I'll report back with anything I find. tools/javac/processing/model/completionfailure/MissingClassFile.java com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: ./lib-classes/pkg/A$I.class illegal start of class file Please remove or make sure it appears in the correct subdirectory of the classpath. at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:296) -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Jun 10 00:03:25 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 9 Jun 2019 17:03:25 -0700 Subject: JDK 13 RFR of JDK-8225495: "Note whether returned annotations are declaration annotations or type annotations." Message-ID: Hello, Please review the changes to address: ??? JDK-8225495: "Note whether returned annotations are declaration annotations or type annotations." ??? webrev: http://cr.openjdk.java.net/~darcy/8225495.0/ ??? specdiff: http://cr.openjdk.java.net/~darcy/8225495.0.specdiff/overview-summary.html Conceptually, the change is just to add ??? "Note that any annotations returned by this method are (declaration|type) annotations." to the appropriate methods, three for element modeling hierarchy and three for the type modeling hierarchy. This requires adding various method overrides to host the specialized javadoc. Thanks, -Joe From maurizio.cimadamore at oracle.com Mon Jun 10 11:33:35 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 10 Jun 2019 12:33:35 +0100 Subject: Inference Bug related to parametric polymorphism unification In-Reply-To: References: Message-ID: Hi John I've been trying to reproduce, but for me the example fails even in 8... That said, I agree that there could be something fishy here; I did some experiments with variations of your example, and it looks like javac can undrestand what the typing of `destructure(Pair::new, entry)` is, in isolation - you can see that by adding this statement: Object o = (String)destructure(Pair::new, entry); This will trigger this error: error: incompatible types: Pair cannot be converted to String Object o = (String)destructure(Pair::new, entry); Which seems to confirm that javac is indeed capable of inferring A and B to String and take it from there. My suspicion is that when you nest these expressions inside each other, you create a 'bigger' inference context, where two expressions cannot be evaluated (we call them 'stuck'): * Pair::new (indirect method reference) * (x, y) -> x + y (implicit lambda) To break this tie, the compiler has to choose which inference variable to instantiate first: the outer { A, B }, or the innermost ones? This choice is, at its core, driven by the spec 18.5.2 (see [1]). In your example we have these inference variables: * A#inner, B#inner and C#inner (from innermost invocation of 'destructure') * A#outer, B#outer and C#outer (from outermost invocation of 'destructure') This analysis is based on the concept of input/output inference variable - in this case: * A#inner,B#inner influence C#inner * A#outer,B#outer influence C#outer So far, if we had to choose between these two constraints, the choice would be non-deterministic (as the two input/output constraints are mirroring each other). But there's another dependency here: * C#inner <: Entry Now, from a programmer perspective, looking at the way the code is written, it's clear we'd like solution of C#inner to influence A#outer, B#outer. But I don't think that's the way the spec works. In this case the spec says that C#inner 'depends' on A#outer, C#outer. So we really have no way That's because the result of the innermost call to 'destructure' is passed to the outermost call, so the inferred type for C#inner can affect the inferred Entry. So, we are basically left with what I think is an non-deterministic choice between eagerly resolving { A#inner, B#inner } or { A#outer, B#outer }. Unfortunately, picking the former makes the code pass, whereas picking the latter makes compilation fail (because at that time we don't know any better than just instantiating A#outer and B#outer to Object). If this is the issue, inference could to a better job, by either looking at presence of other 'more meaningful' bounds on {A#inner, B#inner} (although defining 'more meaningful might be problematic). Or it could just give precedence to innermost variables in case of a tie, which is a rule that I think programmers will find natural. Currently though, these 'extensions' are not part of the JLS - so the behavior here is, essentially, unspecified. At the same time, there's also an argument to be had as to whether the code here isn't inherently buggy - essentially, { A, B, C } in the 'destructure' method are all independent variables so, in a way, the problem is *underconstrained* (e.g. there's no real objective choice for which variable to solve first, other than resorting to heuristics, whose mileage can vary). Note that your second call works simply because, by adding the explicit type param on the method reference receiver, you make the method reference 'direct' meaning its type is evaluated *ahead* of the lambda. Basically you told the compiler which of the two 'stuck' expression should be solved first. @Dan - is this something that has been discussed before in spec-land? Cheers Maurizio [1] - https://docs.oracle.com/javase/specs/jls/se12/html/jls-18.html#jls-18.5.2.2 On 06/06/2019 20:31, John Napier wrote: > Hi all, > > The following code compiles against oracle64-1.8.0.162 but fails on > both openjdk64-11.0.2 and oracle64-12.0.1: > > public static class Example { > > ? ? ? ? public static class Pair implements Map.Entry { > ? ? ? ? ? ? private final A a; > ? ? ? ? ? ? private final B b; > > ? ? ? ? ? ? public Pair(A a, B b) { > ? ? ? ? ? ? ? ? this.a = a; > ? ? ? ? ? ? ? ? this.b = b; > ? ? ? ? ? ? } > > ? ? ? ? ? ? @Override > ? ? ? ? ? ? public A getKey() { > ? ? ? ? ? ? ? ? return a; > ? ? ? ? ? ? } > > ? ? ? ? ? ? @Override > ? ? ? ? ? ? public B getValue() { > ? ? ? ? ? ? ? ? return b; > ? ? ? ? ? ? } > > ? ? ? ? ? ? @Override > ? ? ? ? ? ? public B setValue(B value) { > ? ? ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? ? ? } > ? ? ? ? } > > ? ? ? ? public static C destructure(BiFunction fn, > Map.Entry entry) { > ? ? ? ? ? ? return fn.apply(entry.getKey(), entry.getValue()); > ? ? ? ? } > > ? ? ? ? public static void main(String[] args) { > ? ? ? ? ? ? Map.Entry entry = new Pair<>("foo", "bar"); > > ? ? ? ? ? ? // ill-typed > ? ? ? ? ? ? String inferred = destructure((x, y) -> x + y, > destructure(Pair::new, entry)); > > ? ? ? ? ? ? // well-typed > ? ? ? ? ? ? String ascribed = destructure((x, y) -> x + y, > destructure(Pair::new, entry)); > ? ? ? ? } > ? ? } > > Before submitting more bugs of this same ilk, albeit with slight > variations in occurrence, I must ask: this is not the intentional > modern behavior, correct? Inference should still work as illustrated > above, right? > > Cheers, > > -John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnape09 at gmail.com Mon Jun 10 15:19:58 2019 From: jnape09 at gmail.com (John Napier) Date: Mon, 10 Jun 2019 10:19:58 -0500 Subject: Inference Bug related to parametric polymorphism unification In-Reply-To: References: Message-ID: Hey Maurizio, My apologies; you?re right that the example doesn?t compile against 8 - in my attempts to shrink the code that I have failing locally to the minimal test case, I apparently lost something essential in the translation. In the interest of avoiding further confusion, here is the full, complicated example that compiles against 1.8 but fails to compile without explicit type ascriptions in both 11 and 12: public static class Example { public static Iterable map(Function fn, Iterable as) { throw new UnsupportedOperationException(); } public static Iterable flatten(Iterable> aas) { throw new UnsupportedOperationException(); } public static B foldLeft(BiFunction fn, B b, Iterable as) { throw new UnsupportedOperationException(); } public static C destructure(BiFunction fn, Map.Entry entry) { throw new UnsupportedOperationException(); } public static Function, C> destructure( BiFunction fn) { throw new UnsupportedOperationException(); } public static Function> pair(K fn) { throw new UnsupportedOperationException(); } public static final class Sink { public Sink add(String k, String v) { throw new UnsupportedOperationException(); } } public static void main(String[] args) { Map> headers = Collections.emptyMap(); // type-checks in 8, fails in 11/12 foldLeft((acc, h) -> destructure(acc::add, h), new Sink(), flatten(map(destructure((name, values) -> map(pair(name), values)), headers.entrySet()))); } } Again, so sorry for the confusion. Same question as before: should *that* code continue to compile, or is it correct that it fails to compile in 11 / 12? Cheers, John On Jun 10, 2019, at 6:33 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: Hi John I've been trying to reproduce, but for me the example fails even in 8... That said, I agree that there could be something fishy here; I did some experiments with variations of your example, and it looks like javac can undrestand what the typing of `destructure(Pair::new, entry)` is, in isolation - you can see that by adding this statement: Object o = (String)destructure(Pair::new, entry); This will trigger this error: error: incompatible types: Pair cannot be converted to String Object o = (String)destructure(Pair::new, entry); Which seems to confirm that javac is indeed capable of inferring A and B to String and take it from there. My suspicion is that when you nest these expressions inside each other, you create a 'bigger' inference context, where two expressions cannot be evaluated (we call them 'stuck'): * Pair::new (indirect method reference) * (x, y) -> x + y (implicit lambda) To break this tie, the compiler has to choose which inference variable to instantiate first: the outer { A, B }, or the innermost ones? This choice is, at its core, driven by the spec 18.5.2 (see [1]). In your example we have these inference variables: * A#inner, B#inner and C#inner (from innermost invocation of 'destructure') * A#outer, B#outer and C#outer (from outermost invocation of 'destructure') This analysis is based on the concept of input/output inference variable - in this case: * A#inner,B#inner influence C#inner * A#outer,B#outer influence C#outer So far, if we had to choose between these two constraints, the choice would be non-deterministic (as the two input/output constraints are mirroring each other). But there's another dependency here: * C#inner <: Entry Now, from a programmer perspective, looking at the way the code is written, it's clear we'd like solution of C#inner to influence A#outer, B#outer. But I don't think that's the way the spec works. In this case the spec says that C#inner 'depends' on A#outer, C#outer. So we really have no way That's because the result of the innermost call to 'destructure' is passed to the outermost call, so the inferred type for C#inner can affect the inferred Entry. So, we are basically left with what I think is an non-deterministic choice between eagerly resolving { A#inner, B#inner } or { A#outer, B#outer }. Unfortunately, picking the former makes the code pass, whereas picking the latter makes compilation fail (because at that time we don't know any better than just instantiating A#outer and B#outer to Object). If this is the issue, inference could to a better job, by either looking at presence of other 'more meaningful' bounds on {A#inner, B#inner} (although defining 'more meaningful might be problematic). Or it could just give precedence to innermost variables in case of a tie, which is a rule that I think programmers will find natural. Currently though, these 'extensions' are not part of the JLS - so the behavior here is, essentially, unspecified. At the same time, there's also an argument to be had as to whether the code here isn't inherently buggy - essentially, { A, B, C } in the 'destructure' method are all independent variables so, in a way, the problem is *underconstrained* (e.g. there's no real objective choice for which variable to solve first, other than resorting to heuristics, whose mileage can vary). Note that your second call works simply because, by adding the explicit type param on the method reference receiver, you make the method reference 'direct' meaning its type is evaluated *ahead* of the lambda. Basically you told the compiler which of the two 'stuck' expression should be solved first. @Dan - is this something that has been discussed before in spec-land? Cheers Maurizio [1] - https://docs.oracle.com/javase/specs/jls/se12/html/jls-18.html#jls-18.5.2.2 On 06/06/2019 20:31, John Napier wrote: Hi all, The following code compiles against oracle64-1.8.0.162 but fails on both openjdk64-11.0.2 and oracle64-12.0.1: public static class Example { public static class Pair implements Map.Entry { private final A a; private final B b; public Pair(A a, B b) { this.a = a; this.b = b; } @Override public A getKey() { return a; } @Override public B getValue() { return b; } @Override public B setValue(B value) { throw new UnsupportedOperationException(); } } public static C destructure(BiFunction fn, Map.Entry entry) { return fn.apply(entry.getKey(), entry.getValue()); } public static void main(String[] args) { Map.Entry entry = new Pair<>("foo", "bar"); // ill-typed String inferred = destructure((x, y) -> x + y, destructure(Pair::new, entry)); // well-typed String ascribed = destructure((x, y) -> x + y, destructure(Pair::new, entry)); } } Before submitting more bugs of this same ilk, albeit with slight variations in occurrence, I must ask: this is not the intentional modern behavior, correct? Inference should still work as illustrated above, right? Cheers, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Jun 10 17:48:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 10 Jun 2019 10:48:38 -0700 Subject: JDK 13 RFR of JDK-8225532: Upddate source enums to describe 12 and 13 language features Message-ID: <4d8e9fdf-3a6b-794c-d2c2-1961d6b3d195@oracle.com> Hello, Please review the small comment improvement below ahead of the JDK 13 fork: ??? JDK-8225532: Upddate source enums to describe 12 and 13 language features Patch below; thanks, -Joe diff -r 4cf21c5c956a src/java.compiler/share/classes/javax/lang/model/SourceVersion.java --- a/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Mon Jun 10 09:41:09 2019 -0700 +++ b/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Mon Jun 10 10:47:48 2019 -0700 @@ -58,8 +58,8 @@ ????? *?? 9: modules, small cleanups to 1.7 and 1.8 changes ????? *? 10: local-variable type inference (var) ????? *? 11: local-variable syntax for lambda parameters -???? *? 12: no changes (switch expressions in preview) -???? *? 13: TBD +???? *? 12: no changes (switch expressions were in preview) +???? *? 13: no changes (switch expressions and text blocks in preview) ????? */ ???? /** diff -r 4cf21c5c956a src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java Mon Jun 10 09:41:09 2019 -0700 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java Mon Jun 10 10:47:48 2019 -0700 @@ -84,10 +84,13 @@ ???? /** 1.11 local-variable syntax for lambda parameters */ ???? JDK11("11"), -??? /** 12 covers the to be determined language features that will be added in JDK 12. */ +??? /** 12, no language features, switch expression were in preview */ ???? JDK12("12"), -??? /** 13 covers the to be determined language features that will be added in JDK 13. */ +??? /** +???? * 13, no language features, revised switch expressions in preview +???? * along with text blocks +???? */ ???? JDK13("13"); ???? private static final Context.Key sourceKey = new Context.Key<>(); From alex.buckley at oracle.com Mon Jun 10 18:55:29 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 10 Jun 2019 11:55:29 -0700 Subject: JDK 13 RFR of JDK-8225495: "Note whether returned annotations are declaration annotations or type annotations." In-Reply-To: References: Message-ID: <5CFEA7A1.5020700@oracle.com> On 6/9/2019 5:03 PM, Joe Darcy wrote: > Please review the changes to address: > > JDK-8225495: "Note whether returned annotations are declaration > annotations or type annotations." > webrev: http://cr.openjdk.java.net/~darcy/8225495.0/ > specdiff: > http://cr.openjdk.java.net/~darcy/8225495.0.specdiff/overview-summary.html > > Conceptually, the change is just to add > > "Note that any annotations returned by this method are > (declaration|type) annotations." > > to the appropriate methods, three for element modeling hierarchy and > three for the type modeling hierarchy. This requires adding various > method overrides to host the specialized javadoc. Adding all these method specs to call out "declaration annotations" or "type annotations" seems (1) a bit clunky, and (2) a bit hopeful given that neither term is defined in jx.l.m.AnnotatedConstruct, Element, TypeMirror. Recommend an upgrade to jx.l.m.AnnotatedConstruct: ----- Represents a construct that can be annotated. ~~A construct is either an element or a type. Annotations on an element are on a declaration, whereas annotations on a type are on a specific use of a type name.~~ ++A CONSTRUCT IS EITHER AN _ELEMENT_, REPRESENTING A DECLARATION IN A PROGRAM, OR A _TYPE_, REPRESENTING A SPECIFIC USE OF A TYPE WITHIN A DECLARATION, STATEMENT, OR EXPRESSION IN A PROGRAM.++ [I WAS GOING TO SAY "IN SOURCE CODE", THEN I RECALLED JEP 119 AND HOW JX.L.M IS NOT LIMITED TO MODELING SOURCE STRUCTURES.] ++AN ELEMENT EXPOSES THE ANNOTATIONS THAT APPEAR ON A DECLARATION IN A PROGRAM, KNOWN AS _DECLARATION ANNOTATIONS_. A TYPE EXPOSES THE ANNOTATIONS THAT APPEAR ON A SPECIFIC USE OF A TYPE IN A PROGRAM, KNOWN AS _TYPE ANNOTATIONS_.++ The terms ... are used throughout this interface to describe precisely which annotations ++(WHETHER DECLARATION ANNOTATIONS OR TYPE ANNOTATIONS)++ are returned by the methods ~~defined herein~~ ++OF THIS INTERFACE.++ [PULL THE FOLLOWING INTO THIS PARA.] In the definitions below, an annotation A has an annotation type AT; IF AT is a repeatable annotation type, THEN the type of the containing annotation is ATC. Annotation A is directly present on a construct C if either: ----- In what follows, the phrases "explicitly declared" and "implicitly declared" appear. These are JLS terms that don't work well once we highlight "declaration annotations" in this interface spec. Thankfully, they only appear in the "directly present" definition; all further definitions are careful to vector through it. Here is the original text, with further comments after it: ----- - A is explicitly or implicitly declared as applying to the source code representation of C. Typically, if exactly one annotation of type AT appears in the source code of representation of C, then A is explicitly declared as applying to C. If there are multiple annotations of type AT present on C, then if AT is repeatable annotation type, an annotation of type ATC is implicitly declared on C. ----- 1. "source code representation"? Not "representation in a program"? 2. "A is explicitly declared on C", sure. "A is implicitly declared on C", huh? The point of jx.l.m.AnnotatedConstruct is to align with j.l.r.AnnotatedElement, where the directly-present case is uninterested in container annotations. And consider this: "A is ... implicitly declared" doesn't connect with "...an annotation of type ATC is implicitly declared", A isn't of type ATC. The formatting of the four definitions is painful. Please add newlines, and use bold+italics on these words: either: either: both: either: Add: @jls 9.7.4 Where Annotations May Appear @jls 9.7.5 Multiple Annotations of the Same Type Finally, the interface specs for Element and TypeMirror are ready to refer to declaration annotations and type annotations: - Element: Represents a ~~program element~~ ["A FOO REPRESENTS A FOO" IS NOT ADDING ANY MEANING] ++DECLARATION IN A JAVA PROGRAM++, such as a module, package, class, method, OR VARIABLE. Each element represents a static, language-level construct, RATHER THAN a runtime construct of the ~~virtual machine~~ ++JAVA VIRTUAL MACHINE WITH CAPITAL J V M++. [I DON'T KNOW HOW TO INTERPRET THE PRECEDING SENTENCE WHEN CLASS FILE CONTENT IS EXPOSED VIA THIS API.] ++THE METHODS INHERITED FROM ANNOTATEDCONSTRUCT EXPOSE ANY DECLARATION ANNOTATIONS THAT APPEAR ON THIS DECLARATION.++ - Type: ... first paragraph ... ++THE METHODS INHERITED FROM ANNOTATEDCONSTRUCT EXPOSE ANY TYPE ANNOTATIONS THAT APPEAR ON THE SPECIFIC USE OF A TYPE MODELED BY THIS TYPEMIRROR OBJECT.++ [YUK. THE PROBLEM IS THAT "REPRESENTS TYPES IN THE JAVA PROGRAMMING LANGUAGE." DOESN'T GET TO THE HEART OF "THIS MIRROR REPRESENTS A SPECIFIC UTTERANCE OF A TYPE AT SOME POINT IN THE PROGRAM."] Alex From joe.darcy at oracle.com Mon Jun 10 21:25:42 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 10 Jun 2019 14:25:42 -0700 Subject: JDK 13 RFR of JDK-8225532: Upddate source enums to describe 12 and 13 language features In-Reply-To: <4d8e9fdf-3a6b-794c-d2c2-1961d6b3d195@oracle.com> References: <4d8e9fdf-3a6b-794c-d2c2-1961d6b3d195@oracle.com> Message-ID: <5CFECAD6.4000505@oracle.com> Responding to some off-list feedback, On 6/10/2019 10:48 AM, Joe Darcy wrote: > > /** > diff -r 4cf21c5c956a > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java > Mon Jun 10 09:41:09 2019 -0700 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java > Mon Jun 10 10:47:48 2019 -0700 > @@ -84,10 +84,13 @@ > /** 1.11 local-variable syntax for lambda parameters */ > JDK11("11"), > > - /** 12 covers the to be determined language features that will be > added in JDK 12. */ > + /** 12, no language features, switch expression were in preview */ > JDK12("12"), > > - /** 13 covers the to be determined language features that will be > added in JDK 13. */ > + /** > + * 13, no language features, revised switch expressions in preview > + * along with text blocks > + */ > JDK13("13"); Will upgrade the comma to a semi-colon: " 12, no language features; switch expression were in preview" "13, no language features; text blocks and revised switch expressions in preview Thanks, -Joe From jonathan.gibbons at oracle.com Mon Jun 10 22:55:11 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 10 Jun 2019 15:55:11 -0700 Subject: JDK 13 RFR of JDK-8225532: Upddate source enums to describe 12 and 13 language features In-Reply-To: <5CFECAD6.4000505@oracle.com> References: <4d8e9fdf-3a6b-794c-d2c2-1961d6b3d195@oracle.com> <5CFECAD6.4000505@oracle.com> Message-ID: +1 semicolons for the win! On 06/10/2019 02:25 PM, Joseph D. Darcy wrote: > Responding to some off-list feedback, > > On 6/10/2019 10:48 AM, Joe Darcy wrote: >> >> ???? /** >> diff -r 4cf21c5c956a >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java >> Mon Jun 10 09:41:09 2019 -0700 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java >> Mon Jun 10 10:47:48 2019 -0700 >> @@ -84,10 +84,13 @@ >> ???? /** 1.11 local-variable syntax for lambda parameters */ >> ???? JDK11("11"), >> >> -??? /** 12 covers the to be determined language features that will >> be added in JDK 12. */ >> +??? /** 12, no language features, switch expression were in preview */ >> ???? JDK12("12"), >> >> -??? /** 13 covers the to be determined language features that will >> be added in JDK 13. */ >> +??? /** >> +???? * 13, no language features, revised switch expressions in preview >> +???? * along with text blocks >> +???? */ >> ???? JDK13("13"); > > Will upgrade the comma to a semi-colon: > > ??? " 12, no language features; switch expression were in preview" > ??? "13, no language features; text blocks and revised switch > expressions in preview > > Thanks, > > -Joe From jan.lahoda at oracle.com Tue Jun 11 15:07:04 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 11 Jun 2019 17:07:04 +0200 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> Message-ID: <578889a9-68d9-6f83-aac6-9fd9b2b8fddd@oracle.com> Hi Bernard, Looks good to me. Any comments, Maurizio? Thanks, Jan On 19. 05. 19 16:46, B. Blaser wrote: > Hi Jan and Maurizio, > > I've updated the webrev [1] as you both suggested: > * 'unwindBreak()' commented to warn for a possible dead code marking. > * 'reloadStackBeforeSwitchExpr()' added to factorize the stack reloading. > * 'test4()' below added to Jan's test cases. > > Does this look good to both of you (tier1 is OK)? > > Thanks, > Bernard > > [1] http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.01/ > > > On Sat, 11 May 2019 at 13:29, B. Blaser wrote: >> >> Hi Jan and Maurizio, >> >> Thanks for both feedback. >> >> On Thu, 9 May 2019 at 14:35, Maurizio Cimadamore >> wrote: >>> >>> Hi, >>> I look at the code and discussed it offline with Jan extensively. >>> >>> I think the approach looks good, and it is inspired by what we already >>> do for return expressions (where we use intermediate locals to store >>> return expressions in case there's a finalizer). >>> >>> The only problem I have with this code is that it implicitly relies, in >>> the conditional context case, on the fact that, should the finalizer >>> complete abnormally (isAlive = false), then Code will refuse to emit any >>> additional statements (such as the loads required to restore the stack >>> state). >>> >>> I think the is brittle, and might bite us back in case we revisit this >>> code and add another statement whose behavior is NOT guarded by isAlive. >>> >>> So, I suggest either adding explicit comments, saying that unwindBreak >>> might affect isAlive and, as a result, following statements might not be >>> generated - or, wrap the code in an explicit `if (isAlive)` guard, as >>> done in the other branch of the visitBreak code. >> >> As first step, I guess I'd be more for simply adding a comment but we >> can still rework and consolidate this part later on if necessary. >> >>> As bonus point, since >>> we're restoring the stack in three different places, perhaps we can >>> factor the restoring code out to some common function. >> >> Of course ;-) >> >>> Cheers >>> Maurizio >>> >>> >>> On 09/05/2019 09:34, Jan Lahoda wrote: >>>> Hi Bernard, >>>> >>>> I apologize for late reply. >> >> No problem, I'm rather busy too... >> >>>> Thanks for the patch, looks OK to me, but >>>> I guess it would be good to have another review on this. >>>> >>>> Would it be possible to enhance the tests with the testcase below (and >>>> any other testcases needed)? >> >> Yes, I'll also include this one. >> >> Cheers, >> Bernard >> >> >>>> Thanks, >>>> Jan >>>> >>>> On 27. 03. 19 19:20, B. Blaser wrote: >>>>> Hi, >>>>> >>>>> Please review the following fix for [1] which has already been >>>>> discussed in the corresponding thread [2]: >>>>> >>>>> http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.00/ >>>>> >>>>> It includes the variant I suggested to store the switch expression >>>>> result in a single temporary variable along with Jan's solution for >>>>> switch expressions used as conditions. Note that I had to do a tiny >>>>> correction to the latter (see 'code.resolve(value.trueJumps)') to make >>>>> the following example succeed: >>>>> >>>>> public static void test4() { >>>>> if (!switch (0) { >>>>> default -> { >>>>> try { >>>>> break switch(0) { default -> true; }; >>>>> } >>>>> finally { >>>>> break false; >>>>> } >>>>> } >>>>> }) { >>>>> System.out.println("OK!"); >>>>> } >>>>> } >>>>> >>>>> It also includes Jan's test case. >>>>> >>>>> Any feedback is welcome (tier1 is OK). >>>>> >>>>> Thanks, >>>>> Bernard >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8220018 >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013073.html >>>>> From ronshapiro at google.com Tue Jun 11 18:25:21 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 11 Jun 2019 14:25:21 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <7b6553d4-5081-2459-62ab-beaaec1b3737@oracle.com> <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: Is there a way I can run those? Any way I can help get this in? On Thu, Jun 6, 2019 at 10:36 AM Jan Lahoda wrote: > Hi Ron, > > I think we should run it through the perf tests, just to be sure (and I > didn't have time for that yet), but otherwise, I think that simple > change looks useful to me. > > Thanks, > Jan > > On 06. 06. 19 3:41, Ron Shapiro wrote: > > Friendly ping - is the first webrev ready for submission? > > > > On Thu, May 30, 2019, 7:09 PM Ron Shapiro > > wrote: > > > > Do you have any other comments on the first webrev? Is there > > anything else we need to do to submit that? > > > > On Wed, May 22, 2019 at 11:00 AM Ron Shapiro > > wrote: > > > > I think there still would be benefit in that as well, as I'm > > seeing that come up in other contexts (as referenced in the bug). > > > > On Wed, May 22, 2019 at 9:06 AM Jan Lahoda > > > wrote: > > > > Sorry, I was too busy last few days. > > > > I was peeking at some possible improvements, but I think I > > like Ron's > > first (.00) patch - that caches what can be cached nicely. > > > > Looking at the testcase generated by Ron's reproducer using: > > python test.py 7 > > > > and the (biggest) size of the outcome of: > > types.membersClosure(site, false).getSymbolsByName(sym.name > > , cf) > > > > seems to be 13700 elements - which means the Scope lookup > > and iteration > > runs ~13700 times, so avoiding these additional lookup costs > > seems like > > a clear win. > > > > I have an idea that might speed up the iterations through > > deeply nested > > CompoundScopes, although the effect of that in combination > > with Ron's is > > going to be fairly limited, if any, I think. > > > > Jan > > > > On 22. 05. 19 12:24, Maurizio Cimadamore wrote: > > > This doesn't work. You are basically relying on the order > > in which > > > symbols are entered in the members closure scope. > > > > > > In simple example like these: > > > > > > class A { > > > int m(List l) {return 0;} > > > } > > > > > > class B extends A { > > > int m(List l) {return 0;} > > > } > > > > > > > > > The logic you proposed will not work. That's because we > > first see B::m - > > > and 'symbolByName' is empty at that stage; so we add it > > there. Then we > > > do another round and see A::m - but we don't really look > > there - given > > > that we first check to see if the symbol we're > > considering (sym) is > > > override-equivalent with B::m (the only symbol in > > symbolByName). And > > > that happens to be the case, since they are the same > > symbol. So we exit > > > the loop, w/o having found any clash. > > > > > > In other words, symbolByName would need to also contain > > A::m for the > > > code to see the clash - but that never happens; by the > > time A::m is > > > added, is already too late. > > > > > > > > > I think caching the result of > > > > > > types.membersClosure(site, > > false).getSymbolsByName(sym.name , cf) > > > > > > is a good measure. > > > > > > I'm a bit surprised that iteration is so slow > > (membersClosure is slow to > > > set up, but once you do it the results are cached). So, > > rather than > > > tweaking the algorithm, I think it'd be better to > > investigate the reason > > > was to why asking a compound scope iterator is so slow, > > which then would > > > yield dividends for the rest of the code as well. > > > > > > Maurizio > > > > > > > > > On 21/05/2019 21:21, Maurizio Cimadamore wrote: > > >> > > >> I see what you have done - I have to think about it a > > bit to see if I > > >> can come up with some counter example. > > >> > > >> Thanks > > >> Maurizio > > >> > > >> On 21/05/2019 17:39, Ron Shapiro wrote: > > >>> Are the checks of the inner loop symmetrical? > > >>> > > >>> Currently it's checking m_i against (m_0..n - m_i ). > > This second > > >>> webrev below would check it against just (m_0..i-1 ), > > which albeit > > >>> still n^2, it divides by a factor of 2. > > >>> > > >>> (sorry if the subscripting here doesn't display > correctly) > > >>> > > >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ > > >>> > > >>> This feels conceptually logical to me, but I'm not > > seeing a > > >>> measurable change by it. It looks a little bit cleaner > > to me, but I'm > > >>> fine with either webrev given the benefits they both > bring. > > >>> > > >>> I can take a look in another thread about speeding up > > CompoundScope > > >>> iteration. > > >>> > > >>> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore > > >>> > > > >>> > >> wrote: > > >>> > > >>> > > >>> On 21/05/2019 12:16, Ron Shapiro wrote: > > >>>> I still think that something to optimize the > > actual ScopeImpl > > >>>> Iterable is a worthwhile endeavor, as that would > > alleviate the > > >>>> need to materialize here (and solve hopefully the > > other issues > > >>>> I'm seeing), but I was having trouble figuring out > > how to do > > >>>> that. This may be a good interim option without > > much cost. > > >>> > > >>> Sure - I'm not opposed to optimizing the iteration > > process - I > > >>> was expressing my skepticism w.r.t. making > > checkOverrideClash > > >>> simpler/non quadratic. > > >>> > > >>> Maurizio > > >>> > > >>>> > > >>>> > > >>>> > > >>>> On Tue, May 21, 2019, 5:59 AM Maurizio Cimadamore > > >>>> > > > >>>> > >> wrote: > > >>>> > > >>>> I think your fix is a good one. We spent some > > cycles > > >>>> optimizing this, a bit odd we have missed this > :-) > > >>>> > > >>>> I'm very skeptical you can collapse into a > > single loop, as > > >>>> this implement the logic in JLS 8.4.8.3 [1] > > which, as you > > >>>> can see, is inherently quadratic (for each > > method, we have > > >>>> to scan all methods with same name in > > supertypes to see if > > >>>> there is an override clash). The algorithm > > that was there > > >>>> before wasn't - and it lead to the wrong > > answers in tricky > > >>>> cases - so while you can get 80% there with a > > non-quadratic > > >>>> algorithm, you will miss issues by doing so. > > >>>> > > >>>> One thing that would help would be, instead, > > to limit the > > >>>> analysis only in cases where it adds value - > > for instance, > > >>>> if your hierarchy is just non-generic classes > > (as in your > > >>>> example), then there's no way for you to > > accidentally > > >>>> override a 'bridge' method, since no bridges > > will be > > >>>> generated! But when looking at this, I > > couldn't find great > > >>>> ways to detect these conditions w/o spending > > more time than > > >>>> the check itself. > > >>>> > > >>>> [1] - > > >>>> > > > https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 > > >>>> > > >>>> Maurizio > > >>>> > > >>>> On 20/05/2019 21:58, Ron Shapiro wrote: > > >>>>> In the real world example, I'm seeing the 40s > > that was > > >>>>> previously spent in > > Check.checkOverrideClashes drop to to > > >>>>> 9.5s when using this patch. Of that 9.5, 8.9 > > is spent in > > >>>>> iterating through the CompoundIterator and > > calling > > >>>>> getSymbolsByName. > > >>>>> > > >>>>> On Mon, May 20, 2019 at 4:34 PM Ron Shapiro > > >>>>> > > >> wrote: > > >>>>> > > >>>>> This patch, which materializes the > > duplicate outer and > > >>>>> inner Iterables first into a list. It > > removes the > > >>>>> entire section of the CompoundIterator > > iteration from > > >>>>> the profile. > > >>>>> > > >>>>> webrev: > > >>>>> > > > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html > > >>>>> > > >>>>> I'm not sure it's the absolutely correct > > solution as it > > >>>>> possibly masks an underlying issue. > > >>>>> > > >>>>> I'm still seeing some time spent in > > >>>>> MethodSymbol.overrides, > > Types.isSubSignature, and > > >>>>> Types.memberType, all of which happen in > > the inner > > >>>>> loop. If we can remove those and collapse > > the nested > > >>>>> loops into one, then this solution isn't > > necessary and > > >>>>> it would also solve that performance > issue. > > >>>>> > > >>>>> On Fri, May 17, 2019 at 5:55 PM Ron > Shapiro > > >>>>> > > >> > > >>>>> wrote: > > >>>>> > > >>>>> I still have more to investigate to > > fully wrap my > > >>>>> head around it, but I finally found a > > sample > > >>>>> program that exhibits this. Filed a > > bug here: > > >>>>> https://bugs.openjdk.java.net/browse/JDK-8224161 > > >>>>> > > >>>>> On Fri, May 17, 2019 at 11:21 AM Jan > > Lahoda > > >>>>> > > > >>>>> > >> wrote: > > >>>>> > > >>>>> Hi Ron, > > >>>>> > > >>>>> I am afraid it is hard to guess > > what is the > > >>>>> problem without some > > >>>>> testcase. So, at least to me, > > having a sample > > >>>>> would be helpful. > > >>>>> > > >>>>> Thanks, > > >>>>> Jan > > >>>>> > > >>>>> On 17. 05. 19 0:41, Ron Shapiro > > wrote: > > >>>>> > Hi, > > >>>>> > > > >>>>> > I'm observing a particularly > > bizarre > > >>>>> compilation. It's a single file > > >>>>> > with annotation processing, and > > the type that > > >>>>> is being compiled and > > >>>>> > processed has ~1000 declared > > and inherited > > >>>>> methods combined. The total > > >>>>> > compilation is 3 minutes, but > > 65% of the > > >>>>> entire compilation is spent in > > >>>>> > 3 methods: > > >>>>> > > > >>>>> > > > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), > > >>>>> > > >>>>> > and Resolve.findField(). > > >>>>> > > > >>>>> > Looking at profiles, it looks > like > > >>>>> getSymbolsByName() is the major > > >>>>> > culprit here. I initially > > thought the reason > > >>>>> was that there were far too > > >>>>> > many overloads (this type had > >600 > > >>>>> overloads...) and that that was > > >>>>> > causing a bad regression for the > > >>>>> pseudo-hashmap that ScopeImpl > uses. > > >>>>> > However, renaming the methods > > did not > > >>>>> alleviate the build pain and these > > >>>>> > methods continue to be taking > > long amounts of > > >>>>> time. > > >>>>> > > > >>>>> > I was wondering what could be > > done to improve > > >>>>> the performance of this > > >>>>> > code. It seemed to me that > > something like a > > >>>>> Map> > > >>>>> > could be a reasonable+modern > > replacement for > > >>>>> this table, which would > > >>>>> > naturally have a fast > > getSymbolsForName() > > >>>>> implementation. I'm having > > >>>>> > some trouble implementing it > > correctly, and I > > >>>>> believe it's partially > > >>>>> > related to not fully > > understanding some of > > >>>>> the semantics of the class. > > >>>>> > > > >>>>> > Does what I wrote make sense to > > anyone, and > > >>>>> maybe spark a lightbulb? > > >>>>> > > > >>>>> > I'm trying to put together a > > repro in case > > >>>>> that helps, but I'm not 100% > > >>>>> > sure I even understand what the > > regression > > >>>>> case is. > > >>>>> > > > >>>>> > Thanks for you help! > > >>>>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujie at loongson.cn Wed Jun 12 05:56:40 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 12 Jun 2019 13:56:40 +0800 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp Message-ID: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> Hi all, JBS:??? https://bugs.openjdk.java.net/browse/JDK-8225644 Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ Reason: with -Xcomp, the signature was dumped as "[Ljava/lang/String;" rather than "[Ljava.lang.String;". Fix: It might be better to replace '/' with '.' before matching. Could you please review it? Thanks a lot. Best regards, Jie From joe.darcy at oracle.com Wed Jun 12 06:01:48 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 11 Jun 2019 23:01:48 -0700 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> Message-ID: <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> Hello, If the javac test is only failing under -Xcomp, a reasonable avenue to investigate is that -Xcomp is misbehaving rather than the test code. Cheers, -Joe On 6/11/2019 10:56 PM, Jie Fu wrote: > Hi all, > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8225644 > Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ > > Reason: with -Xcomp, the signature was dumped as "[Ljava/lang/String;" > rather than "[Ljava.lang.String;". > Fix: It might be better to replace '/' with '.' before matching. > > Could you please review it? > > Thanks a lot. > Best regards, > Jie > > From fujie at loongson.cn Wed Jun 12 06:14:56 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 12 Jun 2019 14:14:56 +0800 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> Message-ID: <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> Hi Joe, Thanks for your review. Do you mean the JIT shouldn't dump the signature like "[Ljava/lang/String;"? I'd like to do more investigation. Thanks. Best regards, Jie On 2019/6/12 ??2:01, Joe Darcy wrote: > Hello, > > If the javac test is only failing under -Xcomp, a reasonable avenue to > investigate is that -Xcomp is misbehaving rather than the test code. > > Cheers, > > -Joe > > On 6/11/2019 10:56 PM, Jie Fu wrote: >> Hi all, >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8225644 >> Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ >> >> Reason: with -Xcomp, the signature was dumped as >> "[Ljava/lang/String;" rather than "[Ljava.lang.String;". >> Fix: It might be better to replace '/' with '.' before matching. >> >> Could you please review it? >> >> Thanks a lot. >> Best regards, >> Jie >> >> From gunnar at hibernate.org Wed Jun 12 06:30:05 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 12 Jun 2019 08:30:05 +0200 Subject: Altering AST with javac Plugin Message-ID: Hi, I recently came across a javac plug-in (i.e. implementation of com.sun.source.util.Plugin) which alters/amends the AST of the classes under compilation. Is this an "officially" foreseen usage of that plug-in API? Or i this rather a hack akin to annotation processor implementations that cast the model types to the javac-internal ones in order to modify them? I'm curious, because those AST-modifying annotation processors are troublesome to deal with for other processors which won't "see" those amendments, so I'm wondering whether one would or would not have similar issues when altering the AST with such c.s.s.u.Plugin implementation. Thanks, --Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jun 12 06:44:39 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 12 Jun 2019 08:44:39 +0200 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> Message-ID: <31799d48-c6de-89d5-5d52-c234f3056aa9@oracle.com> Hi Ron, I ran the tests, I think it looks OK. It is this patch, right: http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/ Do you need a sponsor? Maurizio, any comments? Thanks, Jan On 11. 06. 19 20:25, Ron Shapiro wrote: > Is there a way I can run those? Any way I can help get this in? > > On Thu, Jun 6, 2019 at 10:36 AM Jan Lahoda > wrote: > > Hi Ron, > > I think we should run it through the perf tests, just to be sure (and I > didn't have time for that yet), but otherwise, I think that simple > change looks useful to me. > > Thanks, > ? ? ?Jan > > On 06. 06. 19 3:41, Ron Shapiro wrote: > > Friendly ping - is the first webrev ready for submission? > > > > On Thu, May 30, 2019, 7:09 PM Ron Shapiro > > >> wrote: > > > >? ? ?Do you have any other comments on the first webrev? Is there > >? ? ?anything else we need to do to submit that? > > > >? ? ?On Wed, May 22, 2019 at 11:00 AM Ron Shapiro > > >? ? ? >> wrote: > > > >? ? ? ? ?I think there still would be benefit in that as well, as I'm > >? ? ? ? ?seeing that come up in other contexts (as referenced in > the bug). > > > >? ? ? ? ?On Wed, May 22, 2019 at 9:06 AM Jan Lahoda > >? ? ? ? ? > >> wrote: > > > >? ? ? ? ? ? ?Sorry, I was too busy last few days. > > > >? ? ? ? ? ? ?I was peeking at some possible improvements, but I > think I > >? ? ? ? ? ? ?like Ron's > >? ? ? ? ? ? ?first (.00) patch - that caches what can be cached > nicely. > > > >? ? ? ? ? ? ?Looking at the testcase generated by Ron's reproducer > using: > >? ? ? ? ? ? ?python test.py 7 > > > >? ? ? ? ? ? ?and the (biggest) size of the outcome of: > >? ? ? ? ? ? ?types.membersClosure(site, > false).getSymbolsByName(sym.name > >? ? ? ? ? ? ?, cf) > > > >? ? ? ? ? ? ?seems to be 13700 elements - which means the Scope lookup > >? ? ? ? ? ? ?and iteration > >? ? ? ? ? ? ?runs ~13700 times, so avoiding these additional > lookup costs > >? ? ? ? ? ? ?seems like > >? ? ? ? ? ? ?a clear win. > > > >? ? ? ? ? ? ?I have an idea that might speed up the iterations through > >? ? ? ? ? ? ?deeply nested > >? ? ? ? ? ? ?CompoundScopes, although the effect of that in > combination > >? ? ? ? ? ? ?with Ron's is > >? ? ? ? ? ? ?going to be fairly limited, if any, I think. > > > >? ? ? ? ? ? ?Jan > > > >? ? ? ? ? ? ?On 22. 05. 19 12:24, Maurizio Cimadamore wrote: > >? ? ? ? ? ? ? > This doesn't work. You are basically relying on > the order > >? ? ? ? ? ? ?in which > >? ? ? ? ? ? ? > symbols are entered in the members closure scope. > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > In simple example like these: > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > class A { > >? ? ? ? ? ? ? >? ??? int m(List l) {return 0;} > >? ? ? ? ? ? ? > } > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > class B extends A { > >? ? ? ? ? ? ? >? ?? int m(List l) {return 0;} > >? ? ? ? ? ? ? > } > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > The logic you proposed will not work. That's > because we > >? ? ? ? ? ? ?first see B::m - > >? ? ? ? ? ? ? > and 'symbolByName' is empty at that stage; so we > add it > >? ? ? ? ? ? ?there. Then we > >? ? ? ? ? ? ? > do another round and see A::m - but we don't > really look > >? ? ? ? ? ? ?there - given > >? ? ? ? ? ? ? > that we first check to see if the symbol we're > >? ? ? ? ? ? ?considering (sym) is > >? ? ? ? ? ? ? > override-equivalent with B::m (the only symbol in > >? ? ? ? ? ? ?symbolByName). And > >? ? ? ? ? ? ? > that happens to be the case, since they are the same > >? ? ? ? ? ? ?symbol. So we exit > >? ? ? ? ? ? ? > the loop, w/o having found any clash. > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > In other words, symbolByName would need to also > contain > >? ? ? ? ? ? ?A::m for the > >? ? ? ? ? ? ? > code to see the clash - but that never happens; by the > >? ? ? ? ? ? ?time A::m is > >? ? ? ? ? ? ? > added, is already too late. > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > I think caching the result of > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > types.membersClosure(site, > >? ? ? ? ? ? ?false).getSymbolsByName(sym.name > , cf) > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > is a good measure. > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > I'm a bit surprised that iteration is so slow > >? ? ? ? ? ? ?(membersClosure is slow to > >? ? ? ? ? ? ? > set up, but once you do it the results are > cached). So, > >? ? ? ? ? ? ?rather than > >? ? ? ? ? ? ? > tweaking the algorithm, I think it'd be better to > >? ? ? ? ? ? ?investigate the reason > >? ? ? ? ? ? ? > was to why asking a compound scope iterator is so > slow, > >? ? ? ? ? ? ?which then would > >? ? ? ? ? ? ? > yield dividends for the rest of the code as well. > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > Maurizio > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? > On 21/05/2019 21:21, Maurizio Cimadamore wrote: > >? ? ? ? ? ? ? >> > >? ? ? ? ? ? ? >> I see what you have done - I have to think about it a > >? ? ? ? ? ? ?bit to see if I > >? ? ? ? ? ? ? >> can come up with some counter example. > >? ? ? ? ? ? ? >> > >? ? ? ? ? ? ? >> Thanks > >? ? ? ? ? ? ? >> Maurizio > >? ? ? ? ? ? ? >> > >? ? ? ? ? ? ? >> On 21/05/2019 17:39, Ron Shapiro wrote: > >? ? ? ? ? ? ? >>> Are the checks of the inner loop symmetrical? > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> Currently it's checking m_i against (m_0..n - m_i ). > >? ? ? ? ? ? ?This second > >? ? ? ? ? ? ? >>> webrev below would check it against > just?(m_0..i-1 ), > >? ? ? ? ? ? ?which albeit > >? ? ? ? ? ? ? >>> still n^2, it divides by a factor of 2. > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> (sorry if the subscripting here doesn't display > correctly) > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> This feels conceptually logical to me, but I'm not > >? ? ? ? ? ? ?seeing a > >? ? ? ? ? ? ? >>> measurable?change by it. It looks a little bit > cleaner > >? ? ? ? ? ? ?to me, but I'm > >? ? ? ? ? ? ? >>> fine with either webrev given the benefits they > both bring. > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> I can take a look in another thread about > speeding up > >? ? ? ? ? ? ?CompoundScope > >? ? ? ? ? ? ? >>> iteration. > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> On Tue, May 21, 2019 at 8:05 AM Maurizio Cimadamore > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> wrote: > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>>? ? ?On 21/05/2019 12:16, Ron Shapiro wrote: > >? ? ? ? ? ? ? >>>>? ? ?I still think that something to optimize the > >? ? ? ? ? ? ?actual ScopeImpl > >? ? ? ? ? ? ? >>>>? ? ?Iterable is a worthwhile endeavor, as that > would > >? ? ? ? ? ? ?alleviate the > >? ? ? ? ? ? ? >>>>? ? ?need to materialize here (and solve > hopefully the > >? ? ? ? ? ? ?other issues > >? ? ? ? ? ? ? >>>>? ? ?I'm seeing), but I was having trouble > figuring out > >? ? ? ? ? ? ?how to do > >? ? ? ? ? ? ? >>>>? ? ?that. This may be a good interim option without > >? ? ? ? ? ? ?much cost. > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>>? ? ?Sure - I'm not opposed to optimizing the > iteration > >? ? ? ? ? ? ?process - I > >? ? ? ? ? ? ? >>>? ? ?was expressing my skepticism w.r.t. making > >? ? ? ? ? ? ?checkOverrideClash > >? ? ? ? ? ? ? >>>? ? ?simpler/non quadratic. > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>>? ? ?Maurizio > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>>? ? ?On Tue, May 21, 2019, 5:59 AM Maurizio > Cimadamore > >? ? ? ? ? ? ? >>>>? ? ? > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? >>>>? ? ? > >? ? ? ? ? ? ? >>> wrote: > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>>? ? ? ? ?I think your fix is a good one. We > spent some > >? ? ? ? ? ? ?cycles > >? ? ? ? ? ? ? >>>>? ? ? ? ?optimizing this, a bit odd we have > missed this :-) > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>>? ? ? ? ?I'm very skeptical you can collapse into a > >? ? ? ? ? ? ?single loop, as > >? ? ? ? ? ? ? >>>>? ? ? ? ?this implement the logic in JLS 8.4.8.3 [1] > >? ? ? ? ? ? ?which, as you > >? ? ? ? ? ? ? >>>>? ? ? ? ?can see, is inherently quadratic (for each > >? ? ? ? ? ? ?method, we have > >? ? ? ? ? ? ? >>>>? ? ? ? ?to scan all methods with same name in > >? ? ? ? ? ? ?supertypes to see if > >? ? ? ? ? ? ? >>>>? ? ? ? ?there is an override clash). The algorithm > >? ? ? ? ? ? ?that was there > >? ? ? ? ? ? ? >>>>? ? ? ? ?before wasn't - and it lead to the wrong > >? ? ? ? ? ? ?answers in tricky > >? ? ? ? ? ? ? >>>>? ? ? ? ?cases - so while you can get 80% there > with a > >? ? ? ? ? ? ?non-quadratic > >? ? ? ? ? ? ? >>>>? ? ? ? ?algorithm, you will miss issues by > doing so. > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>>? ? ? ? ?One thing that would help would be, > instead, > >? ? ? ? ? ? ?to limit the > >? ? ? ? ? ? ? >>>>? ? ? ? ?analysis only in cases where it adds > value - > >? ? ? ? ? ? ?for instance, > >? ? ? ? ? ? ? >>>>? ? ? ? ?if your hierarchy is just non-generic > classes > >? ? ? ? ? ? ?(as in your > >? ? ? ? ? ? ? >>>>? ? ? ? ?example), then there's no way for you to > >? ? ? ? ? ? ?accidentally > >? ? ? ? ? ? ? >>>>? ? ? ? ?override a 'bridge' method, since no > bridges > >? ? ? ? ? ? ?will be > >? ? ? ? ? ? ? >>>>? ? ? ? ?generated! But when looking at this, I > >? ? ? ? ? ? ?couldn't find great > >? ? ? ? ? ? ? >>>>? ? ? ? ?ways to detect these conditions w/o > spending > >? ? ? ? ? ? ?more time than > >? ? ? ? ? ? ? >>>>? ? ? ? ?the check itself. > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>>? ? ? ? ?[1] - > >? ? ? ? ? ? ? >>>> > > > https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>>? ? ? ? ?Maurizio > >? ? ? ? ? ? ? >>>> > >? ? ? ? ? ? ? >>>>? ? ? ? ?On 20/05/2019 21:58, Ron Shapiro wrote: > >? ? ? ? ? ? ? >>>>>? ? ? ? ?In the real world example, I'm seeing > the 40s > >? ? ? ? ? ? ?that was > >? ? ? ? ? ? ? >>>>>? ? ? ? ?previously spent in > >? ? ? ? ? ? ?Check.checkOverrideClashes drop to to > >? ? ? ? ? ? ? >>>>>? ? ? ? ?9.5s when using this patch. Of that > 9.5, 8.9 > >? ? ? ? ? ? ?is spent in > >? ? ? ? ? ? ? >>>>>? ? ? ? ?iterating through the CompoundIterator and > >? ? ? ? ? ? ?calling > >? ? ? ? ? ? ? >>>>>? ? ? ? ?getSymbolsByName. > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ?On Mon, May 20, 2019 at 4:34 PM Ron > Shapiro > >? ? ? ? ? ? ? >>>>>? ? ? ? ? > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? >>> wrote: > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?This patch, which materializes the > >? ? ? ? ? ? ?duplicate outer and > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?inner Iterables first into a list. It > >? ? ? ? ? ? ?removes the > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?entire section of the CompoundIterator > >? ? ? ? ? ? ?iteration from > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?the profile. > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?webrev: > >? ? ? ? ? ? ? >>>>> > > > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?I'm not sure it's the absolutely > correct > >? ? ? ? ? ? ?solution as it > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?possibly masks an underlying issue. > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?I'm still seeing some time spent in > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?MethodSymbol.overrides, > >? ? ? ? ? ? ?Types.isSubSignature, and > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?Types.memberType, all of which > happen in > >? ? ? ? ? ? ?the inner > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?loop. If we can remove those and > collapse > >? ? ? ? ? ? ?the nested > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?loops into one, then this solution > isn't > >? ? ? ? ? ? ?necessary and > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?it would also solve that > performance issue. > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?On Fri, May 17, 2019 at 5:55 PM > Ron Shapiro > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? >>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?wrote: > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ?I still have more to > investigate to > >? ? ? ? ? ? ?fully wrap my > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ?head around it, but I finally > found a > >? ? ? ? ? ? ?sample > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ?program that exhibits this. > Filed a > >? ? ? ? ? ? ?bug here: > >? ? ? ? ? ? ? >>>>> https://bugs.openjdk.java.net/browse/JDK-8224161 > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ?On Fri, May 17, 2019 at 11:21 > AM Jan > >? ? ? ? ? ? ?Lahoda > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? > >? ? ? ? ? ? ? > > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? > >? ? ? ? ? ? ? >>> wrote: > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?Hi Ron, > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?I am afraid it is hard to > guess > >? ? ? ? ? ? ?what is the > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?problem without some > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?testcase. So, at least to me, > >? ? ? ? ? ? ?having a sample > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?would be helpful. > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?Thanks, > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?? ? ?Jan > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?On 17. 05. 19 0:41, Ron > Shapiro > >? ? ? ? ? ? ?wrote: > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> Hi, > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> I'm observing a particularly > >? ? ? ? ? ? ?bizarre > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?compilation. It's a single > file > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> with annotation > processing, and > >? ? ? ? ? ? ?the type that > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?is being compiled and > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> processed has ~1000 declared > >? ? ? ? ? ? ?and inherited > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?methods combined. The total > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> compilation is 3 > minutes, but > >? ? ? ? ? ? ?65% of the > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?entire compilation is spent in > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> 3 methods: > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> > >? ? ? ? ? ? ? >>>>> > > > ?Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), > >? ? ? ? ? ? ? >>>>> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> and?Resolve.findField(). > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> Looking at profiles, it > looks like > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?getSymbolsByName() is the > major > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> culprit here. I initially > >? ? ? ? ? ? ?thought the reason > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?was that there were far too > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> many overloads (this > type had >600 > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?overloads...) and that > that was > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> causing a bad regression > for the > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?pseudo-hashmap that > ScopeImpl uses. > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> However, renaming the > methods > >? ? ? ? ? ? ?did not > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?alleviate the build pain > and these > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> methods continue to be > taking > >? ? ? ? ? ? ?long amounts of > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?time. > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> I was wondering what > could be > >? ? ? ? ? ? ?done to improve > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?the performance of this > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> code. It seemed to me that > >? ? ? ? ? ? ?something like a > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?Map> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> could be a reasonable+modern > >? ? ? ? ? ? ?replacement for > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?this table, which would > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> naturally have a fast > >? ? ? ? ? ? ?getSymbolsForName() > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?implementation. I'm having > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> some trouble implementing it > >? ? ? ? ? ? ?correctly, and I > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?believe it's partially > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> related to not fully > >? ? ? ? ? ? ?understanding some of > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?the semantics of the class. > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> Does what I wrote make > sense to > >? ? ? ? ? ? ?anyone, and > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?maybe spark a lightbulb? > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> I'm trying to put together a > >? ? ? ? ? ? ?repro in case > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?that helps, but I'm not 100% > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> sure I even understand > what the > >? ? ? ? ? ? ?regression > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?case is. > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> > >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ? ? ?> Thanks for you help! > >? ? ? ? ? ? ? >>>>> > > > From maurizio.cimadamore at oracle.com Wed Jun 12 09:54:00 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 12 Jun 2019 10:54:00 +0100 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: <31799d48-c6de-89d5-5d52-c234f3056aa9@oracle.com> References: <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> <31799d48-c6de-89d5-5d52-c234f3056aa9@oracle.com> Message-ID: On 12/06/2019 07:44, Jan Lahoda wrote: > Hi Ron, > > I ran the tests, I think it looks OK. > It is this patch, right: > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/ > > Do you need a sponsor? Maurizio, any comments? I already approved this simpler fix few emails ago in this thread. Looks good to me. Thanks Maurizio > > Thanks, > ??? Jan > > On 11. 06. 19 20:25, Ron Shapiro wrote: >> Is there a way I can run those? Any way I can help get this in? >> >> On Thu, Jun 6, 2019 at 10:36 AM Jan Lahoda > > wrote: >> >> ??? Hi Ron, >> >> ??? I think we should run it through the perf tests, just to be sure >> (and I >> ??? didn't have time for that yet), but otherwise, I think that simple >> ??? change looks useful to me. >> >> ??? Thanks, >> ???? ? ? ?Jan >> >> ??? On 06. 06. 19 3:41, Ron Shapiro wrote: >> ???? > Friendly ping - is the first webrev ready for submission? >> ???? > >> ???? > On Thu, May 30, 2019, 7:09 PM Ron Shapiro > ??? >> ???? > >> >> wrote: >> ???? > >> ???? >? ? ?Do you have any other comments on the first webrev? Is there >> ???? >? ? ?anything else we need to do to submit that? >> ???? > >> ???? >? ? ?On Wed, May 22, 2019 at 11:00 AM Ron Shapiro >> ??? >> ???? >? ? ?> ??? >> wrote: >> ???? > >> ???? >? ? ? ? ?I think there still would be benefit in that as well, >> as I'm >> ???? >? ? ? ? ?seeing that come up in other contexts (as referenced in >> ??? the bug). >> ???? > >> ???? >? ? ? ? ?On Wed, May 22, 2019 at 9:06 AM Jan Lahoda >> ???? >? ? ? ? ? >> ??? >> >> wrote: >> ???? > >> ???? >? ? ? ? ? ? ?Sorry, I was too busy last few days. >> ???? > >> ???? >? ? ? ? ? ? ?I was peeking at some possible improvements, but I >> ??? think I >> ???? >? ? ? ? ? ? ?like Ron's >> ???? >? ? ? ? ? ? ?first (.00) patch - that caches what can be cached >> ??? nicely. >> ???? > >> ???? >? ? ? ? ? ? ?Looking at the testcase generated by Ron's reproducer >> ??? using: >> ???? >? ? ? ? ? ? ?python test.py 7 >> ???? > >> ???? >? ? ? ? ? ? ?and the (biggest) size of the outcome of: >> ???? >? ? ? ? ? ? ?types.membersClosure(site, >> ??? false).getSymbolsByName(sym.name >> ???? >? ? ? ? ? ? ?, cf) >> ???? > >> ???? >? ? ? ? ? ? ?seems to be 13700 elements - which means the Scope >> lookup >> ???? >? ? ? ? ? ? ?and iteration >> ???? >? ? ? ? ? ? ?runs ~13700 times, so avoiding these additional >> ??? lookup costs >> ???? >? ? ? ? ? ? ?seems like >> ???? >? ? ? ? ? ? ?a clear win. >> ???? > >> ???? >? ? ? ? ? ? ?I have an idea that might speed up the iterations >> through >> ???? >? ? ? ? ? ? ?deeply nested >> ???? >? ? ? ? ? ? ?CompoundScopes, although the effect of that in >> ??? combination >> ???? >? ? ? ? ? ? ?with Ron's is >> ???? >? ? ? ? ? ? ?going to be fairly limited, if any, I think. >> ???? > >> ???? >? ? ? ? ? ? ?Jan >> ???? > >> ???? >? ? ? ? ? ? ?On 22. 05. 19 12:24, Maurizio Cimadamore wrote: >> ???? >? ? ? ? ? ? ? > This doesn't work. You are basically relying on >> ??? the order >> ???? >? ? ? ? ? ? ?in which >> ???? >? ? ? ? ? ? ? > symbols are entered in the members closure scope. >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > In simple example like these: >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > class A { >> ???? >? ? ? ? ? ? ? >? ??? int m(List l) {return 0;} >> ???? >? ? ? ? ? ? ? > } >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > class B extends A { >> ???? >? ? ? ? ? ? ? >? ?? int m(List l) {return 0;} >> ???? >? ? ? ? ? ? ? > } >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > The logic you proposed will not work. That's >> ??? because we >> ???? >? ? ? ? ? ? ?first see B::m - >> ???? >? ? ? ? ? ? ? > and 'symbolByName' is empty at that stage; so we >> ??? add it >> ???? >? ? ? ? ? ? ?there. Then we >> ???? >? ? ? ? ? ? ? > do another round and see A::m - but we don't >> ??? really look >> ???? >? ? ? ? ? ? ?there - given >> ???? >? ? ? ? ? ? ? > that we first check to see if the symbol we're >> ???? >? ? ? ? ? ? ?considering (sym) is >> ???? >? ? ? ? ? ? ? > override-equivalent with B::m (the only symbol in >> ???? >? ? ? ? ? ? ?symbolByName). And >> ???? >? ? ? ? ? ? ? > that happens to be the case, since they are the >> same >> ???? >? ? ? ? ? ? ?symbol. So we exit >> ???? >? ? ? ? ? ? ? > the loop, w/o having found any clash. >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > In other words, symbolByName would need to also >> ??? contain >> ???? >? ? ? ? ? ? ?A::m for the >> ???? >? ? ? ? ? ? ? > code to see the clash - but that never happens; >> by the >> ???? >? ? ? ? ? ? ?time A::m is >> ???? >? ? ? ? ? ? ? > added, is already too late. >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > I think caching the result of >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > types.membersClosure(site, >> ???? >? ? ? ? ? ? ?false).getSymbolsByName(sym.name >> ??? , cf) >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > is a good measure. >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > I'm a bit surprised that iteration is so slow >> ???? >? ? ? ? ? ? ?(membersClosure is slow to >> ???? >? ? ? ? ? ? ? > set up, but once you do it the results are >> ??? cached). So, >> ???? >? ? ? ? ? ? ?rather than >> ???? >? ? ? ? ? ? ? > tweaking the algorithm, I think it'd be better to >> ???? >? ? ? ? ? ? ?investigate the reason >> ???? >? ? ? ? ? ? ? > was to why asking a compound scope iterator is so >> ??? slow, >> ???? >? ? ? ? ? ? ?which then would >> ???? >? ? ? ? ? ? ? > yield dividends for the rest of the code as well. >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > Maurizio >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > >> ???? >? ? ? ? ? ? ? > On 21/05/2019 21:21, Maurizio Cimadamore wrote: >> ???? >? ? ? ? ? ? ? >> >> ???? >? ? ? ? ? ? ? >> I see what you have done - I have to think >> about it a >> ???? >? ? ? ? ? ? ?bit to see if I >> ???? >? ? ? ? ? ? ? >> can come up with some counter example. >> ???? >? ? ? ? ? ? ? >> >> ???? >? ? ? ? ? ? ? >> Thanks >> ???? >? ? ? ? ? ? ? >> Maurizio >> ???? >? ? ? ? ? ? ? >> >> ???? >? ? ? ? ? ? ? >> On 21/05/2019 17:39, Ron Shapiro wrote: >> ???? >? ? ? ? ? ? ? >>> Are the checks of the inner loop symmetrical? >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>> Currently it's checking m_i against (m_0..n - >> m_i ). >> ???? >? ? ? ? ? ? ?This second >> ???? >? ? ? ? ? ? ? >>> webrev below would check it against >> ??? just?(m_0..i-1 ), >> ???? >? ? ? ? ? ? ?which albeit >> ???? >? ? ? ? ? ? ? >>> still n^2, it divides by a factor of 2. >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>> (sorry if the subscripting here doesn't display >> ??? correctly) >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>> >> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>> This feels conceptually logical to me, but >> I'm not >> ???? >? ? ? ? ? ? ?seeing a >> ???? >? ? ? ? ? ? ? >>> measurable?change by it. It looks a little bit >> ??? cleaner >> ???? >? ? ? ? ? ? ?to me, but I'm >> ???? >? ? ? ? ? ? ? >>> fine with either webrev given the benefits they >> ??? both bring. >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>> I can take a look in another thread about >> ??? speeding up >> ???? >? ? ? ? ? ? ?CompoundScope >> ???? >? ? ? ? ? ? ? >>> iteration. >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>> On Tue, May 21, 2019 at 8:05 AM Maurizio >> Cimadamore >> ???? >? ? ? ? ? ? ? >>> > ??? >> ???? >? ? ? ? ? ? ?> ??? > >> ???? >? ? ? ? ? ? ? >>> > ??? >> ???? >? ? ? ? ? ? ?> ??? >>> wrote: >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>>? ? ?On 21/05/2019 12:16, Ron Shapiro wrote: >> ???? >? ? ? ? ? ? ? >>>>? ? ?I still think that something to optimize >> the >> ???? >? ? ? ? ? ? ?actual ScopeImpl >> ???? >? ? ? ? ? ? ? >>>>? ? ?Iterable is a worthwhile endeavor, as that >> ??? would >> ???? >? ? ? ? ? ? ?alleviate the >> ???? >? ? ? ? ? ? ? >>>>? ? ?need to materialize here (and solve >> ??? hopefully the >> ???? >? ? ? ? ? ? ?other issues >> ???? >? ? ? ? ? ? ? >>>>? ? ?I'm seeing), but I was having trouble >> ??? figuring out >> ???? >? ? ? ? ? ? ?how to do >> ???? >? ? ? ? ? ? ? >>>>? ? ?that. This may be a good interim option >> without >> ???? >? ? ? ? ? ? ?much cost. >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>>? ? ?Sure - I'm not opposed to optimizing the >> ??? iteration >> ???? >? ? ? ? ? ? ?process - I >> ???? >? ? ? ? ? ? ? >>>? ? ?was expressing my skepticism w.r.t. making >> ???? >? ? ? ? ? ? ?checkOverrideClash >> ???? >? ? ? ? ? ? ? >>>? ? ?simpler/non quadratic. >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>>? ? ?Maurizio >> ???? >? ? ? ? ? ? ? >>> >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>>? ? ?On Tue, May 21, 2019, 5:59 AM Maurizio >> ??? Cimadamore >> ???? >? ? ? ? ? ? ? >>>> ?> ??? >> ???? >? ? ? ? ? ? ?> ??? > >> ???? >? ? ? ? ? ? ? >>>> ?> ??? >> ???? >? ? ? ? ? ? ?> ??? >>> wrote: >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?I think your fix is a good one. We >> ??? spent some >> ???? >? ? ? ? ? ? ?cycles >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?optimizing this, a bit odd we have >> ??? missed this :-) >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?I'm very skeptical you can collapse >> into a >> ???? >? ? ? ? ? ? ?single loop, as >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?this implement the logic in JLS >> 8.4.8.3 [1] >> ???? >? ? ? ? ? ? ?which, as you >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?can see, is inherently quadratic >> (for each >> ???? >? ? ? ? ? ? ?method, we have >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?to scan all methods with same name in >> ???? >? ? ? ? ? ? ?supertypes to see if >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?there is an override clash). The >> algorithm >> ???? >? ? ? ? ? ? ?that was there >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?before wasn't - and it lead to the >> wrong >> ???? >? ? ? ? ? ? ?answers in tricky >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?cases - so while you can get 80% there >> ??? with a >> ???? >? ? ? ? ? ? ?non-quadratic >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?algorithm, you will miss issues by >> ??? doing so. >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?One thing that would help would be, >> ??? instead, >> ???? >? ? ? ? ? ? ?to limit the >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?analysis only in cases where it adds >> ??? value - >> ???? >? ? ? ? ? ? ?for instance, >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?if your hierarchy is just non-generic >> ??? classes >> ???? >? ? ? ? ? ? ?(as in your >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?example), then there's no way for >> you to >> ???? >? ? ? ? ? ? ?accidentally >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?override a 'bridge' method, since no >> ??? bridges >> ???? >? ? ? ? ? ? ?will be >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?generated! But when looking at this, I >> ???? >? ? ? ? ? ? ?couldn't find great >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?ways to detect these conditions w/o >> ??? spending >> ???? >? ? ? ? ? ? ?more time than >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?the check itself. >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?[1] - >> ???? >? ? ? ? ? ? ? >>>> >> ???? > >> https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?Maurizio >> ???? >? ? ? ? ? ? ? >>>> >> ???? >? ? ? ? ? ? ? >>>>? ? ? ? ?On 20/05/2019 21:58, Ron Shapiro wrote: >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ?In the real world example, I'm seeing >> ??? the 40s >> ???? >? ? ? ? ? ? ?that was >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ?previously spent in >> ???? >? ? ? ? ? ? ?Check.checkOverrideClashes drop to to >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ?9.5s when using this patch. Of that >> ??? 9.5, 8.9 >> ???? >? ? ? ? ? ? ?is spent in >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ?iterating through the >> CompoundIterator and >> ???? >? ? ? ? ? ? ?calling >> ???? >? ? ? ? ? ? ? >>>>> ?getSymbolsByName. >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ?On Mon, May 20, 2019 at 4:34 PM Ron >> ??? Shapiro >> ???? >? ? ? ? ? ? ? >>>>> ?> ??? >> ???? >? ? ? ? ? ? ?> ??? > > ??? >> ???? >? ? ? ? ? ? ?> ??? >>> wrote: >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?This patch, which materializes the >> ???? >? ? ? ? ? ? ?duplicate outer and >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?inner Iterables first into a >> list. It >> ???? >? ? ? ? ? ? ?removes the >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?entire section of the >> CompoundIterator >> ???? >? ? ? ? ? ? ?iteration from >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?the profile. >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?webrev: >> ???? >? ? ? ? ? ? ? >>>>> >> ???? > >> http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?I'm not sure it's the absolutely >> ??? correct >> ???? >? ? ? ? ? ? ?solution as it >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?possibly masks an underlying >> issue. >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?I'm still seeing some time >> spent in >> ???? >? ? ? ? ? ? ? >>>>> ?MethodSymbol.overrides, >> ???? >? ? ? ? ? ? ?Types.isSubSignature, and >> ???? >? ? ? ? ? ? ? >>>>> ?Types.memberType, all of which >> ??? happen in >> ???? >? ? ? ? ? ? ?the inner >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?loop. If we can remove those and >> ??? collapse >> ???? >? ? ? ? ? ? ?the nested >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?loops into one, then this solution >> ??? isn't >> ???? >? ? ? ? ? ? ?necessary and >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?it would also solve that >> ??? performance issue. >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?On Fri, May 17, 2019 at 5:55 PM >> ??? Ron Shapiro >> ???? >? ? ? ? ? ? ? >>>>> ?> ??? >> ???? >? ? ? ? ? ? ?> ??? > > ??? >> ???? >? ? ? ? ? ? ?> ??? >>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ?wrote: >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ?I still have more to >> ??? investigate to >> ???? >? ? ? ? ? ? ?fully wrap my >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ?head around it, but I finally >> ??? found a >> ???? >? ? ? ? ? ? ?sample >> ???? >? ? ? ? ? ? ? >>>>> ?program that exhibits this. >> ??? Filed a >> ???? >? ? ? ? ? ? ?bug here: >> ???? >? ? ? ? ? ? ? >>>>> >> https://bugs.openjdk.java.net/browse/JDK-8224161 >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>>? ? ? ? ? ? ? ? ?On Fri, May 17, 2019 at 11:21 >> ??? AM Jan >> ???? >? ? ? ? ? ? ?Lahoda >> ???? >? ? ? ? ? ? ? >>>>> ?> ??? >> ???? >? ? ? ? ? ? ?> ??? > >> ???? >? ? ? ? ? ? ? >>>>> ?> ??? >> ???? >? ? ? ? ? ? ?> ??? >>> wrote: >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>> ?Hi Ron, >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>> ?I am afraid it is hard to >> ??? guess >> ???? >? ? ? ? ? ? ?what is the >> ???? >? ? ? ? ? ? ? >>>>> ?problem without some >> ???? >? ? ? ? ? ? ? >>>>> ?testcase. So, at least to me, >> ???? >? ? ? ? ? ? ?having a sample >> ???? >? ? ? ? ? ? ? >>>>> ?would be helpful. >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>> ?Thanks, >> ???? >? ? ? ? ? ? ? >>>>> ?? ? ?Jan >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>> ?On 17. 05. 19 0:41, Ron >> ??? Shapiro >> ???? >? ? ? ? ? ? ?wrote: >> ???? >? ? ? ? ? ? ? >>>>> ?> Hi, >> ???? >? ? ? ? ? ? ? >>>>> ?> >> ???? >? ? ? ? ? ? ? >>>>> ?> I'm observing a particularly >> ???? >? ? ? ? ? ? ?bizarre >> ???? >? ? ? ? ? ? ? >>>>> ?compilation. It's a single >> ??? file >> ???? >? ? ? ? ? ? ? >>>>> ?> with annotation >> ??? processing, and >> ???? >? ? ? ? ? ? ?the type that >> ???? >? ? ? ? ? ? ? >>>>> ?is being compiled and >> ???? >? ? ? ? ? ? ? >>>>> ?> processed has ~1000 declared >> ???? >? ? ? ? ? ? ?and inherited >> ???? >? ? ? ? ? ? ? >>>>> ?methods combined. The total >> ???? >? ? ? ? ? ? ? >>>>> ?> compilation is 3 >> ??? minutes, but >> ???? >? ? ? ? ? ? ?65% of the >> ???? >? ? ? ? ? ? ? >>>>> ?entire compilation is spent in >> ???? >? ? ? ? ? ? ? >>>>> ?> 3 methods: >> ???? >? ? ? ? ? ? ? >>>>> ?> >> ???? >? ? ? ? ? ? ? >>>>> >> ???? > ?Check.checkOverrideClashes(),?Resolve.findInheritedMemberType(), >> ???? >? ? ? ? ? ? ? >>>>> >> ???? >? ? ? ? ? ? ? >>>>> ?> and?Resolve.findField(). >> ???? >? ? ? ? ? ? ? >>>>> ?> >> ???? >? ? ? ? ? ? ? >>>>> ?> Looking at profiles, it >> ??? looks like >> ???? >? ? ? ? ? ? ? >>>>> ?getSymbolsByName() is the >> ??? major >> ???? >? ? ? ? ? ? ? >>>>> ?> culprit here. I initially >> ???? >? ? ? ? ? ? ?thought the reason >> ???? >? ? ? ? ? ? ? >>>>> ?was that there were far too >> ???? >? ? ? ? ? ? ? >>>>> ?> many overloads (this >> ??? type had >600 >> ???? >? ? ? ? ? ? ? >>>>> ?overloads...) and that >> ??? that was >> ???? >? ? ? ? ? ? ? >>>>> ?> causing a bad regression >> ??? for the >> ???? >? ? ? ? ? ? ? >>>>> ?pseudo-hashmap that >> ??? ScopeImpl uses. >> ???? >? ? ? ? ? ? ? >>>>> ?> However, renaming the >> ??? methods >> ???? >? ? ? ? ? ? ?did not >> ???? >? ? ? ? ? ? ? >>>>> ?alleviate the build pain >> ??? and these >> ???? >? ? ? ? ? ? ? >>>>> ?> methods continue to be >> ??? taking >> ???? >? ? ? ? ? ? ?long amounts of >> ???? >? ? ? ? ? ? ? >>>>> ?time. >> ???? >? ? ? ? ? ? ? >>>>> ?> >> ???? >? ? ? ? ? ? ? >>>>> ?> I was wondering what >> ??? could be >> ???? >? ? ? ? ? ? ?done to improve >> ???? >? ? ? ? ? ? ? >>>>> ?the performance of this >> ???? >? ? ? ? ? ? ? >>>>> ?> code. It seemed to me that >> ???? >? ? ? ? ? ? ?something like a >> ???? >? ? ? ? ? ? ? >>>>> ?Map> >> ???? >? ? ? ? ? ? ? >>>>> ?> could be a reasonable+modern >> ???? >? ? ? ? ? ? ?replacement for >> ???? >? ? ? ? ? ? ? >>>>> ?this table, which would >> ???? >? ? ? ? ? ? ? >>>>> ?> naturally have a fast >> ???? >? ? ? ? ? ? ?getSymbolsForName() >> ???? >? ? ? ? ? ? ? >>>>> ?implementation. I'm having >> ???? >? ? ? ? ? ? ? >>>>> ?> some trouble implementing it >> ???? >? ? ? ? ? ? ?correctly, and I >> ???? >? ? ? ? ? ? ? >>>>> ?believe it's partially >> ???? >? ? ? ? ? ? ? >>>>> ?> related to not fully >> ???? >? ? ? ? ? ? ?understanding some of >> ???? >? ? ? ? ? ? ? >>>>> ?the semantics of the class. >> ???? >? ? ? ? ? ? ? >>>>> ?> >> ???? >? ? ? ? ? ? ? >>>>> ?> Does what I wrote make >> ??? sense to >> ???? >? ? ? ? ? ? ?anyone, and >> ???? >? ? ? ? ? ? ? >>>>> ?maybe spark a lightbulb? >> ???? >? ? ? ? ? ? ? >>>>> ?> >> ???? >? ? ? ? ? ? ? >>>>> ?> I'm trying to put together a >> ???? >? ? ? ? ? ? ?repro in case >> ???? >? ? ? ? ? ? ? >>>>> ?that helps, but I'm not 100% >> ???? >? ? ? ? ? ? ? >>>>> ?> sure I even understand >> ??? what the >> ???? >? ? ? ? ? ? ?regression >> ???? >? ? ? ? ? ? ? >>>>> ?case is. >> ???? >? ? ? ? ? ? ? >>>>> ?> >> ???? >? ? ? ? ? ? ? >>>>> ?> Thanks for you help! >> ???? >? ? ? ? ? ? ? >>>>> >> ???? > >> From maurizio.cimadamore at oracle.com Wed Jun 12 09:57:27 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 12 Jun 2019 10:57:27 +0100 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: <578889a9-68d9-6f83-aac6-9fd9b2b8fddd@oracle.com> References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> <578889a9-68d9-6f83-aac6-9fd9b2b8fddd@oracle.com> Message-ID: Modulo 'yield' vs 'break', this loos good. Maurizio On 11/06/2019 16:07, Jan Lahoda wrote: > Hi Bernard, > > Looks good to me. Any comments, Maurizio? > > Thanks, > ??? Jan > > On 19. 05. 19 16:46, B. Blaser wrote: >> Hi Jan and Maurizio, >> >> I've updated the webrev [1] as you both suggested: >> * 'unwindBreak()' commented to warn for a possible dead code marking. >> * 'reloadStackBeforeSwitchExpr()' added to factorize the stack >> reloading. >> * 'test4()' below added to Jan's test cases. >> >> Does this look good to both of you (tier1 is OK)? >> >> Thanks, >> Bernard >> >> [1] http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.01/ >> >> >> On Sat, 11 May 2019 at 13:29, B. Blaser wrote: >>> >>> Hi Jan and Maurizio, >>> >>> Thanks for both feedback. >>> >>> On Thu, 9 May 2019 at 14:35, Maurizio Cimadamore >>> wrote: >>>> >>>> Hi, >>>> I look at the code and discussed it offline with Jan extensively. >>>> >>>> I think the approach looks good, and it is inspired by what we already >>>> do for return expressions (where we use intermediate locals to store >>>> return expressions in case there's a finalizer). >>>> >>>> The only problem I have with this code is that it implicitly >>>> relies, in >>>> the conditional context case, on the fact that, should the finalizer >>>> complete abnormally (isAlive = false), then Code will refuse to >>>> emit any >>>> additional statements (such as the loads required to restore the stack >>>> state). >>>> >>>> I think the is brittle, and might bite us back in case we revisit this >>>> code and add another statement whose behavior is NOT guarded by >>>> isAlive. >>>> >>>> So, I suggest either adding explicit comments, saying that unwindBreak >>>> might affect isAlive and, as a result, following statements might >>>> not be >>>> generated - or, wrap the code in an explicit `if (isAlive)` guard, as >>>> done in the other branch of the visitBreak code. >>> >>> As first step, I guess I'd be more for simply adding a comment but we >>> can still rework and consolidate this part later on if necessary. >>> >>>> As bonus point, since >>>> we're restoring the stack in three different places, perhaps we can >>>> factor the restoring code out to some common function. >>> >>> Of course ;-) >>> >>>> Cheers >>>> Maurizio >>>> >>>> >>>> On 09/05/2019 09:34, Jan Lahoda wrote: >>>>> Hi Bernard, >>>>> >>>>> I apologize for late reply. >>> >>> No problem, I'm rather busy too... >>> >>>>> Thanks for the patch, looks OK to me, but >>>>> I guess it would be good to have another review on this. >>>>> >>>>> Would it be possible to enhance the tests with the testcase below >>>>> (and >>>>> any other testcases needed)? >>> >>> Yes, I'll also include this one. >>> >>> Cheers, >>> Bernard >>> >>> >>>>> Thanks, >>>>> ???? Jan >>>>> >>>>> On 27. 03. 19 19:20, B. Blaser wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following fix for [1] which has already been >>>>>> discussed in the corresponding thread [2]: >>>>>> >>>>>> http://cr.openjdk.java.net/~bsrbnd/jdk8220018/webrev.00/ >>>>>> >>>>>> It includes the variant I suggested to store the switch expression >>>>>> result in a single temporary variable along with Jan's solution for >>>>>> switch expressions used as conditions. Note that I had to do a tiny >>>>>> correction to the latter (see 'code.resolve(value.trueJumps)') to >>>>>> make >>>>>> the following example succeed: >>>>>> >>>>>> ????? public static void test4() { >>>>>> ????????? if (!switch (0) { >>>>>> ????????????? default -> { >>>>>> ????????????????? try { >>>>>> ????????????????????? break switch(0) { default -> true; }; >>>>>> ????????????????? } >>>>>> ????????????????? finally { >>>>>> ????????????????????? break false; >>>>>> ????????????????? } >>>>>> ????????????? } >>>>>> ????????? }) { >>>>>> ????????????? System.out.println("OK!"); >>>>>> ????????? } >>>>>> ????? } >>>>>> >>>>>> It also includes Jan's test case. >>>>>> >>>>>> Any feedback is welcome (tier1 is OK). >>>>>> >>>>>> Thanks, >>>>>> Bernard >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8220018 >>>>>> [2] >>>>>> http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013073.html >>>>>> >>>>>> From bsrbnd at gmail.com Wed Jun 12 10:09:07 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 12 Jun 2019 12:09:07 +0200 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> Message-ID: [ Forwarding to hotspot-compiler-dev ] The CCE messages are probably generated here: http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l301 http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l315 Note that the second one might be called from interpreted code and seems to generate the expected message. I hope this helps, Bernard On Wed, 12 Jun 2019 at 08:15, Jie Fu wrote: > > Hi Joe, > > Thanks for your review. > Do you mean the JIT shouldn't dump the signature like "[Ljava/lang/String;"? > > I'd like to do more investigation. > Thanks. > > Best regards, > Jie > > On 2019/6/12 ??2:01, Joe Darcy wrote: > > Hello, > > > > If the javac test is only failing under -Xcomp, a reasonable avenue to > > investigate is that -Xcomp is misbehaving rather than the test code. > > > > Cheers, > > > > -Joe > > > > On 6/11/2019 10:56 PM, Jie Fu wrote: > >> Hi all, > >> > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225644 > >> Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ > >> > >> Reason: with -Xcomp, the signature was dumped as > >> "[Ljava/lang/String;" rather than "[Ljava.lang.String;". > >> Fix: It might be better to replace '/' with '.' before matching. > >> > >> Could you please review it? > >> > >> Thanks a lot. > >> Best regards, > >> Jie > >> > >> > From bsrbnd at gmail.com Wed Jun 12 10:18:24 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 12 Jun 2019 12:18:24 +0200 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> <578889a9-68d9-6f83-aac6-9fd9b2b8fddd@oracle.com> Message-ID: Thanks for both approvals. I'm not sure I'll have time to change 'break' to 'yield' and push this today. So, if this is still targeted to 13, feel free to take it to completion. Cheers, Bernard On Wed, 12 Jun 2019 at 11:57, Maurizio Cimadamore wrote: > > Modulo 'yield' vs 'break', this loos good. > > Maurizio > > On 11/06/2019 16:07, Jan Lahoda wrote: > > Hi Bernard, > > > > Looks good to me. Any comments, Maurizio? > > > > Thanks, > > Jan From ronshapiro at google.com Wed Jun 12 11:03:43 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 12 Jun 2019 07:03:43 -0400 Subject: Performance of Scope.getSymbolsByName() In-Reply-To: References: <76d97972-8fe0-647c-3a52-cb40e3d109de@oracle.com> <31799d48-c6de-89d5-5d52-c234f3056aa9@oracle.com> Message-ID: Great, thanks! On Wed, Jun 12, 2019, 5:54 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 12/06/2019 07:44, Jan Lahoda wrote: > > Hi Ron, > > > > I ran the tests, I think it looks OK. > > It is this patch, right: > > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/ > > > > Do you need a sponsor? Maurizio, any comments? > > I already approved this simpler fix few emails ago in this thread. Looks > good to me. > > Thanks > Maurizio > > > > > Thanks, > > Jan > > > > On 11. 06. 19 20:25, Ron Shapiro wrote: > >> Is there a way I can run those? Any way I can help get this in? > >> > >> On Thu, Jun 6, 2019 at 10:36 AM Jan Lahoda >> > wrote: > >> > >> Hi Ron, > >> > >> I think we should run it through the perf tests, just to be sure > >> (and I > >> didn't have time for that yet), but otherwise, I think that simple > >> change looks useful to me. > >> > >> Thanks, > >> Jan > >> > >> On 06. 06. 19 3:41, Ron Shapiro wrote: > >> > Friendly ping - is the first webrev ready for submission? > >> > > >> > On Thu, May 30, 2019, 7:09 PM Ron Shapiro >> > >> > >> > >> wrote: > >> > > >> > Do you have any other comments on the first webrev? Is there > >> > anything else we need to do to submit that? > >> > > >> > On Wed, May 22, 2019 at 11:00 AM Ron Shapiro > >> > >> > >> >> wrote: > >> > > >> > I think there still would be benefit in that as well, > >> as I'm > >> > seeing that come up in other contexts (as referenced in > >> the bug). > >> > > >> > On Wed, May 22, 2019 at 9:06 AM Jan Lahoda > >> > > >> >> > >> wrote: > >> > > >> > Sorry, I was too busy last few days. > >> > > >> > I was peeking at some possible improvements, but I > >> think I > >> > like Ron's > >> > first (.00) patch - that caches what can be cached > >> nicely. > >> > > >> > Looking at the testcase generated by Ron's reproducer > >> using: > >> > python test.py 7 > >> > > >> > and the (biggest) size of the outcome of: > >> > types.membersClosure(site, > >> false).getSymbolsByName(sym.name > >> > , cf) > >> > > >> > seems to be 13700 elements - which means the Scope > >> lookup > >> > and iteration > >> > runs ~13700 times, so avoiding these additional > >> lookup costs > >> > seems like > >> > a clear win. > >> > > >> > I have an idea that might speed up the iterations > >> through > >> > deeply nested > >> > CompoundScopes, although the effect of that in > >> combination > >> > with Ron's is > >> > going to be fairly limited, if any, I think. > >> > > >> > Jan > >> > > >> > On 22. 05. 19 12:24, Maurizio Cimadamore wrote: > >> > > This doesn't work. You are basically relying on > >> the order > >> > in which > >> > > symbols are entered in the members closure scope. > >> > > > >> > > In simple example like these: > >> > > > >> > > class A { > >> > > int m(List l) {return 0;} > >> > > } > >> > > > >> > > class B extends A { > >> > > int m(List l) {return 0;} > >> > > } > >> > > > >> > > > >> > > The logic you proposed will not work. That's > >> because we > >> > first see B::m - > >> > > and 'symbolByName' is empty at that stage; so we > >> add it > >> > there. Then we > >> > > do another round and see A::m - but we don't > >> really look > >> > there - given > >> > > that we first check to see if the symbol we're > >> > considering (sym) is > >> > > override-equivalent with B::m (the only symbol in > >> > symbolByName). And > >> > > that happens to be the case, since they are the > >> same > >> > symbol. So we exit > >> > > the loop, w/o having found any clash. > >> > > > >> > > In other words, symbolByName would need to also > >> contain > >> > A::m for the > >> > > code to see the clash - but that never happens; > >> by the > >> > time A::m is > >> > > added, is already too late. > >> > > > >> > > > >> > > I think caching the result of > >> > > > >> > > types.membersClosure(site, > >> > false).getSymbolsByName(sym.name > >> , cf) > >> > > > >> > > is a good measure. > >> > > > >> > > I'm a bit surprised that iteration is so slow > >> > (membersClosure is slow to > >> > > set up, but once you do it the results are > >> cached). So, > >> > rather than > >> > > tweaking the algorithm, I think it'd be better to > >> > investigate the reason > >> > > was to why asking a compound scope iterator is so > >> slow, > >> > which then would > >> > > yield dividends for the rest of the code as well. > >> > > > >> > > Maurizio > >> > > > >> > > > >> > > On 21/05/2019 21:21, Maurizio Cimadamore wrote: > >> > >> > >> > >> I see what you have done - I have to think > >> about it a > >> > bit to see if I > >> > >> can come up with some counter example. > >> > >> > >> > >> Thanks > >> > >> Maurizio > >> > >> > >> > >> On 21/05/2019 17:39, Ron Shapiro wrote: > >> > >>> Are the checks of the inner loop symmetrical? > >> > >>> > >> > >>> Currently it's checking m_i against (m_0..n - > >> m_i ). > >> > This second > >> > >>> webrev below would check it against > >> just (m_0..i-1 ), > >> > which albeit > >> > >>> still n^2, it divides by a factor of 2. > >> > >>> > >> > >>> (sorry if the subscripting here doesn't display > >> correctly) > >> > >>> > >> > >>> > >> http://cr.openjdk.java.net/~ronsh/8224161/webrev.01/ > >> > >>> > >> > >>> This feels conceptually logical to me, but > >> I'm not > >> > seeing a > >> > >>> measurable change by it. It looks a little bit > >> cleaner > >> > to me, but I'm > >> > >>> fine with either webrev given the benefits they > >> both bring. > >> > >>> > >> > >>> I can take a look in another thread about > >> speeding up > >> > CompoundScope > >> > >>> iteration. > >> > >>> > >> > >>> On Tue, May 21, 2019 at 8:05 AM Maurizio > >> Cimadamore > >> > >>> >> > >> > >> > > >> > >>> >> > >> > >> >>> wrote: > >> > >>> > >> > >>> > >> > >>> On 21/05/2019 12:16, Ron Shapiro wrote: > >> > >>>> I still think that something to optimize > >> the > >> > actual ScopeImpl > >> > >>>> Iterable is a worthwhile endeavor, as that > >> would > >> > alleviate the > >> > >>>> need to materialize here (and solve > >> hopefully the > >> > other issues > >> > >>>> I'm seeing), but I was having trouble > >> figuring out > >> > how to do > >> > >>>> that. This may be a good interim option > >> without > >> > much cost. > >> > >>> > >> > >>> Sure - I'm not opposed to optimizing the > >> iteration > >> > process - I > >> > >>> was expressing my skepticism w.r.t. making > >> > checkOverrideClash > >> > >>> simpler/non quadratic. > >> > >>> > >> > >>> Maurizio > >> > >>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> On Tue, May 21, 2019, 5:59 AM Maurizio > >> Cimadamore > >> > >>>> >> > >> > >> > > >> > >>>> >> > >> > >> >>> wrote: > >> > >>>> > >> > >>>> I think your fix is a good one. We > >> spent some > >> > cycles > >> > >>>> optimizing this, a bit odd we have > >> missed this :-) > >> > >>>> > >> > >>>> I'm very skeptical you can collapse > >> into a > >> > single loop, as > >> > >>>> this implement the logic in JLS > >> 8.4.8.3 [1] > >> > which, as you > >> > >>>> can see, is inherently quadratic > >> (for each > >> > method, we have > >> > >>>> to scan all methods with same name in > >> > supertypes to see if > >> > >>>> there is an override clash). The > >> algorithm > >> > that was there > >> > >>>> before wasn't - and it lead to the > >> wrong > >> > answers in tricky > >> > >>>> cases - so while you can get 80% there > >> with a > >> > non-quadratic > >> > >>>> algorithm, you will miss issues by > >> doing so. > >> > >>>> > >> > >>>> One thing that would help would be, > >> instead, > >> > to limit the > >> > >>>> analysis only in cases where it adds > >> value - > >> > for instance, > >> > >>>> if your hierarchy is just non-generic > >> classes > >> > (as in your > >> > >>>> example), then there's no way for > >> you to > >> > accidentally > >> > >>>> override a 'bridge' method, since no > >> bridges > >> > will be > >> > >>>> generated! But when looking at this, I > >> > couldn't find great > >> > >>>> ways to detect these conditions w/o > >> spending > >> > more time than > >> > >>>> the check itself. > >> > >>>> > >> > >>>> [1] - > >> > >>>> > >> > > >> > https://docs.oracle.com/javase/specs/jls/se12/html/jls-8.html#jls-8.4.8.3 > >> > >>>> > >> > >>>> Maurizio > >> > >>>> > >> > >>>> On 20/05/2019 21:58, Ron Shapiro wrote: > >> > >>>>> In the real world example, I'm seeing > >> the 40s > >> > that was > >> > >>>>> previously spent in > >> > Check.checkOverrideClashes drop to to > >> > >>>>> 9.5s when using this patch. Of that > >> 9.5, 8.9 > >> > is spent in > >> > >>>>> iterating through the > >> CompoundIterator and > >> > calling > >> > >>>>> getSymbolsByName. > >> > >>>>> > >> > >>>>> On Mon, May 20, 2019 at 4:34 PM Ron > >> Shapiro > >> > >>>>> >> > >> > >> > >> > >> > >> >>> wrote: > >> > >>>>> > >> > >>>>> This patch, which materializes the > >> > duplicate outer and > >> > >>>>> inner Iterables first into a > >> list. It > >> > removes the > >> > >>>>> entire section of the > >> CompoundIterator > >> > iteration from > >> > >>>>> the profile. > >> > >>>>> > >> > >>>>> webrev: > >> > >>>>> > >> > > >> > http://cr.openjdk.java.net/~ronsh/8224161/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java.sdiff.html > >> > >>>>> > >> > >>>>> I'm not sure it's the absolutely > >> correct > >> > solution as it > >> > >>>>> possibly masks an underlying > >> issue. > >> > >>>>> > >> > >>>>> I'm still seeing some time > >> spent in > >> > >>>>> MethodSymbol.overrides, > >> > Types.isSubSignature, and > >> > >>>>> Types.memberType, all of which > >> happen in > >> > the inner > >> > >>>>> loop. If we can remove those and > >> collapse > >> > the nested > >> > >>>>> loops into one, then this solution > >> isn't > >> > necessary and > >> > >>>>> it would also solve that > >> performance issue. > >> > >>>>> > >> > >>>>> On Fri, May 17, 2019 at 5:55 PM > >> Ron Shapiro > >> > >>>>> >> > >> > >> > >> > >> > >> >>> > >> > >>>>> wrote: > >> > >>>>> > >> > >>>>> I still have more to > >> investigate to > >> > fully wrap my > >> > >>>>> head around it, but I finally > >> found a > >> > sample > >> > >>>>> program that exhibits this. > >> Filed a > >> > bug here: > >> > >>>>> > >> https://bugs.openjdk.java.net/browse/JDK-8224161 > >> > >>>>> > >> > >>>>> On Fri, May 17, 2019 at 11:21 > >> AM Jan > >> > Lahoda > >> > >>>>> >> > >> > >> > > >> > >>>>> >> > >> > >> >>> wrote: > >> > >>>>> > >> > >>>>> Hi Ron, > >> > >>>>> > >> > >>>>> I am afraid it is hard to > >> guess > >> > what is the > >> > >>>>> problem without some > >> > >>>>> testcase. So, at least to me, > >> > having a sample > >> > >>>>> would be helpful. > >> > >>>>> > >> > >>>>> Thanks, > >> > >>>>> Jan > >> > >>>>> > >> > >>>>> On 17. 05. 19 0:41, Ron > >> Shapiro > >> > wrote: > >> > >>>>> > Hi, > >> > >>>>> > > >> > >>>>> > I'm observing a particularly > >> > bizarre > >> > >>>>> compilation. It's a single > >> file > >> > >>>>> > with annotation > >> processing, and > >> > the type that > >> > >>>>> is being compiled and > >> > >>>>> > processed has ~1000 declared > >> > and inherited > >> > >>>>> methods combined. The total > >> > >>>>> > compilation is 3 > >> minutes, but > >> > 65% of the > >> > >>>>> entire compilation is spent in > >> > >>>>> > 3 methods: > >> > >>>>> > > >> > >>>>> > >> > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(), > >> > >>>>> > >> > >>>>> > and Resolve.findField(). > >> > >>>>> > > >> > >>>>> > Looking at profiles, it > >> looks like > >> > >>>>> getSymbolsByName() is the > >> major > >> > >>>>> > culprit here. I initially > >> > thought the reason > >> > >>>>> was that there were far too > >> > >>>>> > many overloads (this > >> type had >600 > >> > >>>>> overloads...) and that > >> that was > >> > >>>>> > causing a bad regression > >> for the > >> > >>>>> pseudo-hashmap that > >> ScopeImpl uses. > >> > >>>>> > However, renaming the > >> methods > >> > did not > >> > >>>>> alleviate the build pain > >> and these > >> > >>>>> > methods continue to be > >> taking > >> > long amounts of > >> > >>>>> time. > >> > >>>>> > > >> > >>>>> > I was wondering what > >> could be > >> > done to improve > >> > >>>>> the performance of this > >> > >>>>> > code. It seemed to me that > >> > something like a > >> > >>>>> Map> > >> > >>>>> > could be a reasonable+modern > >> > replacement for > >> > >>>>> this table, which would > >> > >>>>> > naturally have a fast > >> > getSymbolsForName() > >> > >>>>> implementation. I'm having > >> > >>>>> > some trouble implementing it > >> > correctly, and I > >> > >>>>> believe it's partially > >> > >>>>> > related to not fully > >> > understanding some of > >> > >>>>> the semantics of the class. > >> > >>>>> > > >> > >>>>> > Does what I wrote make > >> sense to > >> > anyone, and > >> > >>>>> maybe spark a lightbulb? > >> > >>>>> > > >> > >>>>> > I'm trying to put together a > >> > repro in case > >> > >>>>> that helps, but I'm not 100% > >> > >>>>> > sure I even understand > >> what the > >> > regression > >> > >>>>> case is. > >> > >>>>> > > >> > >>>>> > Thanks for you help! > >> > >>>>> > >> > > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jun 12 12:59:43 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 12 Jun 2019 13:59:43 +0100 Subject: Inference Bug related to parametric polymorphism unification In-Reply-To: References: Message-ID: I took a look at the complete example, and simplified it to this: import java.util.*; import java.util.function.*; class Example { ??? public static FOLD_B foldLeft(BiFunction fn, FOLD_B b, Iterable as) { ??????? throw new UnsupportedOperationException(); ??? } ??? public static Iterable flatten(Iterable> aas) { ??????? throw new UnsupportedOperationException(); ??? } ??? public static Iterable map(Function fn, Iterable as) { ??????? throw new UnsupportedOperationException(); ??? } ??? public static Function, DEST_C> destructure(BiFunction fn) { ??????? throw new UnsupportedOperationException(); ??? } ??? public static void main(String[] args) { ??????? Map> headers = Collections.emptyMap(); ??????? // type-checks in 8, fails in 11/12 ??????? foldLeft( ??????????? (acc, h) -> acc, ??????????? 42, ??????????? flatten( ??????????????? map( ??????????????????? destructure((name, values) -> (Iterable>)null), ??????????????????? headers.entrySet() ??????????????? ) ??????????? ) ??????? ); ??? } } (I've renamed all type variables, for clarity). I believe the issue is the same as last time - there is a "race" between two implicit lambdas whose parameter type-variables have to be resolved eagerly: 1) (acc, h) -> acc (input variables are FOLD_A and FOLD_B, respectively - output var is FOLD_B) 2) (name, values) -> ... (input variables are DEST_A and DEST_B respectively - output var is DEST_C) Now, of course we'd like for input vars in (1) to be solved _after_ those in (2). But to do this we have to prove there's a dependency between the output var of (2) [DEST_C] and one of the input variables of (1) [FOLD_A, FOLD_B]. We can clearly see that there's no dependency between DEST_C and FOLD_B. They are completely unrelated. But what about FOLD_A? Things get tricky here - we have the following constraints: FLAT_A = FOLD_A MAP_B = Iterable DEST_C = MAP_B DEST_A = String DEST_B = List So, DEST_C can influence MAP_B, and MAP_B. But, unfortunately, the chain stops here. That's because it's MAP_B that depends on FLAT_A, not the other way around. The inference engine sees that MAP_B has a bound of Iterable, so it knows it must instantiate FLAT_A first to get at MAP_B. In other words, like last time, we have a case where there's no possible ordering (according to the spec) in which type variables must be solved eagerly. In other words, we're in this case (from JLS 18.5.2): "A subset of constraints is selected in C, satisfying the property that, for each constraint, no input variable can influence an output variable of another constraint in C. The terms /input variable/ and /output variable/ are defined below. An inference variable ? /can influence/ an inference variable ? if ? depends on the resolution of ? (?18.4 ), or vice versa; or if there exists a third inference variable ? such that ? can influence ? and ? can influence ?." Since the constraints for (1) and (2) are independent, see above, we must solve all of them at the same time: "The selected constraint(s) are removed from C. [...]? The input variables ?1, ..., ?m of all the selected constraint(s) are resolved." And this means that the eager instantiation you get will not take the body of the lambda in (1) into account (since that's not looked at during this process). Which means: FLAT_A = FOLD_A = Object MAP_B = Iterable DEST_C = Iterable DEST_A = String DEST_B = List Which doesn't give the desired answer. So, I believe the compiler is correct in rejecting the example. I also notice that the compiler doesn't really implement the spec to the letter here - that is, the spec mandates that _all_ the variables of all constraints in C must be solved at once; whereas javac choose an implementation specific order between the constraints in C, and then solves each of the constraint input variables independently. This can lead to issues like the one you experienced where, if this unspecified order changes from one release to the next (and we have been making changes in this area that could have affected this), you might get 'spurious' successes, because, by accident, the compiler managed to order constraints in the right way. But before we fix the compiler to be even stricter - I'd like to understand if we can't instead, in case of ties like these, improve the spec so that we force resolution of constraints of the kind T> where 'Expression' is the 'most nested' one between the other competing constraints (and then left to right, in case of depth-ties). I think this would give the behavior we want, and it would be intuitive, as developers won't be surprised, I think, to find out that variables are flowing from inner contexts outwards. I note for example that, if cycles are found in the set of constraint C, the spec goes to some length in trying to establish an order in which constraints should be picked inside C. But there's no similar treatment for when multiple constraints in C can go ahead at the same time - and that is unfortunate, because, like in this case, the fact that we cannot establish a direct chain of dependency between DEST_C and FLAT_A doesn't mean the two variables are completely unrelated. So, my question to Dan stands :-) Maurizio On 10/06/2019 16:19, John Napier wrote: > Hey Maurizio, > > My apologies; you?re right that the example doesn?t compile against 8 > - in my attempts to shrink the code that I have failing locally to the > minimal test case, I apparently lost something essential in the > translation. > > In the interest of avoiding further confusion, here is the full, > complicated example that compiles against 1.8 but fails to compile > without explicit type ascriptions in both 11 and 12: > > public static class Example { > > ? ? ? ? public static Iterable map(Function extends B> fn, Iterable as) { > ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? } > > ? ? ? ? public static Iterable flatten(Iterable> aas) { > ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? } > > ? ? ? ? public static B foldLeft(BiFunction A, ? extends B> fn, B b, Iterable as) { > ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? } > > ? ? ? ? public static C destructure(BiFunction super B, ? extends C> fn, > Map.Entry entry) { > ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? } > > ? ? ? ? public static Function, C> destructure( > ? ? ? ? ? ? BiFunction fn) { > ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? } > > ? ? ? ? public static Function> pair(K fn) { > ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? } > > ? ? ? ? public static final class Sink { > > ? ? ? ? ? ? public Sink add(String k, String v) { > ? ? ? ? ? ? ? ? throw new UnsupportedOperationException(); > ? ? ? ? ? ? } > ? ? ? ? } > > ? ? ? ? public static void main(String[] args) { > ? ? ? ? ? ? Map> headers = Collections.emptyMap(); > > ? ? ? ? ? ? // type-checks in 8, fails in 11/12 > ? ? ? ? ? ? foldLeft((acc, h) -> destructure(acc::add, h), > ? ? ? ? ? ? ? ? ? ? ?new Sink(), > ? ? ? ? ? ? ? ? ? ? ?flatten(map(destructure((name, values) -> > map(pair(name), values)), headers.entrySet()))); > ? ? ? ? } > ? ? } > > Again, so sorry for the confusion. > > Same question as before: should *that* code continue to compile, or is > it correct that it fails to compile in 11 / 12? > > Cheers, > John >> On Jun 10, 2019, at 6:33 AM, Maurizio Cimadamore >> > > wrote: >> >> Hi John >> I've been trying to reproduce, but for me the example fails even in 8... >> >> That said, I agree that there could be something fishy here; I did >> some experiments with variations of your example, and it looks like >> javac can undrestand what the typing of `destructure(Pair::new, >> entry)` is, in isolation - you can see that by adding this statement: >> >> Object o = (String)destructure(Pair::new, entry); >> >> This will trigger this error: >> >> error: incompatible types: Pair cannot be converted to >> String >> Object o = (String)destructure(Pair::new, entry); >> >> Which seems to confirm that javac is indeed capable of inferring A >> and B to String and take it from there. >> >> My suspicion is that when you nest these expressions inside each >> other, you create a 'bigger' inference context, where two expressions >> cannot be evaluated (we call them 'stuck'): >> >> * Pair::new (indirect method reference) >> * (x, y) -> x + y (implicit lambda) >> >> To break this tie, the compiler has to choose which inference >> variable to instantiate first: the outer { A, B }, or the innermost >> ones? This choice is, at its core, driven by the spec 18.5.2 (see >> [1]). In your example we have these inference variables: >> >> * A#inner, B#inner and C#inner (from innermost invocation of >> 'destructure') >> * A#outer, B#outer and C#outer (from outermost invocation of >> 'destructure') >> >> This analysis is based on the concept of input/output inference >> variable - in this case: >> >> * A#inner,B#inner influence C#inner >> * A#outer,B#outer influence C#outer >> >> So far, if we had to choose between these two constraints, the choice >> would be non-deterministic (as the two input/output constraints are >> mirroring each other). But there's another dependency here: >> >> * C#inner <: Entry >> >> Now, from a programmer perspective, looking at the way the code is >> written, it's clear we'd like solution of C#inner to influence >> A#outer, B#outer. But I don't think that's the way the spec works. In >> this case the spec says that C#inner 'depends' on A#outer, C#outer. >> >> So we really have no way >> >> That's because the result of the innermost call to 'destructure' is >> passed to the outermost call, so the inferred type for C#inner can >> affect the inferred Entry. >> >> So, we are basically left with what I think is an non-deterministic >> choice between eagerly resolving { A#inner, B#inner } or { A#outer, >> B#outer }. Unfortunately, picking the former makes the code pass, >> whereas picking the latter makes compilation fail (because at that >> time we don't know any better than just instantiating A#outer and >> B#outer to Object). >> >> If this is the issue, inference could to a better job, by either >> looking at presence of other 'more meaningful' bounds on? {A#inner, >> B#inner} (although defining 'more meaningful might be problematic). >> Or it could just give precedence to innermost variables in case of a >> tie, which is a rule that I think programmers will find natural. >> Currently though, these 'extensions' are not part of the JLS - so the >> behavior here is, essentially, unspecified. >> >> At the same time, there's also an argument to be had as to whether >> the code here isn't inherently buggy - essentially, { A, B, C } in >> the 'destructure' method are all independent variables so, in a way, >> the problem is *underconstrained* (e.g. there's no real objective >> choice for which variable to solve first, other than resorting to >> heuristics, whose mileage can vary). >> >> Note that your second call works simply because, by adding the >> explicit type param on the method reference receiver, you make the >> method reference 'direct' meaning its type is evaluated *ahead* of >> the lambda. Basically you told the compiler which of the two 'stuck' >> expression should be solved first. >> >> @Dan - is this something that has been discussed before in spec-land? >> >> Cheers >> Maurizio >> >> [1] - >> https://docs.oracle.com/javase/specs/jls/se12/html/jls-18.html#jls-18.5.2.2 >> >> On 06/06/2019 20:31, John Napier wrote: >>> Hi all, >>> >>> The following code compiles against oracle64-1.8.0.162 but fails on >>> both openjdk64-11.0.2 and oracle64-12.0.1: >>> >>> public static class Example { >>> >>> ? ? ? ? public static class Pair implements Map.Entry { >>> ? ? ? ? ? ? private final A a; >>> ? ? ? ? ? ? private final B b; >>> >>> ? ? ? ? ? ? public Pair(A a, B b) { >>> ? ? ? ? ? ? ? ? this.a = a; >>> ? ? ? ? ? ? ? ? this.b = b; >>> ? ? ? ? ? ? } >>> >>> ? ? ? ? ? ? @Override >>> ? ? ? ? ? ? public A getKey() { >>> ? ? ? ? ? ? ? ? return a; >>> ? ? ? ? ? ? } >>> >>> ? ? ? ? ? ? @Override >>> ? ? ? ? ? ? public B getValue() { >>> ? ? ? ? ? ? ? ? return b; >>> ? ? ? ? ? ? } >>> >>> ? ? ? ? ? ? @Override >>> ? ? ? ? ? ? public B setValue(B value) { >>> ? ? ? ? ? ? ? ? throw new UnsupportedOperationException(); >>> ? ? ? ? ? ? } >>> ? ? ? ? } >>> >>> ? ? ? ? public static C destructure(BiFunction >>> fn, Map.Entry entry) { >>> ? ? ? ? ? ? return fn.apply(entry.getKey(), entry.getValue()); >>> ? ? ? ? } >>> >>> ? ? ? ? public static void main(String[] args) { >>> ? ? ? ? ? ? Map.Entry entry = new Pair<>("foo", "bar"); >>> >>> ? ? ? ? ? ? // ill-typed >>> ? ? ? ? ? ? String inferred = destructure((x, y) -> x + y, >>> destructure(Pair::new, entry)); >>> >>> ? ? ? ? ? ? // well-typed >>> ? ? ? ? ? ? String ascribed = destructure((x, y) -> x + y, >>> destructure(Pair::new, entry)); >>> ? ? ? ? } >>> ? ? } >>> >>> Before submitting more bugs of this same ilk, albeit with slight >>> variations in occurrence, I must ask: this is not the intentional >>> modern behavior, correct? Inference should still work as illustrated >>> above, right? >>> >>> Cheers, >>> >>> -John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Jun 12 15:12:04 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Jun 2019 08:12:04 -0700 Subject: Altering AST with javac Plugin In-Reply-To: References: Message-ID: On 6/11/19 11:30 PM, Gunnar Morling wrote: > Hi, > > I recently came across a javac plug-in (i.e. implementation > of?com.sun.source.util.Plugin) which alters/amends the AST of the > classes under compilation. > > Is this an "officially" foreseen usage of that plug-in API? Or i this > rather a hack akin to annotation processor implementations that cast > the model types to the javac-internal ones in order to modify them? > I'm curious, because those AST-modifying annotation processors are > troublesome to deal?with for other processors which won't "see" those > amendments, so I'm wondering whether one would or would not have > similar issues when altering the AST with such c.s.s.u.Plugin > implementation. > > Thanks, > > --Gunnar > Gunnar, There is no publicly supported API in the jdk.compiler module (or any other module) for modifying an AST during a compilation.? Does that answer your question? -- Jon From yumin.qi at gmail.com Wed Jun 12 19:11:59 2019 From: yumin.qi at gmail.com (yumin qi) Date: Wed, 12 Jun 2019 12:11:59 -0700 Subject: javac warning: no comment Message-ID: HI, I encountered strange compilation warning when building jdk changeset: 55349:139f21bad9fd tag: tip user: iignatyev date: Wed Jun 12 11:48:14 2019 -0700 summary: 8158048: Fix failure message from jtreg gtest wrapper What I changed is adding one field (I am working on bug 8222373) to ClassLoader.java: public abstract class ClassLoader { private static native void registerNatives(); + private static native boolean getShared(); static { registerNatives(); + isShared = getShared(); } // The parent class loader for delegation @@ -249,7 +251,8 @@ // a string for exception message printing private final String nameAndId; - + // CDS enabled + public final static boolean isShared; /home/ws/openjdk/13/jdk/src/java.base/share/classes/java/lang/ClassLoader.java:255: warning: no comment public final static boolean isShared; ^ error: warnings found and -Werror specified 1 error 1 warning Does anybody know what is the problem here? If I code a simple java class, and do the same thing for a public final static variable, it is OK. Thanks Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Jun 12 19:23:37 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Jun 2019 12:23:37 -0700 Subject: javac warning: no comment In-Reply-To: References: Message-ID: Yumin, It looks like you have doclint enabled, and it is warning you that there is no documentation comment on the public field you have added. -- Jon On 6/12/19 12:11 PM, yumin qi wrote: > HI, > > I encountered strange compilation warning when building jdk > changeset: 55349:139f21bad9fd > tag: tip > user: iignatyev > date: Wed Jun 12 11:48:14 2019 -0700 > summary: 8158048: Fix failure message from jtreg gtest wrapper > > What I changed is adding one field (I am working on bug 8222373) to > ClassLoader.java: > > public abstract class ClassLoader { > > private static native void registerNatives(); > + private static native boolean getShared(); > static { > registerNatives(); > + isShared = getShared(); > } > > // The parent class loader for delegation > @@ -249,7 +251,8 @@ > > // a string for exception message printing > private final String nameAndId; > - > + // CDS enabled > + public final static boolean isShared; > > /home/ws/openjdk/13/jdk/src/java.base/share/classes/java/lang/ClassLoader.java:255: > warning: no comment > public final static boolean isShared; > ^ > error: warnings found and -Werror specified > 1 error > 1 warning > > Does anybody know what is the problem here? If I code a simple java > class, and do the same thing for a public final static variable, it is OK. > > Thanks > Yumin From gunnar at hibernate.org Wed Jun 12 20:36:55 2019 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 12 Jun 2019 22:36:55 +0200 Subject: Altering AST with javac Plugin In-Reply-To: References: Message-ID: Yes, it does. Thanks, Jon! --Gunnar Am Mi., 12. Juni 2019 um 17:12 Uhr schrieb Jonathan Gibbons < jonathan.gibbons at oracle.com>: > > On 6/11/19 11:30 PM, Gunnar Morling wrote: > > Hi, > > > > I recently came across a javac plug-in (i.e. implementation > > of com.sun.source.util.Plugin) which alters/amends the AST of the > > classes under compilation. > > > > Is this an "officially" foreseen usage of that plug-in API? Or i this > > rather a hack akin to annotation processor implementations that cast > > the model types to the javac-internal ones in order to modify them? > > I'm curious, because those AST-modifying annotation processors are > > troublesome to deal with for other processors which won't "see" those > > amendments, so I'm wondering whether one would or would not have > > similar issues when altering the AST with such c.s.s.u.Plugin > > implementation. > > > > Thanks, > > > > --Gunnar > > > > Gunnar, > > There is no publicly supported API in the jdk.compiler module (or any > other module) for modifying an AST during a compilation. Does that > answer your question? > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Jun 13 01:14:20 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 12 Jun 2019 18:14:20 -0700 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> Message-ID: <1baadd34-b49e-4d94-88fd-452982e5447d@oracle.com> Hi Jie, To a first approximation, javac's output should predictably rely in its inputs. In other words, the output of javac, and by extension the success or failure of one its regression tests, should be independent of running under a particular HotSpot mode/configuration. If test success/failure is dependent on a mode or configuration, I would suggest eliminating a VM issue as a cause before looking to update the test. HTH, -Joe On 6/11/2019 11:14 PM, Jie Fu wrote: > Hi Joe, > > Thanks for your review. > Do you mean the JIT shouldn't dump the signature like > "[Ljava/lang/String;"? > > I'd like to do more investigation. > Thanks. > > Best regards, > Jie > > On 2019/6/12 ??2:01, Joe Darcy wrote: >> Hello, >> >> If the javac test is only failing under -Xcomp, a reasonable avenue >> to investigate is that -Xcomp is misbehaving rather than the test code. >> >> Cheers, >> >> -Joe >> >> On 6/11/2019 10:56 PM, Jie Fu wrote: >>> Hi all, >>> >>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8225644 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ >>> >>> Reason: with -Xcomp, the signature was dumped as >>> "[Ljava/lang/String;" rather than "[Ljava.lang.String;". >>> Fix: It might be better to replace '/' with '.' before matching. >>> >>> Could you please review it? >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> > From fujie at loongson.cn Thu Jun 13 01:32:11 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 13 Jun 2019 09:32:11 +0800 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: <1baadd34-b49e-4d94-88fd-452982e5447d@oracle.com> References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> <1baadd34-b49e-4d94-88fd-452982e5447d@oracle.com> Message-ID: <8683bbe4-23f1-31f5-8c38-0bcf23d75f74@loongson.cn> Hi Joe, On 2019/6/13 ??9:14, Joe Darcy wrote: > If test success/failure is dependent on a mode or configuration, I > would suggest eliminating a VM issue as a cause before looking to > update the test. Thanks for your suggestion. Work is in progress now. Best regards, Jie From fujie at loongson.cn Thu Jun 13 03:18:55 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 13 Jun 2019 11:18:55 +0800 Subject: RFR: 8225644: [TESTBUG] langtools/tools/javac/generics/inference/8058199/T8058199.java fails with -Xcomp In-Reply-To: References: <0f8b85ed-9fd8-5763-03ba-f26a527c9dbc@loongson.cn> <54c2af0e-cf69-f5a2-d3bb-e2632253baad@oracle.com> <23f4fbf6-786b-fbd7-8d7f-16dc547ade13@loongson.cn> Message-ID: <3734a50d-6d4e-0c97-44cf-5616c6db4509@loongson.cn> Hi Bernard, Thanks for your great help. I've updated the description of the JBS. And will send a new RFR to hotspot-compiler-dev at openjdk.java.net soon. Thanks a lot. Best regards, Jie On 2019/6/12 ??6:09, B. Blaser wrote: > [ Forwarding to hotspot-compiler-dev ] > > The CCE messages are probably generated here: > > http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l301 > http://hg.openjdk.java.net/jdk/jdk/file/755e82641224/src/hotspot/share/runtime/sharedRuntime.hpp#l315 > > Note that the second one might be called from interpreted code and > seems to generate the expected message. > > I hope this helps, > Bernard > > On Wed, 12 Jun 2019 at 08:15, Jie Fu wrote: >> Hi Joe, >> >> Thanks for your review. >> Do you mean the JIT shouldn't dump the signature like "[Ljava/lang/String;"? >> >> I'd like to do more investigation. >> Thanks. >> >> Best regards, >> Jie >> >> On 2019/6/12 ??2:01, Joe Darcy wrote: >>> Hello, >>> >>> If the javac test is only failing under -Xcomp, a reasonable avenue to >>> investigate is that -Xcomp is misbehaving rather than the test code. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 6/11/2019 10:56 PM, Jie Fu wrote: >>>> Hi all, >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8225644 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8225644/webrev.00/ >>>> >>>> Reason: with -Xcomp, the signature was dumped as >>>> "[Ljava/lang/String;" rather than "[Ljava.lang.String;". >>>> Fix: It might be better to replace '/' with '.' before matching. >>>> >>>> Could you please review it? >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jie >>>> >>>> From jan.lahoda at oracle.com Thu Jun 13 05:21:43 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 13 Jun 2019 07:21:43 +0200 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> <578889a9-68d9-6f83-aac6-9fd9b2b8fddd@oracle.com> Message-ID: Done, but I didn't change the changeset author correctly. I apologize for that - the correct author should have been Bernard. Jan On 12. 06. 19 12:18, B. Blaser wrote: > Thanks for both approvals. > > I'm not sure I'll have time to change 'break' to 'yield' and push this today. > So, if this is still targeted to 13, feel free to take it to completion. > > Cheers, > Bernard > > On Wed, 12 Jun 2019 at 11:57, Maurizio Cimadamore > wrote: >> >> Modulo 'yield' vs 'break', this loos good. >> >> Maurizio >> >> On 11/06/2019 16:07, Jan Lahoda wrote: >>> Hi Bernard, >>> >>> Looks good to me. Any comments, Maurizio? >>> >>> Thanks, >>> Jan From yumin.qi at gmail.com Wed Jun 12 22:18:15 2019 From: yumin.qi at gmail.com (yumin qi) Date: Wed, 12 Jun 2019 15:18:15 -0700 Subject: javac warning: no comment In-Reply-To: References: Message-ID: Jonathan Thanks. I see the warning is for 'public' field. Could change to private for it. Thanks Yumin On Wed, Jun 12, 2019 at 12:23 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Yumin, > > It looks like you have doclint enabled, and it is warning you that there > is no documentation comment on the public field you have added. > > -- Jon > > On 6/12/19 12:11 PM, yumin qi wrote: > > HI, > > > > I encountered strange compilation warning when building jdk > > changeset: 55349:139f21bad9fd > > tag: tip > > user: iignatyev > > date: Wed Jun 12 11:48:14 2019 -0700 > > summary: 8158048: Fix failure message from jtreg gtest wrapper > > > > What I changed is adding one field (I am working on bug 8222373) to > > ClassLoader.java: > > > > public abstract class ClassLoader { > > > > private static native void registerNatives(); > > + private static native boolean getShared(); > > static { > > registerNatives(); > > + isShared = getShared(); > > } > > > > // The parent class loader for delegation > > @@ -249,7 +251,8 @@ > > > > // a string for exception message printing > > private final String nameAndId; > > - > > + // CDS enabled > > + public final static boolean isShared; > > > > > /home/ws/openjdk/13/jdk/src/java.base/share/classes/java/lang/ClassLoader.java:255: > > warning: no comment > > public final static boolean isShared; > > ^ > > error: warnings found and -Werror specified > > 1 error > > 1 warning > > > > Does anybody know what is the problem here? If I code a simple java > > class, and do the same thing for a public final static variable, it is > OK. > > > > Thanks > > Yumin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Jun 13 17:52:56 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 13 Jun 2019 19:52:56 +0200 Subject: RFR JDK-8220018: javac crash when compiling try-catch-finally inside switch expression In-Reply-To: References: <5a53a2cd-3be9-8e28-3d27-642cbb0e6fa0@oracle.com> <52f3cc42-811d-7125-9e56-d32d630a0bf4@oracle.com> <578889a9-68d9-6f83-aac6-9fd9b2b8fddd@oracle.com> Message-ID: No problem Jan, you did most of the work on this fix and I was really to busy to push it. Cheers, Bernard On Thu, 13 Jun 2019 at 07:21, Jan Lahoda wrote: > > Done, but I didn't change the changeset author correctly. I apologize > for that - the correct author should have been Bernard. > > Jan > > On 12. 06. 19 12:18, B. Blaser wrote: > > Thanks for both approvals. > > > > I'm not sure I'll have time to change 'break' to 'yield' and push this today. > > So, if this is still targeted to 13, feel free to take it to completion. > > > > Cheers, > > Bernard > > > > On Wed, 12 Jun 2019 at 11:57, Maurizio Cimadamore > > wrote: > >> > >> Modulo 'yield' vs 'break', this loos good. > >> > >> Maurizio > >> > >> On 11/06/2019 16:07, Jan Lahoda wrote: > >>> Hi Bernard, > >>> > >>> Looks good to me. Any comments, Maurizio? > >>> > >>> Thanks, > >>> Jan From joe.darcy at oracle.com Thu Jun 13 23:06:39 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 13 Jun 2019 16:06:39 -0700 Subject: JDK 14 RFR of JDK-8222369: ExecutableElement.getReceiverType returns null instead of NOTYPE In-Reply-To: References: Message-ID: <5D02D6FF.4010107@oracle.com> Hello, Now that there is a line of development for JDK 14 separate from JDK 13, please review the fix and CSR for JDK-8222369: ExecutableElement.getReceiverType returns null instead of NOTYPE webrev: http://cr.openjdk.java.net/~darcy/8222369.1/ CSR: https://bugs.openjdk.java.net/browse/JDK-8225755 For ElementStructureTest.java, I mapped back the results of getReceiverType to null to verify no other behavior of the method was unintentionally changed. The hashes used for comparison in the test could be updated instead. Since there is the possibility users of the method might have worked around its old behavior, getting the fix into build 01 of JDK 14 maximizes the time to flush out any behavioral incompatibilities. Thanks, -Joe On 6/6/2019 2:52 PM, Joe Darcy wrote: > Hello, > > Please review the fix for > > JDK-8222369: ExecutableElement.getReceiverType returns null > instead of NOTYPE > http://cr.openjdk.java.net/~darcy/8222369.0/ > > In the javac implementation, the getReceiverType method is pulled up > to the root of the hierarchy and is defined to return null. > > The hashing in tools/javac/ElementStructureTest will also need to be > adjusted when this fix goes in since that test does factor the result > of getReceiver type into its hash. > > Thanks, > > -Joe > From jonathan.gibbons at oracle.com Thu Jun 13 23:21:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Jun 2019 16:21:55 -0700 Subject: JDK 14 RFR of JDK-8222369: ExecutableElement.getReceiverType returns null instead of NOTYPE In-Reply-To: <5D02D6FF.4010107@oracle.com> References: <5D02D6FF.4010107@oracle.com> Message-ID: OK. I think the method to fix ElementStructureTest is clever, as a way of minimally changing an existing test to test the change in behavior, but now that we have verified the change in behavior, it might be nice to simplify ElementStructureTest to remove that part of the change. That could be done later, if you want, but if you leave ElementStructureTest functionally as-is, I suggest you add a comment to the typeMirorTranslate method to explain what might seem to be strange behavior with anyone not familiar with this part of its history. -- Jon On 06/13/2019 04:06 PM, Joseph D. Darcy wrote: > Hello, > > Now that there is a line of development for JDK 14 separate from JDK > 13, please review the fix and CSR for > > ??? JDK-8222369: ExecutableElement.getReceiverType returns null > instead of NOTYPE > ??? webrev: http://cr.openjdk.java.net/~darcy/8222369.1/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8225755 > > For ElementStructureTest.java, I mapped back the results of > getReceiverType to null to verify no other behavior of the method was > unintentionally changed. The hashes used for comparison in the test > could be updated instead. > > Since there is the possibility users of the method might have worked > around its old behavior, getting the fix into build 01 of JDK 14 > maximizes the time to flush out any behavioral incompatibilities. > > Thanks, > > -Joe > > > On 6/6/2019 2:52 PM, Joe Darcy wrote: >> Hello, >> >> Please review the fix for >> >> ??? JDK-8222369: ExecutableElement.getReceiverType returns null >> instead of NOTYPE >> ??? http://cr.openjdk.java.net/~darcy/8222369.0/ >> >> In the javac implementation, the getReceiverType method is pulled up >> to the root of the hierarchy and is defined to return null. >> >> The hashing in tools/javac/ElementStructureTest will also need to be >> adjusted when this fix goes in since that test does factor the result >> of getReceiver type into its hash. >> >> Thanks, >> >> -Joe >> > From alex.buckley at oracle.com Thu Jun 13 23:48:09 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 13 Jun 2019 16:48:09 -0700 Subject: JDK 14 RFR of JDK-8222369: ExecutableElement.getReceiverType returns null instead of NOTYPE In-Reply-To: <5D02D6FF.4010107@oracle.com> References: <5D02D6FF.4010107@oracle.com> Message-ID: <5D02E0B9.3030404@oracle.com> On 6/13/2019 4:06 PM, Joseph D. Darcy wrote: > Now that there is a line of development for JDK 14 separate from JDK 13, > please review the fix and CSR for > > JDK-8222369: ExecutableElement.getReceiverType returns null instead > of NOTYPE > webrev: http://cr.openjdk.java.net/~darcy/8222369.1/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8225755 Added myself as a reviewer to the CSR, and made some minor edits for clarity. Alex From bsrbnd at gmail.com Fri Jun 14 17:53:48 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 14 Jun 2019 19:53:48 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> Message-ID: As shared code is affected, I've pushed it to jdk/submit to make sure all is right on every supported systems: http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 I've added a configuration to the failing test which might be kept when pushing to jdk/jdk providing that we get a Reviewer approval from the langtools team for this? Thanks, Bernard On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: > > Hi Bernard, > > Thank you for your review. > And could you please sponsor it? > > Thanks a lot. > Best regards, > Jie > > > On 2019/6/14 ??1:45, B. Blaser wrote: > > > Seems good to me too. > > > > Thanks, > > Bernard > > > > On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: > >> Thanks Vladimir Ivanov for your review. > >> > >> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: > >>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ > >>> Looks good. > >>> > >>> Best regards, > >>> Vladimir Ivanov > From fujie at loongson.cn Sat Jun 15 00:27:41 2019 From: fujie at loongson.cn (Jie Fu) Date: Sat, 15 Jun 2019 08:27:41 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> Message-ID: <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Thanks Bernard. I see all tests on mach5 have passed. And could I get one more review from the langtools team for the change[1]? Thanks a lot. Best regards, Jie [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 On 2019/6/15 ??1:53, B. Blaser wrote: > As shared code is affected, I've pushed it to jdk/submit to make sure > all is right on every supported systems: > > http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > > I've added a configuration to the failing test which might be kept > when pushing to jdk/jdk providing that we get a Reviewer approval from > the langtools team for this? > > Thanks, > Bernard > > On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: >> Hi Bernard, >> >> Thank you for your review. >> And could you please sponsor it? >> >> Thanks a lot. >> Best regards, >> Jie >> >> >> On 2019/6/14 ??1:45, B. Blaser wrote: >> >>> Seems good to me too. >>> >>> Thanks, >>> Bernard >>> >>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: >>>> Thanks Vladimir Ivanov for your review. >>>> >>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ >>>>> Looks good. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From jnape09 at gmail.com Sat Jun 15 21:55:16 2019 From: jnape09 at gmail.com (John Napier) Date: Sat, 15 Jun 2019 16:55:16 -0500 Subject: Inference Bug related to parametric polymorphism unification In-Reply-To: References: Message-ID: <33A2476E-A9C0-44A4-A77D-710557152ABE@gmail.com> Thanks for the wonderfully detailed analysis, Maurizio. For whatever it?s worth, I can say that for those of us trying to write more FP-oriented code in Java, expressions relying on inference in this way are extremely common (I ran into a multitude of these while trying to upgrade a code base from Java 8 to 11). I definitely think that your suggestions (or ?musings" if suggestions is too strong a word) for choosing the most deeply nested expression as the unification reference would be an improvement over the current situation from a user's perspective, provided it doesn?t lead to a dramatically slower compilation time. Thanks again for the attention, -John > On Jun 12, 2019, at 7:59 AM, Maurizio Cimadamore wrote: > > I took a look at the complete example, and simplified it to this: > > import java.util.*; > import java.util.function.*; > > class Example { > > public static FOLD_B foldLeft(BiFunction fn, FOLD_B b, Iterable as) { > throw new UnsupportedOperationException(); > } > > public static Iterable flatten(Iterable> aas) { > throw new UnsupportedOperationException(); > } > > public static Iterable map(Function fn, Iterable as) { > throw new UnsupportedOperationException(); > } > > public static Function, DEST_C> destructure(BiFunction fn) { > throw new UnsupportedOperationException(); > } > > public static void main(String[] args) { > Map> headers = Collections.emptyMap(); > > // type-checks in 8, fails in 11/12 > foldLeft( > (acc, h) -> acc, > 42, > flatten( > map( > destructure((name, values) -> (Iterable>)null), > headers.entrySet() > ) > ) > ); > } > } > > (I've renamed all type variables, for clarity). > > I believe the issue is the same as last time - there is a "race" between two implicit lambdas whose parameter type-variables have to be resolved eagerly: > > 1) (acc, h) -> acc (input variables are FOLD_A and FOLD_B, respectively - output var is FOLD_B) > > 2) (name, values) -> ... (input variables are DEST_A and DEST_B respectively - output var is DEST_C) > > Now, of course we'd like for input vars in (1) to be solved _after_ those in (2). But to do this we have to prove there's a dependency between the output var of (2) [DEST_C] and one of the input variables of (1) [FOLD_A, FOLD_B]. > > We can clearly see that there's no dependency between DEST_C and FOLD_B. They are completely unrelated. But what about FOLD_A? Things get tricky here - we have the following constraints: > > FLAT_A = FOLD_A > MAP_B = Iterable > DEST_C = MAP_B > DEST_A = String > DEST_B = List > > So, DEST_C can influence MAP_B, and MAP_B. But, unfortunately, the chain stops here. That's because it's MAP_B that depends on FLAT_A, not the other way around. The inference engine sees that MAP_B has a bound of Iterable, so it knows it must instantiate FLAT_A first to get at MAP_B. > > In other words, like last time, we have a case where there's no possible ordering (according to the spec) in which type variables must be solved eagerly. In other words, we're in this case (from JLS 18.5.2): > > "A subset of constraints is selected in C, satisfying the property that, for each constraint, no input variable can influence an output variable of another constraint in C. The terms input variable and output variable are defined below. An inference variable ? can influence an inference variable ? if ? depends on the resolution of ? (?18.4 ), or vice versa; or if there exists a third inference variable ? such that ? can influence ? and ? can influence ?." > > Since the constraints for (1) and (2) are independent, see above, we must solve all of them at the same time: > > "The selected constraint(s) are removed from C. [...] The input variables ?1, ..., ?m of all the selected constraint(s) are resolved." > > And this means that the eager instantiation you get will not take the body of the lambda in (1) into account (since that's not looked at during this process). Which means: > > FLAT_A = FOLD_A = Object > MAP_B = Iterable > DEST_C = Iterable > DEST_A = String > DEST_B = List > > Which doesn't give the desired answer. > > So, I believe the compiler is correct in rejecting the example. > > I also notice that the compiler doesn't really implement the spec to the letter here - that is, the spec mandates that _all_ the variables of all constraints in C must be solved at once; whereas javac choose an implementation specific order between the constraints in C, and then solves each of the constraint input variables independently. This can lead to issues like the one you experienced where, if this unspecified order changes from one release to the next (and we have been making changes in this area that could have affected this), you might get 'spurious' successes, because, by accident, the compiler managed to order constraints in the right way. > > But before we fix the compiler to be even stricter - I'd like to understand if we can't instead, in case of ties like these, improve the spec so that we force resolution of constraints of the kind T> where 'Expression' is the 'most nested' one between the other competing constraints (and then left to right, in case of depth-ties). I think this would give the behavior we want, and it would be intuitive, as developers won't be surprised, I think, to find out that variables are flowing from inner contexts outwards. > > I note for example that, if cycles are found in the set of constraint C, the spec goes to some length in trying to establish an order in which constraints should be picked inside C. But there's no similar treatment for when multiple constraints in C can go ahead at the same time - and that is unfortunate, because, like in this case, the fact that we cannot establish a direct chain of dependency between DEST_C and FLAT_A doesn't mean the two variables are completely unrelated. > > So, my question to Dan stands :-) > > Maurizio > > > > > > > > On 10/06/2019 16:19, John Napier wrote: >> Hey Maurizio, >> >> My apologies; you?re right that the example doesn?t compile against 8 - in my attempts to shrink the code that I have failing locally to the minimal test case, I apparently lost something essential in the translation. >> >> In the interest of avoiding further confusion, here is the full, complicated example that compiles against 1.8 but fails to compile without explicit type ascriptions in both 11 and 12: >> >> public static class Example { >> >> public static Iterable map(Function fn, Iterable as) { >> throw new UnsupportedOperationException(); >> } >> >> public static Iterable flatten(Iterable> aas) { >> throw new UnsupportedOperationException(); >> } >> >> public static B foldLeft(BiFunction fn, B b, Iterable as) { >> throw new UnsupportedOperationException(); >> } >> >> public static C destructure(BiFunction fn, >> Map.Entry entry) { >> throw new UnsupportedOperationException(); >> } >> >> public static Function, C> destructure( >> BiFunction fn) { >> throw new UnsupportedOperationException(); >> } >> >> public static Function> pair(K fn) { >> throw new UnsupportedOperationException(); >> } >> >> public static final class Sink { >> >> public Sink add(String k, String v) { >> throw new UnsupportedOperationException(); >> } >> } >> >> public static void main(String[] args) { >> Map> headers = Collections.emptyMap(); >> >> // type-checks in 8, fails in 11/12 >> foldLeft((acc, h) -> destructure(acc::add, h), >> new Sink(), >> flatten(map(destructure((name, values) -> map(pair(name), values)), headers.entrySet()))); >> } >> } >> >> Again, so sorry for the confusion. >> >> Same question as before: should *that* code continue to compile, or is it correct that it fails to compile in 11 / 12? >> >> Cheers, >> John >>> On Jun 10, 2019, at 6:33 AM, Maurizio Cimadamore > wrote: >>> >>> Hi John >>> I've been trying to reproduce, but for me the example fails even in 8... >>> >>> That said, I agree that there could be something fishy here; I did some experiments with variations of your example, and it looks like javac can undrestand what the typing of `destructure(Pair::new, entry)` is, in isolation - you can see that by adding this statement: >>> >>> Object o = (String)destructure(Pair::new, entry); >>> >>> This will trigger this error: >>> >>> error: incompatible types: Pair cannot be converted to String >>> Object o = (String)destructure(Pair::new, entry); >>> >>> >>> Which seems to confirm that javac is indeed capable of inferring A and B to String and take it from there. >>> >>> My suspicion is that when you nest these expressions inside each other, you create a 'bigger' inference context, where two expressions cannot be evaluated (we call them 'stuck'): >>> >>> * Pair::new (indirect method reference) >>> * (x, y) -> x + y (implicit lambda) >>> >>> To break this tie, the compiler has to choose which inference variable to instantiate first: the outer { A, B }, or the innermost ones? This choice is, at its core, driven by the spec 18.5.2 (see [1]). In your example we have these inference variables: >>> >>> * A#inner, B#inner and C#inner (from innermost invocation of 'destructure') >>> * A#outer, B#outer and C#outer (from outermost invocation of 'destructure') >>> >>> This analysis is based on the concept of input/output inference variable - in this case: >>> >>> * A#inner,B#inner influence C#inner >>> * A#outer,B#outer influence C#outer >>> >>> So far, if we had to choose between these two constraints, the choice would be non-deterministic (as the two input/output constraints are mirroring each other). But there's another dependency here: >>> >>> * C#inner <: Entry >>> >>> Now, from a programmer perspective, looking at the way the code is written, it's clear we'd like solution of C#inner to influence A#outer, B#outer. But I don't think that's the way the spec works. In this case the spec says that C#inner 'depends' on A#outer, C#outer. >>> >>> So we really have no way >>> >>> That's because the result of the innermost call to 'destructure' is passed to the outermost call, so the inferred type for C#inner can affect the inferred Entry. >>> >>> So, we are basically left with what I think is an non-deterministic choice between eagerly resolving { A#inner, B#inner } or { A#outer, B#outer }. Unfortunately, picking the former makes the code pass, whereas picking the latter makes compilation fail (because at that time we don't know any better than just instantiating A#outer and B#outer to Object). >>> >>> If this is the issue, inference could to a better job, by either looking at presence of other 'more meaningful' bounds on {A#inner, B#inner} (although defining 'more meaningful might be problematic). Or it could just give precedence to innermost variables in case of a tie, which is a rule that I think programmers will find natural. Currently though, these 'extensions' are not part of the JLS - so the behavior here is, essentially, unspecified. >>> >>> At the same time, there's also an argument to be had as to whether the code here isn't inherently buggy - essentially, { A, B, C } in the 'destructure' method are all independent variables so, in a way, the problem is *underconstrained* (e.g. there's no real objective choice for which variable to solve first, other than resorting to heuristics, whose mileage can vary). >>> >>> Note that your second call works simply because, by adding the explicit type param on the method reference receiver, you make the method reference 'direct' meaning its type is evaluated *ahead* of the lambda. Basically you told the compiler which of the two 'stuck' expression should be solved first. >>> >>> @Dan - is this something that has been discussed before in spec-land? >>> >>> Cheers >>> Maurizio >>> >>> [1] - https://docs.oracle.com/javase/specs/jls/se12/html/jls-18.html#jls-18.5.2.2 >>> On 06/06/2019 20:31, John Napier wrote: >>>> Hi all, >>>> >>>> The following code compiles against oracle64-1.8.0.162 but fails on both openjdk64-11.0.2 and oracle64-12.0.1: >>>> >>>> public static class Example { >>>> >>>> public static class Pair implements Map.Entry { >>>> private final A a; >>>> private final B b; >>>> >>>> public Pair(A a, B b) { >>>> this.a = a; >>>> this.b = b; >>>> } >>>> >>>> @Override >>>> public A getKey() { >>>> return a; >>>> } >>>> >>>> @Override >>>> public B getValue() { >>>> return b; >>>> } >>>> >>>> @Override >>>> public B setValue(B value) { >>>> throw new UnsupportedOperationException(); >>>> } >>>> } >>>> >>>> public static C destructure(BiFunction fn, Map.Entry entry) { >>>> return fn.apply(entry.getKey(), entry.getValue()); >>>> } >>>> >>>> public static void main(String[] args) { >>>> Map.Entry entry = new Pair<>("foo", "bar"); >>>> >>>> // ill-typed >>>> String inferred = destructure((x, y) -> x + y, destructure(Pair::new, entry)); >>>> >>>> // well-typed >>>> String ascribed = destructure((x, y) -> x + y, destructure(Pair::new, entry)); >>>> } >>>> } >>>> >>>> Before submitting more bugs of this same ilk, albeit with slight variations in occurrence, I must ask: this is not the intentional modern behavior, correct? Inference should still work as illustrated above, right? >>>> >>>> Cheers, >>>> >>>> -John >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jun 17 00:01:59 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 17 Jun 2019 01:01:59 +0100 Subject: Inference Bug related to parametric polymorphism unification In-Reply-To: <33A2476E-A9C0-44A4-A77D-710557152ABE@gmail.com> References: <33A2476E-A9C0-44A4-A77D-710557152ABE@gmail.com> Message-ID: <0985eaac-ec70-cc85-7750-3fa0762dfb93@oracle.com> On 15/06/2019 22:55, John Napier wrote: > I definitely think that your suggestions (or ?musings" if suggestions > is too strong a word) for choosing the most deeply nested expression > as the unification reference would be an improvement over the current > situation from a user's perspective, provided it doesn?t lead to a > dramatically slower compilation time. Hi John, I think that, in this case performances should not be a problem, as it's mostly matter to sort constraints by position/depth, which should be doable. What I'm afraid of, is that for each example such an analysis might help in getting 'right', there can possibly another where such an analysis would 'block' types from being propagated from the LHS and lead to dual inference failure modes. I'll leave this to Dan - the overall feeling I get on this topic is that the dependency analysis we have in JLS is great in terms of deciding which variables to solve first when we know we have to solve _all_ variables in a dependency graph. The problem is that we try to 'reuse' this same dependency info, decorate it with extra info about directionality of expressions/constraints (e.g. a lambda that takes a X and produces a R, means that there's a new dependency in that R depends on X). While this work in most cases, the fact that the underlying dependency analysis is brittle (e.g. in X <: List we only conclude that X depends on Y, but not viceversa), means that we can 'miss' dependencies between expressions when multiple functional expressions are 'stuck'. This can be summarized with this simple example (if I didn't do any odd mistakes): import java.util.function.*; import java.util.*; class Test { ? static , R, W>? void m(Function a1, Function a2) { ? } ? static , R, W>? void m_inv(Function a2, Function a1) { ? } ? static void test() { ???? m(x -> (List)null, s -> s.length()); ???? m_inv(s -> s.length(), x -> (List)null); ? } } The two invocations are clearly identical (well, symmetric) - m_inv declared formals in opposite order than those of m. Yet, testing on JDK 13, the first invocation passes, while the second fails, with a similar error as the one in your example. In a way, I think that the fact that Y depends on R (as per JLS dependency analysis) should be treated as 'less important' compared to the fact that one of the two lambdas affects the input variables of the other, indirectly, via Y. But I don't think there's an easy way to tweak the spec, w/o coming up with a brand new dependency analysis for handling stuck expressions. Which might push the cost. vs. benefit ratio out of the acceptable limit. Cheers Maurizio From antoniocortes at google.com Mon Jun 17 17:54:15 2019 From: antoniocortes at google.com (Antonio Cortes Perez) Date: Mon, 17 Jun 2019 10:54:15 -0700 Subject: Type-variable parameter with type annotation. Message-ID: Hi, I am not able to retrieve the annotation from the parameter param or its type in the following program when using the javac API (JDK 1.8.0_212). === InputFile.java === import java.lang.annotation.ElementType; import java.lang.annotation.Target; @Target({ ElementType.TYPE_USE, ElementType.TYPE_PARAMETER }) @interface TypeAnnotation { } public class InputFile { void test(@TypeAnnotation T param) {} } === end === This is a sample program that uses the javac API. === JavacTest.java === import com.sun.source.tree.CompilationUnitTree; import com.sun.source.tree.VariableTree; import com.sun.source.util.JavacTask; import com.sun.source.util.TreePathScanner; import com.sun.source.util.Trees; import java.io.IOException; import java.util.Arrays; import javax.lang.model.element.AnnotationMirror; import javax.lang.model.type.TypeMirror; import javax.tools.JavaCompiler; import javax.tools.JavaFileObject; import javax.tools.StandardJavaFileManager; import javax.tools.ToolProvider; public class JavacTest { public static void main(String[] args) throws IOException { JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null); Iterable units = fileManager.getJavaFileObjectsFromStrings( Arrays.asList(args[0])); JavacTask task = (JavacTask) compiler.getTask(null, fileManager, null, null, null, units); Iterable asts = task.parse(); task.analyze(); new Visitor(Trees.instance(task)).scan(asts.iterator().next(), null); fileManager.close(); } private static class Visitor extends TreePathScanner { Trees trees; Visitor(Trees trees) { this.trees = trees; } @Override public Void visitVariable(VariableTree node, Void aVoid) { TypeMirror type = trees.getTypeMirror(getCurrentPath()); for (AnnotationMirror annotation : type.getAnnotationMirrors()) { System.out.println(annotation.toString()); } return null; } } } === end === The program does not print anything when using JDK 1.8. $ javac -cp /path/to/java/home/tools.jar JavacTest.java $ java -cp .:/path/to/java/home/tools.jar JavacTest InputFile.java Using JDK 9 produces the expected output. $ javac JavacTest.java $ java JavacTest InputFile.java @TypeAnnotation I also inspected the element, but I did not find the annotation. Element element = trees.getElement(getCurrentPath()); Set modifiers = element.getModifiers(); List annotations = element.getAnnotationMirrors(); I noticed that the list metadata.type_attributes in the underlying VarSymbol contains the annotation. But I did not find a way to retrieve it via the public API. Any tips are appreciated. Thanks, Antonio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon Jun 17 18:38:40 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 17 Jun 2019 11:38:40 -0700 Subject: Type-variable parameter with type annotation. In-Reply-To: References: Message-ID: <5D07DE30.7070300@oracle.com> On 6/17/2019 10:54 AM, Antonio Cortes Perez wrote: > I am not able to retrieve the annotation from the parameter param or its > type in the following program when using the javac API (JDK 1.8.0_212). > > === InputFile.java === > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > > @Target({ ElementType.TYPE_USE, ElementType.TYPE_PARAMETER }) > @interface TypeAnnotation { > } > > public class InputFile { > void test(@TypeAnnotation T param) {} > } > === end === This test case could be simplified by losing TYPE_PARAMETER (a declaration-site construct) from the @Target. There is one type parameter declared in the above code -- the T in between < > after InputFile -- and that declaration has no annotations. > The program does not print anything when using JDK 1.8. > > Using JDK 9 produces the expected output. Did you search https://bugs.openjdk.java.net/ for bugs in the 'tools' component with fixversion=9 ? > I also inspected the element, but I did not find the annotation. > Element element = trees.getElement(getCurrentPath()); > Set modifiers = element.getModifiers(); > List annotations = > element.getAnnotationMirrors(); > > I noticed that the list metadata.type_attributes in the underlying > VarSymbol contains the annotation. But I did not find a way to retrieve > it via the public API. Any tips are appreciated. You're confusing TYPE_PARAMETER and PARAMETER. Alex From jonathan.gibbons at oracle.com Mon Jun 17 23:56:56 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 17 Jun 2019 16:56:56 -0700 Subject: JDK-8225748: Use SHA-256 for javap classfile checksum Message-ID: Please review a simple small change to javap, to have it use SHA-256 when calculating checksums. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8225748 Webrev: http://cr.openjdk.java.net/~jjg/8225748-sha256/ From mandy.chung at oracle.com Tue Jun 18 00:20:39 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 17 Jun 2019 17:20:39 -0700 Subject: JDK-8225748: Use SHA-256 for javap classfile checksum In-Reply-To: References: Message-ID: <33d30845-5530-b633-1fa8-fc014c7363ca@oracle.com> Looks good. Mandy On 6/17/19 4:56 PM, Jonathan Gibbons wrote: > Please review a simple small change to javap, to have it use SHA-256 > when calculating checksums. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225748 > Webrev: http://cr.openjdk.java.net/~jjg/8225748-sha256/ > From fujie at loongson.cn Wed Jun 19 06:57:20 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 19 Jun 2019 14:57:20 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Hi Joe, Are you OK if one more configuration would be added to the failing test[1] ? Thanks a lot. Best regards, Jie [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323#l2.15 On 2019/6/15 ??8:27, Jie Fu wrote: > Thanks Bernard. > > I see all tests on mach5 have passed. > And could I get one more review from the langtools team for the > change[1]? > > Thanks a lot. > Best regards, > Jie > > [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > > On 2019/6/15 ??1:53, B. Blaser wrote: >> As shared code is affected, I've pushed it to jdk/submit to make sure >> all is right on every supported systems: >> >> http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 >> >> I've added a configuration to the failing test which might be kept >> when pushing to jdk/jdk providing that we get a Reviewer approval from >> the langtools team for this? >> >> Thanks, >> Bernard >> >> On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: >>> Hi Bernard, >>> >>> Thank you for your review. >>> And could you please sponsor it? >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> >>> On 2019/6/14 ??1:45, B. Blaser wrote: >>> >>>> Seems good to me too. >>>> >>>> Thanks, >>>> Bernard >>>> >>>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: >>>>> Thanks Vladimir Ivanov for your review. >>>>> >>>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: >>>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ >>>>>> Looks good. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov > From jonathan.gibbons at oracle.com Wed Jun 19 20:54:19 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 19 Jun 2019 13:54:19 -0700 Subject: RFR: JDK-8226412: Fix command-line help text for javac -target Message-ID: <6ba20b4d-6a98-36be-9f09-a38f72ef2ffc@oracle.com> Please review a small resource-bundle fix for the command-line help for javac --release, --source, --target, to make them consistent in their terminology, with each other and with related documentation. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8226412 Webrev: http://cr.openjdk.java.net/~jjg/8226412-command-line-help/webrev.00/ From joe.darcy at oracle.com Thu Jun 20 17:18:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 20 Jun 2019 10:18:38 -0700 Subject: Improving compiler messages for preview API Message-ID: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> Hello, In JDK 13, as part of the text blocks preview feature (http://openjdk.java.net/jeps/355), there are now several preview API methods in java.lang.String. Preview API handling is discussed in JEP 12: "Preview Language and VM Features" (http://openjdk.java.net/jeps/12): > This JEP does not propose a new mechanism for flagging "preview APIs", > but rather, proposes to reuse the deprecation mechanism: > > 1. > > Essential and reflective APIs that are connected with a preview > feature should be terminally deprecated at birth, that is, > annotated |@Deprecated(forRemoval=true, since=...)| when they are > introduced. > Accordingly, the declaration of the three preview API methods includes javadoc and annotations like: > + * @since 13 + * + * @deprecated This method is associated with text > blocks, a preview language feature. + * Text blocks and/or this method > may be changed or removed in a future release. + */ + > @Deprecated(forRemoval=true, since="13") + public String stripIndent() Using JDK 13 b25 to compile code using both the preview language feature and preview API public class Test { ??? public static void main(String... args) { ??????? String message = """ ???????????????????????? Hello, world. ???????????????????????? """; ??????? System.out.println(message.stripIndent()); //String.stripIndent in preview ??? } } the resulting compiler messages are ?../jdk-13/bin/javac --release 13 --enable-preview Test.java Test.java:7: warning: [removal] stripIndent() in String has been deprecated and marked for removal ??????? System.out.println(message.stripIndent()); ????????????????????????????????? ^ Note: Test.java uses preview language features. Note: Recompile with -Xlint:preview for details. 1 warning The removal warning for using the preview API element stripIndent is a bit harsh, after all the compilation has explicitly enabled preview features. However, strictly speaking such a warning is required by the JLS for a terminally deprecated item. [1] I think more reasonable messaging for this program would be something like: ??? Note: Test.java uses preview language features and preview API elements. ??? ... or just omitting mention of using preview API elements if compiling under --enable-preview. Emitting a warning for using preview API elements when *not* running under --enable-preview is important for the reasons discussed in JEP 12. Refined error messages for preview API elements could be given by the compiler if preview API elements were marked in some way to reliably distinguish them from other terminally deprecated items. Time is late in JDK 13, but for, say, JDK 14 it may be reasonable to add a java.lang.Preview annotation type to mark preview API elements rather than relying on overloading the deprecation mechanism. Such an annotation type would be @Documented an applicable to the sort of declarations @Deprecated can be applied to. If this kind of approach seems reasonable, core-libs will be brought in too. Comments? Cheers, -Joe [1] https://docs.oracle.com/javase/specs/jls/se12/html/jls-9.html#jls-9.6.4.6 > A Java compiler must produce a /removal warning/ when a terminally > deprecated program element is used (overridden, invoked, or referenced > by name) in the declaration of a program element (whether explicitly > or implicitly declared), unless: > > * > > ?The use is within a declaration that is annotated to suppress > removal warnings; or > > * > > The use and declaration are both within the same outermost class; or > > * > > ?The use is within an |import| declaration that imports the > terminally deprecated type or member. > > * > > The use is within an |exports| or |opens| directive. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Jun 20 20:35:24 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 20 Jun 2019 16:35:24 -0400 Subject: RFR: JDK-8226412: Fix command-line help text for javac -target In-Reply-To: <6ba20b4d-6a98-36be-9f09-a38f72ef2ffc@oracle.com> References: <6ba20b4d-6a98-36be-9f09-a38f72ef2ffc@oracle.com> Message-ID: <7512cf6d-2727-a0fd-1a16-e2d49f3ae5f4@oracle.com> looks good, Vicente On 6/19/19 4:54 PM, Jonathan Gibbons wrote: > Please review a small resource-bundle fix for the command-line help > for javac --release, --source, --target, to make them consistent in > their terminology, with each other and with related documentation. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226412 > Webrev: > http://cr.openjdk.java.net/~jjg/8226412-command-line-help/webrev.00/ > > From jan.lahoda at oracle.com Fri Jun 21 15:52:05 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 21 Jun 2019 17:52:05 +0200 Subject: RFR: JDK-8226510: No compilation error when switch expression has no result expressions Message-ID: <09fb074f-62f7-9558-c5a2-60148e700a22@oracle.com> Hi, javac does not correctly detect situation where a switch expression does not yield any value (but has some cases), like: switch (i) { default -> throw new IllegalStateException(); } The proposed solution is to add a check for this situation. Sadly, this triggered updates of several tests (which also contained switch expression which failed to yield a value), which had to be updated. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8226510/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8226510 How does this look? Thanks, Jan From joe.darcy at oracle.com Fri Jun 21 17:38:34 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 21 Jun 2019 10:38:34 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> Message-ID: <07dfe47e-0c68-01eb-951f-563153c8cfaa@oracle.com> PS Prototype version of what this sort of message improvement could look like, initially coded with a JDK-internal annotation type as opposed to one in java.lang: ??? http://cr.openjdk.java.net/~darcy/8226585.0/ When compiling the code public class Test { ??? public static void main(String... args) { ??????? String message = "Hello, world."; ??????? System.out.println(message.stripIndent()); //String.stripIndent in preview ??? } } the revised compiler gives the following messages # Without --enable-preview > javac --release 13 Test.java Test.java:5: warning: [removal] stripIndent() in String has been deprecated and marked for removal as a preview API ??????? System.out.println(message.stripIndent()); //String.stripIndent in preview ????????????????????????????????? ^ 1 warning # With --enable-preview > javac --release 13 --enable-preview Test.java Test.java:5: Note: stripIndent() in String is a preview API and may be removed in a future release ??????? System.out.println(message.stripIndent()); //String.stripIndent in preview ????????????????????????????????? ^ All langtools tests pass with the patch applied. Cheers, -Joe On 6/20/2019 10:18 AM, Joe Darcy wrote: > > Hello, > > In JDK 13, as part of the text blocks preview feature > (http://openjdk.java.net/jeps/355), there are now several preview API > methods in java.lang.String. Preview API handling is discussed in JEP > 12: "Preview Language and VM Features" (http://openjdk.java.net/jeps/12): > >> This JEP does not propose a new mechanism for flagging "preview >> APIs", but rather, proposes to reuse the deprecation mechanism: >> >> 1. >> >> Essential and reflective APIs that are connected with a preview >> feature should be terminally deprecated at birth, that is, >> annotated |@Deprecated(forRemoval=true, since=...)| when they are >> introduced. >> > Accordingly, the declaration of the three preview API methods includes > javadoc and annotations like: > >> + * @since 13 + * + * @deprecated This method is associated with text >> blocks, a preview language feature. + * Text blocks and/or this >> method may be changed or removed in a future release. + */ + >> @Deprecated(forRemoval=true, since="13") + public String stripIndent() > > Using JDK 13 b25 to compile code using both the preview language > feature and preview API > > public class Test { > ??? public static void main(String... args) { > ??????? String message = """ > ???????????????????????? Hello, world. > ???????????????????????? """; > ??????? System.out.println(message.stripIndent()); > //String.stripIndent in preview > ??? } > } > > the resulting compiler messages are > > ?../jdk-13/bin/javac --release 13 --enable-preview Test.java > Test.java:7: warning: [removal] stripIndent() in String has been > deprecated and marked for removal > ??????? System.out.println(message.stripIndent()); > ????????????????????????????????? ^ > Note: Test.java uses preview language features. > Note: Recompile with -Xlint:preview for details. > 1 warning > > The removal warning for using the preview API element stripIndent is a > bit harsh, after all the compilation has explicitly enabled preview > features. However, strictly speaking such a warning is required by the > JLS for a terminally deprecated item. [1] > > I think more reasonable messaging for this program would be something > like: > > ??? Note: Test.java uses preview language features and preview API > elements. > ??? ... > > or just omitting mention of using preview API elements if compiling > under --enable-preview. Emitting a warning for using preview API > elements when *not* running under --enable-preview is important for > the reasons discussed in JEP 12. > > Refined error messages for preview API elements could be given by the > compiler if preview API elements were marked in some way to reliably > distinguish them from other terminally deprecated items. > > Time is late in JDK 13, but for, say, JDK 14 it may be reasonable to > add a java.lang.Preview annotation type to mark preview API elements > rather than relying on overloading the deprecation mechanism. Such an > annotation type would be @Documented an applicable to the sort of > declarations @Deprecated can be applied to. > > If this kind of approach seems reasonable, core-libs will be brought > in too. > > Comments? > > Cheers, > > -Joe > > [1] > https://docs.oracle.com/javase/specs/jls/se12/html/jls-9.html#jls-9.6.4.6 > >> A Java compiler must produce a /removal warning/ when a terminally >> deprecated program element is used (overridden, invoked, or >> referenced by name) in the declaration of a program element (whether >> explicitly or implicitly declared), unless: >> >> * >> >> ?The use is within a declaration that is annotated to suppress >> removal warnings; or >> >> * >> >> The use and declaration are both within the same outermost class; or >> >> * >> >> ?The use is within an |import| declaration that imports the >> terminally deprecated type or member. >> >> * >> >> The use is within an |exports| or |opens| directive. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Jun 21 17:50:28 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 21 Jun 2019 10:50:28 -0700 Subject: Improving compiler messages for preview API In-Reply-To: <07dfe47e-0c68-01eb-951f-563153c8cfaa@oracle.com> References: <1f150fb1-9b9e-9900-f1f8-85279b3616f7@oracle.com> <07dfe47e-0c68-01eb-951f-563153c8cfaa@oracle.com> Message-ID: Joe, The code changes as presented look good.? A slightly more sophisticated solution would be to introduce a new MandatoryWarningHandler similar to "removalHandler", which would allow fewer (but not zero) messages when code is using preview API "a lot".? Maybe that's a future possibility, but the proposed informative-but-not-scary messages are a definite improvement. -- Jon On 06/21/2019 10:38 AM, Joe Darcy wrote: > > PS Prototype version of what this sort of message improvement could > look like, initially coded with a JDK-internal annotation type as > opposed to one in java.lang: > > http://cr.openjdk.java.net/~darcy/8226585.0/ > > When compiling the code > > public class Test { > ??? public static void main(String... args) { > ??????? String message = "Hello, world."; > > ??????? System.out.println(message.stripIndent()); > //String.stripIndent in preview > ??? } > } > > the revised compiler gives the following messages > > # Without --enable-preview > > > javac --release 13 Test.java > Test.java:5: warning: [removal] stripIndent() in String has been > deprecated and marked for removal as a preview API > ??????? System.out.println(message.stripIndent()); > //String.stripIndent in preview > ????????????????????????????????? ^ > 1 warning > > # With --enable-preview > > > javac --release 13 --enable-preview Test.java > Test.java:5: Note: stripIndent() in String is a preview API and may be > removed in a future release > ??????? System.out.println(message.stripIndent()); > //String.stripIndent in preview > ????????????????????????????????? ^ > All langtools tests pass with the patch applied. > > Cheers, > > -Joe > > On 6/20/2019 10:18 AM, Joe Darcy wrote: >> >> Hello, >> >> In JDK 13, as part of the text blocks preview feature >> (http://openjdk.java.net/jeps/355), there are now several preview API >> methods in java.lang.String. Preview API handling is discussed in JEP >> 12: "Preview Language and VM Features" (http://openjdk.java.net/jeps/12): >> >>> This JEP does not propose a new mechanism for flagging "preview >>> APIs", but rather, proposes to reuse the deprecation mechanism: >>> >>> 1. >>> >>> Essential and reflective APIs that are connected with a preview >>> feature should be terminally deprecated at birth, that is, >>> annotated |@Deprecated(forRemoval=true, since=...)| when they >>> are introduced. >>> >> Accordingly, the declaration of the three preview API methods >> includes javadoc and annotations like: >> >>> + * @since 13 + * + * @deprecated This method is associated with >>> text blocks, a preview language feature. + * Text blocks and/or this >>> method may be changed or removed in a future release. + */ + >>> @Deprecated(forRemoval=true, since="13") + public String stripIndent() >> >> Using JDK 13 b25 to compile code using both the preview language >> feature and preview API >> >> public class Test { >> ??? public static void main(String... args) { >> ??????? String message = """ >> ???????????????????????? Hello, world. >> ???????????????????????? """; >> ??????? System.out.println(message.stripIndent()); >> //String.stripIndent in preview >> ??? } >> } >> >> the resulting compiler messages are >> >> ?../jdk-13/bin/javac --release 13 --enable-preview Test.java >> Test.java:7: warning: [removal] stripIndent() in String has been >> deprecated and marked for removal >> ??????? System.out.println(message.stripIndent()); >> ????????????????????????????????? ^ >> Note: Test.java uses preview language features. >> Note: Recompile with -Xlint:preview for details. >> 1 warning >> >> The removal warning for using the preview API element stripIndent is >> a bit harsh, after all the compilation has explicitly enabled preview >> features. However, strictly speaking such a warning is required by >> the JLS for a terminally deprecated item. [1] >> >> I think more reasonable messaging for this program would be something >> like: >> >> ??? Note: Test.java uses preview language features and preview API >> elements. >> ??? ... >> >> or just omitting mention of using preview API elements if compiling >> under --enable-preview. Emitting a warning for using preview API >> elements when *not* running under --enable-preview is important for >> the reasons discussed in JEP 12. >> >> Refined error messages for preview API elements could be given by the >> compiler if preview API elements were marked in some way to reliably >> distinguish them from other terminally deprecated items. >> >> Time is late in JDK 13, but for, say, JDK 14 it may be reasonable to >> add a java.lang.Preview annotation type to mark preview API elements >> rather than relying on overloading the deprecation mechanism. Such an >> annotation type would be @Documented an applicable to the sort of >> declarations @Deprecated can be applied to. >> >> If this kind of approach seems reasonable, core-libs will be brought >> in too. >> >> Comments? >> >> Cheers, >> >> -Joe >> >> [1] >> https://docs.oracle.com/javase/specs/jls/se12/html/jls-9.html#jls-9.6.4.6 >> >>> A Java compiler must produce a /removal warning/ when a terminally >>> deprecated program element is used (overridden, invoked, or >>> referenced by name) in the declaration of a program element (whether >>> explicitly or implicitly declared), unless: >>> >>> * >>> >>> ?The use is within a declaration that is annotated to suppress >>> removal warnings; or >>> >>> * >>> >>> The use and declaration are both within the same outermost >>> class; or >>> >>> * >>> >>> ?The use is within an |import| declaration that imports the >>> terminally deprecated type or member. >>> >>> * >>> >>> The use is within an |exports| or |opens| directive. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Jun 21 19:49:19 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 21 Jun 2019 15:49:19 -0400 Subject: RFR: JDK-8226510: No compilation error when switch expression has no result expressions In-Reply-To: <09fb074f-62f7-9558-c5a2-60148e700a22@oracle.com> References: <09fb074f-62f7-9558-c5a2-60148e700a22@oracle.com> Message-ID: <10013bdd-bad3-e0fe-5886-7b10b41aeb5b@oracle.com> looks good, only a nit: shouldn't the message be: switch expression does not have any _result_ expressions? Vicente On 6/21/19 11:52 AM, Jan Lahoda wrote: > Hi, > > javac does not correctly detect situation where a switch expression > does not yield any value (but has some cases), like: > switch (i) { > ???? default -> throw new IllegalStateException(); > } > > The proposed solution is to add a check for this situation. Sadly, > this triggered updates of several tests (which also contained switch > expression which failed to yield a value), which had to be updated. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8226510/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8226510 > > How does this look? > > Thanks, > ??? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Sun Jun 23 17:27:28 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sun, 23 Jun 2019 19:27:28 +0200 Subject: RFR: JDK-8226510: No compilation error when switch expression has no result expressions In-Reply-To: <10013bdd-bad3-e0fe-5886-7b10b41aeb5b@oracle.com> References: <09fb074f-62f7-9558-c5a2-60148e700a22@oracle.com> <10013bdd-bad3-e0fe-5886-7b10b41aeb5b@oracle.com> Message-ID: <4ab81e03-4d26-5e5c-ed27-5715e1797e5e@oracle.com> On 21. 06. 19 21:49, Vicente Romero wrote: > looks good, only a nit: shouldn't the message be: > > switch expression does not have any _result_ expressions? Oops, you are right. Will fix before pushing. Thanks for the review! Jan > > Vicente > > On 6/21/19 11:52 AM, Jan Lahoda wrote: >> Hi, >> >> javac does not correctly detect situation where a switch expression >> does not yield any value (but has some cases), like: >> switch (i) { >> ???? default -> throw new IllegalStateException(); >> } >> >> The proposed solution is to add a check for this situation. Sadly, >> this triggered updates of several tests (which also contained switch >> expression which failed to yield a value), which had to be updated. >> >> Proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8226510/webrev.00/ >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8226510 >> >> How does this look? >> >> Thanks, >> ??? Jan > From bsrbnd at gmail.com Mon Jun 24 10:54:19 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 24 Jun 2019 12:54:19 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Or we could add another test case not to change the existing one: http://hg.openjdk.java.net/jdk/submit/rev/ba939c7fbedd Full branch log: http://hg.openjdk.java.net/jdk/submit/log?rev=branch(%22JDK-8225644%22) Vladimir, does this look good to you? Thanks, Bernard On Wed, 19 Jun 2019 at 08:57, Jie Fu wrote: > > Hi Joe, > > Are you OK if one more configuration would be added to the failing test[1] ? > > Thanks a lot. > Best regards, > Jie > > [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323#l2.15 > > > On 2019/6/15 ??8:27, Jie Fu wrote: > > Thanks Bernard. > > > > I see all tests on mach5 have passed. > > And could I get one more review from the langtools team for the > > change[1]? > > > > Thanks a lot. > > Best regards, > > Jie > > > > [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > > > > On 2019/6/15 ??1:53, B. Blaser wrote: > >> As shared code is affected, I've pushed it to jdk/submit to make sure > >> all is right on every supported systems: > >> > >> http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 > >> > >> I've added a configuration to the failing test which might be kept > >> when pushing to jdk/jdk providing that we get a Reviewer approval from > >> the langtools team for this? > >> > >> Thanks, > >> Bernard > >> > >> On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: > >>> Hi Bernard, > >>> > >>> Thank you for your review. > >>> And could you please sponsor it? > >>> > >>> Thanks a lot. > >>> Best regards, > >>> Jie > >>> > >>> > >>> On 2019/6/14 ??1:45, B. Blaser wrote: > >>> > >>>> Seems good to me too. > >>>> > >>>> Thanks, > >>>> Bernard > >>>> > >>>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: > >>>>> Thanks Vladimir Ivanov for your review. > >>>>> > >>>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: > >>>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ > >>>>>> Looks good. > >>>>>> > >>>>>> Best regards, > >>>>>> Vladimir Ivanov > > > From vladimir.x.ivanov at oracle.com Tue Jun 25 17:56:16 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 25 Jun 2019 20:56:16 +0300 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: > Or we could add another test case not to change the existing one: > http://hg.openjdk.java.net/jdk/submit/rev/ba939c7fbedd > > Full branch log: > http://hg.openjdk.java.net/jdk/submit/log?rev=branch(%22JDK-8225644%22) > > Vladimir, does this look good to you? Yes, looks good. I'm in favor of a dedicated test rather than introducing new C1-specific configuration into existing one from langtools. Best regards, Vladimir Ivanov > On Wed, 19 Jun 2019 at 08:57, Jie Fu wrote: >> >> Hi Joe, >> >> Are you OK if one more configuration would be added to the failing test[1] ? >> >> Thanks a lot. >> Best regards, >> Jie >> >> [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323#l2.15 >> >> >> On 2019/6/15 ??8:27, Jie Fu wrote: >>> Thanks Bernard. >>> >>> I see all tests on mach5 have passed. >>> And could I get one more review from the langtools team for the >>> change[1]? >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> [1] http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 >>> >>> On 2019/6/15 ??1:53, B. Blaser wrote: >>>> As shared code is affected, I've pushed it to jdk/submit to make sure >>>> all is right on every supported systems: >>>> >>>> http://hg.openjdk.java.net/jdk/submit/rev/9fdceac10323 >>>> >>>> I've added a configuration to the failing test which might be kept >>>> when pushing to jdk/jdk providing that we get a Reviewer approval from >>>> the langtools team for this? >>>> >>>> Thanks, >>>> Bernard >>>> >>>> On Fri, 14 Jun 2019 at 00:55, Jie Fu wrote: >>>>> Hi Bernard, >>>>> >>>>> Thank you for your review. >>>>> And could you please sponsor it? >>>>> >>>>> Thanks a lot. >>>>> Best regards, >>>>> Jie >>>>> >>>>> >>>>> On 2019/6/14 ??1:45, B. Blaser wrote: >>>>> >>>>>> Seems good to me too. >>>>>> >>>>>> Thanks, >>>>>> Bernard >>>>>> >>>>>> On Thu, 13 Jun 2019 at 14:27, Jie Fu wrote: >>>>>>> Thanks Vladimir Ivanov for your review. >>>>>>> >>>>>>> On 2019/6/13 ??5:46, Vladimir Ivanov wrote: >>>>>>>>> http://cr.openjdk.java.net/~jiefu/8225644/webrev.02/ >>>>>>>> Looks good. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>> >> From bsrbnd at gmail.com Tue Jun 25 20:12:18 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 25 Jun 2019 22:12:18 +0200 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Thanks for your approval, Vladimir, and thanks to Jie for his contribution, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/41fd388aaa4d Regards, Bernard On Tue, 25 Jun 2019 at 19:56, Vladimir Ivanov wrote: > > > > Or we could add another test case not to change the existing one: > > http://hg.openjdk.java.net/jdk/submit/rev/ba939c7fbedd > > > > Full branch log: > > http://hg.openjdk.java.net/jdk/submit/log?rev=branch(%22JDK-8225644%22) > > > > Vladimir, does this look good to you? > > Yes, looks good. I'm in favor of a dedicated test rather than > introducing new C1-specific configuration into existing one from langtools. > > Best regards, > Vladimir Ivanov From fujie at loongson.cn Wed Jun 26 00:37:13 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 26 Jun 2019 08:37:13 +0800 Subject: RFR: 8225644: C1 dumps incorrect class name in ClassCastException message In-Reply-To: References: <68c960f2-2db1-ffe5-0fab-90bce8d9cdf3@loongson.cn> <7bb21c11-b78a-31ba-9592-9f6da2f5a867@loongson.cn> <4eb6c63b-0422-423a-401a-d8e8d092c849@loongson.cn> Message-ID: Thank you so much, Bernard and Vladimir Ivanov. On 2019/6/26 ??4:12, B. Blaser wrote: > Thanks for your approval, Vladimir, and thanks to Jie for his > contribution, pushed: > http://hg.openjdk.java.net/jdk/jdk/rev/41fd388aaa4d > > Regards, > Bernard From joe.darcy at oracle.com Wed Jun 26 01:04:15 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 25 Jun 2019 18:04:15 -0700 Subject: JDK 14 RFR of JDK-8226785: MandatoryWarningHandler.java contains implementation of Object.equals functionality Message-ID: <81bb164e-27c4-6483-4c61-798bc3d5ecde@oracle.com> Hello, Noticed while doing some other work, the javac class MandatoryWarningHandler.java contains a local copy of of the logic of the two-argument Objects.equals method. As a refactoring, the library code should be used instead. The method in MandatoryWarningHandler is named "equal" rather than "equals" and escaped previous passes to replace independent implementations of this logic (JDK-7041136). Patch below. Thanks, -Joe diff -r dd697048684f src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java Tue Jun 25 21:33:24 2019 +0000 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java Tue Jun 25 18:02:43 2019 -0700 @@ -26,6 +26,7 @@ ?package com.sun.tools.javac.util; ?import java.util.HashSet; +import java.util.Objects; ?import java.util.Set; ?import javax.tools.JavaFileObject; @@ -147,7 +148,7 @@ ???????????????? deferredDiagnosticArg = currentSource; ???????????? } else if ((deferredDiagnosticKind == DeferredDiagnosticKind.IN_FILE ???????????????????????? || deferredDiagnosticKind == DeferredDiagnosticKind.ADDITIONAL_IN_FILE) -?????????????????????? && !equal(deferredDiagnosticSource, currentSource)) { +?????????????????????? && !Objects.equals(deferredDiagnosticSource, currentSource)) { ???????????????? // additional errors in more than one source file ???????????????? deferredDiagnosticKind = DeferredDiagnosticKind.ADDITIONAL_IN_FILES; ???????????????? deferredDiagnosticArg = null; @@ -159,7 +160,7 @@ ???????????????? deferredDiagnosticSource = currentSource; ???????????????? deferredDiagnosticArg = currentSource; ???????????? }? else if (deferredDiagnosticKind == DeferredDiagnosticKind.IN_FILE && -??????????????????????? !equal(deferredDiagnosticSource, currentSource)) { +??????????????????????? !Objects.equals(deferredDiagnosticSource, currentSource)) { ???????????????? // warnings in multiple source files ???????????????? deferredDiagnosticKind = DeferredDiagnosticKind.IN_FILES; ???????????????? deferredDiagnosticArg = null; @@ -183,13 +184,6 @@ ???? } ???? /** -???? * Check two objects, each possibly null, are either both null or are equal. -???? */ -??? private static boolean equal(Object o1, Object o2) { -??????? return ((o1 == null || o2 == null) ? (o1 == o2) : o1.equals(o2)); -??? } - -??? /** ????? * The log to which to report warnings. ????? */ ???? private Log log; From jonathan.gibbons at oracle.com Wed Jun 26 01:33:29 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 25 Jun 2019 18:33:29 -0700 Subject: JDK 14 RFR of JDK-8226785: MandatoryWarningHandler.java contains implementation of Object.equals functionality In-Reply-To: <81bb164e-27c4-6483-4c61-798bc3d5ecde@oracle.com> References: <81bb164e-27c4-6483-4c61-798bc3d5ecde@oracle.com> Message-ID: +1 On 06/25/2019 06:04 PM, Joe Darcy wrote: > Hello, > > Noticed while doing some other work, the javac class > MandatoryWarningHandler.java contains a local copy of of the logic of > the two-argument Objects.equals method. As a refactoring, the library > code should be used instead. > > The method in MandatoryWarningHandler is named "equal" rather than > "equals" and escaped previous passes to replace independent > implementations of this logic (JDK-7041136). > > Patch below. > > Thanks, > > -Joe > > diff -r dd697048684f > src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java > Tue Jun 25 21:33:24 2019 +0000 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java > Tue Jun 25 18:02:43 2019 -0700 > @@ -26,6 +26,7 @@ > ?package com.sun.tools.javac.util; > > ?import java.util.HashSet; > +import java.util.Objects; > ?import java.util.Set; > ?import javax.tools.JavaFileObject; > > @@ -147,7 +148,7 @@ > ???????????????? deferredDiagnosticArg = currentSource; > ???????????? } else if ((deferredDiagnosticKind == > DeferredDiagnosticKind.IN_FILE > ???????????????????????? || deferredDiagnosticKind == > DeferredDiagnosticKind.ADDITIONAL_IN_FILE) > -?????????????????????? && !equal(deferredDiagnosticSource, > currentSource)) { > +?????????????????????? && !Objects.equals(deferredDiagnosticSource, > currentSource)) { > ???????????????? // additional errors in more than one source file > ???????????????? deferredDiagnosticKind = > DeferredDiagnosticKind.ADDITIONAL_IN_FILES; > ???????????????? deferredDiagnosticArg = null; > @@ -159,7 +160,7 @@ > ???????????????? deferredDiagnosticSource = currentSource; > ???????????????? deferredDiagnosticArg = currentSource; > ???????????? }? else if (deferredDiagnosticKind == > DeferredDiagnosticKind.IN_FILE && > -??????????????????????? !equal(deferredDiagnosticSource, > currentSource)) { > +??????????????????????? !Objects.equals(deferredDiagnosticSource, > currentSource)) { > ???????????????? // warnings in multiple source files > ???????????????? deferredDiagnosticKind = > DeferredDiagnosticKind.IN_FILES; > ???????????????? deferredDiagnosticArg = null; > @@ -183,13 +184,6 @@ > ???? } > > ???? /** > -???? * Check two objects, each possibly null, are either both null or > are equal. > -???? */ > -??? private static boolean equal(Object o1, Object o2) { > -??????? return ((o1 == null || o2 == null) ? (o1 == o2) : > o1.equals(o2)); > -??? } > - > -??? /** > ????? * The log to which to report warnings. > ????? */ > ???? private Log log; > From jan.lahoda at oracle.com Fri Jun 28 12:33:31 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 28 Jun 2019 14:33:31 +0200 Subject: RFR: JDK-8226522: No compilation error reported when yield is used in incorrect context Message-ID: <8272c0f6-2a79-1b74-6ffc-35f9af814a8c@oracle.com> Hi, For code like: I i = (yield a) -> {}; interface I { public void test(String a); } javac will compile the code, as if the "yield" was "var". This is because of a mistake in restricted types handling in this case. Proposed fix is to ensure we are seeing "var" as the lambda parameter type, not yield. Webrev: http://cr.openjdk.java.net/~jlahoda/8226522/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8226522 How does this look? Thanks, Jan From maurizio.cimadamore at oracle.com Sat Jun 29 21:04:57 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 29 Jun 2019 22:04:57 +0100 Subject: RFR: JDK-8226522: No compilation error reported when yield is used in incorrect context In-Reply-To: <8272c0f6-2a79-1b74-6ffc-35f9af814a8c@oracle.com> References: <8272c0f6-2a79-1b74-6ffc-35f9af814a8c@oracle.com> Message-ID: <024dff63-f1d0-b5fb-6ba6-85ebc0560a72@oracle.com> The fix looks good - but I suggest a refactoring of the condition which, as is, is quite difficult to parse (for the human eyes). Maybe factor away: Name restrictedTypeName = restrictedTypeName(result, !allowVar) ? Maurizio On 28/06/2019 13:33, Jan Lahoda wrote: > Hi, > > For code like: > I i = (yield a) -> {}; > > interface I { public void test(String a); } > > javac will compile the code, as if the "yield" was "var". This is > because of a mistake in restricted types handling in this case. > > Proposed fix is to ensure we are seeing "var" as the lambda parameter > type, not yield. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8226522/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8226522 > > How does this look? > > Thanks, > ??? Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: