From jan.lahoda at oracle.com Tue Sep 3 11:51:56 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 3 Sep 2019 13:51:56 +0200 Subject: RFR: JDK-8228460: bootstrap class path not set in conjunction with -source 11 Message-ID: <61ea1a9f-8edb-6187-c310-06f0cbaa206b@oracle.com> Hi, When running with --source which is less than the current default source and -bootclasspath is not specified, a warning about not specified -bootclasspath is printed. But that is not really appropriate for -source 9+, because it should a) mention system module path, rather than -bootclasspath; b) the option to check should be --system, not -bootclasspath. The proposed patch is trying to fix that. JBS: https://bugs.openjdk.java.net/browse/JDK-8228460 Webrev: http://cr.openjdk.java.net/~jlahoda/8228460/webrev.00/ How does this look? Thanks, Jan From jan.lahoda at oracle.com Tue Sep 3 14:50:55 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 3 Sep 2019 16:50:55 +0200 Subject: RFR: JDK-8177068: incomplete classpath causes NPE in Flow In-Reply-To: <6b9e7075-51f7-0642-2296-8e18e11132de@oracle.com> References: <6b9e7075-51f7-0642-2296-8e18e11132de@oracle.com> Message-ID: <66d86dac-542e-5c17-60d0-5d383bb281d6@oracle.com> Hi, As DeferredAttr has been updated so that it has conflict with this patch, I've updated the patch as well: http://cr.openjdk.java.net/~jlahoda/8177068/webrev.01/ Not changes to the way the patch works, just resolving the conflicts. Any feedback on this patch would be welcome! Thanks, Jan On 28. 08. 19 16:12, Jan Lahoda wrote: > Hi, > > If a class cannot be load during speculative attribution due to a > CompletionFailure, the CompletionFailure may not be happening again > during the ordinary attribution, which may lead to errors not being > reported (as the error is a consequence of the CompletionFailure). > Producing the error only on CompletionFailures helps with error recovery > by not producing unnecessary errors. A similar problem with completion > in user code was solved by restoring the ClassSymbol for which the > completion failed to the original state when the user code finishes. > Something similar could be done for speculative attribution, undoing the > completion for ClassSymbols which fail to complete during speculative > attribution, so that their completion will fail again during ordinary > attribution and the error is reported properly. > > Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8177068/webrev.00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8177068 > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Wed Sep 4 03:12:08 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 3 Sep 2019 23:12:08 -0400 Subject: RFR: JDK-8177068: incomplete classpath causes NPE in Flow In-Reply-To: <66d86dac-542e-5c17-60d0-5d383bb281d6@oracle.com> References: <6b9e7075-51f7-0642-2296-8e18e11132de@oracle.com> <66d86dac-542e-5c17-60d0-5d383bb281d6@oracle.com> Message-ID: looks good. I like the fact that you are reusing an approach already tested in a pretty similar situation, Vicente On 9/3/19 10:50 AM, Jan Lahoda wrote: > Hi, > > As DeferredAttr has been updated so that it has conflict with this > patch, I've updated the patch as well: > http://cr.openjdk.java.net/~jlahoda/8177068/webrev.01/ > > Not changes to the way the patch works, just resolving the conflicts. > > Any feedback on this patch would be welcome! > > Thanks, > ??? Jan > > On 28. 08. 19 16:12, Jan Lahoda wrote: >> Hi, >> >> If a class cannot be load during speculative attribution due to a >> CompletionFailure, the CompletionFailure may not be happening again >> during the ordinary attribution, which may lead to errors not being >> reported (as the error is a consequence of the CompletionFailure). >> Producing the error only on CompletionFailures helps with error >> recovery by not producing unnecessary errors. A similar problem with >> completion in user code was solved by restoring the ClassSymbol for >> which the completion failed to the original state when the user code >> finishes. Something similar could be done for speculative >> attribution, undoing the completion for ClassSymbols which fail to >> complete during speculative attribution, so that their completion >> will fail again during ordinary attribution and the error is reported >> properly. >> >> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8177068/webrev.00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177068 >> >> How does this look? >> >> Thanks, >> ???? Jan From ronshapiro at google.com Wed Sep 4 12:05:09 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 4 Sep 2019 15:05:09 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> Message-ID: Friendly ping. This is really hurting some of our builds. Maurizio, are you able to prepare a patch for us to look at? On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro wrote: > Aren't types recreated across rounds if there are any transitive error > types? That was at least my assumption. > > On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda wrote: > >> I wonder if this will work with annotation processors? (As these may >> create new interfaces into the hierarchy.) >> >> Jan >> >> On 07. 08. 19 12:25, Ron Shapiro wrote: >> > Made the change for a WeakHashMap: >> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >> > >> > Perhaps it would make better sense for this to be a field on ClassType? >> > That would avoid the need for managing a cache with weak keys. >> > >> > Do you have any guidance on how you approach tradeoffs in memory vs. >> speed? >> > >> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero < >> vicente.romero at oracle.com >> > > wrote: >> > >> > not sure if we should add yet another cache to javac but in any case >> > it should be implemented with a: WeakHashMap, >> > >> > Thanks, >> > Vicente >> > >> > On 8/5/19 10:32 AM, Ron Shapiro wrote: >> >> Fair question. >> >> >> >> github.com/google/dagger >> >> generates implementations of interfaces that implement a >> >> dependency injection graph. Sometimes, though not always, these >> >> interfaces have dozens if not hundreds of (super)interfaces which >> >> allow for builds to be sharded: each subsection of the build >> >> refers to the superinterface and then at the root of the build >> >> there is a union of them all. Naturally, this means this must be >> >> rebuilt on most/all changes to any subproject of the build. >> >> >> >> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >> >> ?>: >> >> >> >> Hi Ron, >> >> >> >> Just out of curiosity, what is the context in which this issue >> >> arises? Naturally consuming more memory we can speed up javac >> >> but this can lead to other problems too. >> >> >> >> Thanks, >> >> Vicente >> >> >> >> On 8/5/19 8:24 AM, Ron Shapiro wrote: >> >>> Friendly ping >> >>> >> >>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >> >>> ?>: >> >>> >> >>> Hi, >> >>> >> >>> Please review this change to speed up Resolve.findMethod >> >>> for large classes that have large numbers of >> >>> (super)interfaces >> >>> >> >>> webrev: >> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >> >>> >> >>> Thanks, >> >>> Ron >> >>> >> >> >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Wed Sep 4 12:15:16 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 4 Sep 2019 15:15:16 +0300 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> Message-ID: Here's the updated webrev that Brad mentioned in his last message: http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/ On Wed, Aug 28, 2019 at 2:40 AM Brad Corso wrote: > I believe "Do you have any estimates of the increase in size in typical >> usage, due to the extra field in Scope?" (Jon) > > > I was seeing noticeably bad performance once the size of the Entry.sibling > linked list reached ~10000, and the max I saw was ~30000 in a single scope. > Given that an additional reference adds 32/64b, this could add up to > 120/240Kb for the cases I saw. > > I'd add, is there a chance to get an improvement in Scope.remove speed >> without making ScopeImpl.Entry bigger (assuming it gets bigger(?))? One >> possibility that occurred to me is that we could try not to remove the >> things from elems, but only mark them as removed. We would need to do >> filtering (and possibly the actual removal) while reading from the Scope >> (in getSymbols), so this is a different kind of trade-off. > > > > (Overall, I guess the question is whether we are trading problems with >> > Scope.remove speed in some cases for out-of-memory problems in other >> cases.) > > > Thanks, I've verified your suggestion also gives us the performance > improvements, so this change is okay with me. > > > > > On Tue, Aug 27, 2019 at 12:05 AM Jan Lahoda wrote: > >> On 27. 08. 19 0:06, Brad Corso wrote: >> > Sorry, what's the question? >> >> I believe "Do you have any estimates of the increase in size in typical >> usage, due to the extra field in Scope?" (Jon) >> >> I'd add, is there a chance to get an improvement in Scope.remove speed >> without making ScopeImpl.Entry bigger (assuming it gets bigger(?))? One >> possibility that occurred to me is that we could try not to remove the >> things from elems, but only mark them as removed. We would need to do >> filtering (and possibly the actual removal) while reading from the Scope >> (in getSymbols), so this is a different kind of trade-off. >> >> (Overall, I guess the question is whether we are trading problems with >> Scope.remove speed in some cases for out-of-memory problems in other >> cases.) >> >> Jan >> >> > >> > On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro > > > wrote: >> > >> > Adding Brad back in to the thread since he would know best >> > >> > ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan Gibbons >> > ?> >>: >> > >> > >> > On 8/26/19 9:12 AM, Ron Shapiro wrote: >> > > >> > > Note that the patch was prepared by my coworker, Brad (cc'd). >> > I wasn't >> > > sure what to do to make sure that he was attributed >> correctly. >> > >> > >> > Mention this when you have a sponsor to push the changeset, so >> > that it >> > can be marked with "Contributed-By:" >> > >> > -- Jon >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Wed Sep 4 13:02:16 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 4 Sep 2019 16:02:16 +0300 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> Message-ID: Also, this patch by Brad also seems to have a big improvement in Types.union() (and passes jtreg): http://cr.openjdk.java.net/~ronsh/8228675/webrev.02/ It's independent from the above ideas, but does reduce the amount of union()-ing. On Wed, Sep 4, 2019 at 3:05 PM Ron Shapiro wrote: > Friendly ping. This is really hurting some of our builds. Maurizio, are > you able to prepare a patch for us to look at? > > On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro wrote: > >> Aren't types recreated across rounds if there are any transitive error >> types? That was at least my assumption. >> >> On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda wrote: >> >>> I wonder if this will work with annotation processors? (As these may >>> create new interfaces into the hierarchy.) >>> >>> Jan >>> >>> On 07. 08. 19 12:25, Ron Shapiro wrote: >>> > Made the change for a WeakHashMap: >>> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >>> > >>> > Perhaps it would make better sense for this to be a field on >>> ClassType? >>> > That would avoid the need for managing a cache with weak keys. >>> > >>> > Do you have any guidance on how you approach tradeoffs in memory vs. >>> speed? >>> > >>> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero < >>> vicente.romero at oracle.com >>> > > wrote: >>> > >>> > not sure if we should add yet another cache to javac but in any >>> case >>> > it should be implemented with a: WeakHashMap, >>> > >>> > Thanks, >>> > Vicente >>> > >>> > On 8/5/19 10:32 AM, Ron Shapiro wrote: >>> >> Fair question. >>> >> >>> >> github.com/google/dagger >>> >> generates implementations of interfaces that implement a >>> >> dependency injection graph. Sometimes, though not always, these >>> >> interfaces have dozens if not hundreds of (super)interfaces which >>> >> allow for builds to be sharded: each subsection of the build >>> >> refers to the superinterface and then at the root of the build >>> >> there is a union of them all. Naturally, this means this must be >>> >> rebuilt on most/all changes to any subproject of the build. >>> >> >>> >> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >>> >> ?>: >>> >> >>> >> Hi Ron, >>> >> >>> >> Just out of curiosity, what is the context in which this issue >>> >> arises? Naturally consuming more memory we can speed up javac >>> >> but this can lead to other problems too. >>> >> >>> >> Thanks, >>> >> Vicente >>> >> >>> >> On 8/5/19 8:24 AM, Ron Shapiro wrote: >>> >>> Friendly ping >>> >>> >>> >>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >>> >>> ?>: >>> >>> >>> >>> Hi, >>> >>> >>> >>> Please review this change to speed up Resolve.findMethod >>> >>> for large classes that have large numbers of >>> >>> (super)interfaces >>> >>> >>> >>> webrev: >>> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>> >>> >>> >>> Thanks, >>> >>> Ron >>> >>> >>> >> >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Sep 4 13:47:12 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 4 Sep 2019 15:47:12 +0200 Subject: JDK-8208664: JDK8,JDK9-breakpoint on a continue doesnt work on jdb and intellij Message-ID: Hi, There is a small issue in some cases when trying to put breakpoints on break/continue (or stepping through code that has break/continue). Consider this code: --- static void test(boolean a, boolean b) { for (int i = 0; i < 10; i++) { if (a || b) { continue; //set breakpoint here } System.out.println(); } } --- This gets compiled into: --- 0: iconst_0 1: istore_2 2: iload_2 3: bipush 10 5: if_icmpge 28 8: iload_0 9: ifne 22 12: iload_1 13: ifeq 19 16: goto 22 19: invokestatic #3 // Method nop:()V 22: iinc 2, 1 25: goto 2 28: return --- The instruction that corresponds to the "continue" is the "goto" on bytecode index 16. But, if "a" is true, that instruction is never executed, because the test on bytecode index 9 will jump directly to the "continue" target. We cannot generate LineNumberTable saying that bytecode index 9 corresponds to the "continue", as it really belongs to the if, and debuggers would in some cases stop on the wrong line instead of stopping on the continue. So, the issue is that if "a" is true, then there is never a real instruction executed that corresponds to the "continue". What we can do is to change the target if the "ifne" on bytecode index 9 to "16", so that the goto is always executed, and everything would work OK in debuggers, except that one additional jump is performed (and, in some rarer cases, generated, as the actual "goto" can sometimes be skipped). I tried to compile the JDK with and without the proposed patch, and about 1100 out of 31000 classfiles are changed, so this affects roughly 3.5% of the JDK classfiles. The proposed patch is only enabling this behavior when LineNumberTable is being generated, but that is fairly common, and so it is not a big help. One of the alternatives would be to require a special "-g" flag, like "-g:debuglines". JBS: https://bugs.openjdk.java.net/browse/JDK-8208664 Webrev: http://cr.openjdk.java.net/~jlahoda/8208664/webrev.00/ Any opinions? Thanks! Jan From maurizio.cimadamore at oracle.com Wed Sep 4 14:20:44 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 4 Sep 2019 15:20:44 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> Message-ID: This patch seems like a low-hanging fruit - union was already returning element in that order in case they were unrelated, so I agree the extra test looks redundant. Maurizio On 04/09/2019 14:02, Ron Shapiro wrote: > Also, this patch by Brad also seems to have a big improvement in > Types.union() (and passes jtreg): > http://cr.openjdk.java.net/~ronsh/8228675/webrev.02/ > > > It's independent from the above ideas, but does reduce the amount of > union()-ing. > > > > On Wed, Sep 4, 2019 at 3:05 PM Ron Shapiro > wrote: > > Friendly ping. This is really hurting some of our builds. > Maurizio, are you able to prepare a patch for us to look at? > > On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro > wrote: > > Aren't types recreated across rounds if there are any > transitive error types? That was at least my assumption. > > On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda > > wrote: > > I wonder if this will work with annotation processors? (As > these may > create new interfaces into the hierarchy.) > > Jan > > On 07. 08. 19 12:25, Ron Shapiro wrote: > > Made the change for a WeakHashMap: > > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. > > > > Perhaps it would make better sense for this to be a > field on ClassType? > > That would avoid the need for managing a cache with weak > keys. > > > > Do you have any guidance on how you approach tradeoffs > in memory vs. speed? > > > > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero > > > >> wrote: > > > >? ? ?not sure if we should add yet another cache to javac > but in any case > >? ? ?it should be implemented with a: WeakHashMap, > > > >? ? ?Thanks, > >? ? ?Vicente > > > >? ? ?On 8/5/19 10:32 AM, Ron Shapiro wrote: > >>? ? ?Fair question. > >> > >> github.com/google/dagger > > > >>? ? ?generates implementations of interfaces that > implement a > >>? ? ?dependency injection graph. Sometimes, though not > always, these > >>? ? ?interfaces have dozens if not hundreds of > (super)interfaces which > >>? ? ?allow for builds to be sharded: each subsection of > the build > >>? ? ?refers to the superinterface and then at the root > of the build > >>? ? ?there is a union of them all. Naturally, this means > this must be > >>? ? ?rebuilt on most/all changes to any subproject of > the build. > >> > >>? ? ??????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero > >>? ? ?? > >>: > >> > >>? ? ? ? ?Hi Ron, > >> > >>? ? ? ? ?Just out of curiosity, what is the context in > which this issue > >>? ? ? ? ?arises? Naturally consuming more memory we can > speed up javac > >>? ? ? ? ?but this can lead to other problems too. > >> > >>? ? ? ? ?Thanks, > >>? ? ? ? ?Vicente > >> > >>? ? ? ? ?On 8/5/19 8:24 AM, Ron Shapiro wrote: > >>>? ? ? ? ?Friendly ping > >>> > >>>? ? ? ? ??????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro > >>>? ? ? ? ?? > >>: > >>> > >>>? ? ? ? ? ? ?Hi, > >>> > >>>? ? ? ? ? ? ?Please review this change to speed up > Resolve.findMethod > >>>? ? ? ? ? ? ?for large classes that have large numbers of > >>>? ? ? ? ? ? ?(super)interfaces > >>> > >>>? ? ? ? ? ? ?webrev: > http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ > >>>? ? ? ? ? ? ?bug: > https://bugs.openjdk.java.net/browse/JDK-8228675 > >>> > >>>? ? ? ? ? ? ?Thanks, > >>>? ? ? ? ? ? ?Ron > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Sep 4 14:18:48 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 4 Sep 2019 15:18:48 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> Message-ID: <5b523e4f-9a42-6010-9211-a1e99460890b@oracle.com> I didn't realize you were waiting on me to produce a patch; I'm afraid at the moment I don't have many cycles to look into this. Maurizio On 04/09/2019 13:05, Ron Shapiro wrote: > Friendly ping. This is really hurting some of our builds. Maurizio, > are you able to prepare a patch for us to look at? > > On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro > wrote: > > Aren't types recreated across rounds if there are any transitive > error types? That was at least my assumption. > > On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda > wrote: > > I wonder if this will work with annotation processors? (As > these may > create new interfaces into the hierarchy.) > > Jan > > On 07. 08. 19 12:25, Ron Shapiro wrote: > > Made the change for a WeakHashMap: > > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. > > > > Perhaps it would make better sense for this to be a field on > ClassType? > > That would avoid the need for managing a cache with weak keys. > > > > Do you have any guidance on how you approach tradeoffs in > memory vs. speed? > > > > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero > > > >> wrote: > > > >? ? ?not sure if we should add yet another cache to javac but > in any case > >? ? ?it should be implemented with a: WeakHashMap, > > > >? ? ?Thanks, > >? ? ?Vicente > > > >? ? ?On 8/5/19 10:32 AM, Ron Shapiro wrote: > >>? ? ?Fair question. > >> > >> github.com/google/dagger > > >>? ? ?generates implementations of interfaces that implement a > >>? ? ?dependency injection graph. Sometimes, though not > always, these > >>? ? ?interfaces have dozens if not hundreds of > (super)interfaces which > >>? ? ?allow for builds to be sharded: each subsection of the > build > >>? ? ?refers to the superinterface and then at the root of > the build > >>? ? ?there is a union of them all. Naturally, this means > this must be > >>? ? ?rebuilt on most/all changes to any subproject of the build. > >> > >>? ? ??????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero > >>? ? ?? > >>: > >> > >>? ? ? ? ?Hi Ron, > >> > >>? ? ? ? ?Just out of curiosity, what is the context in which > this issue > >>? ? ? ? ?arises? Naturally consuming more memory we can > speed up javac > >>? ? ? ? ?but this can lead to other problems too. > >> > >>? ? ? ? ?Thanks, > >>? ? ? ? ?Vicente > >> > >>? ? ? ? ?On 8/5/19 8:24 AM, Ron Shapiro wrote: > >>>? ? ? ? ?Friendly ping > >>> > >>>? ? ? ? ??????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro > >>>? ? ? ? ?? >>: > >>> > >>>? ? ? ? ? ? ?Hi, > >>> > >>>? ? ? ? ? ? ?Please review this change to speed up > Resolve.findMethod > >>>? ? ? ? ? ? ?for large classes that have large numbers of > >>>? ? ? ? ? ? ?(super)interfaces > >>> > >>>? ? ? ? ? ? ?webrev: > http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ > >>>? ? ? ? ? ? ?bug: > https://bugs.openjdk.java.net/browse/JDK-8228675 > >>> > >>>? ? ? ? ? ? ?Thanks, > >>>? ? ? ? ? ? ?Ron > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Sep 4 19:58:13 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 4 Sep 2019 20:58:13 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: <5b523e4f-9a42-6010-9211-a1e99460890b@oracle.com> References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> <5b523e4f-9a42-6010-9211-a1e99460890b@oracle.com> Message-ID: <16c4bb5f-3d63-d92b-07b8-8a093b151d5b@oracle.com> Hi Ron, I put together something, albeit not the approach I described in this thread. Since, from what I'm reading, the main issue you are seeing is that the use of Types.closure is basically killing performances, I addressed that problem instead, and rewrote the code not to use that method. The new code is probably executing more checks than the old (since interfaces could be implemented multiple times at different levels of the hierarchy), but I think it should be enough to resolve the issue you are seeing. I did not spend a lot of time testing the patch, other than doing some basic validation - so handle with care :-) http://cr.openjdk.java.net/~mcimadamore/8228675/ Maurizio On 04/09/2019 15:18, Maurizio Cimadamore wrote: > > I didn't realize you were waiting on me to produce a patch; I'm afraid > at the moment I don't have many cycles to look into this. > > Maurizio > > On 04/09/2019 13:05, Ron Shapiro wrote: >> Friendly ping. This is really hurting some of our builds. Maurizio, >> are you able to prepare a patch for us to look at? >> >> On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro > > wrote: >> >> Aren't types recreated across rounds if there are any transitive >> error types? That was at least my assumption. >> >> On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda > > wrote: >> >> I wonder if this will work with annotation processors? (As >> these may >> create new interfaces into the hierarchy.) >> >> Jan >> >> On 07. 08. 19 12:25, Ron Shapiro wrote: >> > Made the change for a WeakHashMap: >> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >> > >> > Perhaps it would make better sense for this to be a field >> on ClassType? >> > That would avoid the need for managing a cache with weak keys. >> > >> > Do you have any guidance on how you approach tradeoffs in >> memory vs. speed? >> > >> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero >> >> > > >> wrote: >> > >> >? ? ?not sure if we should add yet another cache to javac >> but in any case >> >? ? ?it should be implemented with a: WeakHashMap, >> > >> >? ? ?Thanks, >> >? ? ?Vicente >> > >> >? ? ?On 8/5/19 10:32 AM, Ron Shapiro wrote: >> >>? ? ?Fair question. >> >> >> >> github.com/google/dagger >> >> >>? ? ?generates implementations of interfaces that implement a >> >>? ? ?dependency injection graph. Sometimes, though not >> always, these >> >>? ? ?interfaces have dozens if not hundreds of >> (super)interfaces which >> >>? ? ?allow for builds to be sharded: each subsection of the >> build >> >>? ? ?refers to the superinterface and then at the root of >> the build >> >>? ? ?there is a union of them all. Naturally, this means >> this must be >> >>? ? ?rebuilt on most/all changes to any subproject of the >> build. >> >> >> >>? ? ??????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >> >>? ? ??> >> > >>: >> >> >> >>? ? ? ? ?Hi Ron, >> >> >> >>? ? ? ? ?Just out of curiosity, what is the context in >> which this issue >> >>? ? ? ? ?arises? Naturally consuming more memory we can >> speed up javac >> >>? ? ? ? ?but this can lead to other problems too. >> >> >> >>? ? ? ? ?Thanks, >> >>? ? ? ? ?Vicente >> >> >> >>? ? ? ? ?On 8/5/19 8:24 AM, Ron Shapiro wrote: >> >>>? ? ? ? ?Friendly ping >> >>> >> >>>? ? ? ? ??????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >> >>>? ? ? ? ??> > >>: >> >>> >> >>>? ? ? ? ? ? ?Hi, >> >>> >> >>>? ? ? ? ? ? ?Please review this change to speed up >> Resolve.findMethod >> >>>? ? ? ? ? ? ?for large classes that have large numbers of >> >>>? ? ? ? ? ? ?(super)interfaces >> >>> >> >>>? ? ? ? ? ? ?webrev: >> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >> >>>? ? ? ? ? ? ?bug: >> https://bugs.openjdk.java.net/browse/JDK-8228675 >> >>> >> >>>? ? ? ? ? ? ?Thanks, >> >>>? ? ? ? ? ? ?Ron >> >>> >> >> >> > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Sep 4 21:19:00 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 4 Sep 2019 14:19:00 -0700 Subject: JDK 14 RFR of JDK-8230626: Make UnknownFooException strings more informative Message-ID: <694d262f-ce05-86c4-6b73-2247ca8ac107@oracle.com> Hello, Responding to some off-list input from Jon, please review the small enhancement for ??? JDK-8230626: Make UnknownFooException strings more informative ??? http://cr.openjdk.java.net/~darcy/8230626.0/ Patch below; thanks, -Joe --- old/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java 2019-09-04 14:16:30.437963468 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java 2019-09-04 14:16:30.141963468 -0700 @@ -60,7 +60,7 @@ ????? * @param p an additional parameter, may be {@code null} ????? */ ???? public UnknownAnnotationValueException(AnnotationValue av, Object p) { -??????? super("Unknown annotation value: " + av); +??????? super("Unknown annotation value: ``" + av + "''"); ???????? this.av = av; ???????? this.parameter = p; ???? } --- old/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java 2019-09-04 14:16:31.153963468 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java 2019-09-04 14:16:30.917963468 -0700 @@ -58,7 +58,7 @@ ????? * @param p an additional parameter, may be {@code null} ????? */ ???? public UnknownElementException(Element e, Object p) { -??????? super("Unknown element: " + e); +??????? super("Unknown element: ``" + e + "''"); ???????? element = e; ???????? this.parameter = p; ???? } --- old/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java 2019-09-04 14:16:31.777963468 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java 2019-09-04 14:16:31.545963468 -0700 @@ -58,7 +58,7 @@ ????? * @param p an additional parameter, may be {@code null} ????? */ ???? public UnknownTypeException(TypeMirror t, Object p) { -??????? super("Unknown type: " + t); +??????? super("Unknown type: ``" + t + "''"); ???????? type = t; ???????? this.parameter = p; ???? } From mark.reinhold at oracle.com Wed Sep 4 22:04:14 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 04 Sep 2019 15:04:14 -0700 Subject: JDK 14 RFR of JDK-8230626: Make UnknownFooException strings more informative In-Reply-To: <694d262f-ce05-86c4-6b73-2247ca8ac107@oracle.com> References: <694d262f-ce05-86c4-6b73-2247ca8ac107@oracle.com> Message-ID: <20190904150414.953803677@eggemoggin.niobe.net> 2019/9/4 14:19:00 -0700, joe.darcy at oracle.com: > Responding to some off-list input from Jon, please review the small > enhancement for > > JDK-8230626: Make UnknownFooException strings more informative > http://cr.openjdk.java.net/~darcy/8230626.0/ > > Patch below; thanks, > ... > - super("Unknown annotation value: " + av); > + super("Unknown annotation value: ``" + av + "''"); The use of GNU-style ``fake curly quotes'' in JDK messages is extremely rare, and jarring to the eye in most typefaces. Pairs of backticks and apostrophes are a poorer subsitute for ?true curly quotes? than simple "vertical quotation marks." Please use vertical quotation marks, which is what we use pretty much everywhere. - Mark From jonathan.gibbons at oracle.com Wed Sep 4 22:06:18 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 4 Sep 2019 15:06:18 -0700 Subject: JDK 14 RFR of JDK-8230626: Make UnknownFooException strings more informative In-Reply-To: <694d262f-ce05-86c4-6b73-2247ca8ac107@oracle.com> References: <694d262f-ce05-86c4-6b73-2247ca8ac107@oracle.com> Message-ID: Just curious, Is there any particular reason to go for the "double single quote" style of presentation? -- Jon On 9/4/19 2:19 PM, Joe Darcy wrote: > Hello, > > Responding to some off-list input from Jon, please review the small > enhancement for > > ??? JDK-8230626: Make UnknownFooException strings more informative > ??? http://cr.openjdk.java.net/~darcy/8230626.0/ > > Patch below; thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java > 2019-09-04 14:16:30.437963468 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java > 2019-09-04 14:16:30.141963468 -0700 > @@ -60,7 +60,7 @@ > ????? * @param p an additional parameter, may be {@code null} > ????? */ > ???? public UnknownAnnotationValueException(AnnotationValue av, Object > p) { > -??????? super("Unknown annotation value: " + av); > +??????? super("Unknown annotation value: ``" + av + "''"); > ???????? this.av = av; > ???????? this.parameter = p; > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java > 2019-09-04 14:16:31.153963468 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java > 2019-09-04 14:16:30.917963468 -0700 > @@ -58,7 +58,7 @@ > ????? * @param p an additional parameter, may be {@code null} > ????? */ > ???? public UnknownElementException(Element e, Object p) { > -??????? super("Unknown element: " + e); > +??????? super("Unknown element: ``" + e + "''"); > ???????? element = e; > ???????? this.parameter = p; > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java > 2019-09-04 14:16:31.777963468 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java > 2019-09-04 14:16:31.545963468 -0700 > @@ -58,7 +58,7 @@ > ????? * @param p an additional parameter, may be {@code null} > ????? */ > ???? public UnknownTypeException(TypeMirror t, Object p) { > -??????? super("Unknown type: " + t); > +??????? super("Unknown type: ``" + t + "''"); > ???????? type = t; > ???????? this.parameter = p; > ???? } > From joe.darcy at oracle.com Wed Sep 4 22:20:51 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 4 Sep 2019 15:20:51 -0700 Subject: JDK 14 RFR of JDK-8230626: Make UnknownFooException strings more informative In-Reply-To: <20190904150414.953803677@eggemoggin.niobe.net> References: <694d262f-ce05-86c4-6b73-2247ca8ac107@oracle.com> <20190904150414.953803677@eggemoggin.niobe.net> Message-ID: Updated webrev with patch below: ??? http://cr.openjdk.java.net/~darcy/8230626.1/ -Joe --- old/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java 2019-09-04 15:19:08.561963468 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java 2019-09-04 15:19:08.385963468 -0700 @@ -60,7 +60,7 @@ ????? * @param p an additional parameter, may be {@code null} ????? */ ???? public UnknownAnnotationValueException(AnnotationValue av, Object p) { -??????? super("Unknown annotation value: " + av); +??????? super("Unknown annotation value: \"" + av + "\""); ???????? this.av = av; ???????? this.parameter = p; ???? } --- old/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java 2019-09-04 15:19:09.005963468 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java 2019-09-04 15:19:08.837963468 -0700 @@ -58,7 +58,7 @@ ????? * @param p an additional parameter, may be {@code null} ????? */ ???? public UnknownElementException(Element e, Object p) { -??????? super("Unknown element: " + e); +??????? super("Unknown element: \"" + e + "\""); ???????? element = e; ???????? this.parameter = p; ???? } --- old/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java 2019-09-04 15:19:09.509963468 -0700 +++ new/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java 2019-09-04 15:19:09.305963468 -0700 @@ -58,7 +58,7 @@ ????? * @param p an additional parameter, may be {@code null} ????? */ ???? public UnknownTypeException(TypeMirror t, Object p) { -??????? super("Unknown type: " + t); +??????? super("Unknown type: \"" + t + "\""); ???????? type = t; ???????? this.parameter = p; ???? } On 9/4/2019 3:04 PM, mark.reinhold at oracle.com wrote: > 2019/9/4 14:19:00 -0700, joe.darcy at oracle.com: >> Responding to some off-list input from Jon, please review the small >> enhancement for >> >> JDK-8230626: Make UnknownFooException strings more informative >> http://cr.openjdk.java.net/~darcy/8230626.0/ >> >> Patch below; thanks, >> ... >> - super("Unknown annotation value: " + av); >> + super("Unknown annotation value: ``" + av + "''"); > The use of GNU-style ``fake curly quotes'' in JDK messages is extremely > rare, and jarring to the eye in most typefaces. Pairs of backticks and > apostrophes are a poorer subsitute for ?true curly quotes? than simple > "vertical quotation marks." Please use vertical quotation marks, which > is what we use pretty much everywhere. > > - Mark From jonathan.gibbons at oracle.com Wed Sep 4 22:22:46 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 4 Sep 2019 15:22:46 -0700 Subject: JDK 14 RFR of JDK-8230626: Make UnknownFooException strings more informative In-Reply-To: References: <694d262f-ce05-86c4-6b73-2247ca8ac107@oracle.com> <20190904150414.953803677@eggemoggin.niobe.net> Message-ID: <744b3611-2865-d983-e8bf-4504de04c4e0@oracle.com> +1 -- Jon On 9/4/19 3:20 PM, Joe Darcy wrote: > Updated webrev with patch below: > > ??? http://cr.openjdk.java.net/~darcy/8230626.1/ > > -Joe > > --- > old/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java > 2019-09-04 15:19:08.561963468 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java > 2019-09-04 15:19:08.385963468 -0700 > @@ -60,7 +60,7 @@ > ????? * @param p an additional parameter, may be {@code null} > ????? */ > ???? public UnknownAnnotationValueException(AnnotationValue av, Object > p) { > -??????? super("Unknown annotation value: " + av); > +??????? super("Unknown annotation value: \"" + av + "\""); > ???????? this.av = av; > ???????? this.parameter = p; > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java > 2019-09-04 15:19:09.005963468 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java > 2019-09-04 15:19:08.837963468 -0700 > @@ -58,7 +58,7 @@ > ????? * @param p an additional parameter, may be {@code null} > ????? */ > ???? public UnknownElementException(Element e, Object p) { > -??????? super("Unknown element: " + e); > +??????? super("Unknown element: \"" + e + "\""); > ???????? element = e; > ???????? this.parameter = p; > ???? } > --- > old/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java > 2019-09-04 15:19:09.509963468 -0700 > +++ > new/src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java > 2019-09-04 15:19:09.305963468 -0700 > @@ -58,7 +58,7 @@ > ????? * @param p an additional parameter, may be {@code null} > ????? */ > ???? public UnknownTypeException(TypeMirror t, Object p) { > -??????? super("Unknown type: " + t); > +??????? super("Unknown type: \"" + t + "\""); > ???????? type = t; > ???????? this.parameter = p; > ???? } > > On 9/4/2019 3:04 PM, mark.reinhold at oracle.com wrote: >> 2019/9/4 14:19:00 -0700, joe.darcy at oracle.com: >>> Responding to some off-list input from Jon, please review the small >>> enhancement for >>> >>> ?? JDK-8230626: Make UnknownFooException strings more informative >>> ?? http://cr.openjdk.java.net/~darcy/8230626.0/ >>> >>> Patch below; thanks, >>> ... >>> - super("Unknown annotation value: " + av); >>> + super("Unknown annotation value: ``" + av + "''"); >> The use of GNU-style ``fake curly quotes'' in JDK messages is extremely >> rare, and jarring to the eye in most typefaces.? Pairs of backticks and >> apostrophes are a poorer subsitute for ?true curly quotes? than simple >> "vertical quotation marks."? Please use vertical quotation marks, which >> is what we use pretty much everywhere. >> >> - Mark From vicente.romero at oracle.com Thu Sep 5 15:57:18 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Sep 2019 11:57:18 -0400 Subject: JDK-8208664: JDK8,JDK9-breakpoint on a continue doesnt work on jdb and intellij In-Reply-To: References: Message-ID: Hi Jan, The fix in the compiler looks good to me, although I'm not sure either what option should we expose this code with. Regarding the test, probably I'm missing something but I was expecting a simpler test generating a class file and then checking if the LNT was as expected. Thanks, Vicente On 9/4/19 9:47 AM, Jan Lahoda wrote: > Hi, > > There is a small issue in some cases when trying to put breakpoints on > break/continue (or stepping through code that has break/continue). > Consider this code: > --- > ?? static void test(boolean a, boolean b) { > ?????? for (int i = 0; i < 10; i++) { > ?????????? if (a || b) { > ?????????????? continue; //set breakpoint here > ?????????? } > ?????????? System.out.println(); > ?????? } > ?? } > --- > > This gets compiled into: > --- > ???????? 0: iconst_0 > ???????? 1: istore_2 > ???????? 2: iload_2 > ???????? 3: bipush??????? 10 > ???????? 5: if_icmpge???? 28 > ???????? 8: iload_0 > ???????? 9: ifne????????? 22 > ??????? 12: iload_1 > ??????? 13: ifeq????????? 19 > ??????? 16: goto????????? 22 > ??????? 19: invokestatic? #3????????????????? // Method nop:()V > ??????? 22: iinc????????? 2, 1 > ??????? 25: goto????????? 2 > ??????? 28: return > --- > > > The instruction that corresponds to the "continue" is the "goto" on > bytecode index 16. But, if "a" is true, that instruction is never > executed, because the test on bytecode index 9 will jump directly to > the "continue" target. We cannot generate LineNumberTable saying that > bytecode index 9 corresponds to the "continue", as it really belongs > to the if, and debuggers would in some cases stop on the wrong line > instead of stopping on the continue. So, the issue is that if "a" is > true, then there is never a real instruction executed that corresponds > to the "continue". What we can do is to change the target if the > "ifne" on bytecode index 9 to "16", so that the goto is always > executed, and everything would work OK in debuggers, except that one > additional jump is performed (and, in some rarer cases, generated, as > the actual "goto" can sometimes be skipped). > > I tried to compile the JDK with and without the proposed patch, and > about 1100 out of 31000 classfiles are changed, so this affects > roughly 3.5% of the JDK classfiles. > > The proposed patch is only enabling this behavior when LineNumberTable > is being generated, but that is fairly common, and so it is not a big > help. One of the alternatives would be to require a special "-g" flag, > like "-g:debuglines". > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208664 > Webrev: http://cr.openjdk.java.net/~jlahoda/8208664/webrev.00/ > > Any opinions? > > Thanks! > > Jan From jan.lahoda at oracle.com Thu Sep 5 17:19:34 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 5 Sep 2019 19:19:34 +0200 Subject: JDK-8208664: JDK8,JDK9-breakpoint on a continue doesnt work on jdb and intellij In-Reply-To: References: Message-ID: On 05. 09. 19 17:57, Vicente Romero wrote: > Hi Jan, > > The fix in the compiler looks good to me, although I'm not sure either > what option should we expose this code with. Regarding the test, > probably I'm missing something but I was expecting a simpler test > generating a class file and then checking if the LNT was as expected. I was thinking of writing such a test (and maybe I still should add it), but it felt insufficient. We have many tests that verify the bytecode we generate by actually running the class (rather than checking specific bytecodes generated). And this test is intended to be similar: it actually runs the class under a debugger (jdb), sets a breakpoint, and observes whether it stops appropriately. Jan > > Thanks, > Vicente > > On 9/4/19 9:47 AM, Jan Lahoda wrote: >> Hi, >> >> There is a small issue in some cases when trying to put breakpoints on >> break/continue (or stepping through code that has break/continue). >> Consider this code: >> --- >> ?? static void test(boolean a, boolean b) { >> ?????? for (int i = 0; i < 10; i++) { >> ?????????? if (a || b) { >> ?????????????? continue; //set breakpoint here >> ?????????? } >> ?????????? System.out.println(); >> ?????? } >> ?? } >> --- >> >> This gets compiled into: >> --- >> ???????? 0: iconst_0 >> ???????? 1: istore_2 >> ???????? 2: iload_2 >> ???????? 3: bipush??????? 10 >> ???????? 5: if_icmpge???? 28 >> ???????? 8: iload_0 >> ???????? 9: ifne????????? 22 >> ??????? 12: iload_1 >> ??????? 13: ifeq????????? 19 >> ??????? 16: goto????????? 22 >> ??????? 19: invokestatic? #3????????????????? // Method nop:()V >> ??????? 22: iinc????????? 2, 1 >> ??????? 25: goto????????? 2 >> ??????? 28: return >> --- >> >> >> The instruction that corresponds to the "continue" is the "goto" on >> bytecode index 16. But, if "a" is true, that instruction is never >> executed, because the test on bytecode index 9 will jump directly to >> the "continue" target. We cannot generate LineNumberTable saying that >> bytecode index 9 corresponds to the "continue", as it really belongs >> to the if, and debuggers would in some cases stop on the wrong line >> instead of stopping on the continue. So, the issue is that if "a" is >> true, then there is never a real instruction executed that corresponds >> to the "continue". What we can do is to change the target if the >> "ifne" on bytecode index 9 to "16", so that the goto is always >> executed, and everything would work OK in debuggers, except that one >> additional jump is performed (and, in some rarer cases, generated, as >> the actual "goto" can sometimes be skipped). >> >> I tried to compile the JDK with and without the proposed patch, and >> about 1100 out of 31000 classfiles are changed, so this affects >> roughly 3.5% of the JDK classfiles. >> >> The proposed patch is only enabling this behavior when LineNumberTable >> is being generated, but that is fairly common, and so it is not a big >> help. One of the alternatives would be to require a special "-g" flag, >> like "-g:debuglines". >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208664 >> Webrev: http://cr.openjdk.java.net/~jlahoda/8208664/webrev.00/ >> >> Any opinions? >> >> Thanks! >> >> Jan > From vicente.romero at oracle.com Thu Sep 5 18:42:26 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Sep 2019 14:42:26 -0400 Subject: JDK-8208664: JDK8,JDK9-breakpoint on a continue doesnt work on jdb and intellij In-Reply-To: References: Message-ID: On 9/5/19 1:19 PM, Jan Lahoda wrote: > On 05. 09. 19 17:57, Vicente Romero wrote: >> Hi Jan, >> >> The fix in the compiler looks good to me, although I'm not sure >> either what option should we expose this code with. Regarding the >> test, probably I'm missing something but I was expecting a simpler >> test generating a class file and then checking if the LNT was as >> expected. > > I was thinking of writing such a test (and maybe I still should add > it), but it felt insufficient. We have many tests that verify the > bytecode we generate by actually running the class (rather than > checking specific bytecodes generated). And this test is intended to > be similar: it actually runs the class under a debugger (jdb), sets a > breakpoint, and observes whether it stops appropriately. right the test you wrote is great, but IMO it is more than needed in this case, it is complex, so maintaining it in the future could be more costly and also adds a dependency with an external tool which can change independently to javac. > > Jan Vicente > >> >> Thanks, >> Vicente >> >> On 9/4/19 9:47 AM, Jan Lahoda wrote: >>> Hi, >>> >>> There is a small issue in some cases when trying to put breakpoints >>> on break/continue (or stepping through code that has >>> break/continue). Consider this code: >>> --- >>> ?? static void test(boolean a, boolean b) { >>> ?????? for (int i = 0; i < 10; i++) { >>> ?????????? if (a || b) { >>> ?????????????? continue; //set breakpoint here >>> ?????????? } >>> ?????????? System.out.println(); >>> ?????? } >>> ?? } >>> --- >>> >>> This gets compiled into: >>> --- >>> ???????? 0: iconst_0 >>> ???????? 1: istore_2 >>> ???????? 2: iload_2 >>> ???????? 3: bipush??????? 10 >>> ???????? 5: if_icmpge???? 28 >>> ???????? 8: iload_0 >>> ???????? 9: ifne????????? 22 >>> ??????? 12: iload_1 >>> ??????? 13: ifeq????????? 19 >>> ??????? 16: goto????????? 22 >>> ??????? 19: invokestatic? #3????????????????? // Method nop:()V >>> ??????? 22: iinc????????? 2, 1 >>> ??????? 25: goto????????? 2 >>> ??????? 28: return >>> --- >>> >>> >>> The instruction that corresponds to the "continue" is the "goto" on >>> bytecode index 16. But, if "a" is true, that instruction is never >>> executed, because the test on bytecode index 9 will jump directly to >>> the "continue" target. We cannot generate LineNumberTable saying >>> that bytecode index 9 corresponds to the "continue", as it really >>> belongs to the if, and debuggers would in some cases stop on the >>> wrong line instead of stopping on the continue. So, the issue is >>> that if "a" is true, then there is never a real instruction executed >>> that corresponds to the "continue". What we can do is to change the >>> target if the "ifne" on bytecode index 9 to "16", so that the goto >>> is always executed, and everything would work OK in debuggers, >>> except that one additional jump is performed (and, in some rarer >>> cases, generated, as the actual "goto" can sometimes be skipped). >>> >>> I tried to compile the JDK with and without the proposed patch, and >>> about 1100 out of 31000 classfiles are changed, so this affects >>> roughly 3.5% of the JDK classfiles. >>> >>> The proposed patch is only enabling this behavior when >>> LineNumberTable is being generated, but that is fairly common, and >>> so it is not a big help. One of the alternatives would be to require >>> a special "-g" flag, like "-g:debuglines". >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208664 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8208664/webrev.00/ >>> >>> Any opinions? >>> >>> Thanks! >>> >>> Jan >> From vicente.romero at oracle.com Thu Sep 5 18:52:09 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Sep 2019 14:52:09 -0400 Subject: RFR: JDK-8228460: bootstrap class path not set in conjunction with -source 11 In-Reply-To: <61ea1a9f-8edb-6187-c310-06f0cbaa206b@oracle.com> References: <61ea1a9f-8edb-6187-c310-06f0cbaa206b@oracle.com> Message-ID: <046fa58c-3f77-ba16-678f-8af312b31926@oracle.com> looks good, Vicente On 9/3/19 7:51 AM, Jan Lahoda wrote: > Hi, > > When running with --source which is less than the current default > source and -bootclasspath is not specified, a warning about not > specified -bootclasspath is printed. But that is not really > appropriate for -source 9+, because it should a) mention system module > path, rather than -bootclasspath; b) the option to check should be > --system, not -bootclasspath. The proposed patch is trying to fix that. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228460 > Webrev: http://cr.openjdk.java.net/~jlahoda/8228460/webrev.00/ > > How does this look? > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Fri Sep 6 10:44:34 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Sep 2019 11:44:34 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: <16c4bb5f-3d63-d92b-07b8-8a093b151d5b@oracle.com> References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> <5b523e4f-9a42-6010-9211-a1e99460890b@oracle.com> <16c4bb5f-3d63-d92b-07b8-8a093b151d5b@oracle.com> Message-ID: <8760c22e-4669-7d3f-23d6-8f8f8c732f75@oracle.com> For the records, I did some internal performance tests, and this patch doesn't seem to make the performance situation worse in the general case. I'm now curious to see if it helps with your specific use case. Maurizio On 04/09/2019 20:58, Maurizio Cimadamore wrote: > > Hi Ron, > I put together something, albeit not the approach I described in this > thread. > > Since, from what I'm reading, the main issue you are seeing is that > the use of Types.closure is basically killing performances, I > addressed that problem instead, and rewrote the code not to use that > method. The new code is probably executing more checks than the old > (since interfaces could be implemented multiple times at different > levels of the hierarchy), but I think it should be enough to resolve > the issue you are seeing. > > I did not spend a lot of time testing the patch, other than doing some > basic validation - so handle with care :-) > > http://cr.openjdk.java.net/~mcimadamore/8228675/ > > Maurizio > > On 04/09/2019 15:18, Maurizio Cimadamore wrote: >> >> I didn't realize you were waiting on me to produce a patch; I'm >> afraid at the moment I don't have many cycles to look into this. >> >> Maurizio >> >> On 04/09/2019 13:05, Ron Shapiro wrote: >>> Friendly ping. This is really hurting some of our builds. Maurizio, >>> are you able to prepare a patch for us to look at? >>> >>> On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro >> > wrote: >>> >>> Aren't types recreated across rounds if there are any transitive >>> error types? That was at least my assumption. >>> >>> On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda >>> > wrote: >>> >>> I wonder if this will work with annotation processors? (As >>> these may >>> create new interfaces into the hierarchy.) >>> >>> Jan >>> >>> On 07. 08. 19 12:25, Ron Shapiro wrote: >>> > Made the change for a WeakHashMap: >>> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >>> > >>> > Perhaps it would make better sense for this to be a field >>> on ClassType? >>> > That would avoid the need for managing a cache with weak keys. >>> > >>> > Do you have any guidance on how you approach tradeoffs in >>> memory vs. speed? >>> > >>> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero >>> >>> > >> >> wrote: >>> > >>> >? ? ?not sure if we should add yet another cache to javac >>> but in any case >>> >? ? ?it should be implemented with a: WeakHashMap, >>> > >>> >? ? ?Thanks, >>> >? ? ?Vicente >>> > >>> >? ? ?On 8/5/19 10:32 AM, Ron Shapiro wrote: >>> >>? ? ?Fair question. >>> >> >>> >> github.com/google/dagger >>> >>> >>> >>? ? ?generates implementations of interfaces that implement a >>> >>? ? ?dependency injection graph. Sometimes, though not >>> always, these >>> >>? ? ?interfaces have dozens if not hundreds of >>> (super)interfaces which >>> >>? ? ?allow for builds to be sharded: each subsection of >>> the build >>> >>? ? ?refers to the superinterface and then at the root of >>> the build >>> >>? ? ?there is a union of them all. Naturally, this means >>> this must be >>> >>? ? ?rebuilt on most/all changes to any subproject of the >>> build. >>> >> >>> >>? ? ??????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >>> >>? ? ??>> >>> >> >>: >>> >> >>> >>? ? ? ? ?Hi Ron, >>> >> >>> >>? ? ? ? ?Just out of curiosity, what is the context in >>> which this issue >>> >>? ? ? ? ?arises? Naturally consuming more memory we can >>> speed up javac >>> >>? ? ? ? ?but this can lead to other problems too. >>> >> >>> >>? ? ? ? ?Thanks, >>> >>? ? ? ? ?Vicente >>> >> >>> >>? ? ? ? ?On 8/5/19 8:24 AM, Ron Shapiro wrote: >>> >>>? ? ? ? ?Friendly ping >>> >>> >>> >>>? ? ? ? ??????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >>> >>>? ? ? ? ??>> >> >>: >>> >>> >>> >>>? ? ? ? ? ? ?Hi, >>> >>> >>> >>>? ? ? ? ? ? ?Please review this change to speed up >>> Resolve.findMethod >>> >>>? ? ? ? ? ? ?for large classes that have large numbers of >>> >>>? ? ? ? ? ? ?(super)interfaces >>> >>> >>> >>>? ? ? ? ? ? ?webrev: >>> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>> >>>? ? ? ? ? ? ?bug: >>> https://bugs.openjdk.java.net/browse/JDK-8228675 >>> >>> >>> >>>? ? ? ? ? ? ?Thanks, >>> >>>? ? ? ? ? ? ?Ron >>> >>> >>> >> >>> > >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Sep 6 11:07:06 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Sep 2019 12:07:06 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: <8760c22e-4669-7d3f-23d6-8f8f8c732f75@oracle.com> References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> <5b523e4f-9a42-6010-9211-a1e99460890b@oracle.com> <16c4bb5f-3d63-d92b-07b8-8a093b151d5b@oracle.com> <8760c22e-4669-7d3f-23d6-8f8f8c732f75@oracle.com> Message-ID: On 06/09/2019 11:44, Maurizio Cimadamore wrote: > > For the records, I did some internal performance tests, and this patch > doesn't seem to make the performance situation worse in the general case. > > I'm now curious to see if it helps with your specific use case. > More generally speaking, for this - and others - performance related issues, we're happy to look into them, but I think it is generally good to submit a reproducible test case that we can use as a playground; this will help us understanding what the problem is, understanding what are the connections to other problems in the code base, as well as to assess its priority. Such a test case would also form the backbone of any test that would be pushed upstream (as it is generally preferrable to always include tests in patches). I know that sometimes distilling such tests takes time, but without them we're basically throwing darts in the dark. Maurizio > Maurizio > > On 04/09/2019 20:58, Maurizio Cimadamore wrote: >> >> Hi Ron, >> I put together something, albeit not the approach I described in this >> thread. >> >> Since, from what I'm reading, the main issue you are seeing is that >> the use of Types.closure is basically killing performances, I >> addressed that problem instead, and rewrote the code not to use that >> method. The new code is probably executing more checks than the old >> (since interfaces could be implemented multiple times at different >> levels of the hierarchy), but I think it should be enough to resolve >> the issue you are seeing. >> >> I did not spend a lot of time testing the patch, other than doing >> some basic validation - so handle with care :-) >> >> http://cr.openjdk.java.net/~mcimadamore/8228675/ >> >> Maurizio >> >> On 04/09/2019 15:18, Maurizio Cimadamore wrote: >>> >>> I didn't realize you were waiting on me to produce a patch; I'm >>> afraid at the moment I don't have many cycles to look into this. >>> >>> Maurizio >>> >>> On 04/09/2019 13:05, Ron Shapiro wrote: >>>> Friendly ping. This is really hurting some of our builds. Maurizio, >>>> are you able to prepare a patch for us to look at? >>>> >>>> On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro >>> > wrote: >>>> >>>> Aren't types recreated across rounds if there are any >>>> transitive error types? That was at least my assumption. >>>> >>>> On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda >>>> > wrote: >>>> >>>> I wonder if this will work with annotation processors? (As >>>> these may >>>> create new interfaces into the hierarchy.) >>>> >>>> Jan >>>> >>>> On 07. 08. 19 12:25, Ron Shapiro wrote: >>>> > Made the change for a WeakHashMap: >>>> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >>>> > >>>> > Perhaps it would make better sense for this to be a field >>>> on ClassType? >>>> > That would avoid the need for managing a cache with weak >>>> keys. >>>> > >>>> > Do you have any guidance on how you approach tradeoffs in >>>> memory vs. speed? >>>> > >>>> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero >>>> >>>> > >>> >> wrote: >>>> > >>>> >? ? ?not sure if we should add yet another cache to javac >>>> but in any case >>>> >? ? ?it should be implemented with a: WeakHashMap, >>>> > >>>> >? ? ?Thanks, >>>> >? ? ?Vicente >>>> > >>>> >? ? ?On 8/5/19 10:32 AM, Ron Shapiro wrote: >>>> >>? ? ?Fair question. >>>> >> >>>> >> github.com/google/dagger >>>> >>>> >>>> >>? ? ?generates implementations of interfaces that implement a >>>> >>? ? ?dependency injection graph. Sometimes, though not >>>> always, these >>>> >>? ? ?interfaces have dozens if not hundreds of >>>> (super)interfaces which >>>> >>? ? ?allow for builds to be sharded: each subsection of >>>> the build >>>> >>? ? ?refers to the superinterface and then at the root of >>>> the build >>>> >>? ? ?there is a union of them all. Naturally, this means >>>> this must be >>>> >>? ? ?rebuilt on most/all changes to any subproject of the >>>> build. >>>> >> >>>> >>? ? ??????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >>>> >>? ? ??>>> >>>> >>> >>: >>>> >> >>>> >>? ? ? ? ?Hi Ron, >>>> >> >>>> >>? ? ? ? ?Just out of curiosity, what is the context in >>>> which this issue >>>> >>? ? ? ? ?arises? Naturally consuming more memory we can >>>> speed up javac >>>> >>? ? ? ? ?but this can lead to other problems too. >>>> >> >>>> >>? ? ? ? ?Thanks, >>>> >>? ? ? ? ?Vicente >>>> >> >>>> >>? ? ? ? ?On 8/5/19 8:24 AM, Ron Shapiro wrote: >>>> >>>? ? ? ? ?Friendly ping >>>> >>> >>>> >>>? ? ? ? ??????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >>>> >>>? ? ? ? ??>>> >>>> >>: >>>> >>> >>>> >>>? ? ? ? ? ? ?Hi, >>>> >>> >>>> >>>? ? ? ? ? ? ?Please review this change to speed up >>>> Resolve.findMethod >>>> >>>? ? ? ? ? ? ?for large classes that have large numbers of >>>> >>>? ? ? ? ? ? ?(super)interfaces >>>> >>> >>>> >>>? ? ? ? ? ? ?webrev: >>>> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>>> >>>? ? ? ? ? ? ?bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8228675 >>>> >>> >>>> >>>? ? ? ? ? ? ?Thanks, >>>> >>>? ? ? ? ? ? ?Ron >>>> >>> >>>> >> >>>> > >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Sep 9 03:06:16 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 8 Sep 2019 20:06:16 -0700 Subject: JDK 14 RFR of 8230734: Remove default constructors from java.compiler Message-ID: <391433d6-1d35-0825-acf8-9498b00f2392@oracle.com> Hello, Please review the removal of two default constructors from java.compiler: ??? 8230734: Remove default constructors from java.compiler ??? webrev: http://cr.openjdk.java.net/~darcy/8230734.0/ ??? CSR:https://bugs.openjdk.java.net/browse/JDK-8230739 Patch below. One constructor is deprecated for removal since the class otherwise only has static members. Note that including this change will require an MR for JSR 199. Thanks, -Joe --- old/src/java.compiler/share/classes/javax/tools/DiagnosticCollector.java 2019-09-08 19:55:24.828001000 -0700 +++ new/src/java.compiler/share/classes/javax/tools/DiagnosticCollector.java 2019-09-08 19:55:24.688001000 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2006, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -43,6 +43,11 @@ ???? private List> diagnostics = ???????????? Collections.synchronizedList(new ArrayList>()); +??? /** +???? * Creates a new instance of DiagnosticCollector. +???? */ +??? public DiagnosticCollector() {} + ???? public void report(Diagnostic diagnostic) { ???????? Objects.requireNonNull(diagnostic); ???????? diagnostics.add(diagnostic); --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java 2019-09-08 19:55:25.164001000 -0700 +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java 2019-09-08 19:55:25.032001000 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -45,6 +45,12 @@ ???? private static final String systemJavaCompilerName?? = "com.sun.tools.javac.api.JavacTool"; ???? /** +???? * Do not call. +???? */ +??? @Deprecated(forRemoval=true, since="14") +??? public ToolProvider() {} + +??? /** ????? * Returns the Java™ programming language compiler provided ????? * with this platform. ????? *

