From vicente.romero at oracle.com Fri Nov 1 01:06:32 2019 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 01 Nov 2019 01:06:32 +0000 Subject: hg: amber/amber: fix error message for constructor with same erasure as canonical Message-ID: <201911010106.xA116XGU017900@aojmv0008.oracle.com> Changeset: 94af517243c6 Author: vromero Date: 2019-10-31 21:06 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/94af517243c6 fix error message for constructor with same erasure as canonical ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties From vicente.romero at oracle.com Fri Nov 1 04:11:19 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 1 Nov 2019 00:11:19 -0400 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: Hi all, Thanks for all the feedback so far. I have published another iteration at [1]. New in this iteration: Flags.java: - I have sync the javadoc and the comment on the RECORD flag - renamed MemberRecordClassFlags -> MemberRecordFlags com.sun.tools.javac.code.Kinds.java: - in order to generate better error messages I have added two new kinds: RECORD_COMPONENT and RECORD Symbols.java - moved method isRecord to ClassSymbol for the rest of the symbols moved back to using the bitwise test - removed method ::isDynamic from MethodSymbol Attr.java - implemented a spec change to relax that constraint that every non-canonical constructor should call the canonical constructor. Now the spec forces every non-canonical constructor to invoke a different constructor as its first statement. This actually implied removing some code. Check.java - at method ::duplicateError, there is new code to avoid generating two errors when the user declares a record with duplicated record component names. If this happens, then a compiler generated canonical constructor would have duplicated parameters. This code is preventing the compiler to generate a second error referring to a method that is not visible to the user. Another option is to not generate the canonical constructor at all if there are duplicate record components - at method ::checkUnique, there is new code to improve the error message when the user defines a constructor with the same erasure as the canonical constructor. Still the error message is not perfect because it shows in both cases the erasure of the methods, so they seem to be the same. But this is not related to records code, that's a simplification that happens at the moment of reporting the error. TypeEnter - removed some commented code - ::addRecordMembersIfNeeded here I added new code to avoid generating accessor methods for forbidden record component names. This is to avoid spurious errors later as any way the compiler will complain because of the forbidden record component names. The issue with this solution is that the list of forbidden record component names has been duplicated here. The other location is Attr. We can probably find a common place to define it. Probably a new utility class? JavacParser: - fixed the bug that the compiler was not allowing final local records - removed the check for abstract modifiers in records, this code was redundant as Check was already checking this - removed the check for duplicated record component names - added a check to forbid instance initializers in records compiler.properties - I hope I got the error messages right, I tried to reflect all the comments, suggestions, etc. I was proposed to create a `master` message for canonical records and use different `causes`, aka fragments, to be more specific. I decided to follow the same pattern for accessor methods. Regarding the suggestion of placing the caret in the throws clause for the corresponding error message, not possible. We would have to move the check for that error to the parser. New in this iteration: - I have included jdeps related code, I was thinking about putting it in a separate review bucket but, it is small, it kind of fits with the rest of the review - a series of supporting libraries for tests under: test/langtools/lib/combo/tools/javac/combo with also the tests that needed to be modified due to changes in the lib. These changes were created by Brian - a minor change done at ToolBox.java Thanks for all the feedback, Vicente [1] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ From vicente.romero at oracle.com Fri Nov 1 04:12:23 2019 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 01 Nov 2019 04:12:23 +0000 Subject: hg: amber/amber: removing redundant code Message-ID: <201911010412.xA14CN3r021143@aojmv0008.oracle.com> Changeset: 93920f18650a Author: vromero Date: 2019-10-31 23:59 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/93920f18650a removing redundant code ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java From maurizio.cimadamore at oracle.com Fri Nov 1 12:06:29 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Nov 2019 12:06:29 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: First, congrats on the work on error messages - it really paid off; the diagnostics now look very consistent and easy to grasp. One minor not on that side is this message: "first statement of this constructor must invoke another constructor" This has two problems, I think: 1) "statement .... must invoke" - a statement does not invoke; maybe rephrase as "first statement ... must be a constructor invocation" 2) we don't have a blessed term to name a non-canonical constructor. Can we just say non-canonical in the diagnostic? E.g. "the first statement in a non-canonical constructor must be an invocation of another constructor" Seems a mouthful. I noted that we have this diagnostic around: # 0: name 230 compiler.err.call.must.be.first.stmt.in.ctor=\ 231 call to {0} must be first statement in constructor Perhaps, inspired by this, we can turn this around and do this: "First statement in non-canonical constructor must be a call to 'this'" ? This seems more compact. More comments inline below: On 01/11/2019 04:11, Vicente Romero wrote: > Hi all, > > Thanks for all the feedback so far. I have published another iteration > at [1]. New in this iteration: > > Flags.java: > > - I have sync the javadoc and the comment on the RECORD flag > - renamed MemberRecordClassFlags -> MemberRecordFlags > > com.sun.tools.javac.code.Kinds.java: > - in order to generate better error messages I have added two new > kinds: RECORD_COMPONENT and RECORD Great - this works very well > > Symbols.java > - moved method isRecord to ClassSymbol for the rest of the symbols > moved back to using the bitwise test > - removed method ::isDynamic from MethodSymbol Good > > Attr.java > - implemented a spec change to relax that constraint that every > non-canonical constructor should call the canonical constructor. Now > the spec forces every non-canonical constructor to invoke a different > constructor as its first statement. This actually implied removing > some code. The new check looks very good - but I think this comment: /* this is it for now we still have to verify that the invocation is actually pointing to +???????????????????? * the canonical constructor as it could be pointing to another constructor, but we need to +???????????????????? * attribute the arguments first in visitApply +???????????????????? */ Is no longer valid? > Check.java > - at method ::duplicateError, there is new code to avoid generating > two errors when the user declares a record with duplicated record > component names. If this happens, then a compiler generated canonical > constructor would have duplicated parameters. This code is preventing > the compiler to generate a second error referring to a method that is > not visible to the user. Another option is to not generate the > canonical constructor at all if there are duplicate record components > - at method ::checkUnique, there is new code to improve the error > message when the user defines a constructor with the same erasure as > the canonical constructor. Still the error message is not perfect > because it shows in both cases the erasure of the methods, so they > seem to be the same. But this is not related to records code, that's a > simplification that happens at the moment of reporting the error. I really don't get why the message shows the erasure of the methods - you are calling: Errors.ConstructorWithSameErasureAsCanonical(other, canonical) That is, you are passing symbols - the symbols contain full type info - why is this being erased? This doesn't seem to happen e.g. in ordinary clash errors, e.g. InheritanceConflict3.java:14:10: compiler.err.name.clash.same.erasure: f(java.lang.Object), f(T) Is it possible, by any chance that we're generating the canonical symbol with an erased type? > > TypeEnter > - removed some commented code > - ::addRecordMembersIfNeeded here I added new code to avoid generating > accessor methods for forbidden record component names. This is to > avoid spurious errors later as any way the compiler will complain > because of the forbidden record component names. The issue with this > solution is that the list of forbidden record component names has been > duplicated here. The other location is Attr. We can probably find a > common place to define it. Probably a new utility class? Looking here http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java.html I noted that there are several indentation issues around BasicConstructorHelper (e.g. closing braces seem to be off) Also, there are some comments like: 1107 // public String toString() { return ???; } Which should be removed, or tweaked. As for the list of forbidden names, I think it should live in Names. After all, these are all names, so you can easily build a list there, and share it across javac components. > JavacParser: > - fixed the bug that the compiler was not allowing final local records > - removed the check for abstract modifiers in records, this code was > redundant as Check was already checking this > - removed the check for duplicated record component names > - added a check to forbid instance initializers in records > > compiler.properties > - I hope I got the error messages right, I tried to reflect all the > comments, suggestions, etc. I was proposed to create a `master` > message for canonical records and use different `causes`, aka > fragments, to be more specific. I decided to follow the same pattern > for accessor methods. Regarding the suggestion of placing the caret in > the throws clause for the corresponding error message, not possible. > We would have to move the check for that error to the parser. Yep, looks good! Maurizio > > New in this iteration: > - I have included jdeps related code, I was thinking about putting it > in a separate review bucket but, it is small, it kind of fits with the > rest of the review > - a series of supporting libraries for tests under: > test/langtools/lib/combo/tools/javac/combo with also the tests that > needed to be modified due to changes in the lib. These changes were > created by Brian > - a minor change done at ToolBox.java > > Thanks for all the feedback, > Vicente > > > [1] > http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ From maurizio.cimadamore at oracle.com Fri Nov 1 12:56:31 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Nov 2019 12:56:31 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> On 01/11/2019 12:06, Maurizio Cimadamore wrote: > I really don't get why the message shows the erasure of the methods - > you are calling: > > Errors.ConstructorWithSameErasureAsCanonical(other, canonical) > > That is, you are passing symbols - the symbols contain full type info > - why is this being erased? This doesn't seem to happen e.g. in > ordinary clash errors, e.g. > > InheritanceConflict3.java:14:10: compiler.err.name.clash.same.erasure: > f(java.lang.Object), f(T) > > Is it possible, by any chance that we're generating the canonical > symbol with an erased type? Did some more investigation on this. The problem was trivial - and was made clearer by compiling an example like this: import java.util.List; record Foo(List ls) { ??? Foo(List li) { } } This generates: Test.java:4: error: signature clash: constructor Foo(List) and canonical constructor Foo(List) have the same erasure ??? Foo(List li) { } ??? ^ 1 error Where it's clear that there's no erasure at play; the real issue is that the underlying diagnostic is bogus: compiler.err.constructor.with.same.erasure.as.canonical=\ ????????? signature clash: constructor {0} and canonical constructor {0} have the same erasure Note the double reference to {0}. If this is fixed as: # 0: symbol, 1: symbol compiler.err.constructor.with.same.erasure.as.canonical=\ ??? signature clash: constructor {0} and canonical constructor {1} have the same erasure Then the error displayed is correct: # 0: symbol, 1: symbol compiler.err.constructor.with.same.erasure.as.canonical=\ ??? signature clash: constructor {0} and canonical constructor {1} have the same erasure Also, while experimenting, I noted that compiling code like: record Foo(String s) { } Without the --enable-preview flag, causes a spurious parser error, with no clue that I'm using a preview feature: Test.java:1: error: class, interface, or enum expected record Foo(String s) { ^ 1 error Is that expected? I believe the issue is with 'isRecordToken' which always returns 'false' if preview features are disabled. I think something should call checkSourceLevel(Feature.RECORDS), so that preview errors for records will be triggered. And, looking more, I see some issues with parsing inside blocks - for instance, this program no longer compiles (w/o enable-preview): class Foo { ??? void test() { ??????? final record r = null; ??? } } class record {} That's because when we're inside a method body, we always interpret 'final record' as a record declaration. A better solution would be to always check (with lookahead) for "record IDENT '('". That should be more robust. In other words, I think that the parser code should be consolidated so that you have a single routine that checks for the start of a record declaration: record IDENT '(' If the above production is matched (with lookahead), then you call checkSourceLevel(Feature.RECORDS), so that the correct errors are generated. The routine could be something like this: boolean isRecordStart() { ???? if (token.kind == IDENTIFIER && token.name() == names.record && ??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || ???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { ????????? checkSourceLevel(Feature.RECORDS); ????????? return true; ??? } else { ?????? return false; ?? } } Then you remove isRecordToken, and start to use the above everywhere. I tried with a crude patch (see below), and things seem to work much better. Examples: record foo(int x) {} gives: Test.java:1: error: records are a preview feature and are disabled by default. record foo(int x) {} ^ ? (use --enable-preview to enable records) 1 error And, this: class Foo { ??? void test() { ??????? final record r = null; ??? } } class record {} Gives the following: Test.java:3: warning: 'record' may become a restricted type name in a future release and may be unusable for type declarations or as the element type of an array ??????? final record r = null; ???????????????????? ^ Test.java:7: warning: 'record' may become a restricted type name in a future release and may be unusable for type declarations or as the element type of an array class record {} ????? ^ 2 warnings Which I think it's closer to what we want. Patch below: diff -r 1da4a8addd21 src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaThu Oct 31 23:59:56 2019 -0400 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaFri Nov 01 12:53:31 2019 +0000 @@ -2558,7 +2558,7 @@ ???????????? if (token.kind == INTERFACE || ???????????????? token.kind == CLASS || ???????????????? token.kind == ENUM || -??????????????? (token.kind == IDENTIFIER && token.name() == names.record) ) { +??????????????? isRecordStart()) { ???????????????? return List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); ???????????? } else { ???????????????? JCExpression t = parseType(true); @@ -2625,9 +2625,7 @@ ???????????????? //else intentional fall-through ???????????? } ???????? } -??????? if (isRecordToken() && -??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || -???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { +??????? if (isRecordStart()) { ???????????? dc = token.comment(CommentStyle.JAVADOC); ???????????? return List.of(recordDeclaration(F.at(pos).Modifiers(0), dc)); ???????? } else { @@ -3661,7 +3659,7 @@ ???? protected JCStatement classOrRecordOrInterfaceOrEnumDeclaration(JCModifiers mods, Comment dc) { ???????? if (token.kind == CLASS) { ???????????? return classDeclaration(mods, dc); -??????? } if (isRecordToken()) { +??????? } if (isRecordStart()) { ???????????? return recordDeclaration(mods, dc); ???????? } else if (token.kind == INTERFACE) { ???????????? return interfaceDeclaration(mods, dc); @@ -4022,7 +4020,7 @@ ???????????? int pos = token.pos; ???????????? JCModifiers mods = modifiersOpt(); ???????????? if (token.kind == CLASS || -??????????????? isRecordToken() || +??????????????? isRecordStart() || ???????????????? token.kind == INTERFACE || ???????????????? token.kind == ENUM) { ???????????????? return List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); @@ -4117,9 +4115,16 @@ ???????? } ???? } -??? boolean isRecordToken() { -??????? return allowRecords && token.kind == IDENTIFIER && token.name() == names.record; -??? } +??? boolean isRecordStart() { +???? if (token.kind == IDENTIFIER && token.name() == names.record && +??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || +???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { +????????? checkSourceLevel(Feature.RECORDS); +????????? return true; +??? } else { +?????? return false; +?? } +} ???? /** MethodDeclaratorRest = ????? *????? FormalParameters BracketsOpt [THROWS TypeList] ( MethodBody | [DEFAULT AnnotationValue] ";") Cheers Maurizio From vicente.romero at oracle.com Fri Nov 1 13:03:56 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 1 Nov 2019 09:03:56 -0400 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <9c9a551e-0356-98e1-9f08-234fbaeebf2c@oracle.com> Hi Maurizio, On 11/1/19 8:06 AM, Maurizio Cimadamore wrote: > > First, congrats on the work on error messages - it really paid off; > the diagnostics now look very consistent and easy to grasp. > good :) > One minor not on that side is this message: > > "first statement of this constructor must invoke another constructor" > yep I wasn't happy with it either > > This has two problems, I think: > > 1) "statement .... must invoke" - a statement does not invoke; maybe > rephrase as "first statement ... must be a constructor invocation" > > 2) we don't have a blessed term to name a non-canonical constructor. > Can we just say non-canonical in the diagnostic? E.g. > > "the first statement in a non-canonical constructor must be an > invocation of another constructor" > > Seems a mouthful. > > I noted that we have this diagnostic around: > > # 0: name > 230 compiler.err.call.must.be.first.stmt.in.ctor=\ > 231 call to {0} must be first statement in constructor > > Perhaps, inspired by this, we can turn this around and do this: > > "First statement in non-canonical constructor must be a call to 'this'" ? > will do > This seems more compact. > > > More comments inline below: > > > On 01/11/2019 04:11, Vicente Romero wrote: >> Hi all, >> >> Thanks for all the feedback so far. I have published another >> iteration at [1]. New in this iteration: >> >> Flags.java: >> >> - I have sync the javadoc and the comment on the RECORD flag >> - renamed MemberRecordClassFlags -> MemberRecordFlags >> >> com.sun.tools.javac.code.Kinds.java: >> - in order to generate better error messages I have added two new >> kinds: RECORD_COMPONENT and RECORD > Great - this works very well >> >> Symbols.java >> - moved method isRecord to ClassSymbol for the rest of the symbols >> moved back to using the bitwise test >> - removed method ::isDynamic from MethodSymbol > Good >> >> Attr.java >> - implemented a spec change to relax that constraint that every >> non-canonical constructor should call the canonical constructor. Now >> the spec forces every non-canonical constructor to invoke a different >> constructor as its first statement. This actually implied removing >> some code. > > The new check looks very good - but I think this comment: > > /* this is it for now we still have to verify that the invocation is > actually pointing to > +???????????????????? * the canonical constructor as it could be > pointing to another constructor, but we need to > +???????????????????? * attribute the arguments first in visitApply > +???????????????????? */ > > Is no longer valid? > yep, removed > > >> Check.java >> - at method ::duplicateError, there is new code to avoid generating >> two errors when the user declares a record with duplicated record >> component names. If this happens, then a compiler generated canonical >> constructor would have duplicated parameters. This code is preventing >> the compiler to generate a second error referring to a method that is >> not visible to the user. Another option is to not generate the >> canonical constructor at all if there are duplicate record components >> - at method ::checkUnique, there is new code to improve the error >> message when the user defines a constructor with the same erasure as >> the canonical constructor. Still the error message is not perfect >> because it shows in both cases the erasure of the methods, so they >> seem to be the same. But this is not related to records code, that's >> a simplification that happens at the moment of reporting the error. > > I really don't get why the message shows the erasure of the methods - > you are calling: > > Errors.ConstructorWithSameErasureAsCanonical(other, canonical) > > That is, you are passing symbols - the symbols contain full type info > - why is this being erased? This doesn't seem to happen e.g. in > ordinary clash errors, e.g. > > InheritanceConflict3.java:14:10: compiler.err.name.clash.same.erasure: > f(java.lang.Object), f(T) > > Is it possible, by any chance that we're generating the canonical > symbol with an erased type? > >> >> TypeEnter >> - removed some commented code >> - ::addRecordMembersIfNeeded here I added new code to avoid >> generating accessor methods for forbidden record component names. >> This is to avoid spurious errors later as any way the compiler will >> complain because of the forbidden record component names. The issue >> with this solution is that the list of forbidden record component >> names has been duplicated here. The other location is Attr. We can >> probably find a common place to define it. Probably a new utility class? > > Looking here > > http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java.html > > I noted that there are several indentation issues around > BasicConstructorHelper (e.g. closing braces seem to be off) > > Also, there are some comments like: > > 1107 // public String toString() { return ???; } > > Which should be removed, or tweaked. > done > > As for the list of forbidden names, I think it should live in Names. > After all, these are all names, so you can easily build a list there, > and share it across javac components. > yep you are right that's the natural place > > >> JavacParser: >> - fixed the bug that the compiler was not allowing final local records >> - removed the check for abstract modifiers in records, this code was >> redundant as Check was already checking this >> - removed the check for duplicated record component names >> - added a check to forbid instance initializers in records >> >> compiler.properties >> - I hope I got the error messages right, I tried to reflect all the >> comments, suggestions, etc. I was proposed to create a `master` >> message for canonical records and use different `causes`, aka >> fragments, to be more specific. I decided to follow the same pattern >> for accessor methods. Regarding the suggestion of placing the caret >> in the throws clause for the corresponding error message, not >> possible. We would have to move the check for that error to the parser. > > Yep, looks good! > cool :) > > > Maurizio > Thanks, Vicente > >> >> New in this iteration: >> - I have included jdeps related code, I was thinking about putting it >> in a separate review bucket but, it is small, it kind of fits with >> the rest of the review >> - a series of supporting libraries for tests under: >> test/langtools/lib/combo/tools/javac/combo with also the tests that >> needed to be modified due to changes in the lib. These changes were >> created by Brian >> - a minor change done at ToolBox.java >> >> Thanks for all the feedback, >> Vicente >> >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ From jan.lahoda at oracle.com Fri Nov 1 13:12:13 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 1 Nov 2019 14:12:13 +0100 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> Message-ID: <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> On 01. 11. 19 13:56, Maurizio Cimadamore wrote: > Also, while experimenting, I noted that compiling code like: > > record Foo(String s) { } > > Without the --enable-preview flag, causes a spurious parser error, with > no clue that I'm using a preview feature: > > Test.java:1: error: class, interface, or enum expected > record Foo(String s) { > ^ > 1 error > > Is that expected? I believe the issue is with 'isRecordToken' which > always returns 'false' if preview features are disabled. I think > something should call checkSourceLevel(Feature.RECORDS), so that preview > errors for records will be triggered. I think I was touching that in one of my comments. I am afraid it is probably not so simple - we could do the checks easily for top-level records, but not so easily for nested records. I.e.: --- class X { record R(int i) { return null; } } class record {} --- is valid currently ("R" is a method which returns "record"), but not with the patch: --- $ javac /tmp/R.java /tmp/R.java:2: error: records are a preview feature and are disabled by default. record R(int i) { ^ (use --enable-preview to enable records) /tmp/R.java:3: error: illegal start of type return null; ^ /tmp/R.java:6: warning: 'record' may become a restricted type name in a future release and may be unusable for type declarations or as the element type of an array class record {} ^ 2 errors 1 warning --- I suspect it may be necessary to only add a warning/note for the suspected records, with a possible special-case for top-level records failing with a more appropriate error. Jan > > And, looking more, I see some issues with parsing inside blocks - for > instance, this program no longer compiles (w/o enable-preview): > > class Foo { > ??? void test() { > ??????? final record r = null; > ??? } > } > > class record {} > > That's because when we're inside a method body, we always interpret > 'final record' as a record declaration. > > A better solution would be to always check (with lookahead) for "record > IDENT '('". That should be more robust. > > > In other words, I think that the parser code should be consolidated so > that you have a single routine that checks for the start of a record > declaration: > > record IDENT '(' > > If the above production is matched (with lookahead), then you call > checkSourceLevel(Feature.RECORDS), so that the correct errors are > generated. > > The routine could be something like this: > > boolean isRecordStart() { > ???? if (token.kind == IDENTIFIER && token.name() == names.record && > ??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || > ???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { > ????????? checkSourceLevel(Feature.RECORDS); > ????????? return true; > ??? } else { > ?????? return false; > ?? } > } > > Then you remove isRecordToken, and start to use the above everywhere. I > tried with a crude patch (see below), and things seem to work much > better. Examples: > > record foo(int x) {} > > gives: > > Test.java:1: error: records are a preview feature and are disabled by > default. > record foo(int x) {} > ^ > ? (use --enable-preview to enable records) > 1 error > > And, this: > > class Foo { > ??? void test() { > ??????? final record r = null; > ??? } > } > > class record {} > > Gives the following: > > Test.java:3: warning: 'record' may become a restricted type name in a > future release and may be unusable for type declarations or as the > element type of an array > ??????? final record r = null; > ???????????????????? ^ > Test.java:7: warning: 'record' may become a restricted type name in a > future release and may be unusable for type declarations or as the > element type of an array > class record {} > ????? ^ > 2 warnings > > > Which I think it's closer to what we want. > > Patch below: > > diff -r 1da4a8addd21 > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaThu > Oct 31 23:59:56 2019 -0400 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaFri > Nov 01 12:53:31 2019 +0000 > @@ -2558,7 +2558,7 @@ > ???????????? if (token.kind == INTERFACE || > ???????????????? token.kind == CLASS || > ???????????????? token.kind == ENUM || > -??????????????? (token.kind == IDENTIFIER && token.name() == > names.record) ) { > +??????????????? isRecordStart()) { > ???????????????? return > List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); > ???????????? } else { > ???????????????? JCExpression t = parseType(true); > @@ -2625,9 +2625,7 @@ > ???????????????? //else intentional fall-through > ???????????? } > ???????? } > -??????? if (isRecordToken() && > -??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || > -???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { > +??????? if (isRecordStart()) { > ???????????? dc = token.comment(CommentStyle.JAVADOC); > ???????????? return List.of(recordDeclaration(F.at(pos).Modifiers(0), > dc)); > ???????? } else { > @@ -3661,7 +3659,7 @@ > ???? protected JCStatement > classOrRecordOrInterfaceOrEnumDeclaration(JCModifiers mods, Comment dc) { > ???????? if (token.kind == CLASS) { > ???????????? return classDeclaration(mods, dc); > -??????? } if (isRecordToken()) { > +??????? } if (isRecordStart()) { > ???????????? return recordDeclaration(mods, dc); > ???????? } else if (token.kind == INTERFACE) { > ???????????? return interfaceDeclaration(mods, dc); > @@ -4022,7 +4020,7 @@ > ???????????? int pos = token.pos; > ???????????? JCModifiers mods = modifiersOpt(); > ???????????? if (token.kind == CLASS || > -??????????????? isRecordToken() || > +??????????????? isRecordStart() || > ???????????????? token.kind == INTERFACE || > ???????????????? token.kind == ENUM) { > ???????????????? return > List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); > @@ -4117,9 +4115,16 @@ > ???????? } > ???? } > > -??? boolean isRecordToken() { > -??????? return allowRecords && token.kind == IDENTIFIER && token.name() > == names.record; > -??? } > +??? boolean isRecordStart() { > +???? if (token.kind == IDENTIFIER && token.name() == names.record && > +??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || > +???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { > +????????? checkSourceLevel(Feature.RECORDS); > +????????? return true; > +??? } else { > +?????? return false; > +?? } > +} > > ???? /** MethodDeclaratorRest = > ????? *????? FormalParameters BracketsOpt [THROWS TypeList] ( > MethodBody | [DEFAULT AnnotationValue] ";") > > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Fri Nov 1 13:18:44 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Nov 2019 13:18:44 +0000 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> <9f8607fd-9fab-cc7a-9b0b-8913887df893@oracle.com> <7ebb480f-bbcb-2ac0-ce9a-73e5888f5df4@oracle.com> Message-ID: <97d2b883-8df4-dd6e-cad4-e2ad5982a92c@oracle.com> On 01/11/2019 13:12, Jan Lahoda wrote: > On 01. 11. 19 13:56, Maurizio Cimadamore wrote: >> Also, while experimenting, I noted that compiling code like: >> >> record Foo(String s) { } >> >> Without the --enable-preview flag, causes a spurious parser error, >> with no clue that I'm using a preview feature: >> >> Test.java:1: error: class, interface, or enum expected >> record Foo(String s) { >> ^ >> 1 error >> >> Is that expected? I believe the issue is with 'isRecordToken' which >> always returns 'false' if preview features are disabled. I think >> something should call checkSourceLevel(Feature.RECORDS), so that >> preview errors for records will be triggered. > > I think I was touching that in one of my comments. I am afraid it is > probably not so simple - we could do the checks easily for top-level > records, but not so easily for nested records. I.e.: > --- > class X { > ??? record R(int i) { > ??????? return null; > ??? } > } > class record {} > --- > > is valid currently ("R" is a method which returns "record"), but not > with the patch: Good point. So, I think the patch fixes the treatment of toplevel and local records. Where it leaves something to be desired, as you point out, is with member records (e.g. records nested inside a class declaration). Here the grammar is inherently ambiguous with method declarations, so not much we can do (we can probably do something if there's a generic record though). In this cases we should just take the record production or the method one, depending on whether preview features are enabled or not. Maurizio > --- > $ javac /tmp/R.java > /tmp/R.java:2: error: records are a preview feature and are disabled > by default. > record R(int i) { > ^ > ? (use --enable-preview to enable records) > /tmp/R.java:3: error: illegal start of type > return null; > ^ > /tmp/R.java:6: warning: 'record' may become a restricted type name in > a future release and may be unusable for type declarations or as the > element type of an array > class record {} > ????? ^ > 2 errors > 1 warning > --- > > I suspect it may be necessary to only add a warning/note for the > suspected records, with a possible special-case for top-level records > failing with a more appropriate error. > > Jan > >> >> And, looking more, I see some issues with parsing inside blocks - for >> instance, this program no longer compiles (w/o enable-preview): >> >> class Foo { >> ???? void test() { >> ???????? final record r = null; >> ???? } >> } >> >> class record {} >> >> That's because when we're inside a method body, we always interpret >> 'final record' as a record declaration. >> >> A better solution would be to always check (with lookahead) for >> "record IDENT '('". That should be more robust. >> >> >> In other words, I think that the parser code should be consolidated >> so that you have a single routine that checks for the start of a >> record declaration: >> >> record IDENT '(' >> >> If the above production is matched (with lookahead), then you call >> checkSourceLevel(Feature.RECORDS), so that the correct errors are >> generated. >> >> The routine could be something like this: >> >> boolean isRecordStart() { >> ????? if (token.kind == IDENTIFIER && token.name() == names.record && >> ???????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || >> ????????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { >> ?????????? checkSourceLevel(Feature.RECORDS); >> ?????????? return true; >> ???? } else { >> ??????? return false; >> ??? } >> } >> >> Then you remove isRecordToken, and start to use the above everywhere. >> I tried with a crude patch (see below), and things seem to work much >> better. Examples: >> >> record foo(int x) {} >> >> gives: >> >> Test.java:1: error: records are a preview feature and are disabled by >> default. >> record foo(int x) {} >> ^ >> ?? (use --enable-preview to enable records) >> 1 error >> >> And, this: >> >> class Foo { >> ???? void test() { >> ???????? final record r = null; >> ???? } >> } >> >> class record {} >> >> Gives the following: >> >> Test.java:3: warning: 'record' may become a restricted type name in a >> future release and may be unusable for type declarations or as the >> element type of an array >> ???????? final record r = null; >> ????????????????????? ^ >> Test.java:7: warning: 'record' may become a restricted type name in a >> future release and may be unusable for type declarations or as the >> element type of an array >> class record {} >> ?????? ^ >> 2 warnings >> >> >> Which I think it's closer to what we want. >> >> Patch below: >> >> diff -r 1da4a8addd21 >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java >> --- >> a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaThu >> Oct 31 23:59:56 2019 -0400 >> +++ >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.javaFri >> Nov 01 12:53:31 2019 +0000 >> @@ -2558,7 +2558,7 @@ >> ????????????? if (token.kind == INTERFACE || >> ????????????????? token.kind == CLASS || >> ????????????????? token.kind == ENUM || >> -??????????????? (token.kind == IDENTIFIER && token.name() == >> names.record) ) { >> +??????????????? isRecordStart()) { >> ????????????????? return >> List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); >> ????????????? } else { >> ????????????????? JCExpression t = parseType(true); >> @@ -2625,9 +2625,7 @@ >> ????????????????? //else intentional fall-through >> ????????????? } >> ????????? } >> -??????? if (isRecordToken() && >> -??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || >> -???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { >> +??????? if (isRecordStart()) { >> ????????????? dc = token.comment(CommentStyle.JAVADOC); >> ????????????? return >> List.of(recordDeclaration(F.at(pos).Modifiers(0), dc)); >> ????????? } else { >> @@ -3661,7 +3659,7 @@ >> ????? protected JCStatement >> classOrRecordOrInterfaceOrEnumDeclaration(JCModifiers mods, Comment >> dc) { >> ????????? if (token.kind == CLASS) { >> ????????????? return classDeclaration(mods, dc); >> -??????? } if (isRecordToken()) { >> +??????? } if (isRecordStart()) { >> ????????????? return recordDeclaration(mods, dc); >> ????????? } else if (token.kind == INTERFACE) { >> ????????????? return interfaceDeclaration(mods, dc); >> @@ -4022,7 +4020,7 @@ >> ????????????? int pos = token.pos; >> ????????????? JCModifiers mods = modifiersOpt(); >> ????????????? if (token.kind == CLASS || >> -??????????????? isRecordToken() || >> +??????????????? isRecordStart() || >> ????????????????? token.kind == INTERFACE || >> ????????????????? token.kind == ENUM) { >> ????????????????? return >> List.of(classOrRecordOrInterfaceOrEnumDeclaration(mods, dc)); >> @@ -4117,9 +4115,16 @@ >> ????????? } >> ????? } >> >> -??? boolean isRecordToken() { >> -??????? return allowRecords && token.kind == IDENTIFIER && >> token.name() == names.record; >> -??? } >> +??? boolean isRecordStart() { >> +???? if (token.kind == IDENTIFIER && token.name() == names.record && >> +??????????? (peekToken(TokenKind.IDENTIFIER, TokenKind.LPAREN) || >> +???????????? peekToken(TokenKind.IDENTIFIER, TokenKind.LT))) { >> +????????? checkSourceLevel(Feature.RECORDS); >> +????????? return true; >> +??? } else { >> +?????? return false; >> +?? } >> +} >> >> ????? /** MethodDeclaratorRest = >> ?????? *????? FormalParameters BracketsOpt [THROWS TypeList] ( >> MethodBody | [DEFAULT AnnotationValue] ";") >> >> >> Cheers >> Maurizio >> From harold.seigel at oracle.com Fri Nov 1 13:38:12 2019 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 01 Nov 2019 13:38:12 +0000 Subject: hg: amber/amber: Summary: fix failing test by adding ctor calls Message-ID: <201911011338.xA1DcC0o014926@aojmv0008.oracle.com> Changeset: b92358773309 Author: hseigel Date: 2019-11-01 13:37 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/b92358773309 Summary: fix failing test by adding ctor calls ! test/jdk/java/lang/instrument/RedefineRecordAttr/Host/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/Host/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostA/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostA/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostAB/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostAB/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostABCD/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostABD/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostAC/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostACB/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostB/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostBA/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostBAC/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostBCA/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostCAB/redef/Host.java ! test/jdk/java/lang/instrument/RedefineRecordAttr/HostCBA/redef/Host.java From alex.buckley at oracle.com Fri Nov 1 17:38:55 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 1 Nov 2019 10:38:55 -0700 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <6a37a5e8-457f-b9c2-eb68-6e980fa65da8@oracle.com> On 11/1/2019 5:06 AM, Maurizio Cimadamore wrote: > "first statement of this constructor must invoke another constructor" > > This has two problems, I think: > > 1) "statement .... must invoke" - a statement does not invoke; maybe > rephrase as "first statement ... must be a constructor invocation" > > 2) we don't have a blessed term to name a non-canonical constructor. Can > we just say non-canonical in the diagnostic? E.g. > > "the first statement in a non-canonical constructor must be an > invocation of another constructor" > > Seems a mouthful. > > I noted that we have this diagnostic around: > > # 0: name > 230 compiler.err.call.must.be.first.stmt.in.ctor=\ > 231 call to {0} must be first statement in constructor > > Perhaps, inspired by this, we can turn this around and do this: > > "First statement in non-canonical constructor must be a call to 'this'" ? > > This seems more compact. This weird corner of the language (JLS 8.8.7.1, which should be cross-ref'd from the penultimate bullet of 8.10.4) DOES have statements that invoke: ----- Explicit constructor invocation statements are divided into two kinds: - Alternate constructor invocations begin with the keyword `this` ... used to invoke an alternate constructor of the same class. ----- These "invocation statements" are weird: despite the s-word, they are not capital-S "Statements" as defined in chapter 14, and despite the i-word, they are not method invocation expressions as defined in chapter 15. They are so weird that even their most colloquial, snappy description -- "a call to 'this'`" -- is weird. It makes sense if you SAY it to yourself when writing a program, but I think it's hard to READ -- "A call to this what? This constructor? This class?" I therefore recommend the following message, which tiptoes around the ugly term "non-canonical": "error: constructor is not canonical, so its first statement must invoke another constructor" Alex From vicente.romero at oracle.com Fri Nov 1 21:18:01 2019 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 01 Nov 2019 21:18:01 +0000 Subject: hg: amber/amber: applying last review comments Message-ID: <201911012118.xA1LI2gL007864@aojmv0008.oracle.com> Changeset: d56cbf3378df Author: vromero Date: 2019-11-01 17:17 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/d56cbf3378df applying last review comments ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java From vicente.romero at oracle.com Sat Nov 2 00:01:21 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 1 Nov 2019 20:01:21 -0400 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> Message-ID: <1f22a71d-d66d-f0ce-9df9-8bee29b94c67@oracle.com> Hi Gavin, At: 9.7.4 Where Annotations May Appear, it says: It is a compile-time error if an annotation of type /T/ is syntactically a modifier for: ... * ??? a record component but /T/ is not applicable to record component declarations, type contexts, type parameter declarations, field declarations, or method declarations. I think that it should say: parameter declarations instead of type parameter declarations. Vicente On 10/31/19 10:17 AM, Gavin Bierman wrote: > An updated draft language spec for JEP 359 (Records) is available at: > > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html > > (Alongside is a draft JVM spec for this feature: > > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jvms.html > > ) > > As always, please email me any comments/thoughts/bugs. > > Thanks, > Gavin > > >> On 23 Aug 2019, at 22:25, Gavin Bierman wrote: >> >> A draft language spec for records is available at: >> >> http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-jls.html >> >> This spec doesn?t yet discuss varargs records - to appear in the next draft. >> >> All comments welcomed! >> >> Thanks, >> Gavin From vicente.romero at oracle.com Sat Nov 2 00:34:34 2019 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 02 Nov 2019 00:34:34 +0000 Subject: hg: amber/amber: applying reflection review comments Message-ID: <201911020034.xA20YYYo019692@aojmv0008.oracle.com> Changeset: d1cbaf90642d Author: vromero Date: 2019-11-01 20:15 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/d1cbaf90642d applying reflection review comments ! src/java.base/share/classes/java/lang/annotation/ElementType.java ! src/java.base/share/classes/java/lang/reflect/RecordComponent.java ! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java From fw at deneb.enyo.de Sat Nov 2 10:21:16 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 02 Nov 2019 11:21:16 +0100 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: (Gavin Bierman's message of "Thu, 31 Oct 2019 14:17:34 +0000") References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> Message-ID: <87bltu1sv7.fsf@mid.deneb.enyo.de> * Gavin Bierman: > An updated draft language spec for JEP 359 (Records) is available at: > > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jls.html > Is it allowed to declare a canonical constructor explicitly and make it non-public? I think the naswer is no. But it's not quite obvious from the spec, I think. Will the canonical constructor be invoked upon deserialization? Sorry, I can't find a discussion of that aspect, but I'm sure it must have come up before. From brian.goetz at oracle.com Sat Nov 2 13:19:33 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 2 Nov 2019 09:19:33 -0400 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: <87bltu1sv7.fsf@mid.deneb.enyo.de> References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> <87bltu1sv7.fsf@mid.deneb.enyo.de> Message-ID: <89445D90-BFAF-4509-A361-0C47AFE003CB@oracle.com> > Is it allowed to declare a canonical constructor explicitly and make > it non-public? I think the naswer is no. But it's not quite obvious > from the spec, I think. No, it is not. The basic idea is that with a record, you?ve given up the right to decouple your API from the representation, which is declared in the header. So you will get a public canonical constructor, accessors, state-based Object methods, and eventually, a deconstruction pattern. You can ?override? these methods, but subject to an invariant: ?copying? a record (feeding the result of its accessors to its canonical actor) must be equals() to the original. A record is the state, the whole state, and nothing but the state. > Will the canonical constructor be invoked upon deserialization? > Sorry, I can't find a discussion of that aspect, but I'm sure it must > have come up before. Yes, this is in the serialization spec, not the language spec. From fw at deneb.enyo.de Sat Nov 2 13:34:30 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 02 Nov 2019 14:34:30 +0100 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: <89445D90-BFAF-4509-A361-0C47AFE003CB@oracle.com> (Brian Goetz's message of "Sat, 2 Nov 2019 09:19:33 -0400") References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> <87bltu1sv7.fsf@mid.deneb.enyo.de> <89445D90-BFAF-4509-A361-0C47AFE003CB@oracle.com> Message-ID: <8736f61jx5.fsf@mid.deneb.enyo.de> * Brian Goetz: >> Is it allowed to declare a canonical constructor explicitly and make >> it non-public? I think the naswer is no. But it's not quite obvious >> from the spec, I think. > > No, it is not. > > The basic idea is that with a record, you?ve given up the right to > decouple your API from the representation, which is declared in the > header. So you will get a public canonical constructor, accessors, > state-based Object methods, and eventually, a deconstruction pattern. > You can ?override? these methods, but subject to an invariant: > ?copying? a record (feeding the result of its accessors to its > canonical actor) must be equals() to the original. A record is the > state, the whole state, and nothing but the state. Sorry, I don't think the current specification of explicitly declared canonical constructors achieves this. As far as I can tell, this is legal: record R(int i) { public R(int i) { this.i = i + 1; } } It also means that serialization with constructor invocation will not produce something that compares equal to the original record. What is the use case for transformation of record fields in canonical constructors? I would expect canonical constructors to have an implicit preamble which assigns all the fields, similar to the compact form. All these constructors can do is checking that the record invariants aren't violated. There is definitely a tension here between encapsulation (of how the internal state is constructed) and transparent construction of record values (for the purposes of serialization, but there could be other applications as well). (If this has already been discussed to death, I will shut up. I understand I'm very late to the party. Sorry.) From ksrinifmt at gmail.com Sat Nov 2 15:12:26 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Sat, 2 Nov 2019 08:12:26 -0700 Subject: RFR: JEP 359-Records: javadoc code In-Reply-To: References: <914ab35b-ff07-1b9e-472c-9a04f7bc49dc@oracle.com> Message-ID: Hi Jon, Firstly I must commend the javadoc.next project for updating javadoc/doclet to use jx.l.m and other improvements to the doc comments management, this has made it relatively easy for javadoc to implement new language features, such as this. Having said that, the changes are looking great, and the langtools stalwarts have done due diligence. Here are some minor review comments, I don't need to see another revision. Default webrev: src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java Likely search/replace - * Keep track of whether or not this typeElement is an record. + * Keep track of whether or not this typeElement is a record. - // only one canonical constructor; no longer need to keep looking + // only one canonical constructor; no need to keep looking - TypeMirror objectType = utils.elementUtils.getTypeElement("java.lang.Object").asType(); + TypeMirror objectType = utils.getObjectType(); There is a symbol table cache maintained in Utils, for performance improvements. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java Nice simplifications to modifiersToString. With the Element ordering changes (ElementComparator) I thought this might cause failures in TestOrdering, I guess the previous ordering are being preserved, but there are no Records elements in this test ? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java + private void add(List contents, String resourceKey) {+ // Special case to allow '{@link ...}' to appear in the string.+ // A less general case would be to detect literal use of Object.equals+ // A more general case would be to allow access to DocCommentParser somehow Yes the church vs. state rule, I don't quite understand the problem we are trying solve with this code. + * name is to be inserted. T+ * @param key the resource key for the description Looks like we have a hanging "T". One last thing, was the doc comparator run ? The reason I ask, there seems to be unrelated improvements ex: Utils::modifiersToString etc, not sure if regressions are lurking in the output. Best, Kumar Srinivasan PS: I will have to go into radio silence for some time. On Wed, Oct 30, 2019 at 4:54 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Please review a moderately small update to the proposed support for > records in javadoc. > > The primary change is to include record components in the signature of a > record displayed near the top of the page. > > In addition, a "combo test" is added into TestRecordTypes.java to verify > the presence or absence of annotations in various places in the > generated page for a record, depending on the `@Target` of the annotations. > > Finally, there are some small cosmetic changes, and the supporting files > for some previously published examples. > > Two webrevs are provided. > > The first is a cumulative webrev of the modified javadoc source and test > files, compared against the default branch of the amber repo (i.e. the > state of the jdk/jdk repo) > http://cr.openjdk.java.net/~jjg/amber-records/webrev.default/ > > The second is a "delta webrev" of the recently modified javadoc source > and test files, compared against the tip of the records branch of the > amber repo. > http://cr.openjdk.java.net/~jjg/amber-records/webrev.tip/ > > Also, the sets of examples are updated, showing examples linked and not > linked to JDK API docs > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-with-link/ > http://cr.openjdk.java.net/~jjg/amber-records/examples/api-no-link/ > > Finally, I note a curiosity, arising from the proposed spec. This is > the first occurrence that I can think of in which an item that is > syntactically necessary in the source code does /not/ show up in the > same place in the generated documentation. In general, in previous > instances where the documented signatures differ from the source code, > the difference has been the addition of default or mandated elements. > Here, the presence of an annotation on the declaration of a record > component in source code may not show up in the corresponding place in > the documented signature, depending on the specified @Target for the > annotation. I'm not saying that's wrong, but it is curious, and may need > explaining to some. > > -- Jon > > JEP 359: https://openjdk.java.net/jeps/359 > > From brian.goetz at oracle.com Sat Nov 2 18:22:51 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 2 Nov 2019 14:22:51 -0400 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: <8736f61jx5.fsf@mid.deneb.enyo.de> References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> <87bltu1sv7.fsf@mid.deneb.enyo.de> <89445D90-BFAF-4509-A361-0C47AFE003CB@oracle.com> <8736f61jx5.fsf@mid.deneb.enyo.de> Message-ID: <65ff3b35-a62d-7127-157d-33c3e21d203a@oracle.com> >> The basic idea is that with a record, you?ve given up the right to >> decouple your API from the representation, which is declared in the >> header. So you will get a public canonical constructor, accessors, >> state-based Object methods, and eventually, a deconstruction pattern. >> You can ?override? these methods, but subject to an invariant: >> ?copying? a record (feeding the result of its accessors to its >> canonical actor) must be equals() to the original. A record is the >> state, the whole state, and nothing but the state. > Sorry, I don't think the current specification of explicitly declared > canonical constructors achieves this. As far as I can tell, this is > legal: > > record R(int i) { > public R(int i) { > this.i = i + 1; > } > } Yes, the compiler will allow this; the specification alluded to above lives in java.lang.Record, the implicit supertype of all record classes.? The class you've written above is broken in exactly the same way this one is: ??? class Foo { ??????? public boolean equals(Object o) { ??????????? return random.nextBoolean(); ??????? } ??? } Your class is broken -- because it fails to conform to the spec of Object::equals -- but it is not the compilers job (nor could it be) to catch these sorts of errors.? It's just bad code.? The only way to prevent this is to not let people override equals, which would obviously be terrible in its own way. > What is the use case for transformation of record fields in canonical > constructors? I would expect canonical constructors to have an > implicit preamble which assigns all the fields, similar to the compact > form. All these constructors can do is checking that the record > invariants aren't violated. There are two main reasons why a record implementation might want to transform its arguments before committing them to fields: defensive copies and argument normalization.? For example, if you have an array component, you might well want to clone() it before storing it (and same in the accessor); the same may be true with other mutable objects.? Normalization is less obvious, but still legitimate; you may want to clamp values to their bounds, or reduce a rational to lowest terms.? So yes, the language lets people write broken records, just as it lets them write classes for which equal objects don't have equal hash codes. From vicente.romero at oracle.com Sun Nov 3 14:28:43 2019 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 03 Nov 2019 14:28:43 +0000 Subject: hg: amber/amber: 58 new changesets Message-ID: <201911031428.xA3ESlsJ015588@aojmv0008.oracle.com> Changeset: 0942a1f47d26 Author: kvn Date: 2019-10-25 11:51 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/0942a1f47d26 8225464: Obsolete TraceNMethodInstalls flag Reviewed-by: dholmes, thartmann ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: d3382812b788 Author: never Date: 2019-10-25 13:17 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/d3382812b788 8233027: OopMapSet::all_do does oms.next() twice during iteration Reviewed-by: shade, kvn ! src/hotspot/share/compiler/oopMap.cpp Changeset: 9261ad32cba9 Author: alanb Date: 2019-10-27 12:13 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/9261ad32cba9 8212132: (dc) Remove DatagramChannelImpl finalize method Reviewed-by: bpb, chegar, dfuchs, martin ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java + test/jdk/java/nio/channels/DatagramChannel/Unref.java Changeset: 44dc3d796110 Author: stefank Date: 2019-10-28 11:21 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/44dc3d796110 8232601: ZGC: Parameterize the ZGranuleMap table size Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zForwardingTable.cpp ! src/hotspot/share/gc/z/zGranuleMap.hpp ! src/hotspot/share/gc/z/zGranuleMap.inline.hpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zPageTable.cpp Changeset: 3aba4a42d8ad Author: stefank Date: 2019-10-28 11:23 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/3aba4a42d8ad 8232602: ZGC: Make ZGranuleMap ZAddress agnostic Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zForwardingTable.cpp ! src/hotspot/share/gc/z/zForwardingTable.inline.hpp ! src/hotspot/share/gc/z/zGranuleMap.hpp ! src/hotspot/share/gc/z/zGranuleMap.inline.hpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zPageTable.cpp ! src/hotspot/share/gc/z/zPageTable.inline.hpp Changeset: 38f4701d6587 Author: stefank Date: 2019-10-28 11:23 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/38f4701d6587 8232648: ZGC: Move ATTRIBUTE_ALIGNED to the front of declarations Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zGlobals.hpp ! src/hotspot/share/gc/z/zMarkStack.hpp ! src/hotspot/share/gc/z/zMarkStackAllocator.hpp ! src/hotspot/share/gc/z/zMarkTerminate.hpp ! src/hotspot/share/gc/z/zNMethodTableIteration.hpp Changeset: 4adca7312d8f Author: stefank Date: 2019-10-28 11:24 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/4adca7312d8f 8232649: ZGC: Add callbacks to ZMemoryManager Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zMemory.cpp ! src/hotspot/share/gc/z/zMemory.hpp Changeset: 67009d58dd70 Author: stefank Date: 2019-10-28 11:26 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/67009d58dd70 8232651: Add implementation of os::processor_id() for Windows Reviewed-by: dholmes, stuefe ! src/hotspot/os/windows/os_windows.cpp Changeset: bfb419c66ae9 Author: stefank Date: 2019-10-28 11:26 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/bfb419c66ae9 8232650: ZGC: Add initialization hooks for OS specific code Reviewed-by: pliden, eosterlund + src/hotspot/os/posix/gc/z/zInitialize_posix.cpp ! src/hotspot/os/posix/gc/z/zVirtualMemory_posix.cpp ! src/hotspot/share/gc/z/zInitialize.cpp ! src/hotspot/share/gc/z/zInitialize.hpp ! src/hotspot/share/gc/z/zVirtualMemory.cpp ! src/hotspot/share/gc/z/zVirtualMemory.hpp Changeset: a4cdca87152b Author: stefank Date: 2019-10-28 11:27 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/a4cdca87152b 8232604: ZGC: Make ZVerifyViews mapping and unmapping precise Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zFuture.hpp ! src/hotspot/share/gc/z/zFuture.inline.hpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zPage.hpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zPageCache.cpp ! src/hotspot/share/gc/z/zPageCache.hpp ! src/hotspot/share/gc/z/zPageCache.inline.hpp ! src/hotspot/share/gc/z/zVerify.cpp ! src/hotspot/share/gc/z/zVerify.hpp Changeset: 77148b8bb7a1 Author: phedlin Date: 2019-10-23 12:51 +0200 URL: https://hg.openjdk.java.net/amber/amber/rev/77148b8bb7a1 8231565: More node budget asserts in fuzzed tests. Reviewed-by: neliasso, thartmann ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/LoopRotateBadNodeBudget.java Changeset: 7f27d70a2424 Author: hseigel Date: 2019-10-28 12:55 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/7f27d70a2424 8232890: Remove bad Code attribute parsing code Summary: Remove code that accepts illegal max_stack, max_locals, and length values for Code attribute in old class files. Reviewed-by: dholmes, lfoltan ! src/hotspot/share/classfile/classFileParser.cpp Changeset: ef8be51fff48 Author: zgu Date: 2019-10-28 11:33 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/ef8be51fff48 8232992: Shenandoah: Implement self-fixing interpreter LRB Reviewed-by: shade ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp Changeset: 5ec8aeda451e Author: bobv Date: 2019-10-28 16:06 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/5ec8aeda451e 8232118: Add JVM option to enable JVMCI compilers in product mode Reviewed-by: kvn, dholmes ! src/hotspot/share/jvmci/jvmci_globals.cpp ! src/hotspot/share/jvmci/jvmci_globals.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/flags/jvmFlag.hpp Changeset: 9d95d8a8b750 Author: lancea Date: 2019-10-28 13:17 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/9d95d8a8b750 8232879: Writing out data with the Zip File System leads to a CRC failure Reviewed-by: lancea, clanger Contributed-by: Jaikiran Pai ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java + test/jdk/jdk/nio/zipfs/CRCWriteTest.java Changeset: c3696c94049d Author: naoto Date: 2019-10-28 11:06 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/c3696c94049d 8231273: Upgrade CLDR to v36 Reviewed-by: rriggs ! make/data/cldr/README ! make/data/cldr/common/bcp47/timezone.xml ! make/data/cldr/common/dtd/ldml.dtd ! make/data/cldr/common/dtd/ldmlBCP47.dtd ! make/data/cldr/common/dtd/ldmlSupplemental.dtd ! make/data/cldr/common/main/af.xml ! make/data/cldr/common/main/af_NA.xml ! make/data/cldr/common/main/af_ZA.xml ! make/data/cldr/common/main/agq.xml ! make/data/cldr/common/main/agq_CM.xml ! make/data/cldr/common/main/ak.xml ! make/data/cldr/common/main/ak_GH.xml ! make/data/cldr/common/main/am.xml ! make/data/cldr/common/main/am_ET.xml ! make/data/cldr/common/main/ar.xml ! make/data/cldr/common/main/ar_001.xml ! make/data/cldr/common/main/ar_AE.xml ! make/data/cldr/common/main/ar_BH.xml ! make/data/cldr/common/main/ar_DJ.xml ! make/data/cldr/common/main/ar_DZ.xml ! make/data/cldr/common/main/ar_EG.xml ! make/data/cldr/common/main/ar_EH.xml ! make/data/cldr/common/main/ar_ER.xml ! make/data/cldr/common/main/ar_IL.xml ! make/data/cldr/common/main/ar_IQ.xml ! make/data/cldr/common/main/ar_JO.xml ! make/data/cldr/common/main/ar_KM.xml ! make/data/cldr/common/main/ar_KW.xml ! make/data/cldr/common/main/ar_LB.xml ! make/data/cldr/common/main/ar_LY.xml ! make/data/cldr/common/main/ar_MA.xml ! make/data/cldr/common/main/ar_MR.xml ! make/data/cldr/common/main/ar_OM.xml ! make/data/cldr/common/main/ar_PS.xml ! make/data/cldr/common/main/ar_QA.xml ! make/data/cldr/common/main/ar_SA.xml ! make/data/cldr/common/main/ar_SD.xml ! make/data/cldr/common/main/ar_SO.xml ! make/data/cldr/common/main/ar_SS.xml ! make/data/cldr/common/main/ar_SY.xml ! make/data/cldr/common/main/ar_TD.xml ! make/data/cldr/common/main/ar_TN.xml ! make/data/cldr/common/main/ar_YE.xml ! make/data/cldr/common/main/as.xml ! make/data/cldr/common/main/as_IN.xml ! make/data/cldr/common/main/asa.xml ! make/data/cldr/common/main/asa_TZ.xml ! make/data/cldr/common/main/ast.xml ! make/data/cldr/common/main/ast_ES.xml ! make/data/cldr/common/main/az.xml ! make/data/cldr/common/main/az_Cyrl.xml ! make/data/cldr/common/main/az_Cyrl_AZ.xml ! make/data/cldr/common/main/az_Latn.xml ! make/data/cldr/common/main/az_Latn_AZ.xml ! make/data/cldr/common/main/bas.xml ! make/data/cldr/common/main/bas_CM.xml ! make/data/cldr/common/main/be.xml ! make/data/cldr/common/main/be_BY.xml ! make/data/cldr/common/main/bem.xml ! make/data/cldr/common/main/bem_ZM.xml ! make/data/cldr/common/main/bez.xml ! make/data/cldr/common/main/bez_TZ.xml ! make/data/cldr/common/main/bg.xml ! make/data/cldr/common/main/bg_BG.xml ! make/data/cldr/common/main/bm.xml ! make/data/cldr/common/main/bm_ML.xml ! make/data/cldr/common/main/bn.xml ! make/data/cldr/common/main/bn_BD.xml ! make/data/cldr/common/main/bn_IN.xml ! make/data/cldr/common/main/bo.xml ! make/data/cldr/common/main/bo_CN.xml ! make/data/cldr/common/main/bo_IN.xml ! make/data/cldr/common/main/br.xml ! make/data/cldr/common/main/br_FR.xml ! make/data/cldr/common/main/brx.xml ! make/data/cldr/common/main/brx_IN.xml ! make/data/cldr/common/main/bs.xml ! make/data/cldr/common/main/bs_Cyrl.xml ! make/data/cldr/common/main/bs_Cyrl_BA.xml ! make/data/cldr/common/main/bs_Latn.xml ! make/data/cldr/common/main/bs_Latn_BA.xml ! make/data/cldr/common/main/ca.xml ! make/data/cldr/common/main/ca_AD.xml ! make/data/cldr/common/main/ca_ES.xml ! make/data/cldr/common/main/ca_ES_VALENCIA.xml ! make/data/cldr/common/main/ca_FR.xml ! make/data/cldr/common/main/ca_IT.xml ! make/data/cldr/common/main/ccp.xml ! make/data/cldr/common/main/ccp_BD.xml ! make/data/cldr/common/main/ccp_IN.xml ! make/data/cldr/common/main/ce.xml ! make/data/cldr/common/main/ce_RU.xml ! make/data/cldr/common/main/ceb.xml ! make/data/cldr/common/main/ceb_PH.xml ! make/data/cldr/common/main/cgg.xml ! make/data/cldr/common/main/cgg_UG.xml ! make/data/cldr/common/main/chr.xml ! make/data/cldr/common/main/chr_US.xml ! make/data/cldr/common/main/ckb.xml ! make/data/cldr/common/main/ckb_IQ.xml ! make/data/cldr/common/main/ckb_IR.xml ! make/data/cldr/common/main/cs.xml ! make/data/cldr/common/main/cs_CZ.xml ! make/data/cldr/common/main/cu.xml ! make/data/cldr/common/main/cu_RU.xml ! make/data/cldr/common/main/cy.xml ! make/data/cldr/common/main/cy_GB.xml ! make/data/cldr/common/main/da.xml ! make/data/cldr/common/main/da_DK.xml ! make/data/cldr/common/main/da_GL.xml ! make/data/cldr/common/main/dav.xml ! make/data/cldr/common/main/dav_KE.xml ! make/data/cldr/common/main/de.xml ! make/data/cldr/common/main/de_AT.xml ! make/data/cldr/common/main/de_BE.xml ! make/data/cldr/common/main/de_CH.xml ! make/data/cldr/common/main/de_DE.xml ! make/data/cldr/common/main/de_IT.xml ! make/data/cldr/common/main/de_LI.xml ! make/data/cldr/common/main/de_LU.xml ! make/data/cldr/common/main/dje.xml ! make/data/cldr/common/main/dje_NE.xml ! make/data/cldr/common/main/dsb.xml ! make/data/cldr/common/main/dsb_DE.xml ! make/data/cldr/common/main/dua.xml ! make/data/cldr/common/main/dua_CM.xml ! make/data/cldr/common/main/dyo.xml ! make/data/cldr/common/main/dyo_SN.xml ! make/data/cldr/common/main/dz.xml ! make/data/cldr/common/main/dz_BT.xml ! make/data/cldr/common/main/ebu.xml ! make/data/cldr/common/main/ebu_KE.xml ! make/data/cldr/common/main/ee.xml ! make/data/cldr/common/main/ee_GH.xml ! make/data/cldr/common/main/ee_TG.xml ! make/data/cldr/common/main/el.xml ! make/data/cldr/common/main/el_CY.xml ! make/data/cldr/common/main/el_GR.xml ! make/data/cldr/common/main/en.xml ! make/data/cldr/common/main/en_001.xml ! make/data/cldr/common/main/en_150.xml ! make/data/cldr/common/main/en_AE.xml ! make/data/cldr/common/main/en_AG.xml ! make/data/cldr/common/main/en_AI.xml ! make/data/cldr/common/main/en_AS.xml ! make/data/cldr/common/main/en_AT.xml ! make/data/cldr/common/main/en_AU.xml ! make/data/cldr/common/main/en_BB.xml ! make/data/cldr/common/main/en_BE.xml ! make/data/cldr/common/main/en_BI.xml ! make/data/cldr/common/main/en_BM.xml ! make/data/cldr/common/main/en_BS.xml ! make/data/cldr/common/main/en_BW.xml ! make/data/cldr/common/main/en_BZ.xml ! make/data/cldr/common/main/en_CA.xml ! make/data/cldr/common/main/en_CC.xml ! make/data/cldr/common/main/en_CH.xml ! make/data/cldr/common/main/en_CK.xml ! make/data/cldr/common/main/en_CM.xml ! make/data/cldr/common/main/en_CX.xml ! make/data/cldr/common/main/en_CY.xml ! make/data/cldr/common/main/en_DE.xml ! make/data/cldr/common/main/en_DG.xml ! make/data/cldr/common/main/en_DK.xml ! make/data/cldr/common/main/en_DM.xml ! make/data/cldr/common/main/en_ER.xml ! make/data/cldr/common/main/en_FI.xml ! make/data/cldr/common/main/en_FJ.xml ! make/data/cldr/common/main/en_FK.xml ! make/data/cldr/common/main/en_FM.xml ! make/data/cldr/common/main/en_GB.xml ! make/data/cldr/common/main/en_GD.xml ! make/data/cldr/common/main/en_GG.xml ! make/data/cldr/common/main/en_GH.xml ! make/data/cldr/common/main/en_GI.xml ! make/data/cldr/common/main/en_GM.xml ! make/data/cldr/common/main/en_GU.xml ! make/data/cldr/common/main/en_GY.xml ! make/data/cldr/common/main/en_HK.xml ! make/data/cldr/common/main/en_IE.xml ! make/data/cldr/common/main/en_IL.xml ! make/data/cldr/common/main/en_IM.xml ! make/data/cldr/common/main/en_IN.xml ! make/data/cldr/common/main/en_IO.xml ! make/data/cldr/common/main/en_JE.xml ! make/data/cldr/common/main/en_JM.xml ! make/data/cldr/common/main/en_KE.xml ! make/data/cldr/common/main/en_KI.xml ! make/data/cldr/common/main/en_KN.xml ! make/data/cldr/common/main/en_KY.xml ! make/data/cldr/common/main/en_LC.xml ! make/data/cldr/common/main/en_LR.xml ! make/data/cldr/common/main/en_LS.xml ! make/data/cldr/common/main/en_MG.xml ! make/data/cldr/common/main/en_MH.xml ! make/data/cldr/common/main/en_MO.xml ! make/data/cldr/common/main/en_MP.xml ! make/data/cldr/common/main/en_MS.xml ! make/data/cldr/common/main/en_MT.xml ! make/data/cldr/common/main/en_MU.xml ! make/data/cldr/common/main/en_MW.xml ! make/data/cldr/common/main/en_MY.xml ! make/data/cldr/common/main/en_NA.xml ! make/data/cldr/common/main/en_NF.xml ! make/data/cldr/common/main/en_NG.xml ! make/data/cldr/common/main/en_NL.xml ! make/data/cldr/common/main/en_NR.xml ! make/data/cldr/common/main/en_NU.xml ! make/data/cldr/common/main/en_NZ.xml ! make/data/cldr/common/main/en_PG.xml ! make/data/cldr/common/main/en_PH.xml ! make/data/cldr/common/main/en_PK.xml ! make/data/cldr/common/main/en_PN.xml ! make/data/cldr/common/main/en_PR.xml ! make/data/cldr/common/main/en_PW.xml ! make/data/cldr/common/main/en_RW.xml ! make/data/cldr/common/main/en_SB.xml ! make/data/cldr/common/main/en_SC.xml ! make/data/cldr/common/main/en_SD.xml ! make/data/cldr/common/main/en_SE.xml ! make/data/cldr/common/main/en_SG.xml ! make/data/cldr/common/main/en_SH.xml ! make/data/cldr/common/main/en_SI.xml ! make/data/cldr/common/main/en_SL.xml ! make/data/cldr/common/main/en_SS.xml ! make/data/cldr/common/main/en_SX.xml ! make/data/cldr/common/main/en_SZ.xml ! make/data/cldr/common/main/en_TC.xml ! make/data/cldr/common/main/en_TK.xml ! make/data/cldr/common/main/en_TO.xml ! make/data/cldr/common/main/en_TT.xml ! make/data/cldr/common/main/en_TV.xml ! make/data/cldr/common/main/en_TZ.xml ! make/data/cldr/common/main/en_UG.xml ! make/data/cldr/common/main/en_UM.xml ! make/data/cldr/common/main/en_US.xml ! make/data/cldr/common/main/en_US_POSIX.xml ! make/data/cldr/common/main/en_VC.xml ! make/data/cldr/common/main/en_VG.xml ! make/data/cldr/common/main/en_VI.xml ! make/data/cldr/common/main/en_VU.xml ! make/data/cldr/common/main/en_WS.xml ! make/data/cldr/common/main/en_ZA.xml ! make/data/cldr/common/main/en_ZM.xml ! make/data/cldr/common/main/en_ZW.xml ! make/data/cldr/common/main/eo.xml ! make/data/cldr/common/main/eo_001.xml ! make/data/cldr/common/main/es.xml ! make/data/cldr/common/main/es_419.xml ! make/data/cldr/common/main/es_AR.xml ! make/data/cldr/common/main/es_BO.xml ! make/data/cldr/common/main/es_BR.xml ! make/data/cldr/common/main/es_BZ.xml ! make/data/cldr/common/main/es_CL.xml ! make/data/cldr/common/main/es_CO.xml ! make/data/cldr/common/main/es_CR.xml ! make/data/cldr/common/main/es_CU.xml ! make/data/cldr/common/main/es_DO.xml ! make/data/cldr/common/main/es_EA.xml ! make/data/cldr/common/main/es_EC.xml ! make/data/cldr/common/main/es_ES.xml ! make/data/cldr/common/main/es_GQ.xml ! make/data/cldr/common/main/es_GT.xml ! make/data/cldr/common/main/es_HN.xml ! make/data/cldr/common/main/es_IC.xml ! make/data/cldr/common/main/es_MX.xml ! make/data/cldr/common/main/es_NI.xml ! make/data/cldr/common/main/es_PA.xml ! make/data/cldr/common/main/es_PE.xml ! make/data/cldr/common/main/es_PH.xml ! make/data/cldr/common/main/es_PR.xml ! make/data/cldr/common/main/es_PY.xml ! make/data/cldr/common/main/es_SV.xml ! make/data/cldr/common/main/es_US.xml ! make/data/cldr/common/main/es_UY.xml ! make/data/cldr/common/main/es_VE.xml ! make/data/cldr/common/main/et.xml ! make/data/cldr/common/main/et_EE.xml ! make/data/cldr/common/main/eu.xml ! make/data/cldr/common/main/eu_ES.xml ! make/data/cldr/common/main/ewo.xml ! make/data/cldr/common/main/ewo_CM.xml ! make/data/cldr/common/main/fa.xml ! make/data/cldr/common/main/fa_AF.xml ! make/data/cldr/common/main/fa_IR.xml ! make/data/cldr/common/main/ff.xml ! make/data/cldr/common/main/ff_Latn.xml ! make/data/cldr/common/main/ff_Latn_BF.xml ! make/data/cldr/common/main/ff_Latn_CM.xml ! make/data/cldr/common/main/ff_Latn_GH.xml ! make/data/cldr/common/main/ff_Latn_GM.xml ! make/data/cldr/common/main/ff_Latn_GN.xml ! make/data/cldr/common/main/ff_Latn_GW.xml ! make/data/cldr/common/main/ff_Latn_LR.xml ! make/data/cldr/common/main/ff_Latn_MR.xml ! make/data/cldr/common/main/ff_Latn_NE.xml ! make/data/cldr/common/main/ff_Latn_NG.xml ! make/data/cldr/common/main/ff_Latn_SL.xml ! make/data/cldr/common/main/ff_Latn_SN.xml ! make/data/cldr/common/main/fi.xml ! make/data/cldr/common/main/fi_FI.xml ! make/data/cldr/common/main/fil.xml ! make/data/cldr/common/main/fil_PH.xml ! make/data/cldr/common/main/fo.xml ! make/data/cldr/common/main/fo_DK.xml ! make/data/cldr/common/main/fo_FO.xml ! make/data/cldr/common/main/fr.xml ! make/data/cldr/common/main/fr_BE.xml ! make/data/cldr/common/main/fr_BF.xml ! make/data/cldr/common/main/fr_BI.xml ! make/data/cldr/common/main/fr_BJ.xml ! make/data/cldr/common/main/fr_BL.xml ! make/data/cldr/common/main/fr_CA.xml ! make/data/cldr/common/main/fr_CD.xml ! make/data/cldr/common/main/fr_CF.xml ! make/data/cldr/common/main/fr_CG.xml ! make/data/cldr/common/main/fr_CH.xml ! make/data/cldr/common/main/fr_CI.xml ! make/data/cldr/common/main/fr_CM.xml ! make/data/cldr/common/main/fr_DJ.xml ! make/data/cldr/common/main/fr_DZ.xml ! make/data/cldr/common/main/fr_FR.xml ! make/data/cldr/common/main/fr_GA.xml ! make/data/cldr/common/main/fr_GF.xml ! make/data/cldr/common/main/fr_GN.xml ! make/data/cldr/common/main/fr_GP.xml ! make/data/cldr/common/main/fr_GQ.xml ! make/data/cldr/common/main/fr_HT.xml ! make/data/cldr/common/main/fr_KM.xml ! make/data/cldr/common/main/fr_LU.xml ! make/data/cldr/common/main/fr_MA.xml ! make/data/cldr/common/main/fr_MC.xml ! make/data/cldr/common/main/fr_MF.xml ! make/data/cldr/common/main/fr_MG.xml ! make/data/cldr/common/main/fr_ML.xml ! make/data/cldr/common/main/fr_MQ.xml ! make/data/cldr/common/main/fr_MR.xml ! make/data/cldr/common/main/fr_MU.xml ! make/data/cldr/common/main/fr_NC.xml ! make/data/cldr/common/main/fr_NE.xml ! make/data/cldr/common/main/fr_PF.xml ! make/data/cldr/common/main/fr_PM.xml ! make/data/cldr/common/main/fr_RE.xml ! make/data/cldr/common/main/fr_RW.xml ! make/data/cldr/common/main/fr_SC.xml ! make/data/cldr/common/main/fr_SN.xml ! make/data/cldr/common/main/fr_SY.xml ! make/data/cldr/common/main/fr_TD.xml ! make/data/cldr/common/main/fr_TG.xml ! make/data/cldr/common/main/fr_TN.xml ! make/data/cldr/common/main/fr_VU.xml ! make/data/cldr/common/main/fr_WF.xml ! make/data/cldr/common/main/fr_YT.xml ! make/data/cldr/common/main/fur.xml ! make/data/cldr/common/main/fur_IT.xml ! make/data/cldr/common/main/fy.xml ! make/data/cldr/common/main/fy_NL.xml ! make/data/cldr/common/main/ga.xml + make/data/cldr/common/main/ga_GB.xml ! make/data/cldr/common/main/ga_IE.xml ! make/data/cldr/common/main/gd.xml ! make/data/cldr/common/main/gd_GB.xml ! make/data/cldr/common/main/gl.xml ! make/data/cldr/common/main/gl_ES.xml ! make/data/cldr/common/main/gsw.xml ! make/data/cldr/common/main/gsw_CH.xml ! make/data/cldr/common/main/gsw_FR.xml ! make/data/cldr/common/main/gsw_LI.xml ! make/data/cldr/common/main/gu.xml ! make/data/cldr/common/main/gu_IN.xml ! make/data/cldr/common/main/guz.xml ! make/data/cldr/common/main/guz_KE.xml ! make/data/cldr/common/main/gv.xml ! make/data/cldr/common/main/gv_IM.xml ! make/data/cldr/common/main/ha.xml ! make/data/cldr/common/main/ha_GH.xml ! make/data/cldr/common/main/ha_NE.xml ! make/data/cldr/common/main/ha_NG.xml ! make/data/cldr/common/main/haw.xml ! make/data/cldr/common/main/haw_US.xml ! make/data/cldr/common/main/he.xml ! make/data/cldr/common/main/he_IL.xml ! make/data/cldr/common/main/hi.xml ! make/data/cldr/common/main/hi_IN.xml ! make/data/cldr/common/main/hr.xml ! make/data/cldr/common/main/hr_BA.xml ! make/data/cldr/common/main/hr_HR.xml ! make/data/cldr/common/main/hsb.xml ! make/data/cldr/common/main/hsb_DE.xml ! make/data/cldr/common/main/hu.xml ! make/data/cldr/common/main/hu_HU.xml ! make/data/cldr/common/main/hy.xml ! make/data/cldr/common/main/hy_AM.xml ! make/data/cldr/common/main/ia.xml ! make/data/cldr/common/main/ia_001.xml ! make/data/cldr/common/main/id.xml ! make/data/cldr/common/main/id_ID.xml ! make/data/cldr/common/main/ig.xml ! make/data/cldr/common/main/ig_NG.xml ! make/data/cldr/common/main/ii.xml ! make/data/cldr/common/main/ii_CN.xml ! make/data/cldr/common/main/is.xml ! make/data/cldr/common/main/is_IS.xml ! make/data/cldr/common/main/it.xml ! make/data/cldr/common/main/it_CH.xml ! make/data/cldr/common/main/it_IT.xml ! make/data/cldr/common/main/it_SM.xml ! make/data/cldr/common/main/it_VA.xml ! make/data/cldr/common/main/ja.xml ! make/data/cldr/common/main/ja_JP.xml ! make/data/cldr/common/main/jgo.xml ! make/data/cldr/common/main/jgo_CM.xml ! make/data/cldr/common/main/jmc.xml ! make/data/cldr/common/main/jmc_TZ.xml ! make/data/cldr/common/main/jv.xml ! make/data/cldr/common/main/jv_ID.xml ! make/data/cldr/common/main/ka.xml ! make/data/cldr/common/main/ka_GE.xml ! make/data/cldr/common/main/kab.xml ! make/data/cldr/common/main/kab_DZ.xml ! make/data/cldr/common/main/kam.xml ! make/data/cldr/common/main/kam_KE.xml ! make/data/cldr/common/main/kde.xml ! make/data/cldr/common/main/kde_TZ.xml ! make/data/cldr/common/main/kea.xml ! make/data/cldr/common/main/kea_CV.xml ! make/data/cldr/common/main/khq.xml ! make/data/cldr/common/main/khq_ML.xml ! make/data/cldr/common/main/ki.xml ! make/data/cldr/common/main/ki_KE.xml ! make/data/cldr/common/main/kk.xml ! make/data/cldr/common/main/kk_KZ.xml ! make/data/cldr/common/main/kkj.xml ! make/data/cldr/common/main/kkj_CM.xml ! make/data/cldr/common/main/kl.xml ! make/data/cldr/common/main/kl_GL.xml ! make/data/cldr/common/main/kln.xml ! make/data/cldr/common/main/kln_KE.xml ! make/data/cldr/common/main/km.xml ! make/data/cldr/common/main/km_KH.xml ! make/data/cldr/common/main/kn.xml ! make/data/cldr/common/main/kn_IN.xml ! make/data/cldr/common/main/ko.xml ! make/data/cldr/common/main/ko_KP.xml ! make/data/cldr/common/main/ko_KR.xml ! make/data/cldr/common/main/kok.xml ! make/data/cldr/common/main/kok_IN.xml ! make/data/cldr/common/main/ks.xml ! make/data/cldr/common/main/ks_IN.xml ! make/data/cldr/common/main/ksb.xml ! make/data/cldr/common/main/ksb_TZ.xml ! make/data/cldr/common/main/ksf.xml ! make/data/cldr/common/main/ksf_CM.xml ! make/data/cldr/common/main/ksh.xml ! make/data/cldr/common/main/ksh_DE.xml ! make/data/cldr/common/main/ku.xml ! make/data/cldr/common/main/ku_TR.xml ! make/data/cldr/common/main/kw.xml ! make/data/cldr/common/main/kw_GB.xml ! make/data/cldr/common/main/ky.xml ! make/data/cldr/common/main/ky_KG.xml ! make/data/cldr/common/main/lag.xml ! make/data/cldr/common/main/lag_TZ.xml ! make/data/cldr/common/main/lb.xml ! make/data/cldr/common/main/lb_LU.xml ! make/data/cldr/common/main/lg.xml ! make/data/cldr/common/main/lg_UG.xml ! make/data/cldr/common/main/lkt.xml ! make/data/cldr/common/main/lkt_US.xml ! make/data/cldr/common/main/ln.xml ! make/data/cldr/common/main/ln_AO.xml ! make/data/cldr/common/main/ln_CD.xml ! make/data/cldr/common/main/ln_CF.xml ! make/data/cldr/common/main/ln_CG.xml ! make/data/cldr/common/main/lo.xml ! make/data/cldr/common/main/lo_LA.xml ! make/data/cldr/common/main/lrc.xml ! make/data/cldr/common/main/lrc_IQ.xml ! make/data/cldr/common/main/lrc_IR.xml ! make/data/cldr/common/main/lt.xml ! make/data/cldr/common/main/lt_LT.xml ! make/data/cldr/common/main/lu.xml ! make/data/cldr/common/main/lu_CD.xml ! make/data/cldr/common/main/luo.xml ! make/data/cldr/common/main/luo_KE.xml ! make/data/cldr/common/main/luy.xml ! make/data/cldr/common/main/luy_KE.xml ! make/data/cldr/common/main/lv.xml ! make/data/cldr/common/main/lv_LV.xml ! make/data/cldr/common/main/mas.xml ! make/data/cldr/common/main/mas_KE.xml ! make/data/cldr/common/main/mas_TZ.xml ! make/data/cldr/common/main/mer.xml ! make/data/cldr/common/main/mer_KE.xml ! make/data/cldr/common/main/mfe.xml ! make/data/cldr/common/main/mfe_MU.xml ! make/data/cldr/common/main/mg.xml ! make/data/cldr/common/main/mg_MG.xml ! make/data/cldr/common/main/mgh.xml ! make/data/cldr/common/main/mgh_MZ.xml ! make/data/cldr/common/main/mgo.xml ! make/data/cldr/common/main/mgo_CM.xml ! make/data/cldr/common/main/mi.xml ! make/data/cldr/common/main/mi_NZ.xml ! make/data/cldr/common/main/mk.xml ! make/data/cldr/common/main/mk_MK.xml ! make/data/cldr/common/main/ml.xml ! make/data/cldr/common/main/ml_IN.xml ! make/data/cldr/common/main/mn.xml ! make/data/cldr/common/main/mn_MN.xml ! make/data/cldr/common/main/mr.xml ! make/data/cldr/common/main/mr_IN.xml ! make/data/cldr/common/main/ms.xml ! make/data/cldr/common/main/ms_BN.xml ! make/data/cldr/common/main/ms_MY.xml ! make/data/cldr/common/main/ms_SG.xml ! make/data/cldr/common/main/mt.xml ! make/data/cldr/common/main/mt_MT.xml ! make/data/cldr/common/main/mua.xml ! make/data/cldr/common/main/mua_CM.xml ! make/data/cldr/common/main/my.xml ! make/data/cldr/common/main/my_MM.xml ! make/data/cldr/common/main/mzn.xml ! make/data/cldr/common/main/mzn_IR.xml ! make/data/cldr/common/main/naq.xml ! make/data/cldr/common/main/naq_NA.xml ! make/data/cldr/common/main/nb.xml ! make/data/cldr/common/main/nb_NO.xml ! make/data/cldr/common/main/nb_SJ.xml ! make/data/cldr/common/main/nd.xml ! make/data/cldr/common/main/nd_ZW.xml ! make/data/cldr/common/main/nds.xml ! make/data/cldr/common/main/nds_DE.xml ! make/data/cldr/common/main/nds_NL.xml ! make/data/cldr/common/main/ne.xml ! make/data/cldr/common/main/ne_IN.xml ! make/data/cldr/common/main/ne_NP.xml ! make/data/cldr/common/main/nl.xml ! make/data/cldr/common/main/nl_AW.xml ! make/data/cldr/common/main/nl_BE.xml ! make/data/cldr/common/main/nl_BQ.xml ! make/data/cldr/common/main/nl_CW.xml ! make/data/cldr/common/main/nl_NL.xml ! make/data/cldr/common/main/nl_SR.xml ! make/data/cldr/common/main/nl_SX.xml ! make/data/cldr/common/main/nmg.xml ! make/data/cldr/common/main/nmg_CM.xml ! make/data/cldr/common/main/nn.xml ! make/data/cldr/common/main/nn_NO.xml ! make/data/cldr/common/main/nnh.xml ! make/data/cldr/common/main/nnh_CM.xml ! make/data/cldr/common/main/nus.xml ! make/data/cldr/common/main/nus_SS.xml ! make/data/cldr/common/main/nyn.xml ! make/data/cldr/common/main/nyn_UG.xml ! make/data/cldr/common/main/om.xml ! make/data/cldr/common/main/om_ET.xml ! make/data/cldr/common/main/om_KE.xml ! make/data/cldr/common/main/or.xml ! make/data/cldr/common/main/or_IN.xml ! make/data/cldr/common/main/os.xml ! make/data/cldr/common/main/os_GE.xml ! make/data/cldr/common/main/os_RU.xml ! make/data/cldr/common/main/pa.xml ! make/data/cldr/common/main/pa_Arab.xml ! make/data/cldr/common/main/pa_Arab_PK.xml ! make/data/cldr/common/main/pa_Guru.xml ! make/data/cldr/common/main/pa_Guru_IN.xml ! make/data/cldr/common/main/pl.xml ! make/data/cldr/common/main/pl_PL.xml ! make/data/cldr/common/main/prg.xml ! make/data/cldr/common/main/prg_001.xml ! make/data/cldr/common/main/ps.xml ! make/data/cldr/common/main/ps_AF.xml ! make/data/cldr/common/main/ps_PK.xml ! make/data/cldr/common/main/pt.xml ! make/data/cldr/common/main/pt_AO.xml ! make/data/cldr/common/main/pt_BR.xml ! make/data/cldr/common/main/pt_CH.xml ! make/data/cldr/common/main/pt_CV.xml ! make/data/cldr/common/main/pt_GQ.xml ! make/data/cldr/common/main/pt_GW.xml ! make/data/cldr/common/main/pt_LU.xml ! make/data/cldr/common/main/pt_MO.xml ! make/data/cldr/common/main/pt_MZ.xml ! make/data/cldr/common/main/pt_PT.xml ! make/data/cldr/common/main/pt_ST.xml ! make/data/cldr/common/main/pt_TL.xml ! make/data/cldr/common/main/qu.xml ! make/data/cldr/common/main/qu_BO.xml ! make/data/cldr/common/main/qu_EC.xml ! make/data/cldr/common/main/qu_PE.xml ! make/data/cldr/common/main/rm.xml ! make/data/cldr/common/main/rm_CH.xml ! make/data/cldr/common/main/rn.xml ! make/data/cldr/common/main/rn_BI.xml ! make/data/cldr/common/main/ro.xml ! make/data/cldr/common/main/ro_MD.xml ! make/data/cldr/common/main/ro_RO.xml ! make/data/cldr/common/main/rof.xml ! make/data/cldr/common/main/rof_TZ.xml ! make/data/cldr/common/main/root.xml ! make/data/cldr/common/main/ru.xml ! make/data/cldr/common/main/ru_BY.xml ! make/data/cldr/common/main/ru_KG.xml ! make/data/cldr/common/main/ru_KZ.xml ! make/data/cldr/common/main/ru_MD.xml ! make/data/cldr/common/main/ru_RU.xml ! make/data/cldr/common/main/ru_UA.xml ! make/data/cldr/common/main/rw.xml ! make/data/cldr/common/main/rw_RW.xml ! make/data/cldr/common/main/rwk.xml ! make/data/cldr/common/main/rwk_TZ.xml ! make/data/cldr/common/main/sah.xml ! make/data/cldr/common/main/sah_RU.xml ! make/data/cldr/common/main/saq.xml ! make/data/cldr/common/main/saq_KE.xml ! make/data/cldr/common/main/sbp.xml ! make/data/cldr/common/main/sbp_TZ.xml ! make/data/cldr/common/main/sd.xml ! make/data/cldr/common/main/sd_PK.xml ! make/data/cldr/common/main/se.xml ! make/data/cldr/common/main/se_FI.xml ! make/data/cldr/common/main/se_NO.xml ! make/data/cldr/common/main/se_SE.xml ! make/data/cldr/common/main/seh.xml ! make/data/cldr/common/main/seh_MZ.xml ! make/data/cldr/common/main/ses.xml ! make/data/cldr/common/main/ses_ML.xml ! make/data/cldr/common/main/sg.xml ! make/data/cldr/common/main/sg_CF.xml ! make/data/cldr/common/main/shi.xml ! make/data/cldr/common/main/shi_Latn.xml ! make/data/cldr/common/main/shi_Latn_MA.xml ! make/data/cldr/common/main/shi_Tfng.xml ! make/data/cldr/common/main/shi_Tfng_MA.xml ! make/data/cldr/common/main/si.xml ! make/data/cldr/common/main/si_LK.xml ! make/data/cldr/common/main/sk.xml ! make/data/cldr/common/main/sk_SK.xml ! make/data/cldr/common/main/sl.xml ! make/data/cldr/common/main/sl_SI.xml ! make/data/cldr/common/main/smn.xml ! make/data/cldr/common/main/smn_FI.xml ! make/data/cldr/common/main/sn.xml ! make/data/cldr/common/main/sn_ZW.xml ! make/data/cldr/common/main/so.xml ! make/data/cldr/common/main/so_DJ.xml ! make/data/cldr/common/main/so_ET.xml ! make/data/cldr/common/main/so_KE.xml ! make/data/cldr/common/main/so_SO.xml ! make/data/cldr/common/main/sq.xml ! make/data/cldr/common/main/sq_AL.xml ! make/data/cldr/common/main/sq_MK.xml ! make/data/cldr/common/main/sq_XK.xml ! make/data/cldr/common/main/sr.xml ! make/data/cldr/common/main/sr_Cyrl.xml ! make/data/cldr/common/main/sr_Cyrl_BA.xml ! make/data/cldr/common/main/sr_Cyrl_ME.xml ! make/data/cldr/common/main/sr_Cyrl_RS.xml ! make/data/cldr/common/main/sr_Cyrl_XK.xml ! make/data/cldr/common/main/sr_Latn.xml ! make/data/cldr/common/main/sr_Latn_BA.xml ! make/data/cldr/common/main/sr_Latn_ME.xml ! make/data/cldr/common/main/sr_Latn_RS.xml ! make/data/cldr/common/main/sr_Latn_XK.xml ! make/data/cldr/common/main/sv.xml ! make/data/cldr/common/main/sv_AX.xml ! make/data/cldr/common/main/sv_FI.xml ! make/data/cldr/common/main/sv_SE.xml ! make/data/cldr/common/main/sw.xml ! make/data/cldr/common/main/sw_CD.xml ! make/data/cldr/common/main/sw_KE.xml ! make/data/cldr/common/main/sw_TZ.xml ! make/data/cldr/common/main/sw_UG.xml ! make/data/cldr/common/main/ta.xml ! make/data/cldr/common/main/ta_IN.xml ! make/data/cldr/common/main/ta_LK.xml ! make/data/cldr/common/main/ta_MY.xml ! make/data/cldr/common/main/ta_SG.xml ! make/data/cldr/common/main/te.xml ! make/data/cldr/common/main/te_IN.xml ! make/data/cldr/common/main/teo.xml ! make/data/cldr/common/main/teo_KE.xml ! make/data/cldr/common/main/teo_UG.xml ! make/data/cldr/common/main/tg.xml ! make/data/cldr/common/main/tg_TJ.xml ! make/data/cldr/common/main/th.xml ! make/data/cldr/common/main/th_TH.xml ! make/data/cldr/common/main/ti.xml ! make/data/cldr/common/main/ti_ER.xml ! make/data/cldr/common/main/ti_ET.xml ! make/data/cldr/common/main/tk.xml ! make/data/cldr/common/main/tk_TM.xml ! make/data/cldr/common/main/to.xml ! make/data/cldr/common/main/to_TO.xml ! make/data/cldr/common/main/tr.xml ! make/data/cldr/common/main/tr_CY.xml ! make/data/cldr/common/main/tr_TR.xml ! make/data/cldr/common/main/tt.xml ! make/data/cldr/common/main/tt_RU.xml ! make/data/cldr/common/main/twq.xml ! make/data/cldr/common/main/twq_NE.xml ! make/data/cldr/common/main/tzm.xml ! make/data/cldr/common/main/tzm_MA.xml ! make/data/cldr/common/main/ug.xml ! make/data/cldr/common/main/ug_CN.xml ! make/data/cldr/common/main/uk.xml ! make/data/cldr/common/main/uk_UA.xml ! make/data/cldr/common/main/ur.xml ! make/data/cldr/common/main/ur_IN.xml ! make/data/cldr/common/main/ur_PK.xml ! make/data/cldr/common/main/uz.xml ! make/data/cldr/common/main/uz_Arab.xml ! make/data/cldr/common/main/uz_Arab_AF.xml ! make/data/cldr/common/main/uz_Cyrl.xml ! make/data/cldr/common/main/uz_Cyrl_UZ.xml ! make/data/cldr/common/main/uz_Latn.xml ! make/data/cldr/common/main/uz_Latn_UZ.xml ! make/data/cldr/common/main/vai.xml ! make/data/cldr/common/main/vai_Latn.xml ! make/data/cldr/common/main/vai_Latn_LR.xml ! make/data/cldr/common/main/vai_Vaii.xml ! make/data/cldr/common/main/vai_Vaii_LR.xml ! make/data/cldr/common/main/vi.xml ! make/data/cldr/common/main/vi_VN.xml ! make/data/cldr/common/main/vo.xml ! make/data/cldr/common/main/vo_001.xml ! make/data/cldr/common/main/vun.xml ! make/data/cldr/common/main/vun_TZ.xml ! make/data/cldr/common/main/wae.xml ! make/data/cldr/common/main/wae_CH.xml ! make/data/cldr/common/main/wo.xml ! make/data/cldr/common/main/wo_SN.xml ! make/data/cldr/common/main/xh.xml ! make/data/cldr/common/main/xh_ZA.xml ! make/data/cldr/common/main/xog.xml ! make/data/cldr/common/main/xog_UG.xml ! make/data/cldr/common/main/yav.xml ! make/data/cldr/common/main/yav_CM.xml ! make/data/cldr/common/main/yi.xml ! make/data/cldr/common/main/yi_001.xml ! make/data/cldr/common/main/yo.xml ! make/data/cldr/common/main/yo_BJ.xml ! make/data/cldr/common/main/yo_NG.xml ! make/data/cldr/common/main/yue.xml ! make/data/cldr/common/main/yue_Hans.xml ! make/data/cldr/common/main/yue_Hans_CN.xml ! make/data/cldr/common/main/yue_Hant.xml ! make/data/cldr/common/main/yue_Hant_HK.xml ! make/data/cldr/common/main/zgh.xml ! make/data/cldr/common/main/zgh_MA.xml ! make/data/cldr/common/main/zh.xml ! make/data/cldr/common/main/zh_Hans.xml ! make/data/cldr/common/main/zh_Hans_CN.xml ! make/data/cldr/common/main/zh_Hans_HK.xml ! make/data/cldr/common/main/zh_Hans_MO.xml ! make/data/cldr/common/main/zh_Hans_SG.xml ! make/data/cldr/common/main/zh_Hant.xml ! make/data/cldr/common/main/zh_Hant_HK.xml ! make/data/cldr/common/main/zh_Hant_MO.xml ! make/data/cldr/common/main/zh_Hant_TW.xml ! make/data/cldr/common/main/zu.xml ! make/data/cldr/common/main/zu_ZA.xml ! make/data/cldr/common/supplemental/attributeValueValidity.xml ! make/data/cldr/common/supplemental/characters.xml ! make/data/cldr/common/supplemental/coverageLevels.xml ! make/data/cldr/common/supplemental/dayPeriods.xml ! make/data/cldr/common/supplemental/genderList.xml ! make/data/cldr/common/supplemental/languageGroup.xml ! make/data/cldr/common/supplemental/languageInfo.xml ! make/data/cldr/common/supplemental/likelySubtags.xml ! make/data/cldr/common/supplemental/metaZones.xml ! make/data/cldr/common/supplemental/numberingSystems.xml ! make/data/cldr/common/supplemental/ordinals.xml ! make/data/cldr/common/supplemental/pluralRanges.xml ! make/data/cldr/common/supplemental/plurals.xml ! make/data/cldr/common/supplemental/rgScope.xml ! make/data/cldr/common/supplemental/subdivisions.xml ! make/data/cldr/common/supplemental/supplementalData.xml ! make/data/cldr/common/supplemental/supplementalMetadata.xml ! make/data/cldr/common/supplemental/windowsZones.xml ! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! test/jdk/java/time/test/java/time/format/TestDateTimeTextProviderWithLocale.java ! test/jdk/java/util/Calendar/CalendarDataTest.java ! test/jdk/java/util/Locale/Bug8179071.java ! test/jdk/java/util/Locale/bcp47u/CurrencyFormatTests.java ! test/jdk/sun/text/resources/LocaleData.cldr ! test/jdk/sun/text/resources/LocaleDataTest.java Changeset: 13ad9a1bac18 Author: coleenp Date: 2019-10-28 16:41 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/13ad9a1bac18 8086003: Test fails on OSX with java.lang.RuntimeException 'Narrow klass base: 0x0000000000000000, Narrow klass shift: 3' missing Summary: Make the test reserve 1G rather than 3G, so it is more reliable. Reviewed-by: hseigel, stuefe ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java Changeset: fa0b9f9c597a Author: weijun Date: 2019-10-29 09:34 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/fa0b9f9c597a 8228969: 2019-09-28 public suffix list update Reviewed-by: mullan ! make/data/publicsuffixlist/VERSION ! make/data/publicsuffixlist/public_suffix_list.dat ! src/java.base/share/legal/public_suffix.md + test/jdk/sun/security/util/RegisteredDomain/ParseNames.java + test/jdk/sun/security/util/RegisteredDomain/tests.dat Changeset: b026a43e1809 Author: weijun Date: 2019-10-29 09:34 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/b026a43e1809 8231365: ServicePermission::equals doesn't comply to the spec 8231196: DelegationPermission allows to create an instance that thows NPE on ::equals call Reviewed-by: mullan ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/ServicePermission.java ! test/jdk/javax/security/auth/kerberos/DelegationPermissionHash.java + test/jdk/javax/security/auth/kerberos/DelegationPermissionInit.java + test/jdk/javax/security/auth/kerberos/ServicePermissionEquals.java Changeset: 31ec3e55fa3d Author: mgronlun Date: 2019-10-29 11:33 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/31ec3e55fa3d 8230400: Missing constant pool entry for a method in stacktrace Reviewed-by: egahlin ! src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java Changeset: 6c255334120d Author: mr Date: 2019-10-29 08:26 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/6c255334120d 8232080: jlink plugins for vendor information and run-time options Reviewed-by: ihse, alanb, kvn, bobv, mchung ! make/autoconf/jdk-version.m4 ! make/autoconf/version-numbers ! make/gensrc/GensrcMisc.gmk ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/flags/jvmFlag.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/java.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/vmError.cpp ! src/java.base/share/classes/java/lang/VersionProps.java.template ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Flags.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddOptionsPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddResourcePlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VendorBugURLPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VendorVMBugURLPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VendorVersionPlugin.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/module-info.java + test/jdk/tools/jlink/plugins/AddOptionsPluginTest.java + test/jdk/tools/jlink/plugins/VendorInfoPluginsTest.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 63994dedec49 Author: jiefu Date: 2019-10-29 10:13 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/63994dedec49 8232864: Classes generated at link time by GenerateJLIClassesPlugin are not reproducible Reviewed-by: redestad, mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! test/jdk/tools/jlink/JLinkReproducibleTest.java Changeset: 5a0e0d0b3a27 Author: ecaspole Date: 2019-10-29 13:51 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/5a0e0d0b3a27 8233075: JFR - nmetods - misspelled in several places Reviewed-by: hseigel, mseledtsov ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! test/jdk/jdk/jfr/event/compiler/TestCompilerStats.java Changeset: e492513d3630 Author: lancea Date: 2019-10-29 14:22 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/e492513d3630 8231766: Files.copy and Files.move do not honor requested compression method when copying or moving within the same zip file Reviewed-by: clanger, bpb, alanb ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java + test/jdk/jdk/nio/zipfs/CopyMoveTests.java ! test/jdk/jdk/nio/zipfs/UpdateEntryTest.java Changeset: f9ac726ab347 Author: erikj Date: 2019-10-29 12:01 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/f9ac726ab347 8232748: Build static versions of certain JDK libraries Reviewed-by: ihse, bobv ! make/Bundles.gmk ! make/Help.gmk ! make/Main.gmk ! make/MainSupport.gmk + make/StaticLibsImage.gmk ! make/autoconf/flags-cflags.m4 ! make/autoconf/spec.gmk.in ! make/common/JdkNativeCompilation.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/conf/jib-profiles.js ! make/lib/Lib-java.base.gmk Changeset: 67a3f50b14ae Author: mchung Date: 2019-10-29 12:52 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/67a3f50b14ae 8173975: Lookup::in should not allow target class be primitive or array class Reviewed-by: alanb ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/lookup/LookupClassTest.java Changeset: f4290bf1cc21 Author: mr Date: 2019-10-29 13:52 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/f4290bf1cc21 8233137: runtime/ErrorHandling/VeryEarlyAssertTest.java fails after 8232080 Reviewed-by: stuefe, iignatyev, mchung ! src/hotspot/share/utilities/vmError.cpp Changeset: f1e6442241ca Author: kvn Date: 2019-10-29 15:35 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/f1e6442241ca 8233035: Update JVMCI Reviewed-by: dlong ! src/hotspot/.mx.jvmci/suite.py ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualObject.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/Cleaner.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledCode.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/Services.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/SuppressFBWarnings.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/DebugInfoTest.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestAssembler.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestHotSpotVMConfig.java + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectFormattingTest.java + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectTestBase.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MethodHandleAccessProviderData.java + test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/VirtualObjectLayoutTest.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestSpeculationLog.java Changeset: 674131501e98 Author: pli Date: 2019-10-30 09:17 +0800 URL: https://hg.openjdk.java.net/amber/amber/rev/674131501e98 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad + test/hotspot/jtreg/compiler/codegen/TestSignedMultiplyLong.java Changeset: 75099fcf7962 Author: zgu Date: 2019-10-30 09:42 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/75099fcf7962 8233165: Shenandoah:SBSA::gen_load_reference_barrier_stub() should use pointer register for address on aarch64 Reviewed-by: rkennke ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp Changeset: 3fc5905f2bec Author: aivanov Date: 2019-10-30 14:08 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/3fc5905f2bec 8232724: Remove indirection with calling JNU_NewStringPlatform Reviewed-by: dholmes, clanger ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/include/jvm.h ! src/java.base/share/native/libjava/jni_util.c ! src/java.base/share/native/libjava/jni_util.h Changeset: 506bd2e1f840 Author: chagedorn Date: 2019-10-29 14:29 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/506bd2e1f840 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" Summary: Explicitly set the receiver klass in the ci MDO to NULL if it is NULL in the MDO while translating. Reviewed-by: kvn, thartmann ! src/hotspot/share/ci/ciMethodData.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 2c3cc4b01880 Author: redestad Date: 2019-10-30 16:14 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/2c3cc4b01880 8233159: Method::result_type should use calculated value in constMethod Reviewed-by: lfoltan, iklam, coleenp ! src/hotspot/share/interpreter/bytecode.cpp ! src/hotspot/share/oops/constMethod.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp Changeset: c16ac7a2eba4 Author: mgronlun Date: 2019-10-30 19:43 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/c16ac7a2eba4 8226511: Implement JFR Event Streaming Reviewed-by: egahlin, mseledtsov, mgronlun Contributed-by: erik.gahlin at oracle.com, mikhailo.seledtsov at oracle.com, markus.gronlund at oracle.com ! src/hotspot/share/gc/g1/g1Trace.cpp ! src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp ! src/hotspot/share/gc/z/zTracer.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.hpp ! src/hotspot/share/jfr/jfr.cpp ! src/hotspot/share/jfr/jfr.hpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.hpp ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.hpp ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp ! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp ! src/hotspot/share/jfr/leakprofiler/leakProfiler.cpp ! src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp ! src/hotspot/share/jfr/metadata/jfrSerializer.hpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/periodic/jfrNetworkUtilization.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/jfr/periodic/jfrThreadCPULoadEvent.cpp ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.hpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrMetadataEvent.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrMetadataEvent.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadGroup.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.hpp + src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp + src/hotspot/share/jfr/recorder/repository/jfrChunk.hpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.hpp ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp ! src/hotspot/share/jfr/recorder/repository/jfrRepository.hpp ! src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp ! src/hotspot/share/jfr/recorder/service/jfrPostBox.hpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.hpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderThreadLoop.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.hpp ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.cpp ! src/hotspot/share/jfr/recorder/storage/jfrBuffer.hpp ! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.hpp ! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.inline.hpp ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp ! src/hotspot/share/jfr/recorder/storage/jfrStorage.hpp ! src/hotspot/share/jfr/recorder/storage/jfrStorageControl.cpp ! src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.hpp ! src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.inline.hpp ! src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp ! src/hotspot/share/jfr/recorder/stringpool/jfrStringPool.cpp ! src/hotspot/share/jfr/recorder/stringpool/jfrStringPool.hpp ! src/hotspot/share/jfr/support/jfrThreadLocal.cpp ! src/hotspot/share/jfr/support/jfrThreadLocal.hpp ! src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp ! src/hotspot/share/jfr/utilities/jfrAllocation.cpp ! src/hotspot/share/jfr/utilities/jfrDoublyLinkedList.hpp ! src/hotspot/share/jfr/utilities/jfrLogTagSets.hpp + src/hotspot/share/jfr/utilities/jfrThreadIterator.cpp + src/hotspot/share/jfr/utilities/jfrThreadIterator.hpp ! src/hotspot/share/jfr/utilities/jfrTypes.hpp ! src/hotspot/share/jfr/writers/jfrJavaEventWriter.hpp ! src/hotspot/share/jfr/writers/jfrStorageAdapter.hpp ! src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/jdk.jfr/share/classes/jdk/jfr/Recording.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ChunkParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ConstantMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/EventParser.java + src/jdk.jfr/share/classes/jdk/jfr/consumer/EventStream.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/LongMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ObjectFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/Parser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ParserFactory.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedClass.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedClassLoader.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedFrame.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedMethod.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedStackTrace.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedThread.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedThreadGroup.java ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java + src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/TimeConverter.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveRecordingEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveSettingEvent.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/EventWriter.java + src/jdk.jfr/share/classes/jdk/jfr/internal/FilePurger.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/LogTag.java + src/jdk.jfr/share/classes/jdk/jfr/internal/LongMap.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataDescriptor.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataReader.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/RepositoryChunk.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/RequestEngine.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SettingsManager.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkHeader.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ConstantLookup.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ConstantMap.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventParser.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/FileAccess.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/JdkJfrConsumer.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ObjectContext.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ObjectFactory.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Parser.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ParserFactory.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ParserFilter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInput.java - src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RepositoryFiles.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/StreamConfiguration.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/StringParser.java + src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/TimeConverter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdConfigure.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Disassemble.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/EventPrintWriter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Metadata.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Summary.java ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc ! test/hotspot/gtest/jfr/test_networkUtilization.cpp ! test/hotspot/gtest/jfr/test_threadCpuLoad.cpp ! test/jdk/ProblemList.txt ! test/jdk/jdk/jfr/api/consumer/TestReadTwice.java ! test/jdk/jdk/jfr/api/consumer/TestRecordingFile.java ! test/jdk/jdk/jfr/api/consumer/TestRecordingInternals.java + test/jdk/jdk/jfr/api/consumer/filestream/TestMultipleChunk.java + test/jdk/jdk/jfr/api/consumer/filestream/TestOrdered.java + test/jdk/jdk/jfr/api/consumer/filestream/TestReuse.java + test/jdk/jdk/jfr/api/consumer/recordingstream/EventProducer.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestAwaitTermination.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestClose.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestConstructor.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestDisable.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestEnable.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestMaxAge.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnClose.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnErrorAsync.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnErrorSync.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnEvent.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestOnFlush.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestRecursive.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestRemove.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestSetEndTime.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestSetFlushInterval.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestSetMaxAge.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestSetMaxSize.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestSetSettings.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestSetStartTime.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestStart.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestStartAsync.java + test/jdk/jdk/jfr/api/consumer/recordingstream/TestUtils.java + test/jdk/jdk/jfr/api/consumer/security/DriverRecordingDumper.java + test/jdk/jdk/jfr/api/consumer/security/TestMissingPermission.java + test/jdk/jdk/jfr/api/consumer/security/TestRecordingFile.java + test/jdk/jdk/jfr/api/consumer/security/TestRecordingStream.java + test/jdk/jdk/jfr/api/consumer/security/TestStreamingFile.java + test/jdk/jdk/jfr/api/consumer/security/TestStreamingLocal.java + test/jdk/jdk/jfr/api/consumer/security/TestStreamingRemote.java + test/jdk/jdk/jfr/api/consumer/security/local-streaming.policy + test/jdk/jdk/jfr/api/consumer/security/no-permission.policy + test/jdk/jdk/jfr/api/consumer/streaming/TestChunkGap.java + test/jdk/jdk/jfr/api/consumer/streaming/TestEmptyChunks.java + test/jdk/jdk/jfr/api/consumer/streaming/TestEnableEvents.java + test/jdk/jdk/jfr/api/consumer/streaming/TestEventRegistration.java + test/jdk/jdk/jfr/api/consumer/streaming/TestFilledChunks.java + test/jdk/jdk/jfr/api/consumer/streaming/TestFiltering.java + test/jdk/jdk/jfr/api/consumer/streaming/TestLatestEvent.java + test/jdk/jdk/jfr/api/consumer/streaming/TestRecordingBefore.java + test/jdk/jdk/jfr/api/consumer/streaming/TestRemovedChunks.java + test/jdk/jdk/jfr/api/consumer/streaming/TestRepositoryMigration.java + test/jdk/jdk/jfr/api/consumer/streaming/TestRepositoryProperty.java + test/jdk/jdk/jfr/api/consumer/streaming/TestStartMultiChunk.java + test/jdk/jdk/jfr/api/consumer/streaming/TestStartSingleChunk.java + test/jdk/jdk/jfr/api/consumer/streaming/TestUnstarted.java + test/jdk/jdk/jfr/api/event/TestEventDuration.java + test/jdk/jdk/jfr/api/recording/time/TestSetFlushInterval.java ! test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java ! test/jdk/jdk/jfr/event/oldobject/TestLargeRootSet.java + test/jdk/jdk/jfr/event/runtime/TestFlush.java + test/jdk/jdk/jfr/jcmd/TestJcmdStartFlushInterval.java + test/jdk/jdk/jfr/jvm/TestThreadExclusion.java ! test/jdk/jdk/jfr/jvm/TestUnsupportedVM.java + test/jdk/jdk/jfr/startupargs/TestFlushInterval.java ! test/lib/jdk/test/lib/jfr/EventNames.java Changeset: fba8635290df Author: lancea Date: 2019-10-30 15:54 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/fba8635290df 8231451: ZipFileInputStream::skip handling of negative values with STORED entries Reviewed-by: clanger, bpb, alanb ! src/java.base/share/classes/java/util/zip/ZipFile.java + test/jdk/java/util/zip/ZipFile/ZipFileInputStreamSkipTest.java Changeset: 6d081cef7ea8 Author: valeriep Date: 2019-10-31 02:22 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/6d081cef7ea8 8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures. Summary: Fixed to treat the queried key size values as bits instead of bytes Reviewed-by: ascarpino, xuelei ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java Changeset: 43cfcb1e39c0 Author: coleenp Date: 2019-10-30 22:32 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/43cfcb1e39c0 8233266: Remove unnecessary fence in restore_unshareable_info Reviewed-by: jiangli, dholmes ! src/hotspot/share/oops/klass.cpp Changeset: 0c671290204c Author: jwilhelm Date: 2019-10-31 04:17 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/0c671290204c Added tag jdk-14+21 for changeset c16ac7a2eba4 ! .hgtags Changeset: f547a06da806 Author: shade Date: 2019-10-31 10:37 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/f547a06da806 8233303: Shenandoah: verifier assert erroneously uses byte_size_in_exact_unit Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Changeset: 27c2d2a4b695 Author: vjovanovic Date: 2019-10-28 15:03 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/27c2d2a4b695 8232806: Introduce a system property to disable eager lambda initialization Reviewed-by: briangoetz, mr, psandoz, forax ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java ! test/langtools/tools/javac/lambda/methodReference/BridgeMethod.java Changeset: ca70299778b9 Author: alanb Date: 2019-10-31 16:45 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/ca70299778b9 8205132: Degrade Thread.countStackFrames() to throw UOE Reviewed-by: mchung, dholmes, dcubed ! make/hotspot/symbols/symbols-unix ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/native/libjava/Thread.c - test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java + test/jdk/java/lang/Thread/CountStackFrames.java Changeset: 5f1fe5971ff9 Author: dfuchs Date: 2019-10-31 19:31 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/5f1fe5971ff9 8231631: sun/net/ftp/FtpURLConnectionLeak.java fails intermittently with NPE Summary: sun/net/www/ftptest/FtpCommandHandler.java is modified to handle EOF properly Reviewed-by: chegar, vtewari ! test/jdk/sun/net/www/ftptest/FtpCommandHandler.java Changeset: c440a6b4e096 Author: bobv Date: 2019-10-31 19:32 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/c440a6b4e096 8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 Reviewed-by: dholmes, sgehwolf, redestad ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/os/linux/osContainer_linux.hpp Changeset: 8c0e8cff877f Author: goetz Date: 2019-10-29 15:08 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/8c0e8cff877f 8232921: assert(is_object_aligned(result)) failed: address not aligned Reviewed-by: coleenp, rschmelter ! src/hotspot/share/classfile/javaClasses.cpp Changeset: 1a8d65e71a66 Author: amenkov Date: 2019-10-31 14:23 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/1a8d65e71a66 8224159: JDWP IPv6 scope support Reviewed-by: sspitsyn, cjplummer ! make/lib/Lib-jdk.jdwp.agent.gmk ! src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c ! test/jdk/com/sun/jdi/JdwpAttachTest.java ! test/jdk/com/sun/jdi/JdwpListenTest.java Changeset: aec7bf35d6f5 Author: dlong Date: 2019-10-31 16:54 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/aec7bf35d6f5 8233273: Update Graal Reviewed-by: kvn ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/EconomicMap.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/EconomicSet.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/Equivalence.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/MapCursor.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/Pair.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/UnmodifiableEconomicMap.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/UnmodifiableEconomicSet.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/UnmodifiableMapCursor.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/package-info.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/ComparableWord.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/LocationIdentity.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/Pointer.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/PointerBase.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/SignedWord.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/UnsignedWord.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/WordBase.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/WordFactory.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/package-info.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitution.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitutionRegistry.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.test/src/org/graalvm/compiler/api/test/ExportingClassLoader.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.test/src/org/graalvm/compiler/api/test/ModuleSupport.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64MacroAssembler.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64MultiplyLongTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64NodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/GraalOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/cfg/AbstractBlockBase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/cfg/AbstractControlFlowGraph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/cfg/Loop.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/IntegerStamp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SPARCNodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/BoxingEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CheckGraalInvariants.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CompareCanonicalizerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CompareCanonicalizerTest2.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CompareCanonicalizerTest3.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationMulTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest10.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest14.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest15.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest16.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest2.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTestBase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CountedLoopTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/DeMorganCanonicalizationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/DegeneratedLoopsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/EnumSwitchTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/FinalizableSubclassTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/FloatingReadTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraalCompilerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraphEncoderTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GuardPrioritiesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/IfCanonicalizerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ImplicitNullCheckTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/IntegerEqualsCanonicalizerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InterfaceMethodHandleTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InvokeExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InvokeHintsTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LateMembarInsertionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LockEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LongNodeChainTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LoopFullUnrollTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LoopUnswitchTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MarkUnsafeAccessTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MemoryGraphCanonicalizeTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MemoryScheduleTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MergeCanonicalizerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MonitorGraphTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/NodePropertiesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/PushNodesThroughPiTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/PushThroughIfTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ReadAfterCheckCastTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ReassociateAndCanonicalTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ScalarTypeSystemTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SchedulingTest2.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/StampCanonicalizerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/StraighteningTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SwitchCanonicalizerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SwitchDyingLoopTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SwitchFoldingTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/TypeSystemTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnsafeReadEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnsafeVirtualizationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnusedArray.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/deopt/CompiledMethodTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/EATestBase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/EarlyReadEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/EscapeAnalysisTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PEAReadEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PartialEscapeAnalysisIterationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PartialEscapeAnalysisTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PartialEscapeAnalysisTreesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PoorMansEATest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/TrufflePEATest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/UnsafeEATest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/InliningTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/NestedLoopEffectsPhaseComplexityTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/NodeMatchRules.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/BaseTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/EconomyHighTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/EconomyLowTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/EconomyMidTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/HighTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/LowTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/MidTier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompileTheWorld.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ConstantPoolSubstitutionsTests.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/DeferredBarrierAdditionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotCryptoSubstitutionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotInvokeDynamicPluginTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ReplaceConstantNodesPhaseTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/TestSHASubstitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/WriteBarrierAdditionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotReplacementsImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/SymbolicSnippetEncoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotHostForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotSuitesProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/BeginLockScopeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/EndLockScopeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/StubForeignCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/InitializeKlassNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/InitializeKlassStubCall.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/ResolveDynamicConstantNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/aot/ResolveDynamicStubCall.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/AheadOfTimeVerificationPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/IdentityHashCodeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/SHA2Substitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/SHA5Substitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/SHASubstitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/ForeignCallStub.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/SnippetStub.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/FrameStateBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/backend/LargeConstantSectionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/except/UntrustedInterfaces.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/optimize/NestedLoop_EA.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/optimize/TrichotomyTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ArithmeticOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Move.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64StringLatin1InflateOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64StringUTF16CompressOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/vector/AMD64VectorMove.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIRIntrospection.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/ConvertDeoptimizeToGuardPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopPeelingPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopTransformations.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.test/src/org/graalvm/compiler/loop/test/LoopPartialUnrollTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/CountedLoopInfo.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/DefaultLoopPolicies.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopEx.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopFragment.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopFragmentInside.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopPolicies.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/MathUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/GraalBenchmark.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMHWhitebox.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/IfNodeCanonicalizationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/LoopPhiCanonicalizerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/ShortCircuitOrNodeTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/FrameState.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GuardProxyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/IfNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeWithExceptionNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/KillingBeginNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/LoopBeginNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/MemoryProxyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ProxyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StartNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StructuredGraph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ValueProxyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/AndNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/BinaryArithmeticNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/CompareNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/OrNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/XorNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/cfg/Block.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/cfg/ControlFlowGraph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/StringToBytesNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/BytecodeExceptionNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/ForeignCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/JavaWriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/MembarNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/RawLoadNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/RawStoreNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/SwitchNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/UnsafeAccessNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/UnsafeMemoryStoreNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderConfiguration.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/InvocationPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/MethodSubstitutionPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AbstractCompareAndSwapNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AbstractUnsafeCompareAndSwapNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AtomicReadAndAddNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AtomicReadAndWriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/ExceptionObjectNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/LoweredAtomicReadAndWriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/MonitorEnterNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/MonitorExitNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/RawMonitorEnterNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/FixedAccessNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/MemoryCheckpoint.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/VolatileReadNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/WriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/DelegatingReplacements.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/Replacements.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/util/GraphUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/virtual/AllocatedObjectNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/virtual/CommitAllocationNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/CanonicalizerPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ConditionalEliminationPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/FloatingReadPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/GuardLoweringPhase.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/InsertMembarsPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/LoweringPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/InliningUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/info/MultiTypeGuardInlineInfo.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/MemoryScheduleVerification.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/SchedulePhase.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/ScheduleVerification.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64CountLeadingZerosNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64CountTrailingZerosNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64GraphBuilderPlugins.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64IntegerSubstitutions.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64LongSubstitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringLatin1InflateNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringUTF16CompressNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.jdk9.test/src/org/graalvm/compiler/replacements/jdk9/test/VarHandleTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.sparc/src/org/graalvm/compiler/replacements/sparc/SPARCGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ArraysSubstitutionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/BitOpNodesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/DeoptimizeOnExceptionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/EdgesTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/FoldTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/IntegerExactFoldTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/MethodSubstitutionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ObjectAccessTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/PEGraphDecoderTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/PointerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ReplacementsParseTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StandardMethodSubstitutionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SubstitutionNodeSourcePositionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SubstitutionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/classfile/ClassfileBytecodeProviderTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/classfile/RedefineIntrinsicTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/CachingPEGraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DefaultJavaLoweringProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/NodeIntrinsificationProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ReplacementsImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetTemplate.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/TargetGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/CheckcastArrayCopyCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/GenericArrayCopyCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BasicArrayCopyNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/MacroNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/MacroStateSplitNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PEReadEliminationClosure.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/ReadEliminationBlockState.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/ReadEliminationClosure.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.util/src/org/graalvm/util/OptionsEncoder.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.util/src/org/graalvm/util/TypedDataInputStream.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.util/src/org/graalvm/util/TypedDataOutputStream.java Changeset: 452df727bebb Author: rschmelter Date: 2019-10-15 17:08 +0200 URL: https://hg.openjdk.java.net/amber/amber/rev/452df727bebb 8232168: Fix non wide char canonicalization on Windows Reviewed-by: clanger, alanb, ccheung ! src/java.base/windows/native/libjava/canonicalize_md.c ! test/hotspot/jtreg/runtime/LoadClass/LongBCP.java Changeset: 717ebfbac29d Author: clanger Date: 2019-11-01 07:58 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/717ebfbac29d 8232980: Cleanup initialization of function pointers into java.base from classloader.cpp Reviewed-by: iklam, ccheung ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp Changeset: 562df5d69eed Author: coleenp Date: 2019-11-01 10:04 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/562df5d69eed 8233386: Initialize NULL fields for unused decorations Reviewed-by: shade, hseigel, dcubed ! src/hotspot/share/logging/logDecorations.cpp Changeset: ab4db38ed085 Author: shade Date: 2019-11-01 16:16 +0100 URL: https://hg.openjdk.java.net/amber/amber/rev/ab4db38ed085 8233387: Shenandoah: passive mode should disable pacing ergonomically Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPassiveMode.cpp Changeset: 35bac2745d04 Author: dl Date: 2019-11-01 09:04 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/35bac2745d04 8231592: Clarify that ConcurrentHashMap compute methods mapping functions execute at most once Reviewed-by: martin ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListMapTest.java ! test/jdk/java/util/concurrent/tck/HashMapTest.java ! test/jdk/java/util/concurrent/tck/HashtableTest.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/LinkedHashMapTest.java ! test/jdk/java/util/concurrent/tck/MapImplementation.java ! test/jdk/java/util/concurrent/tck/MapTest.java ! test/jdk/java/util/concurrent/tck/TreeMapTest.java Changeset: ec954ef6caf1 Author: dl Date: 2019-11-01 09:07 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/ec954ef6caf1 8231026: Miscellaneous changes imported from jsr166 CVS 2019-11 Reviewed-by: martin ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/tck/StampedLockTest.java Changeset: b95bead30957 Author: iveresov Date: 2019-11-01 09:39 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/b95bead30957 8227003: Add high-level JIT compilation mode control mechanism Summary: Add tiered mode to emulate non-tiered with special mode for JVMCI compiler. Add -XX:CompilationMode option. Reviewed-by: never, redestad ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/tieredThresholdPolicy.cpp ! src/hotspot/share/compiler/tieredThresholdPolicy.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass/Launcher.java ! test/hotspot/jtreg/compiler/profiling/spectrapredefineclass_classloaders/Launcher.java ! test/hotspot/jtreg/serviceability/dcmd/vm/FlagsTest.java Changeset: 42aa251d6eed Author: ccheung Date: 2019-11-01 11:31 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/42aa251d6eed 8233363: Clarify the DumpSharedSpaces condition in InstanceKlass::verify_on Summary: change DumpSharedSpaces to Arguments::is_dumping_archive(). Reviewed-by: iklam, coleenp ! src/hotspot/share/oops/instanceKlass.cpp Changeset: bd9daab73a8e Author: jboes Date: 2019-11-01 12:57 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/bd9daab73a8e 8231632: HttpURLConnection::usingProxy could specify that it may lazily evaluate the fact Summary: Modified method description to disambiguate when false is returned and altered implementation Reviewed-by: dfuchs, chegar, vtewari ! src/java.base/share/classes/java/net/HttpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/jdk/java/net/HttpURLConnection/HttpURLConnUsingProxy.java Changeset: 76638c631869 Author: bpb Date: 2019-11-01 13:16 -0700 URL: https://hg.openjdk.java.net/amber/amber/rev/76638c631869 8162520: (fs) FileStore should support file stores with > Long.MAX_VALUE capacity Reviewed-by: alanb, darcy, rriggs ! src/java.base/share/classes/java/nio/file/FileStore.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java ! src/java.base/windows/classes/sun/nio/fs/WindowsFileStore.java Changeset: 4ec9fc2b2f0d Author: kbarrett Date: 2019-11-01 16:21 -0400 URL: https://hg.openjdk.java.net/amber/amber/rev/4ec9fc2b2f0d 8233359: Add global sized operator delete definitions Summary: Added new definitions. Reviewed-by: dholmes ! src/hotspot/share/memory/operator_new.cpp Changeset: 5573a7098439 Author: alanb Date: 2019-11-02 10:02 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/5573a7098439 8232673: (dc) DatagramChannel socket adaptor issues Reviewed-by: dfuchs, chegar ! src/java.base/share/classes/java/net/DatagramSocket.java ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java - test/jdk/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java + test/jdk/java/nio/channels/DatagramChannel/AdaptorBasic.java + test/jdk/java/nio/channels/DatagramChannel/AdaptorConcurrentIO.java + test/jdk/java/nio/channels/DatagramChannel/AdaptorConnect.java + test/jdk/java/nio/channels/DatagramChannel/AdaptorGetters.java ! test/jdk/java/nio/channels/etc/AdaptorCloseAndInterrupt.java From maurizio.cimadamore at oracle.com Sun Nov 3 14:30:49 2019 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sun, 03 Nov 2019 14:30:49 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201911031430.xA3EUnWs016282@aojmv0008.oracle.com> Changeset: 500ef23d397c Author: mcimadamore Date: 2019-11-03 14:30 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/500ef23d397c Automatic merge with default - src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitutionRegistry.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/MemoryScheduleVerification.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ChunkParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ConstantMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/EventParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/LongMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ObjectFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/Parser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ParserFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/TimeConverter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java - test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java - test/jdk/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java From maurizio.cimadamore at oracle.com Sun Nov 3 14:31:12 2019 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sun, 03 Nov 2019 14:31:12 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201911031431.xA3EVC1Y016639@aojmv0008.oracle.com> Changeset: ddcc65b6f1bc Author: mcimadamore Date: 2019-11-03 14:30 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/ddcc65b6f1bc Automatic merge with default - src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitutionRegistry.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/MemoryScheduleVerification.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ChunkParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ConstantMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/EventParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/LongMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ObjectFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/Parser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ParserFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/TimeConverter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java - test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java - test/jdk/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java From maurizio.cimadamore at oracle.com Sun Nov 3 14:31:36 2019 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sun, 03 Nov 2019 14:31:36 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201911031431.xA3EVbWV017074@aojmv0008.oracle.com> Changeset: b3b146f3cb75 Author: mcimadamore Date: 2019-11-03 14:31 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/b3b146f3cb75 Automatic merge with default - src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitutionRegistry.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/MemoryScheduleVerification.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ChunkParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ConstantMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/EventParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/LongMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ObjectFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/Parser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ParserFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/TimeConverter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java - test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java - test/jdk/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java From maurizio.cimadamore at oracle.com Sun Nov 3 14:32:00 2019 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sun, 03 Nov 2019 14:32:00 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201911031432.xA3EW05m017366@aojmv0008.oracle.com> Changeset: f2766f43cc6c Author: mcimadamore Date: 2019-11-03 14:31 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/f2766f43cc6c Automatic merge with default ! make/autoconf/flags-cflags.m4 - src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitutionRegistry.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/MemoryScheduleVerification.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ChunkParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ConstantMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/EventParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/LongMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ObjectFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/Parser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ParserFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/TimeConverter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java - test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java - test/jdk/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java From maurizio.cimadamore at oracle.com Sun Nov 3 14:32:24 2019 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sun, 03 Nov 2019 14:32:24 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201911031432.xA3EWP42017801@aojmv0008.oracle.com> Changeset: 676eaa611531 Author: mcimadamore Date: 2019-11-03 14:32 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/676eaa611531 Automatic merge with default - src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitutionRegistry.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/MemoryScheduleVerification.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ChunkParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ConstantMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/EventParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/LongMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ObjectFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/Parser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ParserFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/TimeConverter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java - test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java - test/jdk/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java From maurizio.cimadamore at oracle.com Sun Nov 3 14:32:48 2019 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sun, 03 Nov 2019 14:32:48 +0000 Subject: hg: amber/amber: Automatic merge with default Message-ID: <201911031432.xA3EWmD4018190@aojmv0008.oracle.com> Changeset: 81d8f438d66d Author: mcimadamore Date: 2019-11-03 14:32 +0000 URL: https://hg.openjdk.java.net/amber/amber/rev/81d8f438d66d Automatic merge with default ! make/hotspot/symbols/symbols-unix ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/include/jvm.h - src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp - src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/prims/jvm.cpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/MethodSubstitutionRegistry.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/schedule/MemoryScheduleVerification.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ChunkParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ConstantMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/EventParser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/LongMap.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ObjectFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/Parser.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/ParserFactory.java - src/jdk.jfr/share/classes/jdk/jfr/consumer/TimeConverter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java - test/hotspot/jtreg/runtime/Thread/CountStackFramesAtExit.java - test/jdk/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java From vicente.romero at oracle.com Sun Nov 3 15:27:34 2019 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sun, 03 Nov 2019 15:27:34 +0000 Subject: hg: amber/amber: removing one @author comment in one library test Message-ID: <201911031527.xA3FRYYV016644@aojmv0008.oracle.com> Changeset: c033807bfd49 Author: vromero Date: 2019-11-03 10:26 -0500 URL: https://hg.openjdk.java.net/amber/amber/rev/c033807bfd49 removing one @author comment in one library test ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java From vicente.romero at oracle.com Sun Nov 3 17:13:45 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Sun, 3 Nov 2019 12:13:45 -0500 Subject: RFR: CSR for Compiler implementation for records Message-ID: Hi, Please review the draft of the CSR for Compiler implementation for records at [1] Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8233433 From joe.darcy at oracle.com Mon Nov 4 05:33:50 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 3 Nov 2019 21:33:50 -0800 Subject: Fwd: Re: RFR: JEP 359-Records: compiler code In-Reply-To: References: <1ae03b10-ec1d-4714-264b-138209e3bdc3@oracle.com> <6675e1f0-1f7a-86cc-5ffc-9ee8d4a2af4f@oracle.com> <1f06861b-ad4b-00cb-11e2-1a2d874b54b4@oracle.com> Message-ID: <1fb0a88c-5d40-475e-984b-570806fd73b4@oracle.com> Hi Vicente, I've taken a pass over the javax.lang.model portions of the change. Elements.recordComponentFor should have an @implSpec tag. I suggest a double-check of the existing visitors/scanners that used to extend one of the "FooVisitor9" types and was updated to extend "FooVisitor14". In prior work, I had to add a new method override for visitRecordComponent to the printing processor to get the proper semantics of that class. For example, PubapiVisitor might need an update. Also, please add the new "FooVisitor14" classes for types. In terms of how the tests are placed, I'd prefer to see tests of, say annotation processing of records, groups with the existing annotation processing tests as opposed to grouped with pure records tests. I think this arrangement provides better test discoverability long term; for example, if someone is updating annotation processing and wants to make sure all the annotation processing tests are run. I recommend the annotation processing tests more consistently subclass JavaTestingAbstractProcessor as opposed to directly subclassing AbstractProcessor. In TestRecord.java, please add newlines to the string arguments to the options method on line 146. Thanks, -Joe On 10/31/2019 9:11 PM, Vicente Romero wrote: > Hi all, > > Thanks for all the feedback so far. I have published another iteration > at [1]. New in this iteration: > > Flags.java: > > - I have sync the javadoc and the comment on the RECORD flag > - renamed MemberRecordClassFlags -> MemberRecordFlags > > com.sun.tools.javac.code.Kinds.java: > - in order to generate better error messages I have added two new > kinds: RECORD_COMPONENT and RECORD > > Symbols.java > - moved method isRecord to ClassSymbol for the rest of the symbols > moved back to using the bitwise test > - removed method ::isDynamic from MethodSymbol > > Attr.java > - implemented a spec change to relax that constraint that every > non-canonical constructor should call the canonical constructor. Now > the spec forces every non-canonical constructor to invoke a different > constructor as its first statement. This actually implied removing > some code. > > Check.java > - at method ::duplicateError, there is new code to avoid generating > two errors when the user declares a record with duplicated record > component names. If this happens, then a compiler generated canonical > constructor would have duplicated parameters. This code is preventing > the compiler to generate a second error referring to a method that is > not visible to the user. Another option is to not generate the > canonical constructor at all if there are duplicate record components > - at method ::checkUnique, there is new code to improve the error > message when the user defines a constructor with the same erasure as > the canonical constructor. Still the error message is not perfect > because it shows in both cases the erasure of the methods, so they > seem to be the same. But this is not related to records code, that's a > simplification that happens at the moment of reporting the error. > > TypeEnter > - removed some commented code > - ::addRecordMembersIfNeeded here I added new code to avoid generating > accessor methods for forbidden record component names. This is to > avoid spurious errors later as any way the compiler will complain > because of the forbidden record component names. The issue with this > solution is that the list of forbidden record component names has been > duplicated here. The other location is Attr. We can probably find a > common place to define it. Probably a new utility class? > > JavacParser: > - fixed the bug that the compiler was not allowing final local records > - removed the check for abstract modifiers in records, this code was > redundant as Check was already checking this > - removed the check for duplicated record component names > - added a check to forbid instance initializers in records > > compiler.properties > - I hope I got the error messages right, I tried to reflect all the > comments, suggestions, etc. I was proposed to create a `master` > message for canonical records and use different `causes`, aka > fragments, to be more specific. I decided to follow the same pattern > for accessor methods. Regarding the suggestion of placing the caret in > the throws clause for the corresponding error message, not possible. > We would have to move the check for that error to the parser. > > New in this iteration: > - I have included jdeps related code, I was thinking about putting it > in a separate review bucket but, it is small, it kind of fits with the > rest of the review > - a series of supporting libraries for tests under: > test/langtools/lib/combo/tools/javac/combo with also the tests that > needed to be modified due to changes in the lib. These changes were > created by Brian > - a minor change done at ToolBox.java > > Thanks for all the feedback, > Vicente > > > [1] > http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.03/ From alex.buckley at oracle.com Mon Nov 4 19:09:03 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 4 Nov 2019 11:09:03 -0800 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: <87bltu1sv7.fsf@mid.deneb.enyo.de> References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> <87bltu1sv7.fsf@mid.deneb.enyo.de> Message-ID: <2455a8ef-e357-79fc-3a7d-92ec91f88fa2@oracle.com> Florian, Thanks for drawing attention to this part of the spec: On 11/2/2019 3:21 AM, Florian Weimer wrote: > Is it allowed to declare a canonical constructor explicitly and make > it non-public? I think the naswer is no. But it's not quite obvious > from the spec, I think. JLS 8.10.4 defines a "canonical" ctor to be a public ctor whose formal parameter list is identical to the record header. If you explicitly declare a ctor whose formal parameter list is identical to the record header, but you do not make it public, then you have not declared a "canonical" ctor. You have declared a ctor that, by virtue of its signature, prevents an implicitly declared canonical ctor from being declared. This is so unfortunate that it deserves an error message, and you will get one. However, you are right that the spec is slightly misworded. It says "It is a compile-time error if a record declaration contains a canonical constructor declaration that is not public." but a "canonical" ctor is public by definition. It should say "It is a compile-time error if a record declaration contains a constructor declaration whose formal parameter list is identical to the record header of R, but which is not public." An alternative approach: JLS 8.10.4 could define a "canonical" ctor as follows: "Every record type R has a _canonical_ constructor, which is a constructor [note the silence on accessibility] whose formal parameter list is identical to the record header of R." ... and deem an implicitly declared canonical ctor to be public. Then, the compile-time error can be left alone, though I would reword it for clarity and for tonal agreement with '[exp|imp]licitly declared': "If a canonical constructor is explicitly declared, then it must be public, or a compile-time error occurs." The alternative approach is best because the sense of "canonical" is dominated by the signature -- just look at javac's error message "canonical record constructor must be public" which assumes that canonical-ness is obvious (signature-driven) and that the access modifier is a separate thing, so to speak. That seems a pretty natural view of things for the JLS to embody. (Sidebar: Why allow a compact ctor declaration to be non-public, when we control its grammar that could be hard-coded to use `public`?) (Sidebar: The compact ctor declaration should be introduced at the same time as "A canonical constructor can be explicitly declared ...". I recall privately discussing the flow of this section but can't find it easily. I suggest that 8.10.4 should be "Canonical Constructor of a Record" and that the sole non-canonical clause "A record declaration may contain constructor declarations." should live in 8.10.2 "Record Body" (not plural; yes, the title of 8.9.2 should drop the D-word too, which will happen auto-magically) ... 8.10.2 already says "may contain constructor and member declarations" but that opening paragraph should advertise the compact ctor's role in helping to initialize the member [because otherwise CompactConstructorDeclaration goes unexplained] ... the line will be hard to write and this mail is already long enough.) Alex From mrjarviscraft at gmail.com Mon Nov 4 19:15:17 2019 From: mrjarviscraft at gmail.com (Japris Pogrammer) Date: Mon, 4 Nov 2019 22:15:17 +0300 Subject: indy-based string-switch proposal Message-ID: Hi there!. I am here with the proposal (and a working implementation prototype [1]) of a invokedynamic-based string-switch which, while not breaking any backwards-compatibility and not requiring any cascade changes, allows improved behaviour for this JLS feature. Idea: Replace the lookupswitch instruction part (and all the following instructions corresponding to its labels) generated by javac for a String-switch (keeping the tableswitch part) with a single invokedynamic instruction using the new SwitchTableFactory. Patch contents: - SwitchTableFactory.java : home for bootstrap-methods replacing the old lookupswitch behaviour - SwitchTableFactoryException.java : exception thrown by bootstrap-methods of SwitchTableFactory - BaseTest.java : simple behavioral test of bootstrap-methods invoking them via invokestatic and testing results produced by MethodHandles of returned CallSites Reasoning: 1) Current approach (used by javac) is generating a complicated structure (whose number of opcodes grows ~linearly on number of branches). Yet this structure is not usually optimized (at current implementation even 1-branch corner-case is not treated specially [2]). Even if these optimizations were performed at compile-time they could have become useless (or even causing performance problems) in future versions which is against backwards-compatibility principle. Also, switches compiled for older versions whould not use newer features which could have allowed better performance. 2) As of current spec, String hash-code is one of the only hard-coded algorithms. This is mostly due to backwards-compatibility principle and was decided to not be changed (TL;DR and this proposal is not trying to do it). However, using indy-based approach would make the compiler independent from it thus allowing removal of String hash-code algorithm in the future. 3) Producing simpler bytecode would allow external tools analyzing it discover string-switches easier (this may also be said about JIT). 4) Current algorithm cannot rely on String implementation details which are not defined at compile-time (such as String's internal fields). Invokedynamic details: Two bootstrap methods are provided in order to allow big switches (C-style arguments layout is due to inability to pass complicated arguments (such as typed arrays) into the bootstap method): 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, MethodType, Object[]) whose bootstrap arguments are the following: , , [, , []*]* 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, MethodType, Object[]) whose bootstrap arguments are the following: , , []* Page is a String of the following pattern: [\0\0[\0]*]* As you can see, it allows for multiple branches (each containing multiple labels) to be described under one page. This is done in order to support big switches which cannot fit into the first method variant. Example: As an example of what could be done by the compiler using this feature, consider the following switch expression: switch (string) { case "foo": case "bar": case "baz": case "qux": default: } Generate bytecode would look like: invokedynamic java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, 0, 1, "foo", 1, 1, "bar", 2, 1, "baz", "qux" } or (this should happen for big switches) invokedynamic java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, 1, "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" } (while the argument looks complicates it is (A) shoter (as each '\000' is actually one char) and (B) linear (meaning it is easy to parse)) Implementation details: Current implementation is based on ASM-generation. Under the hood it generates a class ) with a static String (int) method (passed to ConstantCallSite) performing hash-code() switch + equals(Object) (as currently done by javac) handling 0- and 1-branch cases specially (by using a MethodHandle of a method returning a bound value (default branch ID) and by generating an equals(Object) check respectively). The class is anonymously defined via Unsafe as done by other JDK bootstrap methods. Features to be done (this were not done yet as I am not aware yet if this feature will get positive feedback): 1) Add the class and its indy-details into other classes to have it treated specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. 2) FIll the documentation of the SwitchTableFactory. 3) Use SwitchTableFactory in javac (probably, as a preview feature) and test its behaviour. Possible improvements: 1) Bootstrap's generator may use its own hash-code algorithm (based on direct access to String's content using special Lookup or Unsafe) which would be more efficient than String#hashCode(). 2) Bootstrap's generator may depend on other String's properties, such as compact-mode, length etc. 2) Bootstrap's generator may use switchtable in case of hash-codes being close (yet it seems to be too rare to handle). Subjects to discuss: 1. Should the bootstrap method validate its arguments in order to report irrational arguments (such as usage of duplicate String labels)? 2. Is the current Boostrap-arguments layout fine or should be remade? 3. Which optimizations should be added (and/or toggled by default) to the generator? 4. Should branch IDs be specified explicitly or not (using -1 for default and 0 + i for other branches)? 5. Should there be a way to pass MethodHandles to bootstrap methods to be invoked instead of branch IDs being returned if a switch returns nothing (and should there be a way to do it for stack-affecting switches?)? Possible extensions: 1. As the name of the class suggests, it is a general switch-table factory and it may be used in future for other types of switches. At least, enum-switch *may* be done using it, but (in order to keep it one-switch based) it would be much better to have it implemented via condy producing int-array for ordinals (this would remove the need for extra synthetic class currently being generated). 2. Moreover, this approach may be used for boosted implementations of pattern-matching magic (using the same approach as for the strings) with the exception of the need to pass more complicated structures into the bootstrap method (using condy or references to producing methods or more complicated patterns). 3. In addition to #2, a universal approach may be introduced to allow faster switch by all types of values (which is primary useful for pattern matching) such as passing pairs of int(T) and boolean(T) MethodHandles performing hash-code computation and equality check respectively. I am ready to continue developing this feature (being ready to sign Oracle Contributor Agreement) which includes: - documentation - improvements to the current methods - addition of the class to other - benchmarks and testing - optimization - compiler support for this switch-approach - other features described above, such as a universal switch bootstrap method (Possible extensions, #3) Notes: This might have been discussed in the past (at least indy-based switches in general), if there was a reason for this to not be implemented, please refer me to it. I would be happy to work on this proposal to make this feature (and other ones mentioned) part of OpenJDK. Thanks for your interest and support, Peter Links: [1] https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f Patch (dynamic mirror of the file appended) [2] https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 Current javac String implementation root [3] https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java One of the cases where JDK's Bootstrap-methods are handled specially From alex.buckley at oracle.com Mon Nov 4 19:26:23 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 4 Nov 2019 11:26:23 -0800 Subject: RFR: CSR for Compiler implementation for records In-Reply-To: References: Message-ID: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> Usually, I want a CSR's Solution to break down the new language feature -- for example, see the original CSR for switch expressions JDK-8207241, where the Solution sketches the actual changes, not just "allow switch as an expression kthxbai". However, in the case of record classes, the Solution is legitimately self-contained -- support record classes! -- so no need for a break-down. That said, the phrase "for a fixed set of values" is confusing because it suggests enum-like behavior (the same phrase in the Summary is not confusing because it has a qualifier). Also "Add records classes". Alex On 11/3/2019 9:13 AM, Vicente Romero wrote: > Hi, > > Please review the draft of the CSR for Compiler implementation for > records at [1] > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8233433 From mark.reinhold at oracle.com Mon Nov 4 19:49:27 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 4 Nov 2019 11:49:27 -0800 (PST) Subject: New candidate JEP: 368: Text Blocks (Second Preview) Message-ID: <20191104194927.B3E5330CD01@eggemoggin.niobe.net> https://openjdk.java.net/jeps/368 - Mark From brian.goetz at oracle.com Mon Nov 4 20:24:54 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 4 Nov 2019 21:24:54 +0100 Subject: indy-based string-switch proposal In-Reply-To: References: Message-ID: Indeed, such a translation improvement is on the roadmap ? in fact we want to might all switches other than those over ints to use Indy-based classification. When we extend switch to support patterns, it will force us to revamp switch translation, and this sort of stuff is better done in library code than in generated bytecode. There is a prototype of the bootstraps for string, long, and others, with some test cases, checked into an amber branch ? let me dig this up. As you discovered, there is an Indy pothole regarding long arg lists, but is slated to be fixed (or may already have been). This is a good direction - and something for which we?d be glad for the help (as you?ll see, my initial patch has been moldering for a while). Sent from my iPad > On Nov 4, 2019, at 8:15 PM, Japris Pogrammer wrote: > > Hi there!. > > I am here with the proposal (and a working implementation prototype [1]) of > a invokedynamic-based string-switch which, while not breaking any > backwards-compatibility and not requiring any cascade changes, allows > improved behaviour for this JLS feature. > > Idea: > Replace the lookupswitch instruction part (and all the following > instructions corresponding to its labels) generated by javac for a > String-switch (keeping the tableswitch part) with a single invokedynamic > instruction using the new SwitchTableFactory. > Patch contents: > - SwitchTableFactory.java : home for bootstrap-methods replacing the old > lookupswitch behaviour > - SwitchTableFactoryException.java : exception thrown by bootstrap-methods > of SwitchTableFactory > - BaseTest.java : simple behavioral test of bootstrap-methods invoking them > via invokestatic and testing results produced by MethodHandles of returned > CallSites > > Reasoning: > 1) Current approach (used by javac) is generating a complicated > structure (whose number of opcodes grows ~linearly on number of branches). > Yet this structure is not usually optimized (at current implementation even > 1-branch corner-case is not treated specially [2]). Even if these > optimizations were performed at compile-time they could have become useless > (or even causing performance problems) in future versions which is against > backwards-compatibility principle. Also, switches compiled for older > versions whould not use newer features which could have allowed better > performance. > 2) As of current spec, String hash-code is one of the only hard-coded > algorithms. This is mostly due to backwards-compatibility principle and was > decided to not be changed (TL;DR and this proposal is not trying to do it). > However, using indy-based approach would make the compiler independent from > it thus allowing removal of String hash-code algorithm in the future. > 3) Producing simpler bytecode would allow external tools analyzing it > discover string-switches easier (this may also be said about JIT). > 4) Current algorithm cannot rely on String implementation details which are > not defined at compile-time (such as String's internal fields). > > Invokedynamic details: > Two bootstrap methods are provided in order to allow big switches (C-style > arguments layout is due to inability to pass complicated arguments (such as > typed arrays) into the bootstap method): > 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, MethodType, > Object[]) whose bootstrap arguments are the following: > , , [, String labels corresponsing to the branch>, [ to the branch>]*]* > 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, > MethodType, Object[]) whose bootstrap arguments are the following: > , , > []* > Page is a String of the following pattern: > [\0 branch>\0[\0 corresponsing to the branch>]*]* > As you can see, it allows for multiple branches (each containing multiple > labels) to be described under one page. This is done in order to support > big switches which cannot fit into the first method variant. > > Example: > As an example of what could be done by the compiler using this feature, > consider the following switch expression: > > switch (string) { > case "foo": > case "bar": > case "baz": case "qux": > default: > } > > Generate bytecode would look like: > > invokedynamic > java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, > 0, 1, "foo", > 1, 1, "bar", > 2, 1, "baz", "qux" > } > > > or (this should happen for big switches) > > invokedynamic > java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, 1, > "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" > } > > > (while the argument looks complicates it is (A) shoter (as each '\000' is > actually one char) and (B) linear (meaning it is easy to parse)) > > Implementation details: > Current implementation is based on ASM-generation. Under the hood it > generates a class ) with a static String (int) method (passed to > ConstantCallSite) performing hash-code() switch + equals(Object) (as > currently done by javac) handling 0- and 1-branch cases specially (by using > a MethodHandle of a method returning a bound value (default branch ID) and > by generating an equals(Object) check respectively). The class is > anonymously defined via Unsafe as done by other JDK bootstrap methods. > > Features to be done (this were not done yet as I am not aware yet if this > feature will get positive feedback): > 1) Add the class and its indy-details into other classes to have it treated > specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. > 2) FIll the documentation of the SwitchTableFactory. > 3) Use SwitchTableFactory in javac (probably, as a preview feature) and > test its behaviour. > > Possible improvements: > 1) Bootstrap's generator may use its own hash-code algorithm (based on > direct access to String's content using special Lookup or Unsafe) which > would be more efficient than String#hashCode(). > 2) Bootstrap's generator may depend on other String's properties, such as > compact-mode, length etc. > 2) Bootstrap's generator may use switchtable in case of hash-codes being > close (yet it seems to be too rare to handle). > > Subjects to discuss: > 1. Should the bootstrap method validate its arguments in order to report > irrational arguments (such as usage of duplicate String labels)? > 2. Is the current Boostrap-arguments layout fine or should be remade? > 3. Which optimizations should be added (and/or toggled by default) to the > generator? > 4. Should branch IDs be specified explicitly or not (using -1 for default > and 0 + i for other branches)? > 5. Should there be a way to pass MethodHandles to bootstrap methods to be > invoked instead of branch IDs being returned if a switch returns nothing > (and should there be a way to do it for stack-affecting switches?)? > > Possible extensions: > 1. As the name of the class suggests, it is a general switch-table factory > and it may be used in future for other types of switches. At least, > enum-switch *may* be done using it, but (in order to keep it one-switch > based) it would be much better to have it implemented via condy producing > int-array for ordinals (this would remove the need for extra synthetic > class currently being generated). > 2. Moreover, this approach may be used for boosted implementations of > pattern-matching magic (using the same approach as for the strings) with > the exception of the need to pass more complicated structures into the > bootstrap method (using condy or references to producing methods or more > complicated patterns). > 3. In addition to #2, a universal approach may be introduced to allow > faster switch by all types of values (which is primary useful for pattern > matching) such as passing pairs of int(T) and boolean(T) MethodHandles > performing hash-code computation and equality check respectively. > > I am ready to continue developing this feature (being ready to sign Oracle > Contributor Agreement) which includes: > - documentation > - improvements to the current methods > - addition of the class to other > - benchmarks and testing > - optimization > - compiler support for this switch-approach > - other features described above, such as a universal switch bootstrap > method (Possible extensions, #3) > > Notes: > This might have been discussed in the past (at least indy-based switches in > general), if there was a reason for this to not be implemented, please > refer me to it. I would be happy to work on this proposal to make this > feature (and other ones mentioned) part of OpenJDK. > > Thanks for your interest and support, > Peter > > Links: > [1] https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f Patch > (dynamic mirror of the file appended) > [2] > https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 > Current > javac String implementation root > [3] > https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java > One > of the cases where JDK's Bootstrap-methods are handled specially From brian.goetz at oracle.com Mon Nov 4 20:31:50 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 4 Nov 2019 21:31:50 +0100 Subject: indy-based string-switch proposal In-Reply-To: References: Message-ID: Here?s is the change set that added these files, in branch pattern-runtime. http://hg.openjdk.java.net/amber/amber/rev/755f726a61a7 There may be later changesets but this should get you to where we left it off. Sent from my iPad > On Nov 4, 2019, at 9:24 PM, Brian Goetz wrote: > > Indeed, such a translation improvement is on the roadmap ? in fact we want to might all switches other than those over ints to use Indy-based classification. When we extend switch to support patterns, it will force us to revamp switch translation, and this sort of stuff is better done in library code than in generated bytecode. > > There is a prototype of the bootstraps for string, long, and others, with some test cases, checked into an amber branch ? let me dig this up. > > As you discovered, there is an Indy pothole regarding long arg lists, but is slated to be fixed (or may already have been). > > This is a good direction - and something for which we?d be glad for the help (as you?ll see, my initial patch has been moldering for a while). > > Sent from my iPad > >> On Nov 4, 2019, at 8:15 PM, Japris Pogrammer wrote: >> >> Hi there!. >> >> I am here with the proposal (and a working implementation prototype [1]) of >> a invokedynamic-based string-switch which, while not breaking any >> backwards-compatibility and not requiring any cascade changes, allows >> improved behaviour for this JLS feature. >> >> Idea: >> Replace the lookupswitch instruction part (and all the following >> instructions corresponding to its labels) generated by javac for a >> String-switch (keeping the tableswitch part) with a single invokedynamic >> instruction using the new SwitchTableFactory. >> Patch contents: >> - SwitchTableFactory.java : home for bootstrap-methods replacing the old >> lookupswitch behaviour >> - SwitchTableFactoryException.java : exception thrown by bootstrap-methods >> of SwitchTableFactory >> - BaseTest.java : simple behavioral test of bootstrap-methods invoking them >> via invokestatic and testing results produced by MethodHandles of returned >> CallSites >> >> Reasoning: >> 1) Current approach (used by javac) is generating a complicated >> structure (whose number of opcodes grows ~linearly on number of branches). >> Yet this structure is not usually optimized (at current implementation even >> 1-branch corner-case is not treated specially [2]). Even if these >> optimizations were performed at compile-time they could have become useless >> (or even causing performance problems) in future versions which is against >> backwards-compatibility principle. Also, switches compiled for older >> versions whould not use newer features which could have allowed better >> performance. >> 2) As of current spec, String hash-code is one of the only hard-coded >> algorithms. This is mostly due to backwards-compatibility principle and was >> decided to not be changed (TL;DR and this proposal is not trying to do it). >> However, using indy-based approach would make the compiler independent from >> it thus allowing removal of String hash-code algorithm in the future. >> 3) Producing simpler bytecode would allow external tools analyzing it >> discover string-switches easier (this may also be said about JIT). >> 4) Current algorithm cannot rely on String implementation details which are >> not defined at compile-time (such as String's internal fields). >> >> Invokedynamic details: >> Two bootstrap methods are provided in order to allow big switches (C-style >> arguments layout is due to inability to pass complicated arguments (such as >> typed arrays) into the bootstap method): >> 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, MethodType, >> Object[]) whose bootstrap arguments are the following: >> , , [, > String labels corresponsing to the branch>, [> to the branch>]*]* >> 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, >> MethodType, Object[]) whose bootstrap arguments are the following: >> , , >> []* >> Page is a String of the following pattern: >> [\0> branch>\0[\0> corresponsing to the branch>]*]* >> As you can see, it allows for multiple branches (each containing multiple >> labels) to be described under one page. This is done in order to support >> big switches which cannot fit into the first method variant. >> >> Example: >> As an example of what could be done by the compiler using this feature, >> consider the following switch expression: >> >> switch (string) { >> case "foo": >> case "bar": >> case "baz": case "qux": >> default: >> } >> >> Generate bytecode would look like: >> >> invokedynamic >> java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, >> 0, 1, "foo", >> 1, 1, "bar", >> 2, 1, "baz", "qux" >> } >> >> >> or (this should happen for big switches) >> >> invokedynamic >> java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, 1, >> "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" >> } >> >> >> (while the argument looks complicates it is (A) shoter (as each '\000' is >> actually one char) and (B) linear (meaning it is easy to parse)) >> >> Implementation details: >> Current implementation is based on ASM-generation. Under the hood it >> generates a class ) with a static String (int) method (passed to >> ConstantCallSite) performing hash-code() switch + equals(Object) (as >> currently done by javac) handling 0- and 1-branch cases specially (by using >> a MethodHandle of a method returning a bound value (default branch ID) and >> by generating an equals(Object) check respectively). The class is >> anonymously defined via Unsafe as done by other JDK bootstrap methods. >> >> Features to be done (this were not done yet as I am not aware yet if this >> feature will get positive feedback): >> 1) Add the class and its indy-details into other classes to have it treated >> specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. >> 2) FIll the documentation of the SwitchTableFactory. >> 3) Use SwitchTableFactory in javac (probably, as a preview feature) and >> test its behaviour. >> >> Possible improvements: >> 1) Bootstrap's generator may use its own hash-code algorithm (based on >> direct access to String's content using special Lookup or Unsafe) which >> would be more efficient than String#hashCode(). >> 2) Bootstrap's generator may depend on other String's properties, such as >> compact-mode, length etc. >> 2) Bootstrap's generator may use switchtable in case of hash-codes being >> close (yet it seems to be too rare to handle). >> >> Subjects to discuss: >> 1. Should the bootstrap method validate its arguments in order to report >> irrational arguments (such as usage of duplicate String labels)? >> 2. Is the current Boostrap-arguments layout fine or should be remade? >> 3. Which optimizations should be added (and/or toggled by default) to the >> generator? >> 4. Should branch IDs be specified explicitly or not (using -1 for default >> and 0 + i for other branches)? >> 5. Should there be a way to pass MethodHandles to bootstrap methods to be >> invoked instead of branch IDs being returned if a switch returns nothing >> (and should there be a way to do it for stack-affecting switches?)? >> >> Possible extensions: >> 1. As the name of the class suggests, it is a general switch-table factory >> and it may be used in future for other types of switches. At least, >> enum-switch *may* be done using it, but (in order to keep it one-switch >> based) it would be much better to have it implemented via condy producing >> int-array for ordinals (this would remove the need for extra synthetic >> class currently being generated). >> 2. Moreover, this approach may be used for boosted implementations of >> pattern-matching magic (using the same approach as for the strings) with >> the exception of the need to pass more complicated structures into the >> bootstrap method (using condy or references to producing methods or more >> complicated patterns). >> 3. In addition to #2, a universal approach may be introduced to allow >> faster switch by all types of values (which is primary useful for pattern >> matching) such as passing pairs of int(T) and boolean(T) MethodHandles >> performing hash-code computation and equality check respectively. >> >> I am ready to continue developing this feature (being ready to sign Oracle >> Contributor Agreement) which includes: >> - documentation >> - improvements to the current methods >> - addition of the class to other >> - benchmarks and testing >> - optimization >> - compiler support for this switch-approach >> - other features described above, such as a universal switch bootstrap >> method (Possible extensions, #3) >> >> Notes: >> This might have been discussed in the past (at least indy-based switches in >> general), if there was a reason for this to not be implemented, please >> refer me to it. I would be happy to work on this proposal to make this >> feature (and other ones mentioned) part of OpenJDK. >> >> Thanks for your interest and support, >> Peter >> >> Links: >> [1] https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f Patch >> (dynamic mirror of the file appended) >> [2] >> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 >> Current >> javac String implementation root >> [3] >> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java >> One >> of the cases where JDK's Bootstrap-methods are handled specially > From fw at deneb.enyo.de Mon Nov 4 20:50:09 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Nov 2019 21:50:09 +0100 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: <2455a8ef-e357-79fc-3a7d-92ec91f88fa2@oracle.com> (Alex Buckley's message of "Mon, 4 Nov 2019 11:09:03 -0800") References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> <87bltu1sv7.fsf@mid.deneb.enyo.de> <2455a8ef-e357-79fc-3a7d-92ec91f88fa2@oracle.com> Message-ID: <87wocfgyda.fsf@mid.deneb.enyo.de> * Alex Buckley: > However, you are right that the spec is slightly misworded. It says "It > is a compile-time error if a record declaration contains a canonical > constructor declaration that is not public." but a "canonical" ctor is > public by definition. It should say "It is a compile-time error if a > record declaration contains a constructor declaration whose formal > parameter list is identical to the record header of R, but which is not > public." I think we are looking at different versions of the spec. I don't see either wording here: But the updated wording works for me. Also thanks to Brian for explaining the rationale to me. I agree that the current behavior is consistent with the kind of restrictions imposed (or not) by the rest of the language. The need for defensive copies is particularly persuasive. From vicente.romero at oracle.com Mon Nov 4 20:53:09 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 4 Nov 2019 15:53:09 -0500 Subject: RFR: CSR for Compiler implementation for records In-Reply-To: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> References: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> Message-ID: <43c69224-ff98-afff-df58-c2b416545d60@oracle.com> Hi Alex, Thanks for your comments, I have modified the CSR, does it look better now? Thanks, Vicente On 11/4/19 2:26 PM, Alex Buckley wrote: > Usually, I want a CSR's Solution to break down the new language > feature -- for example, see the original CSR for switch expressions > JDK-8207241, where the Solution sketches the actual changes, not just > "allow switch as an expression kthxbai". However, in the case of > record classes, the Solution is legitimately self-contained -- support > record classes! -- so no need for a break-down. That said, the phrase > "for a fixed set of values" is confusing because it suggests enum-like > behavior (the same phrase in the Summary is not confusing because it > has a qualifier). Also "Add records classes". > > Alex > > On 11/3/2019 9:13 AM, Vicente Romero wrote: >> Hi, >> >> Please review the draft of the CSR for Compiler implementation for >> records at [1] >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8233433 From vicente.romero at oracle.com Mon Nov 4 20:54:59 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 4 Nov 2019 15:54:59 -0500 Subject: RFR: CSR Core-libs support for records Message-ID: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com> Hi, Please review the draft of the CSR for Core-libs support for records at [1] Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8233436 From fw at deneb.enyo.de Mon Nov 4 21:27:57 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Nov 2019 22:27:57 +0100 Subject: RFR: CSR Core-libs support for records In-Reply-To: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com> (Vicente Romero's message of "Mon, 4 Nov 2019 15:54:59 -0500") References: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com> Message-ID: <878sovgwma.fsf@mid.deneb.enyo.de> * Vicente Romero: > Please review the draft of the CSR for Core-libs support for records at [1] > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8233436 I would have expected something regarding serialization in the description of java.lang.Record. Right now, it appears to be possible to have a record implement java.io.Serializable, and serialization will appear to work, but because the names of the implicitly generated private fields are not specified, it is not portable across compilers and even compiler versions. From alex.buckley at oracle.com Mon Nov 4 21:54:16 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 4 Nov 2019 13:54:16 -0800 Subject: Updated Draft specs for JEP 359 (Records) In-Reply-To: <87wocfgyda.fsf@mid.deneb.enyo.de> References: <146C0891-97B3-4DBD-AA10-CCD485357BA2@oracle.com> <87bltu1sv7.fsf@mid.deneb.enyo.de> <2455a8ef-e357-79fc-3a7d-92ec91f88fa2@oracle.com> <87wocfgyda.fsf@mid.deneb.enyo.de> Message-ID: <85d2ca19-8c22-e494-0552-1d34f624d539@oracle.com> On 11/4/2019 12:50 PM, Florian Weimer wrote: > I think we are looking at different versions of the spec. I don't see > either wording here: > > > > But the updated wording works for me. Doh, you're right, and the updated spec already reflects some of the re-structuring I talked about in mail. However, the thrust of my comments about detaching 'public' and 'throws' from the definition of "canonical" still apply. The 2019-10-31 spec says "If the canonical constructor is not explicitly declared, then it is implicitly declared." but it is not possible to implicitly declare `public R(int i)` if the pretender `R(int i)` has been explicitly declared in `record R(int i)`. Yes, there is an error mandated for the pretender -- "The erasure of the signature of the constructor must not be equal to the erasure of the signature of the canonical constructor." -- but (1) A compiler vendor now has an impossible thing mandated on the one hand and a must-not-be-equal error mandated on the other hand, so which should be reported first? and (2) While it's appropriate to mention erasure when contrasting List and List (e.g. the javac test case), it's confusing to mention erasure when dealing with int and int. The JLS should be more explicit about how mis-declared modifiers and 'throws' are handled. Alex From alex.buckley at oracle.com Mon Nov 4 21:59:46 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 4 Nov 2019 13:59:46 -0800 Subject: RFR: CSR for Compiler implementation for records In-Reply-To: <43c69224-ff98-afff-df58-c2b416545d60@oracle.com> References: <1c3a6e90-a7fb-97aa-828a-93929d88b442@oracle.com> <43c69224-ff98-afff-df58-c2b416545d60@oracle.com> Message-ID: I edited "Add records classes" to say "Add record classes". I also turned a "very low" into just a "low" in the Compatibility Risk Description; more could be written about which aspects of records are most likely to change due to feedback, but there are diminishing returns from spending on this CSR. Added myself as a reviewer. Alex On 11/4/2019 12:53 PM, Vicente Romero wrote: > Hi Alex, > > Thanks for your comments, I have modified the CSR, does it look better now? > > Thanks, > Vicente > > On 11/4/19 2:26 PM, Alex Buckley wrote: >> Usually, I want a CSR's Solution to break down the new language >> feature -- for example, see the original CSR for switch expressions >> JDK-8207241, where the Solution sketches the actual changes, not just >> "allow switch as an expression kthxbai". However, in the case of >> record classes, the Solution is legitimately self-contained -- support >> record classes! -- so no need for a break-down. That said, the phrase >> "for a fixed set of values" is confusing because it suggests enum-like >> behavior (the same phrase in the Summary is not confusing because it >> has a qualifier). Also "Add records classes". >> >> Alex >> >> On 11/3/2019 9:13 AM, Vicente Romero wrote: >>> Hi, >>> >>> Please review the draft of the CSR for Compiler implementation for >>> records at [1] >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8233433 > From paul.sandoz at oracle.com Mon Nov 4 22:27:00 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 4 Nov 2019 14:27:00 -0800 Subject: indy-based string-switch proposal In-Reply-To: References: Message-ID: > On Nov 4, 2019, at 12:24 PM, Brian Goetz wrote: > > Indeed, such a translation improvement is on the roadmap ? in fact we want to might all switches other than those over ints to use Indy-based classification. When we extend switch to support patterns, it will force us to revamp switch translation, and this sort of stuff is better done in library code than in generated bytecode. > > There is a prototype of the bootstraps for string, long, and others, with some test cases, checked into an amber branch ? let me dig this up. > > As you discovered, there is an Indy pothole regarding long arg lists, but is slated to be fixed (or may already have been). > If you are referring to the 255 BSM method arg limit, that was lifted when constant dynamic was integrated. BSMs are invoked as if by a call to invokeWithArguments. Still, bundling the trailing BSM args in Object[] feels a little unsatisfying. We a marginal increase in encoding complexity we could represent as a repeating structure using candy. Paul. > This is a good direction - and something for which we?d be glad for the help (as you?ll see, my initial patch has been moldering for a while). > > Sent from my iPad From john.r.rose at oracle.com Mon Nov 4 23:09:12 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 4 Nov 2019 15:09:12 -0800 Subject: indy-based string-switch proposal In-Reply-To: References: Message-ID: On Nov 4, 2019, at 2:27 PM, Paul Sandoz wrote: > > repeating structure using candy Such as an apartment building canvassed by trick-or-treaters? (Boo, spell-check!) Condy can be good for factoring out repeats. But watch the per-condy overhead. Sometimes there?s a good answer from cooking up a simple stringy DSL as with the string concatenation work. When I evaluate alternative encoding schemes I usually ask what is the expected number of constant pool indexes burned, for an average use case. Sometimes class file size (in bytes) comes into it also, but CP slots are a uniquely limited resource, since the whole class file has to make do with 2^16-1 of them. The important goal, IMO, is to make each constant in an indy/condy construct carry its weight, or else somehow maintain an expectation that the constant is probably already in use somewhere else in the class file. ? John P.S. There are incremental ways to lift the 2^16-1 restriction, if we ever need to go there. See notes on CONSTANT_Group in https://bugs.openjdk.java.net/browse/JDK-8161256 From augustnagro at gmail.com Mon Nov 4 23:18:37 2019 From: augustnagro at gmail.com (August Nagro) Date: Mon, 4 Nov 2019 17:18:37 -0600 Subject: Switch Statement Fall-Through Message-ID: <089675F2-EF49-40B8-8B3A-ED70848BC7BB@gmail.com> Hi! I recently read Stephen Colebourne?s blog on the new switch syntax (https://blog.joda.org/2019/11/java-switch-4-wrongs-dont-make-right.html), and although I don?t agree with the proposed solution, his issue with the new switch falling-through is spot-on. I've personally used fall-through switch statements, but I think they should only ever be applicable to the old-style switch. Having the compiler enforce this will prevent a lot of misuse and confusion. Instead of four types of switch, there is only two: 1. switch with only ->, that doesn't fall-through, checks exhaustiveness, has yield, commas between cases, and can be used as an expression. 2. switch with only :, the standard switch. Sincerely, August Nagro From joe.darcy at oracle.com Mon Nov 4 23:22:22 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 4 Nov 2019 15:22:22 -0800 Subject: RFR: CSR Core-libs support for records In-Reply-To: <878sovgwma.fsf@mid.deneb.enyo.de> References: <4228cc74-7c04-5001-1998-3f7012e02775@oracle.com> <878sovgwma.fsf@mid.deneb.enyo.de> Message-ID: <2436079e-7047-675d-5eb1-e0723d3f94a9@oracle.com> Hello, On 11/4/2019 1:27 PM, Florian Weimer wrote: > * Vicente Romero: > >> Please review the draft of the CSR for Core-libs support for records at [1] >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8233436 > I would have expected something regarding serialization in the > description of java.lang.Record. > > Right now, it appears to be possible to have a record implement > java.io.Serializable, and serialization will appear to work, but > because the names of the implicitly generated private fields are not > specified, it is not portable across compilers and even compiler > versions. There is a separate serialization spec update for records that has been discussed on the amber lists. It isn't unreasonable for java.lang.Record to make some mention of the special treatment by serialization. (As a point of reference, java.lang.Enum does *not* reference the special handling of enums of serialization.) I think a reference to the serialization spec in java.lang.Record would suffice. Cheers, -Joe From forax at univ-mlv.fr Mon Nov 4 23:39:38 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 5 Nov 2019 00:39:38 +0100 (CET) Subject: indy-based string-switch proposal In-Reply-To: References: Message-ID: <1812165693.631000.1572910778030.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "JARvis PROgrammer" > Cc: "amber-dev" > Envoy?: Lundi 4 Novembre 2019 21:24:54 > Objet: Re: indy-based string-switch proposal > Indeed, such a translation improvement is on the roadmap ? in fact we want to > might all switches other than those over ints to use Indy-based classification. > When we extend switch to support patterns, it will force us to revamp switch > translation, and this sort of stuff is better done in library code than in > generated bytecode. We will still need one or two method handle combinators to emulate the table switch and the lookup switch. So the generated code should not use directly but indirectly those new combinators may generate bytecodes. > > There is a prototype of the bootstraps for string, long, and others, with some > test cases, checked into an amber branch ? let me dig this up. > > As you discovered, there is an Indy pothole regarding long arg lists, but is > slated to be fixed (or may already have been). > > This is a good direction - and something for which we?d be glad for the help (as > you?ll see, my initial patch has been moldering for a while). R?mi > > Sent from my iPad > >> On Nov 4, 2019, at 8:15 PM, Japris Pogrammer wrote: >> >> Hi there!. >> >> I am here with the proposal (and a working implementation prototype [1]) of >> a invokedynamic-based string-switch which, while not breaking any >> backwards-compatibility and not requiring any cascade changes, allows >> improved behaviour for this JLS feature. >> >> Idea: >> Replace the lookupswitch instruction part (and all the following >> instructions corresponding to its labels) generated by javac for a >> String-switch (keeping the tableswitch part) with a single invokedynamic >> instruction using the new SwitchTableFactory. >> Patch contents: >> - SwitchTableFactory.java : home for bootstrap-methods replacing the old >> lookupswitch behaviour >> - SwitchTableFactoryException.java : exception thrown by bootstrap-methods >> of SwitchTableFactory >> - BaseTest.java : simple behavioral test of bootstrap-methods invoking them >> via invokestatic and testing results produced by MethodHandles of returned >> CallSites >> >> Reasoning: >> 1) Current approach (used by javac) is generating a complicated >> structure (whose number of opcodes grows ~linearly on number of branches). >> Yet this structure is not usually optimized (at current implementation even >> 1-branch corner-case is not treated specially [2]). Even if these >> optimizations were performed at compile-time they could have become useless >> (or even causing performance problems) in future versions which is against >> backwards-compatibility principle. Also, switches compiled for older >> versions whould not use newer features which could have allowed better >> performance. >> 2) As of current spec, String hash-code is one of the only hard-coded >> algorithms. This is mostly due to backwards-compatibility principle and was >> decided to not be changed (TL;DR and this proposal is not trying to do it). >> However, using indy-based approach would make the compiler independent from >> it thus allowing removal of String hash-code algorithm in the future. >> 3) Producing simpler bytecode would allow external tools analyzing it >> discover string-switches easier (this may also be said about JIT). >> 4) Current algorithm cannot rely on String implementation details which are >> not defined at compile-time (such as String's internal fields). >> >> Invokedynamic details: >> Two bootstrap methods are provided in order to allow big switches (C-style >> arguments layout is due to inability to pass complicated arguments (such as >> typed arrays) into the bootstap method): >> 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, MethodType, >> Object[]) whose bootstrap arguments are the following: >> , , [, > String labels corresponsing to the branch>, [> to the branch>]*]* >> 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, >> MethodType, Object[]) whose bootstrap arguments are the following: >> , , >> []* >> Page is a String of the following pattern: >> [\0> branch>\0[\0> corresponsing to the branch>]*]* >> As you can see, it allows for multiple branches (each containing multiple >> labels) to be described under one page. This is done in order to support >> big switches which cannot fit into the first method variant. >> >> Example: >> As an example of what could be done by the compiler using this feature, >> consider the following switch expression: >> >> switch (string) { >> case "foo": >> case "bar": >> case "baz": case "qux": >> default: >> } >> >> Generate bytecode would look like: >> >> invokedynamic >> java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, >> 0, 1, "foo", >> 1, 1, "bar", >> 2, 1, "baz", "qux" >> } >> >> >> or (this should happen for big switches) >> >> invokedynamic >> java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, 1, >> "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" >> } >> >> >> (while the argument looks complicates it is (A) shoter (as each '\000' is >> actually one char) and (B) linear (meaning it is easy to parse)) >> >> Implementation details: >> Current implementation is based on ASM-generation. Under the hood it >> generates a class ) with a static String (int) method (passed to >> ConstantCallSite) performing hash-code() switch + equals(Object) (as >> currently done by javac) handling 0- and 1-branch cases specially (by using >> a MethodHandle of a method returning a bound value (default branch ID) and >> by generating an equals(Object) check respectively). The class is >> anonymously defined via Unsafe as done by other JDK bootstrap methods. >> >> Features to be done (this were not done yet as I am not aware yet if this >> feature will get positive feedback): >> 1) Add the class and its indy-details into other classes to have it treated >> specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. >> 2) FIll the documentation of the SwitchTableFactory. >> 3) Use SwitchTableFactory in javac (probably, as a preview feature) and >> test its behaviour. >> >> Possible improvements: >> 1) Bootstrap's generator may use its own hash-code algorithm (based on >> direct access to String's content using special Lookup or Unsafe) which >> would be more efficient than String#hashCode(). >> 2) Bootstrap's generator may depend on other String's properties, such as >> compact-mode, length etc. >> 2) Bootstrap's generator may use switchtable in case of hash-codes being >> close (yet it seems to be too rare to handle). >> >> Subjects to discuss: >> 1. Should the bootstrap method validate its arguments in order to report >> irrational arguments (such as usage of duplicate String labels)? >> 2. Is the current Boostrap-arguments layout fine or should be remade? >> 3. Which optimizations should be added (and/or toggled by default) to the >> generator? >> 4. Should branch IDs be specified explicitly or not (using -1 for default >> and 0 + i for other branches)? >> 5. Should there be a way to pass MethodHandles to bootstrap methods to be >> invoked instead of branch IDs being returned if a switch returns nothing >> (and should there be a way to do it for stack-affecting switches?)? >> >> Possible extensions: >> 1. As the name of the class suggests, it is a general switch-table factory >> and it may be used in future for other types of switches. At least, >> enum-switch *may* be done using it, but (in order to keep it one-switch >> based) it would be much better to have it implemented via condy producing >> int-array for ordinals (this would remove the need for extra synthetic >> class currently being generated). >> 2. Moreover, this approach may be used for boosted implementations of >> pattern-matching magic (using the same approach as for the strings) with >> the exception of the need to pass more complicated structures into the >> bootstrap method (using condy or references to producing methods or more >> complicated patterns). >> 3. In addition to #2, a universal approach may be introduced to allow >> faster switch by all types of values (which is primary useful for pattern >> matching) such as passing pairs of int(T) and boolean(T) MethodHandles >> performing hash-code computation and equality check respectively. >> >> I am ready to continue developing this feature (being ready to sign Oracle >> Contributor Agreement) which includes: >> - documentation >> - improvements to the current methods >> - addition of the class to other >> - benchmarks and testing >> - optimization >> - compiler support for this switch-approach >> - other features described above, such as a universal switch bootstrap >> method (Possible extensions, #3) >> >> Notes: >> This might have been discussed in the past (at least indy-based switches in >> general), if there was a reason for this to not be implemented, please >> refer me to it. I would be happy to work on this proposal to make this >> feature (and other ones mentioned) part of OpenJDK. >> >> Thanks for your interest and support, >> Peter >> >> Links: >> [1] https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f Patch >> (dynamic mirror of the file appended) >> [2] >> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 >> Current >> javac String implementation root >> [3] >> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java >> One > > of the cases where JDK's Bootstrap-methods are handled specially From forax at univ-mlv.fr Mon Nov 4 23:42:53 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 5 Nov 2019 00:42:53 +0100 (CET) Subject: indy-based string-switch proposal In-Reply-To: References: Message-ID: <168413605.631206.1572910973388.JavaMail.zimbra@u-pem.fr> I term of arguments to sent to the boostrap methods, you can only send the strings (concatenated as one big string) with the convention that you will return 0 for the first one, 1 for the next one, etc. R?mi ----- Mail original ----- > De: "JARvis PROgrammer" > ?: "amber-dev" > Envoy?: Lundi 4 Novembre 2019 20:15:17 > Objet: indy-based string-switch proposal > Hi there!. > > I am here with the proposal (and a working implementation prototype [1]) of > a invokedynamic-based string-switch which, while not breaking any > backwards-compatibility and not requiring any cascade changes, allows > improved behaviour for this JLS feature. > > Idea: > Replace the lookupswitch instruction part (and all the following > instructions corresponding to its labels) generated by javac for a > String-switch (keeping the tableswitch part) with a single invokedynamic > instruction using the new SwitchTableFactory. > Patch contents: > - SwitchTableFactory.java : home for bootstrap-methods replacing the old > lookupswitch behaviour > - SwitchTableFactoryException.java : exception thrown by bootstrap-methods > of SwitchTableFactory > - BaseTest.java : simple behavioral test of bootstrap-methods invoking them > via invokestatic and testing results produced by MethodHandles of returned > CallSites > > Reasoning: > 1) Current approach (used by javac) is generating a complicated > structure (whose number of opcodes grows ~linearly on number of branches). > Yet this structure is not usually optimized (at current implementation even > 1-branch corner-case is not treated specially [2]). Even if these > optimizations were performed at compile-time they could have become useless > (or even causing performance problems) in future versions which is against > backwards-compatibility principle. Also, switches compiled for older > versions whould not use newer features which could have allowed better > performance. > 2) As of current spec, String hash-code is one of the only hard-coded > algorithms. This is mostly due to backwards-compatibility principle and was > decided to not be changed (TL;DR and this proposal is not trying to do it). > However, using indy-based approach would make the compiler independent from > it thus allowing removal of String hash-code algorithm in the future. > 3) Producing simpler bytecode would allow external tools analyzing it > discover string-switches easier (this may also be said about JIT). > 4) Current algorithm cannot rely on String implementation details which are > not defined at compile-time (such as String's internal fields). > > Invokedynamic details: > Two bootstrap methods are provided in order to allow big switches (C-style > arguments layout is due to inability to pass complicated arguments (such as > typed arrays) into the bootstap method): > 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, MethodType, > Object[]) whose bootstrap arguments are the following: > , , [, String labels corresponsing to the branch>, [ to the branch>]*]* > 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, > MethodType, Object[]) whose bootstrap arguments are the following: > , , > []* > Page is a String of the following pattern: > [\0 branch>\0[\0 corresponsing to the branch>]*]* > As you can see, it allows for multiple branches (each containing multiple > labels) to be described under one page. This is done in order to support > big switches which cannot fit into the first method variant. > > Example: > As an example of what could be done by the compiler using this feature, > consider the following switch expression: > > switch (string) { > case "foo": > case "bar": > case "baz": case "qux": > default: > } > > Generate bytecode would look like: > > invokedynamic > java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, > 0, 1, "foo", > 1, 1, "bar", > 2, 1, "baz", "qux" > } > > > or (this should happen for big switches) > > invokedynamic > java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, 1, > "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" > } > > > (while the argument looks complicates it is (A) shoter (as each '\000' is > actually one char) and (B) linear (meaning it is easy to parse)) > > Implementation details: > Current implementation is based on ASM-generation. Under the hood it > generates a class ) with a static String (int) method (passed to > ConstantCallSite) performing hash-code() switch + equals(Object) (as > currently done by javac) handling 0- and 1-branch cases specially (by using > a MethodHandle of a method returning a bound value (default branch ID) and > by generating an equals(Object) check respectively). The class is > anonymously defined via Unsafe as done by other JDK bootstrap methods. > > Features to be done (this were not done yet as I am not aware yet if this > feature will get positive feedback): > 1) Add the class and its indy-details into other classes to have it treated > specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. > 2) FIll the documentation of the SwitchTableFactory. > 3) Use SwitchTableFactory in javac (probably, as a preview feature) and > test its behaviour. > > Possible improvements: > 1) Bootstrap's generator may use its own hash-code algorithm (based on > direct access to String's content using special Lookup or Unsafe) which > would be more efficient than String#hashCode(). > 2) Bootstrap's generator may depend on other String's properties, such as > compact-mode, length etc. > 2) Bootstrap's generator may use switchtable in case of hash-codes being > close (yet it seems to be too rare to handle). > > Subjects to discuss: > 1. Should the bootstrap method validate its arguments in order to report > irrational arguments (such as usage of duplicate String labels)? > 2. Is the current Boostrap-arguments layout fine or should be remade? > 3. Which optimizations should be added (and/or toggled by default) to the > generator? > 4. Should branch IDs be specified explicitly or not (using -1 for default > and 0 + i for other branches)? > 5. Should there be a way to pass MethodHandles to bootstrap methods to be > invoked instead of branch IDs being returned if a switch returns nothing > (and should there be a way to do it for stack-affecting switches?)? > > Possible extensions: > 1. As the name of the class suggests, it is a general switch-table factory > and it may be used in future for other types of switches. At least, > enum-switch *may* be done using it, but (in order to keep it one-switch > based) it would be much better to have it implemented via condy producing > int-array for ordinals (this would remove the need for extra synthetic > class currently being generated). > 2. Moreover, this approach may be used for boosted implementations of > pattern-matching magic (using the same approach as for the strings) with > the exception of the need to pass more complicated structures into the > bootstrap method (using condy or references to producing methods or more > complicated patterns). > 3. In addition to #2, a universal approach may be introduced to allow > faster switch by all types of values (which is primary useful for pattern > matching) such as passing pairs of int(T) and boolean(T) MethodHandles > performing hash-code computation and equality check respectively. > > I am ready to continue developing this feature (being ready to sign Oracle > Contributor Agreement) which includes: > - documentation > - improvements to the current methods > - addition of the class to other > - benchmarks and testing > - optimization > - compiler support for this switch-approach > - other features described above, such as a universal switch bootstrap > method (Possible extensions, #3) > > Notes: > This might have been discussed in the past (at least indy-based switches in > general), if there was a reason for this to not be implemented, please > refer me to it. I would be happy to work on this proposal to make this > feature (and other ones mentioned) part of OpenJDK. > > Thanks for your interest and support, > Peter > > Links: > [1] https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f Patch > (dynamic mirror of the file appended) > [2] > https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 > Current > javac String implementation root > [3] > https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java > One > of the cases where JDK's Bootstrap-methods are handled specially From mrjarviscraft at gmail.com Mon Nov 4 23:49:58 2019 From: mrjarviscraft at gmail.com (Japris Pogrammer) Date: Tue, 5 Nov 2019 02:49:58 +0300 Subject: indy-based string-switch proposal In-Reply-To: <168413605.631206.1572910973388.JavaMail.zimbra@u-pem.fr> References: <168413605.631206.1572910973388.JavaMail.zimbra@u-pem.fr> Message-ID: I wonit say that the limitation is so strict. In the patch (from which this topic starts) I've used more complicated String-patterns (aka pages) in order to allow single String bootstrap argument contain description for multiple switch labels. ??, 5 ????. 2019 ?. ? 02:42, Remi Forax : > I term of arguments to sent to the boostrap methods, you can only send the > strings (concatenated as one big string) > with the convention that you will return 0 for the first one, 1 for the > next one, etc. > > R?mi > > ----- Mail original ----- > > De: "JARvis PROgrammer" > > ?: "amber-dev" > > Envoy?: Lundi 4 Novembre 2019 20:15:17 > > Objet: indy-based string-switch proposal > > > Hi there!. > > > > I am here with the proposal (and a working implementation prototype [1]) > of > > a invokedynamic-based string-switch which, while not breaking any > > backwards-compatibility and not requiring any cascade changes, allows > > improved behaviour for this JLS feature. > > > > Idea: > > Replace the lookupswitch instruction part (and all the following > > instructions corresponding to its labels) generated by javac for a > > String-switch (keeping the tableswitch part) with a single invokedynamic > > instruction using the new SwitchTableFactory. > > Patch contents: > > - SwitchTableFactory.java : home for bootstrap-methods replacing the old > > lookupswitch behaviour > > - SwitchTableFactoryException.java : exception thrown by > bootstrap-methods > > of SwitchTableFactory > > - BaseTest.java : simple behavioral test of bootstrap-methods invoking > them > > via invokestatic and testing results produced by MethodHandles of > returned > > CallSites > > > > Reasoning: > > 1) Current approach (used by javac) is generating a complicated > > structure (whose number of opcodes grows ~linearly on number of > branches). > > Yet this structure is not usually optimized (at current implementation > even > > 1-branch corner-case is not treated specially [2]). Even if these > > optimizations were performed at compile-time they could have become > useless > > (or even causing performance problems) in future versions which is > against > > backwards-compatibility principle. Also, switches compiled for older > > versions whould not use newer features which could have allowed better > > performance. > > 2) As of current spec, String hash-code is one of the only hard-coded > > algorithms. This is mostly due to backwards-compatibility principle and > was > > decided to not be changed (TL;DR and this proposal is not trying to do > it). > > However, using indy-based approach would make the compiler independent > from > > it thus allowing removal of String hash-code algorithm in the future. > > 3) Producing simpler bytecode would allow external tools analyzing it > > discover string-switches easier (this may also be said about JIT). > > 4) Current algorithm cannot rely on String implementation details which > are > > not defined at compile-time (such as String's internal fields). > > > > Invokedynamic details: > > Two bootstrap methods are provided in order to allow big switches > (C-style > > arguments layout is due to inability to pass complicated arguments (such > as > > typed arrays) into the bootstap method): > > 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, MethodType, > > Object[]) whose bootstrap arguments are the following: > > , , [, > String labels corresponsing to the branch>, [ > to the branch>]*]* > > 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, > > MethodType, Object[]) whose bootstrap arguments are the following: > > , , > > []* > > Page is a String of the following pattern: > > [\0 > branch>\0[\0 > corresponsing to the branch>]*]* > > As you can see, it allows for multiple branches (each containing multiple > > labels) to be described under one page. This is done in order to support > > big switches which cannot fit into the first method variant. > > > > Example: > > As an example of what could be done by the compiler using this feature, > > consider the following switch expression: > > > > switch (string) { > > case "foo": > > case "bar": > > case "baz": case "qux": > > default: > > } > > > > Generate bytecode would look like: > > > > invokedynamic > > java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, > > 0, 1, "foo", > > 1, 1, "bar", > > 2, 1, "baz", "qux" > > } > > > > > > or (this should happen for big switches) > > > > invokedynamic > > java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, > 1, > > "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" > > } > > > > > > (while the argument looks complicates it is (A) shoter (as each '\000' is > > actually one char) and (B) linear (meaning it is easy to parse)) > > > > Implementation details: > > Current implementation is based on ASM-generation. Under the hood it > > generates a class ) with a static String (int) method (passed to > > ConstantCallSite) performing hash-code() switch + equals(Object) (as > > currently done by javac) handling 0- and 1-branch cases specially (by > using > > a MethodHandle of a method returning a bound value (default branch ID) > and > > by generating an equals(Object) check respectively). The class is > > anonymously defined via Unsafe as done by other JDK bootstrap methods. > > > > Features to be done (this were not done yet as I am not aware yet if this > > feature will get positive feedback): > > 1) Add the class and its indy-details into other classes to have it > treated > > specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. > > 2) FIll the documentation of the SwitchTableFactory. > > 3) Use SwitchTableFactory in javac (probably, as a preview feature) and > > test its behaviour. > > > > Possible improvements: > > 1) Bootstrap's generator may use its own hash-code algorithm (based on > > direct access to String's content using special Lookup or Unsafe) which > > would be more efficient than String#hashCode(). > > 2) Bootstrap's generator may depend on other String's properties, such as > > compact-mode, length etc. > > 2) Bootstrap's generator may use switchtable in case of hash-codes being > > close (yet it seems to be too rare to handle). > > > > Subjects to discuss: > > 1. Should the bootstrap method validate its arguments in order to report > > irrational arguments (such as usage of duplicate String labels)? > > 2. Is the current Boostrap-arguments layout fine or should be remade? > > 3. Which optimizations should be added (and/or toggled by default) to the > > generator? > > 4. Should branch IDs be specified explicitly or not (using -1 for default > > and 0 + i for other branches)? > > 5. Should there be a way to pass MethodHandles to bootstrap methods to be > > invoked instead of branch IDs being returned if a switch returns nothing > > (and should there be a way to do it for stack-affecting switches?)? > > > > Possible extensions: > > 1. As the name of the class suggests, it is a general switch-table > factory > > and it may be used in future for other types of switches. At least, > > enum-switch *may* be done using it, but (in order to keep it one-switch > > based) it would be much better to have it implemented via condy producing > > int-array for ordinals (this would remove the need for extra synthetic > > class currently being generated). > > 2. Moreover, this approach may be used for boosted implementations of > > pattern-matching magic (using the same approach as for the strings) with > > the exception of the need to pass more complicated structures into the > > bootstrap method (using condy or references to producing methods or more > > complicated patterns). > > 3. In addition to #2, a universal approach may be introduced to allow > > faster switch by all types of values (which is primary useful for pattern > > matching) such as passing pairs of int(T) and boolean(T) MethodHandles > > performing hash-code computation and equality check respectively. > > > > I am ready to continue developing this feature (being ready to sign > Oracle > > Contributor Agreement) which includes: > > - documentation > > - improvements to the current methods > > - addition of the class to other > > - benchmarks and testing > > - optimization > > - compiler support for this switch-approach > > - other features described above, such as a universal switch bootstrap > > method (Possible extensions, #3) > > > > Notes: > > This might have been discussed in the past (at least indy-based switches > in > > general), if there was a reason for this to not be implemented, please > > refer me to it. I would be happy to work on this proposal to make this > > feature (and other ones mentioned) part of OpenJDK. > > > > Thanks for your interest and support, > > Peter > > > > Links: > > [1] https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f > Patch > > (dynamic mirror of the file appended) > > [2] > > > https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 > > Current > > javac String implementation root > > [3] > > > https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java > > One > > of the cases where JDK's Bootstrap-methods are handled specially > From forax at univ-mlv.fr Mon Nov 4 23:59:30 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 5 Nov 2019 00:59:30 +0100 (CET) Subject: indy-based string-switch proposal In-Reply-To: References: <168413605.631206.1572910973388.JavaMail.zimbra@u-pem.fr> Message-ID: <2326792.632351.1572911970986.JavaMail.zimbra@u-pem.fr> > De: "JARvis PROgrammer" > ?: "Remi Forax" , "amber-dev" > Envoy?: Mardi 5 Novembre 2019 00:49:58 > Objet: Re: indy-based string-switch proposal > I wonit say that the limitation is so strict. > In the patch (from which this topic starts) I've used more complicated > String-patterns (aka pages) in order to allow single String bootstrap argument > contain description for multiple switch labels. multiple labels can be handled by the tableswitch that follow the call to invokedynamic. R?mi > ??, 5 ????. 2019 ?. ? 02:42, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] >: >> I term of arguments to sent to the boostrap methods, you can only send the >> strings (concatenated as one big string) >> with the convention that you will return 0 for the first one, 1 for the next >> one, etc. >> R?mi >> ----- Mail original ----- >>> De: "JARvis PROgrammer" < [ mailto:mrjarviscraft at gmail.com | >> > mrjarviscraft at gmail.com ] > >>> ?: "amber-dev" < [ mailto:amber-dev at openjdk.java.net | >> > amber-dev at openjdk.java.net ] > >> > Envoy?: Lundi 4 Novembre 2019 20:15:17 >> > Objet: indy-based string-switch proposal >> > Hi there!. >> > I am here with the proposal (and a working implementation prototype [1]) of >> > a invokedynamic-based string-switch which, while not breaking any >> > backwards-compatibility and not requiring any cascade changes, allows >> > improved behaviour for this JLS feature. >> > Idea: >> > Replace the lookupswitch instruction part (and all the following >> > instructions corresponding to its labels) generated by javac for a >> > String-switch (keeping the tableswitch part) with a single invokedynamic >> > instruction using the new SwitchTableFactory. >> > Patch contents: >> > - SwitchTableFactory.java : home for bootstrap-methods replacing the old >> > lookupswitch behaviour >> > - SwitchTableFactoryException.java : exception thrown by bootstrap-methods >> > of SwitchTableFactory >> > - BaseTest.java : simple behavioral test of bootstrap-methods invoking them >> > via invokestatic and testing results produced by MethodHandles of returned >> > CallSites >> > Reasoning: >> > 1) Current approach (used by javac) is generating a complicated >> > structure (whose number of opcodes grows ~linearly on number of branches). >> > Yet this structure is not usually optimized (at current implementation even >> > 1-branch corner-case is not treated specially [2]). Even if these >> > optimizations were performed at compile-time they could have become useless >> > (or even causing performance problems) in future versions which is against >> > backwards-compatibility principle. Also, switches compiled for older >> > versions whould not use newer features which could have allowed better >> > performance. >> > 2) As of current spec, String hash-code is one of the only hard-coded >> > algorithms. This is mostly due to backwards-compatibility principle and was >> > decided to not be changed (TL;DR and this proposal is not trying to do it). >> > However, using indy-based approach would make the compiler independent from >> > it thus allowing removal of String hash-code algorithm in the future. >> > 3) Producing simpler bytecode would allow external tools analyzing it >> > discover string-switches easier (this may also be said about JIT). >> > 4) Current algorithm cannot rely on String implementation details which are >> > not defined at compile-time (such as String's internal fields). >> > Invokedynamic details: >> > Two bootstrap methods are provided in order to allow big switches (C-style >> > arguments layout is due to inability to pass complicated arguments (such as >> > typed arrays) into the bootstap method): >> > 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, MethodType, >> > Object[]) whose bootstrap arguments are the following: >> > , , [, > > String labels corresponsing to the branch>, [> > to the branch>]*]* >> > 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, >> > MethodType, Object[]) whose bootstrap arguments are the following: >> > , , >> > []* >> > Page is a String of the following pattern: >> > [\0> > branch>\0[\0> > corresponsing to the branch>]*]* >> > As you can see, it allows for multiple branches (each containing multiple >> > labels) to be described under one page. This is done in order to support >> > big switches which cannot fit into the first method variant. >> > Example: >> > As an example of what could be done by the compiler using this feature, >> > consider the following switch expression: >> > switch (string) { >> > case "foo": >> > case "bar": >> > case "baz": case "qux": >> > default: >> > } >> > Generate bytecode would look like: >> > invokedynamic >> > java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, >> > 0, 1, "foo", >> > 1, 1, "bar", >> > 2, 1, "baz", "qux" >> > } >> > >> > or (this should happen for big switches) >> > invokedynamic >> > java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, 1, >> > "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" >> > } >> > >> > (while the argument looks complicates it is (A) shoter (as each '\000' is >> > actually one char) and (B) linear (meaning it is easy to parse)) >> > Implementation details: >> > Current implementation is based on ASM-generation. Under the hood it >> > generates a class ) with a static String (int) method (passed to >> > ConstantCallSite) performing hash-code() switch + equals(Object) (as >> > currently done by javac) handling 0- and 1-branch cases specially (by using >> > a MethodHandle of a method returning a bound value (default branch ID) and >> > by generating an equals(Object) check respectively). The class is >> > anonymously defined via Unsafe as done by other JDK bootstrap methods. >> > Features to be done (this were not done yet as I am not aware yet if this >> > feature will get positive feedback): >> > 1) Add the class and its indy-details into other classes to have it treated >> > specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. >> > 2) FIll the documentation of the SwitchTableFactory. >> > 3) Use SwitchTableFactory in javac (probably, as a preview feature) and >> > test its behaviour. >> > Possible improvements: >> > 1) Bootstrap's generator may use its own hash-code algorithm (based on >> > direct access to String's content using special Lookup or Unsafe) which >> > would be more efficient than String#hashCode(). >> > 2) Bootstrap's generator may depend on other String's properties, such as >> > compact-mode, length etc. >> > 2) Bootstrap's generator may use switchtable in case of hash-codes being >> > close (yet it seems to be too rare to handle). >> > Subjects to discuss: >> > 1. Should the bootstrap method validate its arguments in order to report >> > irrational arguments (such as usage of duplicate String labels)? >> > 2. Is the current Boostrap-arguments layout fine or should be remade? >> > 3. Which optimizations should be added (and/or toggled by default) to the >> > generator? >> > 4. Should branch IDs be specified explicitly or not (using -1 for default >> > and 0 + i for other branches)? >> > 5. Should there be a way to pass MethodHandles to bootstrap methods to be >> > invoked instead of branch IDs being returned if a switch returns nothing >> > (and should there be a way to do it for stack-affecting switches?)? >> > Possible extensions: >> > 1. As the name of the class suggests, it is a general switch-table factory >> > and it may be used in future for other types of switches. At least, >> > enum-switch *may* be done using it, but (in order to keep it one-switch >> > based) it would be much better to have it implemented via condy producing >> > int-array for ordinals (this would remove the need for extra synthetic >> > class currently being generated). >> > 2. Moreover, this approach may be used for boosted implementations of >> > pattern-matching magic (using the same approach as for the strings) with >> > the exception of the need to pass more complicated structures into the >> > bootstrap method (using condy or references to producing methods or more >> > complicated patterns). >> > 3. In addition to #2, a universal approach may be introduced to allow >> > faster switch by all types of values (which is primary useful for pattern >> > matching) such as passing pairs of int(T) and boolean(T) MethodHandles >> > performing hash-code computation and equality check respectively. >> > I am ready to continue developing this feature (being ready to sign Oracle >> > Contributor Agreement) which includes: >> > - documentation >> > - improvements to the current methods >> > - addition of the class to other >> > - benchmarks and testing >> > - optimization >> > - compiler support for this switch-approach >> > - other features described above, such as a universal switch bootstrap >> > method (Possible extensions, #3) >> > Notes: >> > This might have been discussed in the past (at least indy-based switches in >> > general), if there was a reason for this to not be implemented, please >> > refer me to it. I would be happy to work on this proposal to make this >> > feature (and other ones mentioned) part of OpenJDK. >> > Thanks for your interest and support, >> > Peter >> > Links: >>> [1] [ https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f | >> > https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f ] Patch >> > (dynamic mirror of the file appended) >> > [2] >>> [ >>> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 >>> | >>> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 >> > ] >> > Current >> > javac String implementation root >> > [3] >>> [ >>> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java >>> | >>> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java >> > ] >> > One >> > of the cases where JDK's Bootstrap-methods are handled specially From mrjarviscraft at gmail.com Tue Nov 5 00:05:58 2019 From: mrjarviscraft at gmail.com (Japris Pogrammer) Date: Tue, 5 Nov 2019 03:05:58 +0300 Subject: indy-based string-switch proposal In-Reply-To: <2326792.632351.1572911970986.JavaMail.zimbra@u-pem.fr> References: <168413605.631206.1572910973388.JavaMail.zimbra@u-pem.fr> <2326792.632351.1572911970986.JavaMail.zimbra@u-pem.fr> Message-ID: But is not it breaking the whole idea of indy-fication of the switches? Is not it better to let the compiler generate minimal code for these delegating all job to the bootstrap? Again, by doing so we allow future implementations optimize this behavour without changing the class. For example, CallSite may omit unneeded checks based on these which it has already performed. ??, 5 ????. 2019 ?. ? 02:59, : > > > ------------------------------ > > *De: *"JARvis PROgrammer" > *?: *"Remi Forax" , "amber-dev" < > amber-dev at openjdk.java.net> > *Envoy?: *Mardi 5 Novembre 2019 00:49:58 > *Objet: *Re: indy-based string-switch proposal > > I wonit say that the limitation is so strict. > In the patch (from which this topic starts) I've used more complicated > String-patterns (aka pages) in order to allow single String bootstrap > argument contain description for multiple switch labels. > > > multiple labels can be handled by the tableswitch that follow the call to > invokedynamic. > > R?mi > > > > ??, 5 ????. 2019 ?. ? 02:42, Remi Forax : > >> I term of arguments to sent to the boostrap methods, you can only send >> the strings (concatenated as one big string) >> with the convention that you will return 0 for the first one, 1 for the >> next one, etc. >> >> R?mi >> >> ----- Mail original ----- >> > De: "JARvis PROgrammer" >> > ?: "amber-dev" >> > Envoy?: Lundi 4 Novembre 2019 20:15:17 >> > Objet: indy-based string-switch proposal >> >> > Hi there!. >> > >> > I am here with the proposal (and a working implementation prototype >> [1]) of >> > a invokedynamic-based string-switch which, while not breaking any >> > backwards-compatibility and not requiring any cascade changes, allows >> > improved behaviour for this JLS feature. >> > >> > Idea: >> > Replace the lookupswitch instruction part (and all the following >> > instructions corresponding to its labels) generated by javac for a >> > String-switch (keeping the tableswitch part) with a single invokedynamic >> > instruction using the new SwitchTableFactory. >> > Patch contents: >> > - SwitchTableFactory.java : home for bootstrap-methods replacing the old >> > lookupswitch behaviour >> > - SwitchTableFactoryException.java : exception thrown by >> bootstrap-methods >> > of SwitchTableFactory >> > - BaseTest.java : simple behavioral test of bootstrap-methods invoking >> them >> > via invokestatic and testing results produced by MethodHandles of >> returned >> > CallSites >> > >> > Reasoning: >> > 1) Current approach (used by javac) is generating a complicated >> > structure (whose number of opcodes grows ~linearly on number of >> branches). >> > Yet this structure is not usually optimized (at current implementation >> even >> > 1-branch corner-case is not treated specially [2]). Even if these >> > optimizations were performed at compile-time they could have become >> useless >> > (or even causing performance problems) in future versions which is >> against >> > backwards-compatibility principle. Also, switches compiled for older >> > versions whould not use newer features which could have allowed better >> > performance. >> > 2) As of current spec, String hash-code is one of the only hard-coded >> > algorithms. This is mostly due to backwards-compatibility principle and >> was >> > decided to not be changed (TL;DR and this proposal is not trying to do >> it). >> > However, using indy-based approach would make the compiler independent >> from >> > it thus allowing removal of String hash-code algorithm in the future. >> > 3) Producing simpler bytecode would allow external tools analyzing it >> > discover string-switches easier (this may also be said about JIT). >> > 4) Current algorithm cannot rely on String implementation details which >> are >> > not defined at compile-time (such as String's internal fields). >> > >> > Invokedynamic details: >> > Two bootstrap methods are provided in order to allow big switches >> (C-style >> > arguments layout is due to inability to pass complicated arguments >> (such as >> > typed arrays) into the bootstap method): >> > 1) SwitchTableFactory:createStringSwitchTable(Lookup, String, >> MethodType, >> > Object[]) whose bootstrap arguments are the following: >> > , , [, > > String labels corresponsing to the branch>, [> corresponsing >> > to the branch>]*]* >> > 2) SwitchTableFactory:altCreateStringSwitchTable(Lookup, String, >> > MethodType, Object[]) whose bootstrap arguments are the following: >> > , , >> > []* >> > Page is a String of the following pattern: >> > [\0> > branch>\0[\0> > corresponsing to the branch>]*]* >> > As you can see, it allows for multiple branches (each containing >> multiple >> > labels) to be described under one page. This is done in order to support >> > big switches which cannot fit into the first method variant. >> > >> > Example: >> > As an example of what could be done by the compiler using this feature, >> > consider the following switch expression: >> > >> > switch (string) { >> > case "foo": >> > case "bar": >> > case "baz": case "qux": >> > default: >> > } >> > >> > Generate bytecode would look like: >> > >> > invokedynamic >> > java/lang/invoke/SwitchTableFactory:createStringSwitchTable(..) {-1, 4, >> > 0, 1, "foo", >> > 1, 1, "bar", >> > 2, 1, "baz", "qux" >> > } >> > >> > >> > or (this should happen for big switches) >> > >> > invokedynamic >> > java/lang/invoke/SwitchTableFactory:altCreateStringSwitchTable(..) {-1, >> 1, >> > "0\0001\0003\000foo1\0001\0003\000bar2\0002\0003\000baz3\000qux" >> > } >> > >> > >> > (while the argument looks complicates it is (A) shoter (as each '\000' >> is >> > actually one char) and (B) linear (meaning it is easy to parse)) >> > >> > Implementation details: >> > Current implementation is based on ASM-generation. Under the hood it >> > generates a class ) with a static String (int) method (passed to >> > ConstantCallSite) performing hash-code() switch + equals(Object) (as >> > currently done by javac) handling 0- and 1-branch cases specially (by >> using >> > a MethodHandle of a method returning a bound value (default branch ID) >> and >> > by generating an equals(Object) check respectively). The class is >> > anonymously defined via Unsafe as done by other JDK bootstrap methods. >> > >> > Features to be done (this were not done yet as I am not aware yet if >> this >> > feature will get positive feedback): >> > 1) Add the class and its indy-details into other classes to have it >> treated >> > specially (as done for LambdaMetaFactory and StringConcatFactory) [3]. >> > 2) FIll the documentation of the SwitchTableFactory. >> > 3) Use SwitchTableFactory in javac (probably, as a preview feature) and >> > test its behaviour. >> > >> > Possible improvements: >> > 1) Bootstrap's generator may use its own hash-code algorithm (based on >> > direct access to String's content using special Lookup or Unsafe) which >> > would be more efficient than String#hashCode(). >> > 2) Bootstrap's generator may depend on other String's properties, such >> as >> > compact-mode, length etc. >> > 2) Bootstrap's generator may use switchtable in case of hash-codes being >> > close (yet it seems to be too rare to handle). >> > >> > Subjects to discuss: >> > 1. Should the bootstrap method validate its arguments in order to report >> > irrational arguments (such as usage of duplicate String labels)? >> > 2. Is the current Boostrap-arguments layout fine or should be remade? >> > 3. Which optimizations should be added (and/or toggled by default) to >> the >> > generator? >> > 4. Should branch IDs be specified explicitly or not (using -1 for >> default >> > and 0 + i for other branches)? >> > 5. Should there be a way to pass MethodHandles to bootstrap methods to >> be >> > invoked instead of branch IDs being returned if a switch returns nothing >> > (and should there be a way to do it for stack-affecting switches?)? >> > >> > Possible extensions: >> > 1. As the name of the class suggests, it is a general switch-table >> factory >> > and it may be used in future for other types of switches. At least, >> > enum-switch *may* be done using it, but (in order to keep it one-switch >> > based) it would be much better to have it implemented via condy >> producing >> > int-array for ordinals (this would remove the need for extra synthetic >> > class currently being generated). >> > 2. Moreover, this approach may be used for boosted implementations of >> > pattern-matching magic (using the same approach as for the strings) with >> > the exception of the need to pass more complicated structures into the >> > bootstrap method (using condy or references to producing methods or more >> > complicated patterns). >> > 3. In addition to #2, a universal approach may be introduced to allow >> > faster switch by all types of values (which is primary useful for >> pattern >> > matching) such as passing pairs of int(T) and boolean(T) MethodHandles >> > performing hash-code computation and equality check respectively. >> > >> > I am ready to continue developing this feature (being ready to sign >> Oracle >> > Contributor Agreement) which includes: >> > - documentation >> > - improvements to the current methods >> > - addition of the class to other >> > - benchmarks and testing >> > - optimization >> > - compiler support for this switch-approach >> > - other features described above, such as a universal switch bootstrap >> > method (Possible extensions, #3) >> > >> > Notes: >> > This might have been discussed in the past (at least indy-based >> switches in >> > general), if there was a reason for this to not be implemented, please >> > refer me to it. I would be happy to work on this proposal to make this >> > feature (and other ones mentioned) part of OpenJDK. >> > >> > Thanks for your interest and support, >> > Peter >> > >> > Links: >> > [1] >> https://gist.github.com/JarvisCraft/53b6e5e4eb91419b6e852cf63e1c8a2f >> Patch >> > (dynamic mirror of the file appended) >> > [2] >> > >> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java#l3692 >> > Current >> > javac String implementation root >> > [3] >> > >> https://hg.openjdk.java.net/amber/amber/file/c033807bfd49/src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java >> > One >> > of the cases where JDK's Bootstrap-methods are handled specially >> > > From mrjarviscraft at gmail.com Tue Nov 5 00:18:11 2019 From: mrjarviscraft at gmail.com (Japris Pogrammer) Date: Tue, 5 Nov 2019 03:18:11 +0300 Subject: indy-based string-switch proposal In-Reply-To: References: <168413605.631206.1572910973388.JavaMail.zimbra@u-pem.fr> <2326792.632351.1572911970986.JavaMail.zimbra@u-pem.fr> Message-ID: My idea arond it was: - Compiler: - Counts the number of branches - Associates branches with some close IDs - Associates branch values with IDs After all we get something like int : branch ID> (branch IDs by labels) + int : default ID - Generated invokedynamic to accept value and return the corresponding ID - Generates lookuptable to go to branches by IDs - Bootstap method at runtime: - Generate maximally effective implementation of