The file manager returned by calling From jonathan.gibbons at oracle.com Wed Sep 11 15:46:55 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Sep 2019 08:46:55 -0700 Subject: JDK 14 RFR of 8230734: Remove default constructors from java.compiler In-Reply-To: <391433d6-1d35-0825-acf8-9498b00f2392@oracle.com> References: <391433d6-1d35-0825-acf8-9498b00f2392@oracle.com> Message-ID: Joe, OK, but note possible inconsistent indentation in one of the comments. Since you're deprecating one constructor for removal, does that need a CSR? -- Jon On 9/8/19 8:06 PM, Joe Darcy wrote: > Hello, > > Please review the removal of two default constructors from java.compiler: > > ??? 8230734: Remove default constructors from java.compiler > ??? webrev: http://cr.openjdk.java.net/~darcy/8230734.0/ > ??? CSR:https://bugs.openjdk.java.net/browse/JDK-8230739 > > Patch below. One constructor is deprecated for removal since the class > otherwise only has static members. > > Note that including this change will require an MR for JSR 199. > > Thanks, > > -Joe > > --- > old/src/java.compiler/share/classes/javax/tools/DiagnosticCollector.java > 2019-09-08 19:55:24.828001000 -0700 > +++ > new/src/java.compiler/share/classes/javax/tools/DiagnosticCollector.java > 2019-09-08 19:55:24.688001000 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2006, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -43,6 +43,11 @@ > ???? private List> diagnostics = > ???????????? Collections.synchronizedList(new ArrayList extends S>>()); > > +??? /** > +???? * Creates a new instance of DiagnosticCollector. > +???? */ > +??? public DiagnosticCollector() {} > + > ???? public void report(Diagnostic diagnostic) { > ???????? Objects.requireNonNull(diagnostic); > ???????? diagnostics.add(diagnostic); > --- old/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2019-09-08 19:55:25.164001000 -0700 > +++ new/src/java.compiler/share/classes/javax/tools/ToolProvider.java > 2019-09-08 19:55:25.032001000 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -45,6 +45,12 @@ > ???? private static final String systemJavaCompilerName?? = > "com.sun.tools.javac.api.JavacTool"; > > ???? /** > +???? * Do not call. > +???? */ > +??? @Deprecated(forRemoval=true, since="14") > +??? public ToolProvider() {} > + > +??? /** > ????? * Returns the Java™ programming language compiler provided > ????? * with this platform. > ????? *

The file manager returned by calling > From jan.lahoda at oracle.com Thu Sep 12 09:30:19 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 12 Sep 2019 11:30:19 +0200 Subject: RFR: JDK-8230847: Trees.getScope may crash when invoked for statement inside switch. Message-ID: Hi, There are some cases where the Trees.getScope may misbehave: -consider code like this: switch (i) { case 0: String.valueOf(0); //calling getScope on this place int i; break; } javac will create a copy the tree, attribute it, and stop the attribution at the specified place by throwing BreakAttr. But in the case above, Attr.handleSwitch will invoke Attr.addVars (in a finally), which will try to add the "int i;"'s symbol into a Scope, which fails, as that variable is not attributed. The proposed solution is to simply not call addVars if an exception is thrown, by moving the call out of the current finally block. -the attribution when a scope is being computed is not running with a ArgumentAttr.withLocalCacheContext(), which may lead to the cache pollution, and trouble for further getScope (or other attribution) invocations (see the testMemberRefs() test). The proposal is to run with the withLocalCacheContext(), but as a more general approach, I tried to reuse as much as possible from the speculative attribution for Scope computation, as was proposed some time back. -there is a corner case, where if the BreakAttr is thrown while attribution an annotation's type, Annotate.flush() may not finish, and there may be remaining tasks in the Annotate queues, which may fail on subsequent flushes (possibly due to subsequent invocations of getScope()). The proposed solution here is to save and restore the queues for the isolated/speculative attributions. In the current patch, this is being done for all speculative attributions, but if that would be too dangerous, we could move that to getScope computation only. (See tests testAnnotations() and testAnnotationsLazy().) -there is a corner case, where calling getScope inside an initializer of a class that depends on itself (i.e. has a cyclic dependency) may crash, as the initializer is not properly recognized as an initializer. The proposed solution is to recognize initializers in erroneous classes as intializers. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8230847/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8230847 How does this look? Thanks, Jan From joe.darcy at oracle.com Sat Sep 14 20:09:07 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 14 Sep 2019 13:09:07 -0700 Subject: JDK 14 RFR of JDK-8230882: Use @index in javax.lang.model javadoc Message-ID: <2e017cda-54bc-90f9-2dfd-6437b996e51c@oracle.com> Hello, Please review the simple doc improvement for the javax.lang.model package javadoc: ??? JDK-8230882: Use @index in javax.lang.model javadoc Patch below; thanks, -Joe diff -r 88bbe06ab8d6 src/java.compiler/share/classes/javax/lang/model/package-info.java --- a/src/java.compiler/share/classes/javax/lang/model/package-info.java Fri Sep 13 09:33:54 2019 -0700 +++ b/src/java.compiler/share/classes/javax/lang/model/package-info.java Sat Sep 14 13:06:20 2019 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -24,7 +24,8 @@ ? */ ?/** - * Classes and hierarchies of packages used to model the Java + * Types and hierarchies of packages comprising a {@index "Java language + * model"}, a model of the declarations and types of the Java ? * programming language. ? * ? * The members of this package and its subpackages are for use in @@ -41,14 +42,14 @@ ? * Languages and Applications, October 2004. ? * ? * - * In particular, the model makes a distinction between static + * In particular, the model makes a distinction between declared ? * language constructs, like the {@linkplain javax.lang.model.element ? * element} representing {@code java.util.Set}, and the family of ? * {@linkplain javax.lang.model.type types} that may be associated ? * with an element, like the raw type {@code java.util.Set}, {@code ? * java.util.Set}, and {@code java.util.Set}. ? * - *

Unless otherwise specified, methods in this package will throw + *

Unless otherwise specified, methods in this package will throw ? * a {@code NullPointerException} if given a {@code null} argument. ? * ? * @author Joseph D. Darcy From jonathan.gibbons at oracle.com Sun Sep 15 04:31:36 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 14 Sep 2019 21:31:36 -0700 Subject: JDK 14 RFR of JDK-8230882: Use @index in javax.lang.model javadoc In-Reply-To: <2e017cda-54bc-90f9-2dfd-6437b996e51c@oracle.com> References: <2e017cda-54bc-90f9-2dfd-6437b996e51c@oracle.com> Message-ID: +1 On 9/14/19 1:09 PM, Joe Darcy wrote: > Hello, > > Please review the simple doc improvement for the javax.lang.model > package javadoc: > > ??? JDK-8230882: Use @index in javax.lang.model javadoc > > Patch below; thanks, > > -Joe > > diff -r 88bbe06ab8d6 > src/java.compiler/share/classes/javax/lang/model/package-info.java > --- > a/src/java.compiler/share/classes/javax/lang/model/package-info.java > Fri Sep 13 09:33:54 2019 -0700 > +++ > b/src/java.compiler/share/classes/javax/lang/model/package-info.java > Sat Sep 14 13:06:20 2019 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2005, 2006, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -24,7 +24,8 @@ > ? */ > > ?/** > - * Classes and hierarchies of packages used to model the Java > + * Types and hierarchies of packages comprising a {@index "Java language > + * model"}, a model of the declarations and types of the Java > ? * programming language. > ? * > ? * The members of this package and its subpackages are for use in > @@ -41,14 +42,14 @@ > ? * Languages and Applications, October 2004. > ? * > ? * > - * In particular, the model makes a distinction between static > + * In particular, the model makes a distinction between declared > ? * language constructs, like the {@linkplain javax.lang.model.element > ? * element} representing {@code java.util.Set}, and the family of > ? * {@linkplain javax.lang.model.type types} that may be associated > ? * with an element, like the raw type {@code java.util.Set}, {@code > ? * java.util.Set}, and {@code java.util.Set}. > ? * > - *

Unless otherwise specified, methods in this package will throw > + *

Unless otherwise specified, methods in this package will throw > ? * a {@code NullPointerException} if given a {@code null} argument. > ? * > ? * @author Joseph D. Darcy > From jan.lahoda at oracle.com Wed Sep 18 07:38:26 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Sep 2019 09:38:26 +0200 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> Message-ID: <591e776d-9d9e-261e-9202-ffff4d4e0844@oracle.com> I've added logging to count how many Entries are created, and there's a little above 500000 instances created for java.base and a little less for java.desktop. So if the Entry would be 8 bytes bigger, it would be about 4MB, which does not sound terrible. So maybe we should go with version .00. Jan On 18. 09. 19 3:10, Brad Corso wrote: > Hi Jan, are you okay moving forward with > http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/? > > On Wed, Sep 4, 2019 at 5:15 AM Ron Shapiro > wrote: > > Here's the updated webrev that Brad mentioned in his last message: > http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/ > > On Wed, Aug 28, 2019 at 2:40 AM Brad Corso > wrote: > > I believe "Do you have any estimates of the increase in size > in typical > usage, due to the extra field in Scope?" (Jon) > > I was seeing noticeably bad performance once the size of the > Entry.sibling linked list reached ~10000, and the max I saw was > ~30000 in a single scope. Given that an additional reference > adds 32/64b, this could add up to 120/240Kb for the cases I saw. > > I'd add, is there a chance to get an improvement in > Scope.remove speed > without making ScopeImpl.Entry bigger (assuming it gets > bigger(?))? One > possibility that occurred to me is that we could try not to > remove the > things from elems, but only mark them as removed. We would > need to do > filtering (and possibly the actual removal) while reading > from the Scope > (in getSymbols), so this is a different kind of trade-off. > > (Overall, I guess the question is whether we are trading > problems with > > Scope.remove speed in some cases for out-of-memory problems > in other cases.) > > Thanks, I've verified your suggestion also gives us the > performance improvements, so this change is okay with me. > > > > On Tue, Aug 27, 2019 at 12:05 AM Jan Lahoda > > wrote: > > On 27. 08. 19 0:06, Brad Corso wrote: > > Sorry, what's the question? > > I believe "Do you have any estimates of the increase in size > in typical > usage, due to the extra field in Scope?" (Jon) > > I'd add, is there a chance to get an improvement in > Scope.remove speed > without making ScopeImpl.Entry bigger (assuming it gets > bigger(?))? One > possibility that occurred to me is that we could try not to > remove the > things from elems, but only mark them as removed. We would > need to do > filtering (and possibly the actual removal) while reading > from the Scope > (in getSymbols), so this is a different kind of trade-off. > > (Overall, I guess the question is whether we are trading > problems with > Scope.remove speed in some cases for out-of-memory problems > in other cases.) > > Jan > > > > > On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro > > > >> wrote: > > > >? ? ?Adding Brad back in to the thread since he would know > best > > > >? ? ??????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan Gibbons > >? ? ?? > >>: > > > > > >? ? ? ? ?On 8/26/19 9:12 AM, Ron Shapiro wrote: > >? ? ? ? ? > > >? ? ? ? ? > Note that the patch was prepared by my > coworker, Brad (cc'd). > >? ? ? ? ?I wasn't > >? ? ? ? ? > sure what to do to make sure that he was > attributed correctly. > > > > > >? ? ? ? ?Mention this when you have a sponsor to push the > changeset, so > >? ? ? ? ?that it > >? ? ? ? ?can be marked with "Contributed-By:" > > > >? ? ? ? ?-- Jon > > > From jan.lahoda at oracle.com Wed Sep 18 11:33:45 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 18 Sep 2019 13:33:45 +0200 Subject: RFR: JDK-8231176: Test tools/javac/options/BCPOrSystemNotSpecified.java broken on Windows Message-ID: <0d02ca05-48bc-d73b-80fe-9e7ee16f5df5@oracle.com> Hi, The newly added tools/javac/options/BCPOrSystemNotSpecified.java test is failing on Windows, so tier 1 is failing. I'd like to temporarily problem list the test, so that it can be properly investigated: http://cr.openjdk.java.net/~jlahoda/8231176/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8231176 Does this look OK? Thanks, Jan From vicente.romero at oracle.com Wed Sep 18 13:11:21 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 18 Sep 2019 09:11:21 -0400 Subject: RFR: JDK-8231176: Test tools/javac/options/BCPOrSystemNotSpecified.java broken on Windows In-Reply-To: <0d02ca05-48bc-d73b-80fe-9e7ee16f5df5@oracle.com> References: <0d02ca05-48bc-d73b-80fe-9e7ee16f5df5@oracle.com> Message-ID: <1e933044-42f7-c888-6b5a-92f4edef4bee@oracle.com> looks good, Vicente On 9/18/19 7:33 AM, Jan Lahoda wrote: > Hi, > > The newly added tools/javac/options/BCPOrSystemNotSpecified.java test > is failing on Windows, so tier 1 is failing. I'd like to temporarily > problem list the test, so that it can be properly investigated: > http://cr.openjdk.java.net/~jlahoda/8231176/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8231176 > > Does this look OK? > > Thanks, > ??? Jan From maurizio.cimadamore at oracle.com Thu Sep 19 11:18:17 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 19 Sep 2019 12:18:17 +0100 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> <5b523e4f-9a42-6010-9211-a1e99460890b@oracle.com> <16c4bb5f-3d63-d92b-07b8-8a093b151d5b@oracle.com> <8760c22e-4669-7d3f-23d6-8f8f8c732f75@oracle.com> Message-ID: On 18/09/2019 02:06, Brad Corso wrote: > > This patch seems like a low-hanging fruit - union was already > returning element in that order in case they were unrelated, so I > agree the extra test looks redundant. > > Thanks for taking a look Maurizio. > > What's the best way to get this submitted? Should we file a separate > bug for the changes in > http://cr.openjdk.java.net/~ronsh/8228675/webrev.02/ > ? > I think that would be best, yes Maurizio > On Fri, Sep 6, 2019 at 4:08 AM Maurizio Cimadamore > > wrote: > > > On 06/09/2019 11:44, Maurizio Cimadamore wrote: >> >> For the records, I did some internal performance tests, and this >> patch doesn't seem to make the performance situation worse in the >> general case. >> >> I'm now curious to see if it helps with your specific use case. >> > More generally speaking, for this - and others - performance > related issues, we're happy to look into them, but I think it is > generally good to submit a reproducible test case that we can use > as a playground; this will help us understanding what the problem > is, understanding what are the connections to other problems in > the code base, as well as to assess its priority. Such a test case > would also form the backbone of any test that would be pushed > upstream (as it is generally preferrable to always include tests > in patches). I know that sometimes distilling such tests takes > time, but without them we're basically throwing darts in the dark. > > Maurizio > > >> Maurizio >> >> On 04/09/2019 20:58, Maurizio Cimadamore wrote: >>> >>> Hi Ron, >>> I put together something, albeit not the approach I described in >>> this thread. >>> >>> Since, from what I'm reading, the main issue you are seeing is >>> that the use of Types.closure is basically killing performances, >>> I addressed that problem instead, and rewrote the code not to >>> use that method. The new code is probably executing more checks >>> than the old (since interfaces could be implemented multiple >>> times at different levels of the hierarchy), but I think it >>> should be enough to resolve the issue you are seeing. >>> >>> I did not spend a lot of time testing the patch, other than >>> doing some basic validation - so handle with care :-) >>> >>> http://cr.openjdk.java.net/~mcimadamore/8228675/ >>> >>> Maurizio >>> >>> On 04/09/2019 15:18, Maurizio Cimadamore wrote: >>>> >>>> I didn't realize you were waiting on me to produce a patch; I'm >>>> afraid at the moment I don't have many cycles to look into this. >>>> >>>> Maurizio >>>> >>>> On 04/09/2019 13:05, Ron Shapiro wrote: >>>>> Friendly ping. This is really hurting some of our builds. >>>>> Maurizio, are you able to prepare a patch for us to look at? >>>>> >>>>> On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro >>>>> > wrote: >>>>> >>>>> Aren't types recreated across rounds if there are any >>>>> transitive error types? That was at least my assumption. >>>>> >>>>> On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda >>>>> > wrote: >>>>> >>>>> I wonder if this will work with annotation processors? >>>>> (As these may >>>>> create new interfaces into the hierarchy.) >>>>> >>>>> Jan >>>>> >>>>> On 07. 08. 19 12:25, Ron Shapiro wrote: >>>>> > Made the change for a WeakHashMap: >>>>> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >>>>> > >>>>> > Perhaps it would make better sense for this to be a >>>>> field on ClassType? >>>>> > That would avoid the need for managing a cache with >>>>> weak keys. >>>>> > >>>>> > Do you have any guidance on how you approach >>>>> tradeoffs in memory vs. speed? >>>>> > >>>>> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero >>>>> >>>> >>>>> > >>>> >> wrote: >>>>> > >>>>> >? ? ?not sure if we should add yet another cache to >>>>> javac but in any case >>>>> >? ? ?it should be implemented with a: WeakHashMap, >>>>> > >>>>> >? ? ?Thanks, >>>>> >? ? ?Vicente >>>>> > >>>>> >? ? ?On 8/5/19 10:32 AM, Ron Shapiro wrote: >>>>> >>? ? ?Fair question. >>>>> >> >>>>> >> github.com/google/dagger >>>>> >>>>> >>>>> >>? ? ?generates implementations of interfaces that >>>>> implement a >>>>> >>? ? ?dependency injection graph. Sometimes, though >>>>> not always, these >>>>> >>? ? ?interfaces have dozens if not hundreds of >>>>> (super)interfaces which >>>>> >>? ? ?allow for builds to be sharded: each subsection >>>>> of the build >>>>> >>? ? ?refers to the superinterface and then at the >>>>> root of the build >>>>> >>? ? ?there is a union of them all. Naturally, this >>>>> means this must be >>>>> >>? ? ?rebuilt on most/all changes to any subproject >>>>> of the build. >>>>> >> >>>>> >>? ? ??????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente >>>>> Romero >>>>> >>? ? ??>>>> >>>>> >>>> >>: >>>>> >> >>>>> >>? ? ? ? ?Hi Ron, >>>>> >> >>>>> >>? ? ? ? ?Just out of curiosity, what is the context >>>>> in which this issue >>>>> >>? ? ? ? ?arises? Naturally consuming more memory we >>>>> can speed up javac >>>>> >>? ? ? ? ?but this can lead to other problems too. >>>>> >> >>>>> >>? ? ? ? ?Thanks, >>>>> >>? ? ? ? ?Vicente >>>>> >> >>>>> >>? ? ? ? ?On 8/5/19 8:24 AM, Ron Shapiro wrote: >>>>> >>>? ? ? ? ?Friendly ping >>>>> >>> >>>>> >>>? ? ? ? ??????? ???, 27 ????? 2019, 0:05, ??? Ron >>>>> Shapiro >>>>> >>>? ? ? ? ??>>>> >>>>> >>>> >>: >>>>> >>> >>>>> >>>? ? ? ? ? ? ?Hi, >>>>> >>> >>>>> >>>? ? ? ? ? ? ?Please review this change to speed up >>>>> Resolve.findMethod >>>>> >>>? ? ? ? ? ? ?for large classes that have large >>>>> numbers of >>>>> >>>? ? ? ? ? ? ?(super)interfaces >>>>> >>> >>>>> >>>? ? ? ? ? ? ?webrev: >>>>> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>>>> >>>? ? ? ? ? ? ?bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8228675 >>>>> >>> >>>>> >>>? ? ? ? ? ? ?Thanks, >>>>> >>>? ? ? ? ? ? ?Ron >>>>> >>> >>>>> >> >>>>> > >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcorso at google.com Wed Sep 18 01:10:28 2019 From: bcorso at google.com (Brad Corso) Date: Tue, 17 Sep 2019 18:10:28 -0700 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> Message-ID: Hi Jan, are you okay moving forward with http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/? On Wed, Sep 4, 2019 at 5:15 AM Ron Shapiro wrote: > Here's the updated webrev that Brad mentioned in his last message: > http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/ > > On Wed, Aug 28, 2019 at 2:40 AM Brad Corso wrote: > >> I believe "Do you have any estimates of the increase in size in typical >>> usage, due to the extra field in Scope?" (Jon) >> >> >> I was seeing noticeably bad performance once the size of the >> Entry.sibling linked list reached ~10000, and the max I saw was ~30000 in a >> single scope. Given that an additional reference adds 32/64b, this could >> add up to 120/240Kb for the cases I saw. >> >> I'd add, is there a chance to get an improvement in Scope.remove speed >>> without making ScopeImpl.Entry bigger (assuming it gets bigger(?))? One >>> possibility that occurred to me is that we could try not to remove the >>> things from elems, but only mark them as removed. We would need to do >>> filtering (and possibly the actual removal) while reading from the Scope >>> (in getSymbols), so this is a different kind of trade-off. >> >> >> >> (Overall, I guess the question is whether we are trading problems with >>> >> Scope.remove speed in some cases for out-of-memory problems in other >>> cases.) >> >> >> Thanks, I've verified your suggestion also gives us the performance >> improvements, so this change is okay with me. >> >> >> >> >> On Tue, Aug 27, 2019 at 12:05 AM Jan Lahoda >> wrote: >> >>> On 27. 08. 19 0:06, Brad Corso wrote: >>> > Sorry, what's the question? >>> >>> I believe "Do you have any estimates of the increase in size in typical >>> usage, due to the extra field in Scope?" (Jon) >>> >>> I'd add, is there a chance to get an improvement in Scope.remove speed >>> without making ScopeImpl.Entry bigger (assuming it gets bigger(?))? One >>> possibility that occurred to me is that we could try not to remove the >>> things from elems, but only mark them as removed. We would need to do >>> filtering (and possibly the actual removal) while reading from the Scope >>> (in getSymbols), so this is a different kind of trade-off. >>> >>> (Overall, I guess the question is whether we are trading problems with >>> Scope.remove speed in some cases for out-of-memory problems in other >>> cases.) >>> >>> Jan >>> >>> > >>> > On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro >> > > wrote: >>> > >>> > Adding Brad back in to the thread since he would know best >>> > >>> > ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan Gibbons >>> > ?>> >>: >>> > >>> > >>> > On 8/26/19 9:12 AM, Ron Shapiro wrote: >>> > > >>> > > Note that the patch was prepared by my coworker, Brad >>> (cc'd). >>> > I wasn't >>> > > sure what to do to make sure that he was attributed >>> correctly. >>> > >>> > >>> > Mention this when you have a sponsor to push the changeset, so >>> > that it >>> > can be marked with "Contributed-By:" >>> > >>> > -- Jon >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcorso at google.com Wed Sep 18 16:55:00 2019 From: bcorso at google.com (Brad Corso) Date: Wed, 18 Sep 2019 09:55:00 -0700 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: <591e776d-9d9e-261e-9202-ffff4d4e0844@oracle.com> References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> <591e776d-9d9e-261e-9202-ffff4d4e0844@oracle.com> Message-ID: Hi Jan, I'm okay with either version so I'll leave that decision up to you. Let me know if there's anything else you need from me. Thanks! Brad On Wed, Sep 18, 2019 at 12:38 AM Jan Lahoda wrote: > I've added logging to count how many Entries are created, and there's a > little above 500000 instances created for java.base and a little less > for java.desktop. So if the Entry would be 8 bytes bigger, it would be > about 4MB, which does not sound terrible. So maybe we should go with > version .00. > > Jan > > On 18. 09. 19 3:10, Brad Corso wrote: > > Hi Jan, are you okay moving forward with > > http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/? > > > > On Wed, Sep 4, 2019 at 5:15 AM Ron Shapiro > > wrote: > > > > Here's the updated webrev that Brad mentioned in his last message: > > http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/ > > > > On Wed, Aug 28, 2019 at 2:40 AM Brad Corso > > wrote: > > > > I believe "Do you have any estimates of the increase in size > > in typical > > usage, due to the extra field in Scope?" (Jon) > > > > I was seeing noticeably bad performance once the size of the > > Entry.sibling linked list reached ~10000, and the max I saw was > > ~30000 in a single scope. Given that an additional reference > > adds 32/64b, this could add up to 120/240Kb for the cases I saw. > > > > I'd add, is there a chance to get an improvement in > > Scope.remove speed > > without making ScopeImpl.Entry bigger (assuming it gets > > bigger(?))? One > > possibility that occurred to me is that we could try not to > > remove the > > things from elems, but only mark them as removed. We would > > need to do > > filtering (and possibly the actual removal) while reading > > from the Scope > > (in getSymbols), so this is a different kind of trade-off. > > > > (Overall, I guess the question is whether we are trading > > problems with > > > > Scope.remove speed in some cases for out-of-memory problems > > in other cases.) > > > > Thanks, I've verified your suggestion also gives us the > > performance improvements, so this change is okay with me. > > > > > > > > On Tue, Aug 27, 2019 at 12:05 AM Jan Lahoda > > > wrote: > > > > On 27. 08. 19 0:06, Brad Corso wrote: > > > Sorry, what's the question? > > > > I believe "Do you have any estimates of the increase in size > > in typical > > usage, due to the extra field in Scope?" (Jon) > > > > I'd add, is there a chance to get an improvement in > > Scope.remove speed > > without making ScopeImpl.Entry bigger (assuming it gets > > bigger(?))? One > > possibility that occurred to me is that we could try not to > > remove the > > things from elems, but only mark them as removed. We would > > need to do > > filtering (and possibly the actual removal) while reading > > from the Scope > > (in getSymbols), so this is a different kind of trade-off. > > > > (Overall, I guess the question is whether we are trading > > problems with > > Scope.remove speed in some cases for out-of-memory problems > > in other cases.) > > > > Jan > > > > > > > > On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro > > > > > > >> wrote: > > > > > > Adding Brad back in to the thread since he would know > > best > > > > > > ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan > Gibbons > > > ? > > > > >>: > > > > > > > > > On 8/26/19 9:12 AM, Ron Shapiro wrote: > > > > > > > > Note that the patch was prepared by my > > coworker, Brad (cc'd). > > > I wasn't > > > > sure what to do to make sure that he was > > attributed correctly. > > > > > > > > > Mention this when you have a sponsor to push the > > changeset, so > > > that it > > > can be marked with "Contributed-By:" > > > > > > -- Jon > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcorso at google.com Wed Sep 18 01:06:23 2019 From: bcorso at google.com (Brad Corso) Date: Tue, 17 Sep 2019 18:06:23 -0700 Subject: RFR 8228675: Resolve.findMethod doesn't cache interface type calculation In-Reply-To: References: <5274db51-45c0-4d3a-3eb1-4c9d2f149bab@oracle.com> <2a1227f7-bcfa-11ce-1188-6c84abac1a29@oracle.com> <41dadee0-3f18-1f7a-6ae5-9cb20e292e88@oracle.com> <5b523e4f-9a42-6010-9211-a1e99460890b@oracle.com> <16c4bb5f-3d63-d92b-07b8-8a093b151d5b@oracle.com> <8760c22e-4669-7d3f-23d6-8f8f8c732f75@oracle.com> Message-ID: > This patch seems like a low-hanging fruit - union was already returning element in that order in case they were unrelated, so I agree the extra test looks redundant. Thanks for taking a look Maurizio. What's the best way to get this submitted? Should we file a separate bug for the changes in http://cr.openjdk.java.net/~ronsh/8228675/webrev.02/? On Fri, Sep 6, 2019 at 4:08 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 06/09/2019 11:44, Maurizio Cimadamore wrote: > > For the records, I did some internal performance tests, and this patch > doesn't seem to make the performance situation worse in the general case. > > I'm now curious to see if it helps with your specific use case. > > More generally speaking, for this - and others - performance related > issues, we're happy to look into them, but I think it is generally good to > submit a reproducible test case that we can use as a playground; this will > help us understanding what the problem is, understanding what are the > connections to other problems in the code base, as well as to assess its > priority. Such a test case would also form the backbone of any test that > would be pushed upstream (as it is generally preferrable to always include > tests in patches). I know that sometimes distilling such tests takes time, > but without them we're basically throwing darts in the dark. > > Maurizio > > > Maurizio > On 04/09/2019 20:58, Maurizio Cimadamore wrote: > > Hi Ron, > I put together something, albeit not the approach I described in this > thread. > > Since, from what I'm reading, the main issue you are seeing is that the > use of Types.closure is basically killing performances, I addressed that > problem instead, and rewrote the code not to use that method. The new code > is probably executing more checks than the old (since interfaces could be > implemented multiple times at different levels of the hierarchy), but I > think it should be enough to resolve the issue you are seeing. > > I did not spend a lot of time testing the patch, other than doing some > basic validation - so handle with care :-) > > http://cr.openjdk.java.net/~mcimadamore/8228675/ > > Maurizio > On 04/09/2019 15:18, Maurizio Cimadamore wrote: > > I didn't realize you were waiting on me to produce a patch; I'm afraid at > the moment I don't have many cycles to look into this. > > Maurizio > On 04/09/2019 13:05, Ron Shapiro wrote: > > Friendly ping. This is really hurting some of our builds. Maurizio, are > you able to prepare a patch for us to look at? > > On Tue, Aug 13, 2019 at 8:12 AM Ron Shapiro wrote: > >> Aren't types recreated across rounds if there are any transitive error >> types? That was at least my assumption. >> >> On Mon, Aug 12, 2019 at 5:50 PM Jan Lahoda wrote: >> >>> I wonder if this will work with annotation processors? (As these may >>> create new interfaces into the hierarchy.) >>> >>> Jan >>> >>> On 07. 08. 19 12:25, Ron Shapiro wrote: >>> > Made the change for a WeakHashMap: >>> > http://cr.openjdk.java.net/~ronsh/8228675/webrev.01/. >>> > >>> > Perhaps it would make better sense for this to be a field on >>> ClassType? >>> > That would avoid the need for managing a cache with weak keys. >>> > >>> > Do you have any guidance on how you approach tradeoffs in memory vs. >>> speed? >>> > >>> > On Mon, Aug 5, 2019 at 7:25 PM Vicente Romero < >>> vicente.romero at oracle.com >>> > > wrote: >>> > >>> > not sure if we should add yet another cache to javac but in any >>> case >>> > it should be implemented with a: WeakHashMap, >>> > >>> > Thanks, >>> > Vicente >>> > >>> > On 8/5/19 10:32 AM, Ron Shapiro wrote: >>> >> Fair question. >>> >> >>> >> github.com/google/dagger >>> >> generates implementations of interfaces that implement a >>> >> dependency injection graph. Sometimes, though not always, these >>> >> interfaces have dozens if not hundreds of (super)interfaces which >>> >> allow for builds to be sharded: each subsection of the build >>> >> refers to the superinterface and then at the root of the build >>> >> there is a union of them all. Naturally, this means this must be >>> >> rebuilt on most/all changes to any subproject of the build. >>> >> >>> >> ?????? ??? ??, 5 ????? 2019, 17:05, ??? Vicente Romero >>> >> ?>: >>> >> >>> >> Hi Ron, >>> >> >>> >> Just out of curiosity, what is the context in which this issue >>> >> arises? Naturally consuming more memory we can speed up javac >>> >> but this can lead to other problems too. >>> >> >>> >> Thanks, >>> >> Vicente >>> >> >>> >> On 8/5/19 8:24 AM, Ron Shapiro wrote: >>> >>> Friendly ping >>> >>> >>> >>> ?????? ???, 27 ????? 2019, 0:05, ??? Ron Shapiro >>> >>> ?>: >>> >>> >>> >>> Hi, >>> >>> >>> >>> Please review this change to speed up Resolve.findMethod >>> >>> for large classes that have large numbers of >>> >>> (super)interfaces >>> >>> >>> >>> webrev: >>> http://cr.openjdk.java.net/~ronsh/8228675/webrev.00/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8228675 >>> >>> >>> >>> Thanks, >>> >>> Ron >>> >>> >>> >> >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mernst at cs.washington.edu Fri Sep 20 03:32:32 2019 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 19 Sep 2019 20:32:32 -0700 Subject: Use of an annotation without @Target meta-annotation on a module declaration In-Reply-To: References: <4137c111-8f14-562b-c889-59fef8867493@oracle.com> Message-ID: I agree that the JLS uses unfortunate wording, and it is a bug that the wording was not updated for Java 9. We have an opportunity to fix it now. When an annotation has no @TargetType meta-annotation, here are 5 different things that it could mean: * Only Java 7 declaration contexts (not modules). Rationale: backward compatibility for existing annotations that were poorly written (without a @Target meta-annotation). This is the current *intent* of the specification authors (but not what is written in the specification). This is implemented in javac. * All decl contexts except type parameter declarations (this includes modules) This is what is currently written in the specification. No one thinks this is a useful specification. * All Java 8 contexts except TYPE_USE. This is another description of what is currently written in the specification. It is also not what we want. * All declaration contexts. This is definitely better than all of the foregoing. It is a behavior change from the current specification, but a small one that affects poorly-written programs that have no @Target meta-annotation. This is Alex's proposal. * All contexts. This is the simplest and clearest specification. It is the most intuitive and easiest to remember, and therefore least likely to lead to problems. Those qualities make it attractive. It is a behavior change from the current specification, but a small one that affects poorly-written programs that have no @Target meta-annotation. I propose that we adopt this meaning. From: Alex Buckley > Date: Thu, Aug 29, 2019 at 9:45 PM > Subject: Re: Use of an annotation without @Target meta-annotation on a > module declaration > To: compiler-dev > > > On 8/29/2019 5:35 PM, Werner Dietl wrote: > > Since Java 8, the JavaDoc for java.lang.annotation.Target contains: > > > > "If an @Target meta-annotation is not present on an annotation type T, > > then an annotation of type T may be written as a modifier for any > > declaration except a type parameter declaration." > > > > In Java 9, the additional constant MODULE was added to > > java.lang.annotation.ElementType for module declarations. > > > > Should an annotation without @Target meta-annotation be usable on a > > module declaration or not? > > The API spec of j.l.a.Target agrees with JLS 9.6.4.1 which defines the > meaning of @Target when it appears (and when it doesn't) on annotation > type declarations. Without @Target on its declaration, an annotation > type is applicable on module declarations. Below, ecj is right and javac > is wrong. > > JSR 308 introduced the "all declaration contexts except type parameter > declarations" rule in an attempt to constrain no- at Target to SE 7 > contexts only. As the Java language gets more kinds of declarations -- > modules, records, values -- the open-ended wording of the rule ("all") > is at odds with its closed-ended intent. The ongoing maintenance burden > for javac and the API spec and the JLS is unwelcome. Frankly, I think > the SE 7-only intent was misguided; no- at Target should have meant "all > declaration contexts", end of story, no more threads like this ever > again. Any objections to changing the rule in a future SE release? > > Alex > > > Take a file module-info.java: > > > > @pkg.Anno > > module moduletest {} > > > > and a file pgk/Anno.java: > > > > package pkg; > > public @interface Anno {} > > > > The above specification would seem to allow the use of @Anno on > > moduletest and ecj (tested with version 3.16.0) compiles the test case > > above. > > However, javac version 11.0.1 gives the following error: > > > > module-info.java:1: error: annotation type not applicable to this kind > > of declaration > > @pkg.Anno > > ^ > > 1 error > > > > The javac error goes away when adding a @Target(ElementType.MODULE) > > meta-annotation. > > > > Is this a bug in javac or is this a problem with the JavaDoc? > > > > Best, > > cu, WMD. > > > > > -- > https://ece.uwaterloo.ca/~wdietl/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openjdk at duigou.org Tue Sep 24 17:31:00 2019 From: openjdk at duigou.org (Mike Duigou) Date: Tue, 24 Sep 2019 10:31:00 -0700 Subject: Handling for new warning? Message-ID: I am working on a feature for javac that adds a new lint level warning for undeclared thrown RuntimeExceptions. The patch itself is small but since the compiler is built with all warnings enabled there are thousands of methods with found to be missing "throws" for RuntimeExceptions that they currently don't declare. Should I prepare the patch of this new feature to include all of the warnings fixes or omit them and explicitly disable the new warning in the build configuration? The former would be more correct and complete but masks the substance of the change in a huge volume of chaff. The later would be more convenient and results in a more succinct path but feels like a regression in not enabling all warnings. Cheers, Mike From joe.darcy at oracle.com Tue Sep 24 17:49:03 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 24 Sep 2019 10:49:03 -0700 Subject: JDK 14 RFR of JDK-8231414: Mark various instance fields of javac internal types as transient Message-ID: <3718ded6-874e-3e92-cf54-c9d119f250a1@oracle.com> Hello, As part of the on-going serialization cleanup (JDK-8160675 and related), please review ??? JDK-8231414: Mark various instance fields of javac internal types as transient ??? http://cr.openjdk.java.net/~darcy/8231414.0/ which marks instance fields of various serializable javac and javadoc internal types as transient. I got a clean local test run of all the langtools regression tests with this change applied. Thanks, -Joe From maurizio.cimadamore at oracle.com Tue Sep 24 17:52:37 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 24 Sep 2019 18:52:37 +0100 Subject: Handling for new warning? In-Reply-To: References: Message-ID: <68bdf8b6-bcd3-9dfa-d05f-bef5c7728e71@oracle.com> As with all warnings - I think step 1 is to add the logic to javac (and disable them in the build), step 2 is to play whack a mole and fix occurrences in the JDK. Doing it all at once might just be too much. Maurizio On 24/09/2019 18:31, Mike Duigou wrote: > I am working on a feature for javac that adds a new lint level warning > for undeclared thrown RuntimeExceptions. The patch itself is small but > since the compiler is built with all warnings enabled there are > thousands of methods with found to be missing "throws" for > RuntimeExceptions that they currently don't declare. Should I prepare > the patch of this new feature to include all of the warnings fixes or > omit them and explicitly disable the new warning in the build > configuration? The former would be more correct and complete but masks > the substance of the change in a huge volume of chaff. The later would > be more convenient and results in a more succinct path but feels like > a regression in not enabling all warnings. > > Cheers, > > Mike From brian.goetz at oracle.com Tue Sep 24 18:36:55 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 24 Sep 2019 14:36:55 -0400 Subject: Handling for new warning? In-Reply-To: <68bdf8b6-bcd3-9dfa-d05f-bef5c7728e71@oracle.com> References: <68bdf8b6-bcd3-9dfa-d05f-bef5c7728e71@oracle.com> Message-ID: <27d49930-aa3c-3cb0-2af0-9e71bd8d761f@oracle.com> And, even if you do it all at once, break it into two changesets -- compiler and JDK -- since the review process is likely different between them. There is an IntelliJ refactoring "Add runtime exception to signatures" that can be used (recursively) to provide the correct signatures. On 9/24/2019 1:52 PM, Maurizio Cimadamore wrote: > As with all warnings - I think step 1 is to add the logic to javac > (and disable them in the build), step 2 is to play whack a mole and > fix occurrences in the JDK. Doing it all at once might just be too much. > > Maurizio > > On 24/09/2019 18:31, Mike Duigou wrote: >> I am working on a feature for javac that adds a new lint level >> warning for undeclared thrown RuntimeExceptions. The patch itself is >> small but since the compiler is built with all warnings enabled there >> are thousands of methods with found to be missing "throws" for >> RuntimeExceptions that they currently don't declare. Should I prepare >> the patch of this new feature to include all of the warnings fixes or >> omit them and explicitly disable the new warning in the build >> configuration? The former would be more correct and complete but >> masks the substance of the change in a huge volume of chaff. The >> later would be more convenient and results in a more succinct path >> but feels like a regression in not enabling all warnings. >> >> Cheers, >> >> Mike From mark.reinhold at oracle.com Tue Sep 24 19:31:03 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Sep 2019 12:31:03 -0700 Subject: Handling for new warning? In-Reply-To: References: Message-ID: <20190924123103.215029939@eggemoggin.niobe.net> 2019/9/24 10:31:00 -0700, openjdk at duigou.org: > I am working on a feature for javac that adds a new lint level warning > for undeclared thrown RuntimeExceptions. RuntimeExceptions are unchecked exceptions. Do you mean to require that they be mentioned in `throws` clauses, even though the language doesn?t require that? If so, why is that a good idea? Will this check apply only to direct instances of `RuntimeException`, or to instances of that class and all its subclasses? - Mark From openjdk at duigou.org Tue Sep 24 22:45:48 2019 From: openjdk at duigou.org (Mike Duigou) Date: Tue, 24 Sep 2019 15:45:48 -0700 Subject: Handling for new warning? In-Reply-To: <27d49930-aa3c-3cb0-2af0-9e71bd8d761f@oracle.com> References: <68bdf8b6-bcd3-9dfa-d05f-bef5c7728e71@oracle.com> <27d49930-aa3c-3cb0-2af0-9e71bd8d761f@oracle.com> Message-ID: This change applies only to the jdk.compiler module though there are probably many fixups which can be done later to fix the new warning. The Intellij refactoring seems like a reasonable way to get ahead of it. I chose this change first because it doesn't require any JLS spec changes--it is just another lint "hygiene" warning. Cheers, Mike On 2019-09-24 11:36, Brian Goetz wrote: > And, even if you do it all at once, break it into two changesets -- > compiler and JDK -- since the review process is likely different > between them. > > There is an IntelliJ refactoring "Add runtime exception to signatures" > that can be used (recursively) to provide the correct signatures. > > On 9/24/2019 1:52 PM, Maurizio Cimadamore wrote: >> As with all warnings - I think step 1 is to add the logic to javac >> (and disable them in the build), step 2 is to play whack a mole and >> fix occurrences in the JDK. Doing it all at once might just be too >> much. >> >> Maurizio >> >> On 24/09/2019 18:31, Mike Duigou wrote: >>> I am working on a feature for javac that adds a new lint level >>> warning for undeclared thrown RuntimeExceptions. The patch itself is >>> small but since the compiler is built with all warnings enabled there >>> are thousands of methods with found to be missing "throws" for >>> RuntimeExceptions that they currently don't declare. Should I prepare >>> the patch of this new feature to include all of the warnings fixes or >>> omit them and explicitly disable the new warning in the build >>> configuration? The former would be more correct and complete but >>> masks the substance of the change in a huge volume of chaff. The >>> later would be more convenient and results in a more succinct path >>> but feels like a regression in not enabling all warnings. >>> >>> Cheers, >>> >>> Mike From openjdk at duigou.org Tue Sep 24 22:56:37 2019 From: openjdk at duigou.org (Mike Duigou) Date: Tue, 24 Sep 2019 15:56:37 -0700 Subject: Handling for new warning? In-Reply-To: <20190924123103.215029939@eggemoggin.niobe.net> References: <20190924123103.215029939@eggemoggin.niobe.net> Message-ID: <22a5da78b149115bf3fad38fa91ddc04@duigou.org> The proposed change is to add a lint level warning, ie. -XLint:runtime-undeclared , suggestion to add the unrequired but missing throws declarations for RuntimeException et al. The advantage to providing the complete throws including RuntimeExceptions is to make them more visible and encourage handling of them. We have one good example of a library which does declare the RuntimeException that are thrown, the JDK. Having those optional declarations has already been deemed invaluable and necessary to writing good tests, the most direct example being the JCK. The intent is to encourage declaration of RuntimeExceptions that might be thrown so that callers can better plan for the potential behaviour of methods both in their production code and in tests. The check will apply to all instances of RuntimeException and all subclasses. This change is one of the two proposals I made for improving exceptions in my CodeOne talk "Exceptions 2020", the other change requires JLS changes so I decided to pursue this one first. Cheers, Mike On 2019-09-24 12:31, mark.reinhold at oracle.com wrote: > 2019/9/24 10:31:00 -0700, openjdk at duigou.org: >> I am working on a feature for javac that adds a new lint level warning >> for undeclared thrown RuntimeExceptions. > > RuntimeExceptions are unchecked exceptions. Do you mean to require > that > they be mentioned in `throws` clauses, even though the language doesn?t > require that? If so, why is that a good idea? > > Will this check apply only to direct instances of `RuntimeException`, > or > to instances of that class and all its subclasses? > > - Mark From jonathan.gibbons at oracle.com Tue Sep 24 23:13:41 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Sep 2019 16:13:41 -0700 Subject: Handling for new warning? In-Reply-To: References: <68bdf8b6-bcd3-9dfa-d05f-bef5c7728e71@oracle.com> <27d49930-aa3c-3cb0-2af0-9e71bd8d761f@oracle.com> Message-ID: <6e86d37f-5e13-071c-2b74-48b8191ce67a@oracle.com> Is this really a good idea -- adding the lint warning, with the downstream cost to projects that like to compile with `-Xlint:all -Werror`? If nothing else, your note earlier that in JDK /there are thousands of methods with found to be missing "throws" for RuntimeExceptions that they currently don't declare./ is in itself a big red flag indicative of the impact of this change. Before you post any proposed updates to javac or JDK, I suggest there should be a more general discussion on the desirability of this change, and its impact on existing code. -- Jon On 9/24/19 3:45 PM, Mike Duigou wrote: > This change applies only to the jdk.compiler module though there are > probably many fixups which can be done later to fix the new warning. > The Intellij refactoring seems like a reasonable way to get ahead of it. > > I chose this change first because it doesn't require any JLS spec > changes--it is just another lint "hygiene" warning. > > Cheers, > > Mike > > On 2019-09-24 11:36, Brian Goetz wrote: >> And, even if you do it all at once, break it into two changesets -- >> compiler and JDK -- since the review process is likely different >> between them. >> >> There is an IntelliJ refactoring "Add runtime exception to signatures" >> that can be used (recursively) to provide the correct signatures. >> >> On 9/24/2019 1:52 PM, Maurizio Cimadamore wrote: >>> As with all warnings - I think step 1 is to add the logic to javac >>> (and disable them in the build), step 2 is to play whack a mole and >>> fix occurrences in the JDK. Doing it all at once might just be too >>> much. >>> >>> Maurizio >>> >>> On 24/09/2019 18:31, Mike Duigou wrote: >>>> I am working on a feature for javac that adds a new lint level >>>> warning for undeclared thrown RuntimeExceptions. The patch itself >>>> is small but since the compiler is built with all warnings enabled >>>> there are thousands of methods with found to be missing "throws" >>>> for RuntimeExceptions that they currently don't declare. Should I >>>> prepare the patch of this new feature to include all of the >>>> warnings fixes or omit them and explicitly disable the new warning >>>> in the build configuration? The former would be more correct and >>>> complete but masks the substance of the change in a huge volume of >>>> chaff. The later would be more convenient and results in a more >>>> succinct path but feels like a regression in not enabling all >>>> warnings. >>>> >>>> Cheers, >>>> >>>> Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Tue Sep 24 23:25:32 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Sep 2019 16:25:32 -0700 Subject: Handling for new warning? In-Reply-To: <22a5da78b149115bf3fad38fa91ddc04@duigou.org> References: <20190924123103.215029939@eggemoggin.niobe.net> <22a5da78b149115bf3fad38fa91ddc04@duigou.org> Message-ID: <20190924162532.469518448@eggemoggin.niobe.net> 2019/9/24 15:56:37 -0700, openjdk at duigou.org: > The proposed change is to add a lint level warning, ie. > -XLint:runtime-undeclared , suggestion to add the unrequired but missing > throws declarations for RuntimeException et al. The advantage to > providing the complete throws including RuntimeExceptions is to make > them more visible and encourage handling of them. We have one good > example of a library which does declare the RuntimeException that are > thrown, the JDK. I?m confused. I thought you said earlier that there are thousands of missing cases in the JDK. > ... > > The check will apply to all instances of RuntimeException and all > subclasses. I agree with Jon: This proposal is likely to have broad impact and thus needs wider discussion. May I suggest the jdk-dev list? - Mark From alex.buckley at oracle.com Tue Sep 24 23:52:03 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 24 Sep 2019 16:52:03 -0700 Subject: Use of an annotation without @Target meta-annotation on a module declaration In-Reply-To: References: <4137c111-8f14-562b-c889-59fef8867493@oracle.com> Message-ID: <3a4bb381-5aa7-0c93-b4d9-550763d6d1a2@oracle.com> On 9/19/2019 8:32 PM, Michael Ernst wrote: > * All contexts. > ? This is the simplest and clearest specification.? It is the most > intuitive and easiest to remember, and therefore least likely to lead to > problems.? Those qualities make it attractive. > ? It is a behavior change from the current specification, but a small > one that affects poorly-written programs that have no @Target > meta-annotation. > ? I propose that we adopt this meaning. I completely agree with this approach. JLS and javac bugs filed: https://bugs.openjdk.java.net/browse/JDK-8231435 https://bugs.openjdk.java.net/browse/JDK-8231436 Alex From openjdk at duigou.org Wed Sep 25 00:46:37 2019 From: openjdk at duigou.org (Mike Duigou) Date: Tue, 24 Sep 2019 17:46:37 -0700 Subject: Handling for new warning? In-Reply-To: <20190924162532.469518448@eggemoggin.niobe.net> References: <20190924123103.215029939@eggemoggin.niobe.net> <22a5da78b149115bf3fad38fa91ddc04@duigou.org> <20190924162532.469518448@eggemoggin.niobe.net> Message-ID: <44c5b0bb5ebb92a41efde9b9a6bc85ed@duigou.org> On 2019-09-24 16:25, mark.reinhold at oracle.com wrote: > 2019/9/24 15:56:37 -0700, openjdk at duigou.org: >> The proposed change is to add a lint level warning, ie. >> -XLint:runtime-undeclared , suggestion to add the unrequired but >> missing >> throws declarations for RuntimeException et al. The advantage to >> providing the complete throws including RuntimeExceptions is to make >> them more visible and encourage handling of them. We have one good >> example of a library which does declare the RuntimeException that are >> thrown, the JDK. > > I?m confused. I thought you said earlier that there are thousands of > missing cases in the JDK. JDK seems to be in pretty good shape though -Werror stops compilation well before completion. The observed problems with large numbers of missing declarations have been in javac where there are hundreds (perhaps many more) missing throws declarations primarily, so far, for IllegalArgumentException and CompletionFailure. There's no easy way to know the total number of potential throws "fixes" needed because adding missing declarations has a tendency to produce new warnings in the methods which call the fixed method. I added a couple hundred across a dozen or so files but didn't feel I was any near complete based on the number of files I hadn't yet covered in the javac source. > >> ... >> >> The check will apply to all instances of RuntimeException and all >> subclasses. > > I agree with Jon: This proposal is likely to have broad impact and thus > needs wider discussion. May I suggest the jdk-dev list? For JDK this would seem to be a separate problem--the missing "throws" could in some cases mean that the method signature and javadoc are an incomplete specification of the API and a potential/probable JCK issue. For the moment I am going to working on completing the minimal patch which provides the new lint warning and allows compilation by disabling the warning. > > - Mark Cheers, Mike From jonathan.gibbons at oracle.com Wed Sep 25 00:59:17 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Sep 2019 17:59:17 -0700 Subject: Handling for new warning? In-Reply-To: <44c5b0bb5ebb92a41efde9b9a6bc85ed@duigou.org> References: <20190924123103.215029939@eggemoggin.niobe.net> <22a5da78b149115bf3fad38fa91ddc04@duigou.org> <20190924162532.469518448@eggemoggin.niobe.net> <44c5b0bb5ebb92a41efde9b9a6bc85ed@duigou.org> Message-ID: <5a6db3b9-76af-2afd-9343-85f43b311a5f@oracle.com> On 9/24/19 5:46 PM, Mike Duigou wrote: > > > > > On 2019-09-24 16:25, mark.reinhold at oracle.com wrote: >> 2019/9/24 15:56:37 -0700, openjdk at duigou.org: >>> The proposed change is to add a lint level warning, ie. >>> -XLint:runtime-undeclared , suggestion to add the unrequired but >>> missing >>> throws declarations for RuntimeException et al. The advantage to >>> providing the complete throws including RuntimeExceptions is to make >>> them more visible and encourage handling of them. We have one good >>> example of a library which does declare the RuntimeException that are >>> thrown, the JDK. >> >> I?m confused.? I thought you said earlier that there are thousands of >> missing cases in the JDK. > > JDK seems to be in pretty good shape though -Werror stops compilation > well before completion. The observed problems with large numbers of > missing declarations have been in javac where there are hundreds > (perhaps many more) missing throws declarations primarily, so far, for > IllegalArgumentException and CompletionFailure. I don't think it would be acceptable to change javac so that CompletionFailure is specified all over the place.?? Story: a long time ago, back when I joined the javac team, I tried doing something similar to what you're proposing now, except that I tried to do it by changing CompletionFailure to a checked exception. As you might guess, the size of the change became unreasonable and I abandoned the experiment. I'd also be concerned about IllegalArgumentException and friends like NullPointerException becoming too pervasive across the codebase. -- Jon > > There's no easy way to know the total number of potential throws > "fixes" needed because adding missing declarations has a tendency to > produce new warnings in the methods which call the fixed method. I > added a couple hundred across a dozen or so files but didn't feel I > was any near complete based on the number of files I hadn't yet > covered in the javac source. > >> >>> ... >>> >>> The check will apply to all instances of RuntimeException and all >>> subclasses. >> >> I agree with Jon: This proposal is likely to have broad impact and thus >> needs wider discussion.? May I suggest the jdk-dev list? > > > For JDK this would seem to be a separate problem--the missing "throws" > could in some cases mean that the method signature and javadoc are an > incomplete specification of the API and a potential/probable JCK issue. > > For the moment I am going to working on completing the minimal patch > which provides the new lint warning and allows compilation by > disabling the warning. > >> >> - Mark > > > Cheers, > > Mike From maurizio.cimadamore at oracle.com Wed Sep 25 01:37:07 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 25 Sep 2019 02:37:07 +0100 Subject: Handling for new warning? In-Reply-To: <5a6db3b9-76af-2afd-9343-85f43b311a5f@oracle.com> References: <20190924123103.215029939@eggemoggin.niobe.net> <22a5da78b149115bf3fad38fa91ddc04@duigou.org> <20190924162532.469518448@eggemoggin.niobe.net> <44c5b0bb5ebb92a41efde9b9a6bc85ed@duigou.org> <5a6db3b9-76af-2afd-9343-85f43b311a5f@oracle.com> Message-ID: <4be97521-1607-a855-5cf2-87b56a1db10f@oracle.com> My (very humble) 0.02$ on this; I can see where Mike is coming from _and_ where Jon and Mark are coming from. The problem is that, when we are inside an _implementation_ class (think of a non-exported package in a module), we probably don't want to be too formal about the set of unchecked annotations being thrown. Conversely, when we are in a public-facing API, it is very likely that unchecked exceptions carry value (IllegalArgumentExecption, IllegalStateException to name a few) and should therefore be documented. To be more concrete, on my recent work on the memory access API, while developing the API and writing the docs I wish I had an automatic way to detect all unchecked exception I missed in the 'throws' clause, as they were likely (a) some documentation missing somewhere or (b) a missing test for that particular failure mode. The problem is how to reconcile these two aspects - you want a warnings that's useful, but not one that's excessively punitive so that apparently good code gets flagged (I am reminded of when I introduced the warning for raw types and later on relaxed that not to be triggered on stuff like 'instanceof List', which is pretty widespread - and for which adding an extra '' doesn't really add a lot of value). And, in this case, it can be tricky to come up with a way to distinguish between API and internals. Perhaps we could use the module system to our advantage, and only enable the Lint check for public methods in public classes/interfaces in exported packages. I'm pretty sure something like this should reduce the 'noise' of such a check quite significantly (and the remaining places where the warning is still issued are likely to be informative for us). Thoughts? Maurizio On 25/09/2019 01:59, Jonathan Gibbons wrote: > > On 9/24/19 5:46 PM, Mike Duigou wrote: >> >> >> >> >> On 2019-09-24 16:25, mark.reinhold at oracle.com wrote: >>> 2019/9/24 15:56:37 -0700, openjdk at duigou.org: >>>> The proposed change is to add a lint level warning, ie. >>>> -XLint:runtime-undeclared , suggestion to add the unrequired but >>>> missing >>>> throws declarations for RuntimeException et al. The advantage to >>>> providing the complete throws including RuntimeExceptions is to make >>>> them more visible and encourage handling of them. We have one good >>>> example of a library which does declare the RuntimeException that are >>>> thrown, the JDK. >>> >>> I?m confused.? I thought you said earlier that there are thousands of >>> missing cases in the JDK. >> >> JDK seems to be in pretty good shape though -Werror stops compilation >> well before completion. The observed problems with large numbers of >> missing declarations have been in javac where there are hundreds >> (perhaps many more) missing throws declarations primarily, so far, >> for IllegalArgumentException and CompletionFailure. > > I don't think it would be acceptable to change javac so that > CompletionFailure is specified all over the place.?? Story: a long > time ago, back when I joined the javac team, I tried doing something > similar to what you're proposing now, except that I tried to do it by > changing CompletionFailure to a checked exception. As you might guess, > the size of the change became unreasonable and I abandoned the > experiment. > > I'd also be concerned about IllegalArgumentException and friends like > NullPointerException becoming too pervasive across the codebase. > > -- Jon > > >> >> There's no easy way to know the total number of potential throws >> "fixes" needed because adding missing declarations has a tendency to >> produce new warnings in the methods which call the fixed method. I >> added a couple hundred across a dozen or so files but didn't feel I >> was any near complete based on the number of files I hadn't yet >> covered in the javac source. >> >>> >>>> ... >>>> >>>> The check will apply to all instances of RuntimeException and all >>>> subclasses. >>> >>> I agree with Jon: This proposal is likely to have broad impact and thus >>> needs wider discussion.? May I suggest the jdk-dev list? >> >> >> For JDK this would seem to be a separate problem--the missing >> "throws" could in some cases mean that the method signature and >> javadoc are an incomplete specification of the API and a >> potential/probable JCK issue. >> >> For the moment I am going to working on completing the minimal patch >> which provides the new lint warning and allows compilation by >> disabling the warning. >> >>> >>> - Mark >> >> >> Cheers, >> >> Mike From joe.darcy at oracle.com Wed Sep 25 02:42:24 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 24 Sep 2019 19:42:24 -0700 Subject: Handling for new warning? In-Reply-To: <4be97521-1607-a855-5cf2-87b56a1db10f@oracle.com> References: <20190924123103.215029939@eggemoggin.niobe.net> <22a5da78b149115bf3fad38fa91ddc04@duigou.org> <20190924162532.469518448@eggemoggin.niobe.net> <44c5b0bb5ebb92a41efde9b9a6bc85ed@duigou.org> <5a6db3b9-76af-2afd-9343-85f43b311a5f@oracle.com> <4be97521-1607-a855-5cf2-87b56a1db10f@oracle.com> Message-ID: <32ef5f1c-d83d-f966-6f14-a14d14ce4b20@oracle.com> Hi Mike, Sharing some experience from developing new lint warnings and clearing the JDK code base of them, even seemingly simple warnings often need some refinement before being ready for production use. This was the case for the equals-hashCode warning (first JDK-6563143, then JDK-8008436, and JDK-8009138), handling many subtleties not discussed in the corresponding "Effective Java" item. More recently, when starting work on JDK-8071961: "Add javac lint warning when a default constructor is created," the earliest iteration was trivial since there is easy-to-find code in javac which generates a default constructor. However, I quick had to start adding conditions to when the warning would be printed to avoid spurious messages. I believe default constructors and the exception warning you're working on have a property in common that the warning is most sensible on serious/formal classes but not wanted on informal ones or ones that are not part of a public API. For clearing a warning of the JDK in particular, it can be helpful to modify the build options, say, to exclude the warning by default "-Xlint:all,-new-warning" .. and only enable it on selected modules. The files in question are: ??? jdk/make/common/SetupJavaCompilers.gmk ??? jdk/make/CompileJavaModules.gmk HTH, -Joe On 9/24/2019 6:37 PM, Maurizio Cimadamore wrote: > My (very humble) 0.02$ on this; I can see where Mike is coming from > _and_ where Jon and Mark are coming from. > > The problem is that, when we are inside an _implementation_ class > (think of a non-exported package in a module), we probably don't want > to be too formal about the set of unchecked annotations being thrown. > > Conversely, when we are in a public-facing API, it is very likely that > unchecked exceptions carry value (IllegalArgumentExecption, > IllegalStateException to name a few) and should therefore be > documented. To be more concrete, on my recent work on the memory > access API, while developing the API and writing the docs I wish I had > an automatic way to detect all unchecked exception I missed in the > 'throws' clause, as they were likely (a) some documentation missing > somewhere or (b) a missing test for that particular failure mode. > > The problem is how to reconcile these two aspects - you want a > warnings that's useful, but not one that's excessively punitive so > that apparently good code gets flagged (I am reminded of when I > introduced the warning for raw types and later on relaxed that not to > be triggered on stuff like 'instanceof List', which is pretty > widespread - and for which adding an extra '' doesn't really add a > lot of value). > > And, in this case, it can be tricky to come up with a way to > distinguish between API and internals. Perhaps we could use the module > system to our advantage, and only enable the Lint check for public > methods in public classes/interfaces in exported packages. I'm pretty > sure something like this should reduce the 'noise' of such a check > quite significantly (and the remaining places where the warning is > still issued are likely to be informative for us). > > Thoughts? > > Maurizio > > On 25/09/2019 01:59, Jonathan Gibbons wrote: >> >> On 9/24/19 5:46 PM, Mike Duigou wrote: >>> >>> >>> >>> >>> On 2019-09-24 16:25, mark.reinhold at oracle.com wrote: >>>> 2019/9/24 15:56:37 -0700, openjdk at duigou.org: >>>>> The proposed change is to add a lint level warning, ie. >>>>> -XLint:runtime-undeclared , suggestion to add the unrequired but >>>>> missing >>>>> throws declarations for RuntimeException et al. The advantage to >>>>> providing the complete throws including RuntimeExceptions is to make >>>>> them more visible and encourage handling of them. We have one good >>>>> example of a library which does declare the RuntimeException that are >>>>> thrown, the JDK. >>>> >>>> I?m confused.? I thought you said earlier that there are thousands of >>>> missing cases in the JDK. >>> >>> JDK seems to be in pretty good shape though -Werror stops >>> compilation well before completion. The observed problems with large >>> numbers of missing declarations have been in javac where there are >>> hundreds (perhaps many more) missing throws declarations primarily, >>> so far, for IllegalArgumentException and CompletionFailure. >> >> I don't think it would be acceptable to change javac so that >> CompletionFailure is specified all over the place.?? Story: a long >> time ago, back when I joined the javac team, I tried doing something >> similar to what you're proposing now, except that I tried to do it by >> changing CompletionFailure to a checked exception. As you might >> guess, the size of the change became unreasonable and I abandoned the >> experiment. >> >> I'd also be concerned about IllegalArgumentException and friends like >> NullPointerException becoming too pervasive across the codebase. >> >> -- Jon >> >> >>> >>> There's no easy way to know the total number of potential throws >>> "fixes" needed because adding missing declarations has a tendency to >>> produce new warnings in the methods which call the fixed method. I >>> added a couple hundred across a dozen or so files but didn't feel I >>> was any near complete based on the number of files I hadn't yet >>> covered in the javac source. >>> >>>> >>>>> ... >>>>> >>>>> The check will apply to all instances of RuntimeException and all >>>>> subclasses. >>>> >>>> I agree with Jon: This proposal is likely to have broad impact and >>>> thus >>>> needs wider discussion.? May I suggest the jdk-dev list? >>> >>> >>> For JDK this would seem to be a separate problem--the missing >>> "throws" could in some cases mean that the method signature and >>> javadoc are an incomplete specification of the API and a >>> potential/probable JCK issue. >>> >>> For the moment I am going to working on completing the minimal patch >>> which provides the new lint warning and allows compilation by >>> disabling the warning. >>> >>>> >>>> - Mark >>> >>> >>> Cheers, >>> >>> Mike From arno.zeller at sap.com Wed Sep 25 05:55:53 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Wed, 25 Sep 2019 05:55:53 +0000 Subject: RFR(T) 8230110: TestLinkageErrorInGenerateOopMap times out Message-ID: Hi, I have seen some occurrences of this issue (8230110) on our AIX and Windows test machines. The test times out because it writes a huge core file (I have seen more than 24GB on one machine) and this might take minutes. As far as I understand the test does not need a core file. Therefore my suggestion is to set a max java heap size (-Xmx64m) and switch of core file writing (-XX:-CreateCoredumpOnCrash). Reopened bug: https://bugs.openjdk.java.net/browse/JDK-8230110 Webrev: http://cr.openjdk.java.net/~azeller/webrevs/JKD8230110_TestLinkageErrorInGenerateOopMap_times_out/webrev/ I am no committer - I will need a sponsor for this change. Best regards, Arno -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Sep 25 06:04:46 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 25 Sep 2019 08:04:46 +0200 Subject: RFR(T) 8230110: TestLinkageErrorInGenerateOopMap times out In-Reply-To: References: Message-ID: Hi Arno, Seems reasonable, assuming you verified that 64m heap are enough for this test on all platforms. I can sponsor this for you. Cheers, Thomas On Wed, Sep 25, 2019, 07:57 Zeller, Arno wrote: > Hi, > > > > I have seen some occurrences of this issue (8230110) on our AIX and > Windows test machines. The test times out because it writes a huge core > file (I have seen more than 24GB on one machine) and this might take > minutes. > > As far as I understand the test does not need a core file. Therefore my > suggestion is to set a max java heap size (-Xmx64m) and switch of core file > writing (-XX:-CreateCoredumpOnCrash). > > > > Reopened bug: https://bugs.openjdk.java.net/browse/JDK-8230110 > > Webrev: > http://cr.openjdk.java.net/~azeller/webrevs/JKD8230110_TestLinkageErrorInGenerateOopMap_times_out/webrev/ > > > > I am no committer ? I will need a sponsor for this change. > > > > Best regards, > Arno > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arno.zeller at sap.com Wed Sep 25 09:04:44 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Wed, 25 Sep 2019 09:04:44 +0000 Subject: RFR(T) 8230110: TestLinkageErrorInGenerateOopMap times out In-Reply-To: References: Message-ID: Hi Thomas, thanks for taking a look and for sponsoring. I put the test in our internal test system and it passed on all our Linux platforms, AIX, Windows 64bit and Solaris. I think 64m should be fine. Linux on ARM64 and macOS did not run yet but I expect no problems. Best regards, Arno From: Thomas St?fe Sent: Mittwoch, 25. September 2019 08:05 To: Zeller, Arno Cc: compiler-dev at openjdk.java.net Subject: Re: RFR(T) 8230110: TestLinkageErrorInGenerateOopMap times out Hi Arno, Seems reasonable, assuming you verified that 64m heap are enough for this test on all platforms. I can sponsor this for you. Cheers, Thomas On Wed, Sep 25, 2019, 07:57 Zeller, Arno > wrote: Hi, I have seen some occurrences of this issue (8230110) on our AIX and Windows test machines. The test times out because it writes a huge core file (I have seen more than 24GB on one machine) and this might take minutes. As far as I understand the test does not need a core file. Therefore my suggestion is to set a max java heap size (-Xmx64m) and switch of core file writing (-XX:-CreateCoredumpOnCrash). Reopened bug: https://bugs.openjdk.java.net/browse/JDK-8230110 Webrev: http://cr.openjdk.java.net/~azeller/webrevs/JKD8230110_TestLinkageErrorInGenerateOopMap_times_out/webrev/ I am no committer ? I will need a sponsor for this change. Best regards, Arno -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Sep 25 20:14:41 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 25 Sep 2019 13:14:41 -0700 Subject: JDK 14 RFR of JDK-8231443: Add java.io.Serial to list of platform annotations for annotation processing Message-ID: <95eb578d-b078-5eec-2f52-8c6d4f2516d8@oracle.com> Hello, To avoid spurious warnings about unclaimed annotations, the annotation processing machinery in javac maintains a list of platform annotation to screen out.? With the new platform annotation java.io.Serial (JDK-8202385), being added in JDK 14, the list needs to be updated: ??? JDK-8231443 : Add java.io.Serial to list of platform annotations for annotation processing ??? http://cr.openjdk.java.net/~darcy/8231443.0/ Patch below. It isn't harmful for the annotations list for pre-14 release to contain an extra entry. Thanks, -Joe --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-09-25 13:08:17.596467999 -0700 +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java 2019-09-25 13:08:17.424553999 -0700 @@ -264,7 +264,9 @@ ?????????????????????? module_prefix + "java.lang.annotation.Native", ?????????????????????? module_prefix + "java.lang.annotation.Repeatable", ?????????????????????? module_prefix + "java.lang.annotation.Retention", -????????????????????? module_prefix + "java.lang.annotation.Target"); +????????????????????? module_prefix + "java.lang.annotation.Target", + +????????????????????? module_prefix + "java.io.Serial"); ???? } ???? private void initProcessorLoader() { From jonathan.gibbons at oracle.com Wed Sep 25 20:16:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 25 Sep 2019 13:16:31 -0700 Subject: JDK 14 RFR of JDK-8231443: Add java.io.Serial to list of platform annotations for annotation processing In-Reply-To: <95eb578d-b078-5eec-2f52-8c6d4f2516d8@oracle.com> References: <95eb578d-b078-5eec-2f52-8c6d4f2516d8@oracle.com> Message-ID: <526b7e3f-0a29-cf99-7b84-59c2d1ea0318@oracle.com> +1 On 9/25/19 1:14 PM, Joe Darcy wrote: > Hello, > > To avoid spurious warnings about unclaimed annotations, the annotation > processing machinery in javac maintains a list of platform annotation > to screen out.? With the new platform annotation java.io.Serial > (JDK-8202385), being added in JDK 14, the list needs to be updated: > > ??? JDK-8231443 : Add java.io.Serial to list of platform annotations > for annotation processing > ??? http://cr.openjdk.java.net/~darcy/8231443.0/ > > Patch below. It isn't harmful for the annotations list for pre-14 > release to contain an extra entry. > > Thanks, > > -Joe > > --- > old/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > 2019-09-25 13:08:17.596467999 -0700 > +++ > new/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java > 2019-09-25 13:08:17.424553999 -0700 > @@ -264,7 +264,9 @@ > ?????????????????????? module_prefix + "java.lang.annotation.Native", > ?????????????????????? module_prefix + "java.lang.annotation.Repeatable", > ?????????????????????? module_prefix + "java.lang.annotation.Retention", > -????????????????????? module_prefix + "java.lang.annotation.Target"); > +????????????????????? module_prefix + "java.lang.annotation.Target", > + > +????????????????????? module_prefix + "java.io.Serial"); > ???? } > > ???? private void initProcessorLoader() { > From christoph.langer at sap.com Wed Sep 25 09:10:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 25 Sep 2019 09:10:03 +0000 Subject: RFR(T) 8230110: TestLinkageErrorInGenerateOopMap times out In-Reply-To: References: Message-ID: Hi Arno, this testfix seems reasonable, +1. You?ve posted it to the wrong mailing list, though. It should be directed to hotspot-compiler-dev, hence I?ve copied this list in my reply. Bcc-ing compiler-dev. Best regards Christoph From: compiler-dev On Behalf Of Thomas St?fe Sent: Mittwoch, 25. September 2019 08:05 To: Zeller, Arno Cc: compiler-dev at openjdk.java.net Subject: Re: RFR(T) 8230110: TestLinkageErrorInGenerateOopMap times out Hi Arno, Seems reasonable, assuming you verified that 64m heap are enough for this test on all platforms. I can sponsor this for you. Cheers, Thomas On Wed, Sep 25, 2019, 07:57 Zeller, Arno > wrote: Hi, I have seen some occurrences of this issue (8230110) on our AIX and Windows test machines. The test times out because it writes a huge core file (I have seen more than 24GB on one machine) and this might take minutes. As far as I understand the test does not need a core file. Therefore my suggestion is to set a max java heap size (-Xmx64m) and switch of core file writing (-XX:-CreateCoredumpOnCrash). Reopened bug: https://bugs.openjdk.java.net/browse/JDK-8230110 Webrev: http://cr.openjdk.java.net/~azeller/webrevs/JKD8230110_TestLinkageErrorInGenerateOopMap_times_out/webrev/ I am no committer ? I will need a sponsor for this change. Best regards, Arno -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcorso at google.com Mon Sep 30 16:16:14 2019 From: bcorso at google.com (Brad Corso) Date: Mon, 30 Sep 2019 09:16:14 -0700 Subject: RFR 8230162: ScopeImpl.remove() has O(N) performance In-Reply-To: References: <635e2298-3bb2-e576-d741-48dcddd132d4@oracle.com> <591e776d-9d9e-261e-9202-ffff4d4e0844@oracle.com> Message-ID: Friendly ping. On Wed, Sep 18, 2019 at 9:55 AM Brad Corso wrote: > Hi Jan, > > I'm okay with either version so I'll leave that decision up to you. > > Let me know if there's anything else you need from me. > > Thanks! > Brad > > On Wed, Sep 18, 2019 at 12:38 AM Jan Lahoda wrote: > >> I've added logging to count how many Entries are created, and there's a >> little above 500000 instances created for java.base and a little less >> for java.desktop. So if the Entry would be 8 bytes bigger, it would be >> about 4MB, which does not sound terrible. So maybe we should go with >> version .00. >> >> Jan >> >> On 18. 09. 19 3:10, Brad Corso wrote: >> > Hi Jan, are you okay moving forward with >> > http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/? >> > >> > On Wed, Sep 4, 2019 at 5:15 AM Ron Shapiro > > > wrote: >> > >> > Here's the updated webrev that Brad mentioned in his last message: >> > http://cr.openjdk.java.net/~ronsh/8230162/webrev.01/ >> > >> > On Wed, Aug 28, 2019 at 2:40 AM Brad Corso > > > wrote: >> > >> > I believe "Do you have any estimates of the increase in size >> > in typical >> > usage, due to the extra field in Scope?" (Jon) >> > >> > I was seeing noticeably bad performance once the size of the >> > Entry.sibling linked list reached ~10000, and the max I saw was >> > ~30000 in a single scope. Given that an additional reference >> > adds 32/64b, this could add up to 120/240Kb for the cases I saw. >> > >> > I'd add, is there a chance to get an improvement in >> > Scope.remove speed >> > without making ScopeImpl.Entry bigger (assuming it gets >> > bigger(?))? One >> > possibility that occurred to me is that we could try not to >> > remove the >> > things from elems, but only mark them as removed. We would >> > need to do >> > filtering (and possibly the actual removal) while reading >> > from the Scope >> > (in getSymbols), so this is a different kind of trade-off. >> > >> > (Overall, I guess the question is whether we are trading >> > problems with >> > >> > Scope.remove speed in some cases for out-of-memory problems >> > in other cases.) >> > >> > Thanks, I've verified your suggestion also gives us the >> > performance improvements, so this change is okay with me. >> > >> > >> > >> > On Tue, Aug 27, 2019 at 12:05 AM Jan Lahoda >> > > wrote: >> > >> > On 27. 08. 19 0:06, Brad Corso wrote: >> > > Sorry, what's the question? >> > >> > I believe "Do you have any estimates of the increase in size >> > in typical >> > usage, due to the extra field in Scope?" (Jon) >> > >> > I'd add, is there a chance to get an improvement in >> > Scope.remove speed >> > without making ScopeImpl.Entry bigger (assuming it gets >> > bigger(?))? One >> > possibility that occurred to me is that we could try not to >> > remove the >> > things from elems, but only mark them as removed. We would >> > need to do >> > filtering (and possibly the actual removal) while reading >> > from the Scope >> > (in getSymbols), so this is a different kind of trade-off. >> > >> > (Overall, I guess the question is whether we are trading >> > problems with >> > Scope.remove speed in some cases for out-of-memory problems >> > in other cases.) >> > >> > Jan >> > >> > > >> > > On Mon, Aug 26, 2019 at 1:54 PM Ron Shapiro >> > >> > > > > >> wrote: >> > > >> > > Adding Brad back in to the thread since he would know >> > best >> > > >> > > ?????? ??? ??, 26 ????? 2019, 19:40, ??? Jonathan >> Gibbons >> > > ?> > >> > > > >>: >> > > >> > > >> > > On 8/26/19 9:12 AM, Ron Shapiro wrote: >> > > > >> > > > Note that the patch was prepared by my >> > coworker, Brad (cc'd). >> > > I wasn't >> > > > sure what to do to make sure that he was >> > attributed correctly. >> > > >> > > >> > > Mention this when you have a sponsor to push the >> > changeset, so >> > > that it >> > > can be marked with "Contributed-By:" >> > > >> > > -- Jon >> > > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: