From joe.darcy at oracle.com Mon Jun 1 03:37:33 2015 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 31 May 2015 20:37:33 -0700 Subject: JDK 9 RFR of JDK-8075546: Add tiered testing definitions to the langtools repo Message-ID: <556BD37D.7090508@oracle.com> Hello, As part of implementing the tiered testing policy in JDK 9 [1], please review the changes for 8075546: Add tiered testing definitions to the langtools repo http://cr.openjdk.java.net/~darcy/8075546.0/ A few comments, I've made the TEST.ROOT file in langtools consistent with the keywords and minimum jtreg version used in the jdk repo. The one javadoc test GetTask_DocletClassTest.java uses randomness and I've marked it accordingly. I've created an empty problem list file so that command lines to invoke the test suites for a repository can be more uniform across repositories. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From aleksey.shipilev at oracle.com Mon Jun 1 07:49:19 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 01 Jun 2015 10:49:19 +0300 Subject: String concatenation tweaks In-Reply-To: <556B7E3E.8050707@gmail.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> Message-ID: <556C0E7F.9090308@oracle.com> Hi Peter, On 06/01/2015 12:33 AM, Peter Levart wrote: > On 05/31/2015 11:06 PM, Peter Levart wrote: >> On 05/31/2015 10:58 PM, Peter Levart wrote: >>> This is a noble goal. I will just warn you about the possible >>> initialization problems. String concatenation is a very rudimentary >>> operation and might be used very early in the startup of the JVM. If >>> it is used before the system class loader is initialized (before the >>> main method is executed), you will be faced with the following issue >>> at least: >>> >>> >>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006386.html >>> >>> ...so we might need to fix these early java.lang.invoke >>> initialization problems 1st. >> >> Not to mention that java.lang.invoke infrastructure (at least the part >> that is used to support invokedynamic etc.) should then *not* use >> string concatenation... > > One way to tackle this is to have a javac option to emit classical > StringBuilder-based code and then build the (java.base module at least) > with this option. So only other modules and user code would use indy > based concatenation. If you read my notes about this: http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/notes.txt You will see the mention of "java.base is exempt from indy string concat, otherwise the initialization circularity ensues". Indeed, there is a patch that disables indy string concat for java.base: http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/patch-root-1.patch > This will also eliminate worries about startup time. It would not, because, as I was saying in the notes, the significant time is spent dealing with indy infrastructure for every user string concat. In other words, a simple smoke test with HelloWorld concating a simple string suffers quite a bit. Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jan.lahoda at oracle.com Mon Jun 1 09:29:03 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 01 Jun 2015 11:29:03 +0200 Subject: String concatenation tweaks In-Reply-To: <556C0E7F.9090308@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> Message-ID: <556C25DF.4090503@oracle.com> Hi, While I agree that use of invokedynamic to allow optimized String concatenation is very clever, using invokedynamic for so basic operation seems like an overkill to me. I suppose that many tools that read/analyze/manipulate the classfiles would need understand what this new code is doing etc. Is there any chance JIT could detect and optimize the pattern? The advantage of that would not only be that existing classfiles would get the optimization, and maybe also (some) hand-written String concatenations could get the improved behavior as well? Thanks, Jan On 1.6.2015 09:49, Aleksey Shipilev wrote: > Hi Peter, > > On 06/01/2015 12:33 AM, Peter Levart wrote: >> On 05/31/2015 11:06 PM, Peter Levart wrote: >>> On 05/31/2015 10:58 PM, Peter Levart wrote: >>>> This is a noble goal. I will just warn you about the possible >>>> initialization problems. String concatenation is a very rudimentary >>>> operation and might be used very early in the startup of the JVM. If >>>> it is used before the system class loader is initialized (before the >>>> main method is executed), you will be faced with the following issue >>>> at least: >>>> >>>> >>>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006386.html >>>> >>>> ...so we might need to fix these early java.lang.invoke >>>> initialization problems 1st. >>> >>> Not to mention that java.lang.invoke infrastructure (at least the part >>> that is used to support invokedynamic etc.) should then *not* use >>> string concatenation... >> >> One way to tackle this is to have a javac option to emit classical >> StringBuilder-based code and then build the (java.base module at least) >> with this option. So only other modules and user code would use indy >> based concatenation. > > If you read my notes about this: > http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/notes.txt > > You will see the mention of "java.base is exempt from indy string > concat, otherwise the initialization circularity ensues". Indeed, there > is a patch that disables indy string concat for java.base: > http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/patch-root-1.patch > >> This will also eliminate worries about startup time. > > It would not, because, as I was saying in the notes, the significant > time is spent dealing with indy infrastructure for every user string > concat. In other words, a simple smoke test with HelloWorld concating a > simple string suffers quite a bit. > > Thanks, > -Aleksey. > > From aleksey.shipilev at oracle.com Mon Jun 1 11:09:05 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 01 Jun 2015 14:09:05 +0300 Subject: String concatenation tweaks In-Reply-To: <556C25DF.4090503@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C25DF.4090503@oracle.com> Message-ID: <556C3D51.6000008@oracle.com> Hi Jan, Thanks for pointing out this alternative, I should add it to JEP "Alternatives" section. See below: On 06/01/2015 12:29 PM, Jan Lahoda wrote: > While I agree that use of invokedynamic to allow optimized String > concatenation is very clever, using invokedynamic for so basic operation > seems like an overkill to me. I suppose that many tools that > read/analyze/manipulate the classfiles would need understand what this > new code is doing etc. Think about indy here as the declaration of the intent. Yes, it will require tools to recognize that (newly shaped) intent. But we've been that path before with lambda translation. Having this new bytecode shape is one of the reasons why we better do it in the upcoming *major* release. The overheads, even in current (crude) prototype are about the first linkage of indy callsite, when we need to expand on the intent -- this is what crude startup tests are trying to show. There should be not much of a difference (if any) after the indy had linked, i.e. when we reach the steady state. > Is there any chance JIT could detect and optimize the pattern? The > advantage of that would not only be that existing classfiles would get > the optimization, and maybe also (some) hand-written String > concatenations could get the improved behavior as well? C2 already optimizes quite a few StringBuilder append chains (see -XX:+-OptimizeStringConcat [1]), but not all of them. In fact, Louis told us that their "precompute the final String length" trick improves performance beyond what OptoStringConcat does today. There are two types of troubles I see with extending OptoStringConcat to more cases: a) The need to recognize the code shape emitted by javac. The minute differences in the bytecode shape break OptoStringConcat, as we saw in this work already. This is somewhat alleviated if we agree to keep the javac-generated code shape to stay in current form forever and ever. (There also was a funny thread on StackOverflow about the differences in Eclipse's compiler vs Oracle's javac when it comes to String concat, but I can't find it now). b) Optimizing at JIT compiler side will require spelling out the toString conversions and storage management on C2 IR. See e.g. the rewrite of corresponding Java code in PhaseStringOpts::int_getChars [1]. JIT optimizations, in fact, make the whole business *less* observable than just a plain bytecode and/or MH combinators. There is a careful balance between what JIT compiler can recognize, and what it should be forced to recognize. Clearly demarcating the intent to "concat" helps to recognize the idiom. The choice of indy is incidental here: it actually covers the case when compiler cannot recognize the idiom, and we need to end up running almost the same bytecode sequence as javac currently generates. If that was not an issue, and we did not care about the fallback performance, we might as well do java.lang.StringConcat::concat(Object... args), ask JIT to eliminate the boxing in primitive args and the array for varargs call, provide a fallback implementation in Java for the cases JIT refuses to optimize, and be done by lunch. On a top of that, let's ask the philosophical question: if JIT recognizes the StringBuilder append chain with default initial capacity, can/should it really replace it with an optimized concat code? Or, that is just an accident from inability to disambiguate javac's generated bytecode sequence (which actually spells "don't care about the capacity at this point, this is just the concat, go wild") from a genuine user code (which *may* spell "I am relying on default capacity rules as described in StringBuilder Javadocs")? Thanks, -Aleksey. [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/ac6a7b63d701/src/share/vm/opto/stringopts.cpp > On 1.6.2015 09:49, Aleksey Shipilev wrote: >> Hi Peter, >> >> On 06/01/2015 12:33 AM, Peter Levart wrote: >>> On 05/31/2015 11:06 PM, Peter Levart wrote: >>>> On 05/31/2015 10:58 PM, Peter Levart wrote: >>>>> This is a noble goal. I will just warn you about the possible >>>>> initialization problems. String concatenation is a very rudimentary >>>>> operation and might be used very early in the startup of the JVM. If >>>>> it is used before the system class loader is initialized (before the >>>>> main method is executed), you will be faced with the following issue >>>>> at least: >>>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006386.html >>>>> >>>>> ...so we might need to fix these early java.lang.invoke >>>>> initialization problems 1st. >>>> >>>> Not to mention that java.lang.invoke infrastructure (at least the part >>>> that is used to support invokedynamic etc.) should then *not* use >>>> string concatenation... >>> >>> One way to tackle this is to have a javac option to emit classical >>> StringBuilder-based code and then build the (java.base module at least) >>> with this option. So only other modules and user code would use indy >>> based concatenation. >> >> If you read my notes about this: >> http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/notes.txt >> >> You will see the mention of "java.base is exempt from indy string >> concat, otherwise the initialization circularity ensues". Indeed, there >> is a patch that disables indy string concat for java.base: >> >> http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/patch-root-1.patch >> >> >>> This will also eliminate worries about startup time. >> >> It would not, because, as I was saying in the notes, the significant >> time is spent dealing with indy infrastructure for every user string >> concat. In other words, a simple smoke test with HelloWorld concating a >> simple string suffers quite a bit. >> >> Thanks, >> -Aleksey. >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From peter.levart at gmail.com Mon Jun 1 13:38:44 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 01 Jun 2015 15:38:44 +0200 Subject: String concatenation tweaks In-Reply-To: <556C0E7F.9090308@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> Message-ID: <556C6064.5080704@gmail.com> Hi Aleksey, On 06/01/2015 09:49 AM, Aleksey Shipilev wrote: > Hi Peter, > > On 06/01/2015 12:33 AM, Peter Levart wrote: >> One way to tackle this is to have a javac option to emit classical >> StringBuilder-based code and then build the (java.base module at least) >> with this option. So only other modules and user code would use indy >> based concatenation. > If you read my notes about this: > http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/notes.txt > > You will see the mention of "java.base is exempt from indy string > concat, otherwise the initialization circularity ensues". Indeed, there > is a patch that disables indy string concat for java.base: > http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/patch-root-1.patch I must have missed that. Thanks for pointing out. > >> This will also eliminate worries about startup time. > It would not, because, as I was saying in the notes, the significant > time is spent dealing with indy infrastructure for every user string > concat. In other words, a simple smoke test with HelloWorld concating a > simple string suffers quite a bit. That's the overhead of initializing (generating) code for each new unused shape? If the same shape repeats at some other call-site, then it should already be cached, right? One thing I noticed after briefly checking the code is the following. Javac, as I understand, emits the invokedynamic using compile-time argument types. From them the MethodType is constructed when the indy is invoked the 1st time and gets passed to the bootstrap method. Are the argument types truncated or passed as compiler knows them? Passing more type info might at first seem beneficial to potential strategies that might use it to construct better specializations, but semantically we don't need all the reference types. StringBuilder.append() overloads only differentiate among 4 distinct reference types: Object, String, StringBuffer, CharSequence But internally StringBuilder actually dispatches dynamically to 5 different run-time cases and treats them differently: null, Object, String, AbstractStringBuilder, CharSequence Javac could truncate the reference types to one of the above 5 before emitting invokedynamic. The null literal value could be passed via the Void parameter type to differentiate it from other types. Why is truncating necessary? - the key space for the cached shapes is reduced this way. There are only 8 primitive + 5 reference = 13 types possible at each argument position this way. - passing truncated reference types to invokedynamic means that the bootstrap method doesn't have to do the truncation. - the truncation has to be performed anyway to get rid of custom/user reference types which, if used in the MethodType key for caching, will cause Class[Loader] leaks. What do you think? Regards, Peter From aleksey.shipilev at oracle.com Mon Jun 1 14:52:56 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 01 Jun 2015 17:52:56 +0300 Subject: String concatenation tweaks In-Reply-To: <556C6064.5080704@gmail.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> Message-ID: <556C71C8.6090109@oracle.com> Hi Peter, On 06/01/2015 04:38 PM, Peter Levart wrote: > On 06/01/2015 09:49 AM, Aleksey Shipilev wrote: >> On 06/01/2015 12:33 AM, Peter Levart wrote: >>> This will also eliminate worries about startup time. >> It would not, because, as I was saying in the notes, the significant >> time is spent dealing with indy infrastructure for every user string >> concat. In other words, a simple smoke test with HelloWorld concating a >> simple string suffers quite a bit. > > That's the overhead of initializing (generating) code for each new > unused shape? If the same shape repeats at some other call-site, then it > should already be cached, right? I haven't quantified carefully it yet, but a brief look at profiles point fingers at actual construction, yes. The cached shapes are not showing up in profiles. But again, I should construct more accurate stress test for it. > One thing I noticed after briefly checking the code is the following. > Javac, as I understand, emits the invokedynamic using compile-time > argument types. From them the MethodType is constructed when the indy is > invoked the 1st time and gets passed to the bootstrap method. Are the > argument types truncated or passed as compiler knows them? Yes, we pass the exact types javac knows about. Sometimes it is problematic, since we need to substitute a bottom type (null) with something else. Current prototype says it's Object.class. I don't fully understand if Void is a good substitute for a bottom type. Is it? Asking for a compiler friend here. > Passing more > type info might at first seem beneficial to potential strategies that > might use it to construct better specializations, but semantically we > don't need all the reference types. StringBuilder.append() overloads > only differentiate among 4 distinct reference types: > > Object, String, StringBuffer, CharSequence > > But internally StringBuilder actually dispatches dynamically to 5 > different run-time cases and treats them differently: > > null, Object, String, AbstractStringBuilder, CharSequence > > Javac could truncate the reference types to one of the above 5 before > emitting invokedynamic. The null literal value could be passed via the > Void parameter type to differentiate it from other types. Why is > truncating necessary? > > - the key space for the cached shapes is reduced this way. There are > only 8 primitive + 5 reference = 13 types possible at each argument > position this way. > - passing truncated reference types to invokedynamic means that the > bootstrap method doesn't have to do the truncation. > - the truncation has to be performed anyway to get rid of custom/user > reference types which, if used in the MethodType key for caching, will > cause Class[Loader] leaks. > > What do you think? I think since we need to get the javac bytecode part future-proof, we are better off passing the concrete type info to the indy bootstrap. Bootstrap can then decide if it wants to collapse the types back to those 4-5 variants, solving both the explosion of shapes, and the class leaks. (Note to self: current prototype collapses the types *after* checking with cache, need to fix that possible class leak, thanks!) We are not inherently limited with StringBuilder API to do the concatenation. This compiler improvement actually opens up the way for specialized implementations that span more than just current 4 reference types. Example case: would it make sense to null-check and unbox Integer before pushing it on to append() chain? This will set us up for OptoStringConcat for new SB().append(String).append(Integer).toString() :) Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jan.lahoda at oracle.com Mon Jun 1 15:56:04 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 01 Jun 2015 17:56:04 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <5565B730.5030602@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> Message-ID: <556C8094.3050800@oracle.com> Hi, I made a somewhat bigger update (partially based on other feedback). Summary of changes: -the history data has been moved into langtools (I also moved the Ctsym.gmk) -there are JDK 6 data now -renamed the "-platform" option to "-release". Code/tests directly related to the option has been also changed as well. I kept the internal PlatformProvider API in javac as is, and also kept related code. -added a note that the is generated by CreateSymbols. Webrevs: top-level: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ langtools: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ Delta webrevs are also available. How does this look? Thanks for the comments so far! Jan On 27.5.2015 14:23, Jan Lahoda wrote: > Ah, yes, I did not realize that. Thanks, will fix. > > Thanks, > Jan > > On 27.5.2015 11:59, Maurizio Cimadamore wrote: >> Looks great. The only nitpick is that the comments in CreateSymbols >> don't mention the fact that a side effect of the sym.txt generation is >> the mentioned earlier in the same comments >> (so one might wonder where does that come from). >> >> Maurizio >> >> On 27/05/15 10:37, Jan Lahoda wrote: >>> Hi, >>> >>> I've uploaded another iteration, with these changes: >>> -the "symbols" file is now generated automatically (for the typical >>> OpenJDK case). >>> -fixed a minor issue in CreateSymbols that could cause putting class >>> description into wrong a file (the "break" -> "break OUTER;" change). >>> -jdk.management module has been split out from java.management >>> recently, so splitting the corresponding .sym.txt files into >>> java.management and jdk.management as well. >>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>> >>> Webrevs: >>> -top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>> -langtools (no changes against the last webrev): >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>> >>> Delta webrevs against the previous iteration are included under >>> "Author comments". >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>> Excellent work. >>>>> >>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>> Probe >>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>> >>>>> /bin/java Probe --> classes-8 >>>>> /bin/java Probe --> classes-7 >>>>> /bin/java Probe --> classes-7 >>>>> >>>>> etc. >>>> >>>> Sure, will do. >>>> >>>> I'll also look at generating the make/data/symbols/symbols descriptions >>>> automatically, per our offline discussion. >>>> >>>> Thanks! >>>> >>>> Jan >>>> >>>>> >>>>> Maurizio >>>>> >>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded a new iteration of the patch(es): >>>>>> top-level repository: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>> langtools: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>> >>>>>> (besides full webrevs, there are also webrevs showing the differences >>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>> "Author's comments") >>>>>> >>>>>> Summary of changes: >>>>>> -applied Eric's build changes >>>>>> -moved CreateSymbols into >>>>>> make/src/classes/build/tools/symbolgenerator >>>>>> -tried to improve the specification of base platforms in >>>>>> CreateSymbols, per Maurizio's comment >>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>>> >>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>> Hi Jan, >>>>>>> great work - couple of comments below: >>>>>>> >>>>>>> * it seems like some of the routines in Arguments can be simplified >>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>> checkOptionAllowed >>>>>>> * Why JDKPlatformProvider is not called >>>>>>> JDKPlatformProvider*Factory* ? >>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>> commonalities >>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>> this a >>>>>>> bit? >>>>>>> * What's the rationale for giving an error if -platform is specified >>>>>>> and >>>>>>> a non-StandardFileManager is provided? Can't we simply swallow that, >>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>> * Would it make sense for some of the classfile generation logic in >>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>> * I had hard time reconciling some of the comments in CreateSymbols >>>>>>> with >>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>> that >>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>> (i.e. 8) >>>>>>> and then generate diffs for 9 and 7 against the 8 one. If that's the >>>>>>> use >>>>>>> case, I think the command line can be simplified a bit in order to >>>>>>> explicitly state which of the platform is the baseline one, and the >>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>> seem to be typically all >>>>>>> identical >>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>> the >>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>> 7 and >>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>> should be >>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>> there >>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>> >>>>>>>> Patch for the top-level repository is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>> >>>>>>>> Patch for the langtools repository is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>> >>>>>>>> These changes also require additional langtools changes as their >>>>>>>> prerequisite: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>> >>>>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>> values >>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>> correspond to >>>>>>>> Open JDK 7 and 8 GA. >>>>>>>> >>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>> N. The >>>>>>>> proposal is to include history data in the textual format inside >>>>>>>> the >>>>>>>> OpenJDK repositories (the input data), process them at build time >>>>>>>> and >>>>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>>>> running with the -platform option then compiles against the >>>>>>>> lib/ct.sym >>>>>>>> file. The input history data are placed >>>>>>>> /make/data/symbols (the sym.txt files). This >>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for public >>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>> >>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>> checkout and >>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>> significantly >>>>>>>> if additional classes/elements, like non-public API classes, would >>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>> >>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>> them as >>>>>>>> classfiles), but are missing some attributes, most notably the Code >>>>>>>> attribute. On the top-level, the ct.sym contains directories named >>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>> bootclasspath >>>>>>>> for that version is obtained by using directories which have 'N' in >>>>>>>> their name. >>>>>>>> >>>>>>>> The sigfiles for ct.sym are created by >>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>> >>>>>>>> >>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>> Concise >>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>> >>>>>>>> I am sending this as one review, as the changes together make one >>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>> to a >>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>> and the >>>>>>>> top-level changes add the history data and ability to build the >>>>>>>> ct.sym >>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>> independently. >>>>>>>> >>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>>>>>>> Bateman and others who have provided advices and help on the matter >>>>>>>> before. >>>>>>>> >>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>> >>>>> >> From joe.darcy at oracle.com Mon Jun 1 17:08:35 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 01 Jun 2015 10:08:35 -0700 Subject: JDK 9 RFR of JDK-8075546: Add tiered testing definitions to the langtools repo In-Reply-To: <556BD37D.7090508@oracle.com> References: <556BD37D.7090508@oracle.com> Message-ID: <556C9193.2050401@oracle.com> PS Upon further reflection, I think it would be preferable rather than defining the keywords recognized in langtools to be keys=2d dnd i18n intermittent randomness to instead just have keys=intermittent randomness Thanks, -Joe On 5/31/2015 8:37 PM, joe darcy wrote: > Hello, > > As part of implementing the tiered testing policy in JDK 9 [1], please > review the changes for > > 8075546: Add tiered testing definitions to the langtools repo > http://cr.openjdk.java.net/~darcy/8075546.0/ > > A few comments, I've made the TEST.ROOT file in langtools consistent > with the keywords and minimum jtreg version used in the jdk repo. > > The one javadoc test GetTask_DocletClassTest.java uses randomness and > I've marked it accordingly. > > I've created an empty problem list file so that command lines to > invoke the test suites for a repository can be more uniform across > repositories. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From jonathan.gibbons at oracle.com Mon Jun 1 22:17:02 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 01 Jun 2015 15:17:02 -0700 Subject: JDK 9 RFR of JDK-8075546: Add tiered testing definitions to the langtools repo In-Reply-To: <556C9193.2050401@oracle.com> References: <556BD37D.7090508@oracle.com> <556C9193.2050401@oracle.com> Message-ID: <556CD9DE.40500@oracle.com> Looks good to me. It looks like there are opportunities for additional followup cleanup for rationalizing use of @ignore and ProblemList across repos. -- Jon On 06/01/2015 10:08 AM, joe darcy wrote: > PS Upon further reflection, I think it would be preferable rather than > defining the keywords recognized in langtools to be > > keys=2d dnd i18n intermittent randomness > > to instead just have > > keys=intermittent randomness > > Thanks, > > -Joe > > On 5/31/2015 8:37 PM, joe darcy wrote: >> Hello, >> >> As part of implementing the tiered testing policy in JDK 9 [1], >> please review the changes for >> >> 8075546: Add tiered testing definitions to the langtools repo >> http://cr.openjdk.java.net/~darcy/8075546.0/ >> >> A few comments, I've made the TEST.ROOT file in langtools consistent >> with the keywords and minimum jtreg version used in the jdk repo. >> >> The one javadoc test GetTask_DocletClassTest.java uses randomness and >> I've marked it accordingly. >> >> I've created an empty problem list file so that command lines to >> invoke the test suites for a repository can be more uniform across >> repositories. >> >> Thanks, >> >> -Joe >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html > From peter.levart at gmail.com Mon Jun 1 23:04:33 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 02 Jun 2015 01:04:33 +0200 Subject: String concatenation tweaks In-Reply-To: <556C71C8.6090109@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> Message-ID: <556CE501.4040009@gmail.com> Hi Aleksey, On 06/01/2015 04:52 PM, Aleksey Shipilev wrote: >> >Passing more >> >type info might at first seem beneficial to potential strategies that >> >might use it to construct better specializations, but semantically we >> >don't need all the reference types. StringBuilder.append() overloads >> >only differentiate among 4 distinct reference types: >> > >> > Object, String, StringBuffer, CharSequence >> > >> >But internally StringBuilder actually dispatches dynamically to 5 >> >different run-time cases and treats them differently: >> > >> > null, Object, String, AbstractStringBuilder, CharSequence >> > >> >Javac could truncate the reference types to one of the above 5 before >> >emitting invokedynamic. The null literal value could be passed via the >> >Void parameter type to differentiate it from other types. Why is >> >truncating necessary? >> > >> >- the key space for the cached shapes is reduced this way. There are >> >only 8 primitive + 5 reference = 13 types possible at each argument >> >position this way. >> >- passing truncated reference types to invokedynamic means that the >> >bootstrap method doesn't have to do the truncation. >> >- the truncation has to be performed anyway to get rid of custom/user >> >reference types which, if used in the MethodType key for caching, will >> >cause Class[Loader] leaks. >> > >> >What do you think? > I think since we need to get the javac bytecode part future-proof, we > are better off passing the concrete type info to the indy bootstrap. > Bootstrap can then decide if it wants to collapse the types back to > those 4-5 variants, solving both the explosion of shapes, and the class > leaks. String concatenation actually needs just two reference types (maybe three if you want to optimize for the literal null as a special type which is really a very rare case in practice). The JLS says that '+' binary operator where at least one of the arguments is of String type is string concatenation operator. If the other argument is not of String type then it must be converted to String type via String conversion: https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.11 Which says that .toString() needs to be called if the argument is a reference type other than String and not null at runtime. I checked javac and yes, it emits code which only ever invokes two of the overloaded StringBuilder.append() methods for reference type arguments: append(String); append(Object); so the following expression: "a" + new StringBuffer("b") ...is actually translated to equivalent of: new StringBuilder().append("a").append((Object) new StringBuffer("b")).toString() .. the 'new StringBuffer("b")' argument is translated .toString() 1st and then appended. If the overloaded append method for StringBuffer argument was used, then .getChars() would be invoked on the argument instead to copy chars directly. The same happens if the argument type is CharSequence. Does this subtle detail need to be respected or can dirty tricks be played with known types to "optimize" their conversion to String without actually invoking .toString() or even creating an intermediary String object? Also the String Conversion specification says that in case the .toString() method returns null, then "null" string is a result of such String conversion. So there have to be 2 null checks for reference arguments - before and after .toString() call. Regarding future-proof translation. Do you think that in the future, JLS could change and say that some pre-existing reference type different from String is to be treated differently than before? There might be some future reference type that is to be treated differently, but such type does not exist in bytecode compiled before the type is invented. So if you only put String,Object,null into bytecode now, it should be future proof and the set of truncated reference types can be extended in the future. Also I don't think string concatenation will ever want to know the precise compile-time types of the reference typed arguments apart from the three mentioned: String, Object, null, unless it wants to play dirty tricks with some types to "optimize" String conversion (like StringBuilder.append(StringBuffer) does for example). Regards, Peter > (Note to self: current prototype collapses the types*after* checking > with cache, need to fix that possible class leak, thanks!) > > We are not inherently limited with StringBuilder API to do the > concatenation. This compiler improvement actually opens up the way for > specialized implementations that span more than just current 4 reference > types. > > Example case: would it make sense to null-check and unbox Integer before > pushing it on to append() chain? This will set us up for > OptoStringConcat for new SB().append(String).append(Integer).toString():) What is Integer at compile time can always be null at runtime: Integer i = null; System.out.println("i=" + i); > Thanks, > -Aleksey. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Jun 2 02:39:03 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 1 Jun 2015 19:39:03 -0700 Subject: String concatenation tweaks In-Reply-To: <556C71C8.6090109@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> Message-ID: <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> On Jun 1, 2015, at 7:52 AM, Aleksey Shipilev wrote: > > Hi Peter, > >> On 06/01/2015 04:38 PM, Peter Levart wrote: >>> On 06/01/2015 09:49 AM, Aleksey Shipilev wrote: >>>> On 06/01/2015 12:33 AM, Peter Levart wrote: >>>> This will also eliminate worries about startup time. >>> It would not, because, as I was saying in the notes, the significant >>> time is spent dealing with indy infrastructure for every user string >>> concat. In other words, a simple smoke test with HelloWorld concating a >>> simple string suffers quite a bit. >> >> That's the overhead of initializing (generating) code for each new >> unused shape? If the same shape repeats at some other call-site, then it >> should already be cached, right? > > I haven't quantified carefully it yet, but a brief look at profiles > point fingers at actual construction, yes. The cached shapes are not > showing up in profiles. But again, I should construct more accurate > stress test for it. > > >> One thing I noticed after briefly checking the code is the following. >> Javac, as I understand, emits the invokedynamic using compile-time >> argument types. From them the MethodType is constructed when the indy is >> invoked the 1st time and gets passed to the bootstrap method. Are the >> argument types truncated or passed as compiler knows them? > > Yes, we pass the exact types javac knows about. Sometimes it is > problematic, since we need to substitute a bottom type (null) with > something else. Current prototype says it's Object.class. > > I don't fully understand if Void is a good substitute for a bottom type. > Is it? Asking for a compiler friend here. Void is the convention used by MH.invoke and it works here too. The only ref of that type is null. > >> Passing more >> type info might at first seem beneficial to potential strategies that >> might use it to construct better specializations, but semantically we >> don't need all the reference types. StringBuilder.append() overloads >> only differentiate among 4 distinct reference types: >> >> Object, String, StringBuffer, CharSequence >> >> But internally StringBuilder actually dispatches dynamically to 5 >> different run-time cases and treats them differently: >> >> null, Object, String, AbstractStringBuilder, CharSequence >> >> Javac could truncate the reference types to one of the above 5 before >> emitting invokedynamic. The null literal value could be passed via the >> Void parameter type to differentiate it from other types. Why is >> truncating necessary? >> >> - the key space for the cached shapes is reduced this way. There are >> only 8 primitive + 5 reference = 13 types possible at each argument >> position this way. >> - passing truncated reference types to invokedynamic means that the >> bootstrap method doesn't have to do the truncation. >> - the truncation has to be performed anyway to get rid of custom/user >> reference types which, if used in the MethodType key for caching, will >> cause Class[Loader] leaks. >> >> What do you think? > > I think since we need to get the javac bytecode part future-proof, we > are better off passing the concrete type info to the indy bootstrap. > Bootstrap can then decide if it wants to collapse the types back to > those 4-5 variants, solving both the explosion of shapes, and the class > leaks. That sounds reasonable. This is an intended use pattern for Indy?to capture accurate static types. > (Note to self: current prototype collapses the types *after* checking > with cache, need to fix that possible class leak, thanks! Yep. A late asType call will fix things up. We can optimize the pattern more if needed. > We are not inherently limited with StringBuilder API to do the > concatenation. This compiler improvement actually opens up the way for > specialized implementations that span more than just current 4 reference > types. > > Example case: would it make sense to null-check and unbox Integer before > pushing it on to append() chain? This will set us up for > OptoStringConcat for new SB().append(String).append(Integer).toString() :) Yes. You could express this quite directly with a filterArgs or asType transform. If that creates too many LFs we can optimize that also. Note to other self: asType LFs are not well cached at present. Fix. ? John > Thanks, > -Aleksey. > > > > From erik.joelsson at oracle.com Tue Jun 2 14:04:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 16:04:25 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556C8094.3050800@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> Message-ID: <556DB7E9.7090709@oracle.com> Hello Jan, Sorry to bother you with even more build changes, but with these file moves, I realized that this new file, ct.sym, is really a part of the jdk.compiler module and really not a special case at all. Because of this, it should be generated as part of the jdk.compiler-gendata target. This also eliminates all the changes in the top level repo and only leaves one new makefile in the langtools repo. http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ /Erik On 2015-06-01 17:56, Jan Lahoda wrote: > Hi, > > I made a somewhat bigger update (partially based on other feedback). > Summary of changes: > -the history data has been moved into langtools (I also moved the > Ctsym.gmk) > -there are JDK 6 data now > -renamed the "-platform" option to "-release". Code/tests directly > related to the option has been also changed as well. I kept the > internal PlatformProvider API in javac as is, and also kept related code. > -added a note that the is generated by > CreateSymbols. > > Webrevs: > top-level: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ > langtools: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ > > Delta webrevs are also available. > > How does this look? > > Thanks for the comments so far! > > Jan > > On 27.5.2015 14:23, Jan Lahoda wrote: >> Ah, yes, I did not realize that. Thanks, will fix. >> >> Thanks, >> Jan >> >> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>> Looks great. The only nitpick is that the comments in CreateSymbols >>> don't mention the fact that a side effect of the sym.txt generation is >>> the mentioned earlier in the same comments >>> (so one might wonder where does that come from). >>> >>> Maurizio >>> >>> On 27/05/15 10:37, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I've uploaded another iteration, with these changes: >>>> -the "symbols" file is now generated automatically (for the typical >>>> OpenJDK case). >>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>> description into wrong a file (the "break" -> "break OUTER;" change). >>>> -jdk.management module has been split out from java.management >>>> recently, so splitting the corresponding .sym.txt files into >>>> java.management and jdk.management as well. >>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>> >>>> Webrevs: >>>> -top-level: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>> -langtools (no changes against the last webrev): >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>> >>>> Delta webrevs against the previous iteration are included under >>>> "Author comments". >>>> >>>> Thanks for the comments so far! >>>> >>>> Jan >>>> >>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>> Excellent work. >>>>>> >>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>> Probe >>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>> >>>>>> /bin/java Probe --> classes-8 >>>>>> /bin/java Probe --> classes-7 >>>>>> /bin/java Probe --> classes-7 >>>>>> >>>>>> etc. >>>>> >>>>> Sure, will do. >>>>> >>>>> I'll also look at generating the make/data/symbols/symbols >>>>> descriptions >>>>> automatically, per our offline discussion. >>>>> >>>>> Thanks! >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>> top-level repository: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>> langtools: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>> >>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>> differences >>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>> "Author's comments") >>>>>>> >>>>>>> Summary of changes: >>>>>>> -applied Eric's build changes >>>>>>> -moved CreateSymbols into >>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>> -tried to improve the specification of base platforms in >>>>>>> CreateSymbols, per Maurizio's comment >>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>>> >>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>> Hi Jan, >>>>>>>> great work - couple of comments below: >>>>>>>> >>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>> simplified >>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>> checkOptionAllowed >>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>> commonalities >>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>> this a >>>>>>>> bit? >>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>> specified >>>>>>>> and >>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>> that, >>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>> logic in >>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>> CreateSymbols >>>>>>>> with >>>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>>> that >>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>> (i.e. 8) >>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>> that's the >>>>>>>> use >>>>>>>> case, I think the command line can be simplified a bit in order to >>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>> the >>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>> seem to be typically all >>>>>>>> identical >>>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>>> the >>>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>>> 7 and >>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>> should be >>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>> there >>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>> >>>>>>>>> Patch for the top-level repository is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>> >>>>>>>>> Patch for the langtools repository is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>> >>>>>>>>> These changes also require additional langtools changes as their >>>>>>>>> prerequisite: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>> >>>>>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>> values >>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>> correspond to >>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>> >>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>> N. The >>>>>>>>> proposal is to include history data in the textual format inside >>>>>>>>> the >>>>>>>>> OpenJDK repositories (the input data), process them at build time >>>>>>>>> and >>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>>>>> running with the -platform option then compiles against the >>>>>>>>> lib/ct.sym >>>>>>>>> file. The input history data are placed >>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>> This >>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>> public >>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>> >>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>> checkout and >>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>> significantly >>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>> would >>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>> >>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>> them as >>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>> Code >>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>> named >>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>> bootclasspath >>>>>>>>> for that version is obtained by using directories which have >>>>>>>>> 'N' in >>>>>>>>> their name. >>>>>>>>> >>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>> Concise >>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>> >>>>>>>>> I am sending this as one review, as the changes together make one >>>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>>> to a >>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>> and the >>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>> ct.sym >>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>> independently. >>>>>>>>> >>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>> Alan >>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>> matter >>>>>>>>> before. >>>>>>>>> >>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>> >>>>>> >>> From jan.lahoda at oracle.com Tue Jun 2 16:50:52 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 02 Jun 2015 18:50:52 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DB7E9.7090709@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> Message-ID: <556DDEEC.2000505@oracle.com> Hello Eric, Thanks for the change, this seems definitely better to me. I've folded your change that into my patch. An updated version (just langtools this time): http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ Thanks! Jan On 2.6.2015 16:04, Erik Joelsson wrote: > Hello Jan, > > Sorry to bother you with even more build changes, but with these file > moves, I realized that this new file, ct.sym, is really a part of the > jdk.compiler module and really not a special case at all. Because of > this, it should be generated as part of the jdk.compiler-gendata target. > This also eliminates all the changes in the top level repo and only > leaves one new makefile in the langtools repo. > > http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ > > /Erik > > On 2015-06-01 17:56, Jan Lahoda wrote: >> Hi, >> >> I made a somewhat bigger update (partially based on other feedback). >> Summary of changes: >> -the history data has been moved into langtools (I also moved the >> Ctsym.gmk) >> -there are JDK 6 data now >> -renamed the "-platform" option to "-release". Code/tests directly >> related to the option has been also changed as well. I kept the >> internal PlatformProvider API in javac as is, and also kept related code. >> -added a note that the is generated by >> CreateSymbols. >> >> Webrevs: >> top-level: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >> langtools: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >> >> Delta webrevs are also available. >> >> How does this look? >> >> Thanks for the comments so far! >> >> Jan >> >> On 27.5.2015 14:23, Jan Lahoda wrote: >>> Ah, yes, I did not realize that. Thanks, will fix. >>> >>> Thanks, >>> Jan >>> >>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>> don't mention the fact that a side effect of the sym.txt generation is >>>> the mentioned earlier in the same comments >>>> (so one might wonder where does that come from). >>>> >>>> Maurizio >>>> >>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I've uploaded another iteration, with these changes: >>>>> -the "symbols" file is now generated automatically (for the typical >>>>> OpenJDK case). >>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>> description into wrong a file (the "break" -> "break OUTER;" change). >>>>> -jdk.management module has been split out from java.management >>>>> recently, so splitting the corresponding .sym.txt files into >>>>> java.management and jdk.management as well. >>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>> >>>>> Webrevs: >>>>> -top-level: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>> -langtools (no changes against the last webrev): >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>> >>>>> Delta webrevs against the previous iteration are included under >>>>> "Author comments". >>>>> >>>>> Thanks for the comments so far! >>>>> >>>>> Jan >>>>> >>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>> Excellent work. >>>>>>> >>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>> Probe >>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>> >>>>>>> /bin/java Probe --> classes-8 >>>>>>> /bin/java Probe --> classes-7 >>>>>>> /bin/java Probe --> classes-7 >>>>>>> >>>>>>> etc. >>>>>> >>>>>> Sure, will do. >>>>>> >>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>> descriptions >>>>>> automatically, per our offline discussion. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jan >>>>>> >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>> top-level repository: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>> langtools: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>> >>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>> differences >>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>> "Author's comments") >>>>>>>> >>>>>>>> Summary of changes: >>>>>>>> -applied Eric's build changes >>>>>>>> -moved CreateSymbols into >>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>> -tried to improve the specification of base platforms in >>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>>> >>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>> Hi Jan, >>>>>>>>> great work - couple of comments below: >>>>>>>>> >>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>> simplified >>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>> checkOptionAllowed >>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>> commonalities >>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>> this a >>>>>>>>> bit? >>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>> specified >>>>>>>>> and >>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>> that, >>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>> logic in >>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>> CreateSymbols >>>>>>>>> with >>>>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>>>> that >>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>> (i.e. 8) >>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>> that's the >>>>>>>>> use >>>>>>>>> case, I think the command line can be simplified a bit in order to >>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>> the >>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>> seem to be typically all >>>>>>>>> identical >>>>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>>>> the >>>>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>>>> 7 and >>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>> should be >>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>> there >>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>> >>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>> >>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>> >>>>>>>>>> These changes also require additional langtools changes as their >>>>>>>>>> prerequisite: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>> >>>>>>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>> values >>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>> correspond to >>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>> >>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>> N. The >>>>>>>>>> proposal is to include history data in the textual format inside >>>>>>>>>> the >>>>>>>>>> OpenJDK repositories (the input data), process them at build time >>>>>>>>>> and >>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>> lib/ct.sym >>>>>>>>>> file. The input history data are placed >>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>> This >>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>> public >>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>> >>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>> checkout and >>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>> significantly >>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>> would >>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>> >>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>> them as >>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>> Code >>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>> named >>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>> bootclasspath >>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>> 'N' in >>>>>>>>>> their name. >>>>>>>>>> >>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>> Concise >>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>> >>>>>>>>>> I am sending this as one review, as the changes together make one >>>>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>>>> to a >>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>> and the >>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>> ct.sym >>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>> independently. >>>>>>>>>> >>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>> Alan >>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>> matter >>>>>>>>>> before. >>>>>>>>>> >>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jan >>>>>>>>> >>>>>>> >>>> > From georgiy.rakov at oracle.com Tue Jun 2 17:37:32 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Tue, 02 Jun 2015 20:37:32 +0300 Subject: Anonymous classes with diamond, subexpression excludes bounds of type variable Message-ID: <556DE9DC.7000500@oracle.com> Hello, new assertion for the new "anonymous classes with diamond" feature specified in JDK-8073593 comment states: The term "subexpression" includes type arguments of parameterized types (4.5), bounds of wildcards (4.5.1), and element types of array types (10.1). /_*It excludes bounds of type variables*_/.*** The part of assertion I'm interested in is emphasized above. Could you please tell if you consider this part of assertion as testable and if you do could you please provide the example of the code verifying this assertion. The example I can think out is presented below: class Foo {...} that is type variable U is bounded by type variable T which can be inferred as a capture variable, inaccessible type or intersection type. But if this happens instance creation of anonymous Foo class will still result in compiler error because Foo will get parameterized by the inferred type T (T is a Foo type variable besides the fact that it's a bound of U). Thank you, Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Wed Jun 3 08:35:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Jun 2015 10:35:06 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DDEEC.2000505@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> Message-ID: <556EBC3A.8030605@oracle.com> On 2015-06-02 18:50, Jan Lahoda wrote: > Hello Eric, > > Thanks for the change, this seems definitely better to me. I've folded > your change that into my patch. An updated version (just langtools > this time): > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ > > Thanks! From a build perspective, this looks good - nah, awesome! :) - to me. /Magnus > > Jan > > On 2.6.2015 16:04, Erik Joelsson wrote: >> Hello Jan, >> >> Sorry to bother you with even more build changes, but with these file >> moves, I realized that this new file, ct.sym, is really a part of the >> jdk.compiler module and really not a special case at all. Because of >> this, it should be generated as part of the jdk.compiler-gendata target. >> This also eliminates all the changes in the top level repo and only >> leaves one new makefile in the langtools repo. >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >> >> /Erik >> >> On 2015-06-01 17:56, Jan Lahoda wrote: >>> Hi, >>> >>> I made a somewhat bigger update (partially based on other feedback). >>> Summary of changes: >>> -the history data has been moved into langtools (I also moved the >>> Ctsym.gmk) >>> -there are JDK 6 data now >>> -renamed the "-platform" option to "-release". Code/tests directly >>> related to the option has been also changed as well. I kept the >>> internal PlatformProvider API in javac as is, and also kept related >>> code. >>> -added a note that the is generated by >>> CreateSymbols. >>> >>> Webrevs: >>> top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>> langtools: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>> >>> Delta webrevs are also available. >>> >>> How does this look? >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>> Ah, yes, I did not realize that. Thanks, will fix. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>> don't mention the fact that a side effect of the sym.txt >>>>> generation is >>>>> the mentioned earlier in the same >>>>> comments >>>>> (so one might wonder where does that come from). >>>>> >>>>> Maurizio >>>>> >>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded another iteration, with these changes: >>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>> OpenJDK case). >>>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>> change). >>>>>> -jdk.management module has been split out from java.management >>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>> java.management and jdk.management as well. >>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>> >>>>>> Webrevs: >>>>>> -top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>> -langtools (no changes against the last webrev): >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>> >>>>>> Delta webrevs against the previous iteration are included under >>>>>> "Author comments". >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>> Excellent work. >>>>>>>> >>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>> Probe >>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>> >>>>>>>> /bin/java Probe --> classes-8 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> >>>>>>>> etc. >>>>>>> >>>>>>> Sure, will do. >>>>>>> >>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>> descriptions >>>>>>> automatically, per our offline discussion. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>> top-level repository: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>> langtools: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>> >>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>> differences >>>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>>> "Author's comments") >>>>>>>>> >>>>>>>>> Summary of changes: >>>>>>>>> -applied Eric's build changes >>>>>>>>> -moved CreateSymbols into >>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> great work - couple of comments below: >>>>>>>>>> >>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>> simplified >>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>> checkOptionAllowed >>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>> commonalities >>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>> this a >>>>>>>>>> bit? >>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>> specified >>>>>>>>>> and >>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>> that, >>>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>> logic in >>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>> CreateSymbols >>>>>>>>>> with >>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>> mean is >>>>>>>>>> that >>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>> (i.e. 8) >>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>> that's the >>>>>>>>>> use >>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>> order to >>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>> the >>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>> seem to be typically all >>>>>>>>>> identical >>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>> Maybe >>>>>>>>>> the >>>>>>>>>> inference logic should be different (i.e. use 8 as a baseline >>>>>>>>>> for >>>>>>>>>> 7 and >>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>> should be >>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>>> there >>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>> >>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>> their >>>>>>>>>>> prerequisite: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>> effect as >>>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>>> values >>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>> correspond to >>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>> >>>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>>> N. The >>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>> inside >>>>>>>>>>> the >>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>> time >>>>>>>>>>> and >>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>> javac >>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>> lib/ct.sym >>>>>>>>>>> file. The input history data are placed >>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>> This >>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>> public >>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>> >>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>> checkout and >>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>> significantly >>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>> would >>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>> >>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>> them as >>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>> Code >>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>> named >>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>> bootclasspath >>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>> 'N' in >>>>>>>>>>> their name. >>>>>>>>>>> >>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>> Concise >>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> I am sending this as one review, as the changes together >>>>>>>>>>> make one >>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>> independent >>>>>>>>>>> to a >>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>> and the >>>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>>> ct.sym >>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>> independently. >>>>>>>>>>> >>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>> Alan >>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>> matter >>>>>>>>>>> before. >>>>>>>>>>> >>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>> >>>>>>>> >>>>> >> From aleksey.shipilev at oracle.com Thu Jun 4 09:21:49 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 12:21:49 +0300 Subject: String concatenation tweaks In-Reply-To: <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> Message-ID: <557018AD.1040308@oracle.com> On 06/02/2015 05:39 AM, John Rose wrote: > On Jun 1, 2015, at 7:52 AM, Aleksey Shipilev wrote: > Void is the convention used by MH.invoke and it works here too. The only ref of that type is null. Good, thanks! Using Void.class now. >> (Note to self: current prototype collapses the types *after* checking >> with cache, need to fix that possible class leak, thanks! > > Yep. A late asType call will fix things up. We can optimize the pattern more if needed. Plus, we need to adjust the MethodType accordingly, since it is a key in our cache. Done as well. I have submitted a draft JEP for this: https://bugs.openjdk.java.net/browse/JDK-8085796 Please take a look, and we will submit it. The patches, notes, benchmarks are moved under the appropriate bug ID: http://cr.openjdk.java.net/~shade/8085796/ The patches now have a complete support in javac (implemented the "s += concat part as well), passes jtreg and other smoke tests [*], plus newly developed regression tests. I think this gives us enough confidence with going forward. Thanks, -Aleksey [*] There are few regression tests that start to fail with the change: one seems Indify-specific, and another is a javac-specific regression test. Current patches work that around, and we will probably have to fix these properly before integration. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Thu Jun 4 09:46:09 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 04 Jun 2015 10:46:09 +0100 Subject: String concatenation tweaks In-Reply-To: <557018AD.1040308@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> Message-ID: <55701E61.1050905@oracle.com> Cool stuff! I've looked at your benchmarks in here: http://cr.openjdk.java.net/~shade/8085796/notes.txt If I parse correctly, in the string_string_long case the MH version (either plain or sized) is slower than baseline with size 100? Why is so? Maurizio On 04/06/15 10:21, Aleksey Shipilev wrote: > On 06/02/2015 05:39 AM, John Rose wrote: >> On Jun 1, 2015, at 7:52 AM, Aleksey Shipilev wrote: >> Void is the convention used by MH.invoke and it works here too. The only ref of that type is null. > Good, thanks! Using Void.class now. > >>> (Note to self: current prototype collapses the types *after* checking >>> with cache, need to fix that possible class leak, thanks! >> Yep. A late asType call will fix things up. We can optimize the pattern more if needed. > Plus, we need to adjust the MethodType accordingly, since it is a key in > our cache. Done as well. > > I have submitted a draft JEP for this: > https://bugs.openjdk.java.net/browse/JDK-8085796 > > Please take a look, and we will submit it. > > The patches, notes, benchmarks are moved under the appropriate bug ID: > http://cr.openjdk.java.net/~shade/8085796/ > > The patches now have a complete support in javac (implemented the "s += > concat part as well), passes jtreg and other smoke tests [*], > plus newly developed regression tests. I think this gives us enough > confidence with going forward. > > Thanks, > -Aleksey > > [*] There are few regression tests that start to fail with the change: > one seems Indify-specific, and another is a javac-specific regression > test. Current patches work that around, and we will probably have to fix > these properly before integration. > > From aleksey.shipilev at oracle.com Thu Jun 4 09:47:53 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 12:47:53 +0300 Subject: String concatenation tweaks In-Reply-To: <556CE501.4040009@gmail.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <556CE501.4040009@gmail.com> Message-ID: <55701EC9.5020502@oracle.com> Hi Peter, (I realized this was left unreplied) On 06/02/2015 02:04 AM, Peter Levart wrote: > String concatenation actually needs just two reference types (maybe > three if you want to optimize for the literal null as a special type > which is really a very rare case in practice). The JLS says that '+' > binary operator where at least one of the arguments is of String type > is string concatenation operator. If the other argument is not of > String type then it must be converted to String type via String > conversion: > > https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.11 > Which says that .toString() needs to be called if the argument is a > reference type other than String and not null at runtime. I checked > javac and yes, it emits code which only ever invokes two of the > overloaded StringBuilder.append() methods for reference type > arguments: > > append(String); append(Object); > > so the following expression: > > "a" + new StringBuffer("b") > > ...is actually translated to equivalent of: > > new StringBuilder().append("a").append((Object) new > StringBuffer("b")).toString() Notice that even now javac is not following the JLS to the exact letter. If you interpret the JLS wording as the implementation requirement, you would expect javac to instead emit: new StringBuilder() .append("a") .append((new StringBuffer("b").toString()) .toString() ...and basically use only the StringBuilder::append(String) everywhere. StringBuilder::append(Object) *and* StringBuilder::append() should be out of the question, if you treat the JLS semantic guidance as the only implementation. But javac does not do it, and this is fine, because... > Does this subtle detail need to be respected or can dirty > tricks be played with known types to "optimize" their conversion to > String without actually invoking .toString() or even creating an > intermediary String object? Also the String Conversion specification > says that in case the .toString() method returns null, then "null" > string is a result of such String conversion. So there have to be 2 null > checks for reference arguments - before and after .toString() call. ...there is a long way from what spec requires "to behave like", and what is actually done by the implementation. C2's OptimizeStringConcat, for example, does not care about toString() calls anymore, it has its own idea how to convert arguments to Strings. Until users can detect the semantics deviation, I think we are fine. > Also I don't think string concatenation will ever want to know the > precise compile-time types of the reference typed arguments apart from > the three mentioned: String, Object, null, unless it wants to play dirty > tricks with some types to "optimize" String conversion (like > StringBuilder.append(StringBuffer) does for example). Future-proof basically means that we don't preclude optimizations we are dumb to come up with today. The absence of evidence is not the evidence of absence. It would be much safer to leave the exact types in the generated bytecode and have no optimizations to leverage them yet, than to strip the types out, and realize you need them for some future optimization to work. Contingencies! >> Example case: would it make sense to null-check and unbox Integer before >> pushing it on to append() chain? This will set us up for >> OptoStringConcat for new SB().append(String).append(Integer).toString() :) > > What is Integer at compile time can always be null at runtime: > > Integer i = null; > > System.out.println("i=" + i); Yes, but a funny part is that you can null-check it early, replace it with "null" if something goes wrong; unbox the Integer on a "happy path", and employ the in-place int->char[] conversion. Granted, you can emit the (arg instanceof Integer) if Integer was stripped down to opaque Object by javac, but why doing this if we can allow the exact types communicated to us by javac itself? Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Thu Jun 4 10:02:55 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 13:02:55 +0300 Subject: String concatenation tweaks In-Reply-To: <55701E61.1050905@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> Message-ID: <5570224F.8040809@oracle.com> On 06/04/2015 12:46 PM, Maurizio Cimadamore wrote: > Cool stuff! Thanks, Maurizio! Can I lure you into reviewing the JEP draft? ;) > I've looked at your benchmarks in here: > > http://cr.openjdk.java.net/~shade/8085796/notes.txt > > If I parse correctly, in the string_string_long case the MH version > (either plain or sized) is slower than baseline with size 100? Why is so? I think you are reading these in reverse. The benchmark scores are in ns/op, so the lower the better. It might be confusing the see the auxiliary allocation data, measured in bytes/op interleaved in the same report... FULL_MH and NAIVE_MH_FILTER_SIZED are slower at low sizes, and start to win on large ones, once they start to guess the final length right, and compensate for the additional steps to compute the length with that improvement. The goal for current benchmarking was to explore if we can move the code into runtime without prohibitive performance regressions (and there is no throughput regressions for INNER!), and to explore if other strategies can be employed (and they can, but they require more polishing if we want to switch to them). Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Thu Jun 4 11:50:33 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 04 Jun 2015 12:50:33 +0100 Subject: String concatenation tweaks In-Reply-To: <5570224F.8040809@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> Message-ID: <55703B89.3090804@oracle.com> On 04/06/15 11:02, Aleksey Shipilev wrote: > FULL_MH and NAIVE_MH_FILTER_SIZED are slower at low sizes, and start to > win on large ones, once they start to guess the final length right, and > compensate for the additional steps to compute the length with that > improvement. > > The goal for current benchmarking was to explore if we can move the code > into runtime without prohibitive performance regressions (and there is > no throughput regressions for INNER!), and to explore if other > strategies can be employed (and they can, but they require more > polishing if we want to switch to them). So, if I parse correctly, it seems that either FULL_MH and NAIVE_MH_FILTER_SIZED wins on large size, but are considerably slower at lower sizes. On the other hand, INNER_SIZED seems like the best across the board? Maurizio From aleksey.shipilev at oracle.com Thu Jun 4 11:56:51 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 14:56:51 +0300 Subject: String concatenation tweaks In-Reply-To: <55703B89.3090804@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> Message-ID: <55703D03.8050207@oracle.com> On 06/04/2015 02:50 PM, Maurizio Cimadamore wrote: > So, if I parse correctly, it seems that either FULL_MH and > NAIVE_MH_FILTER_SIZED wins on large size, but are considerably slower at > lower sizes. On the other hand, INNER_SIZED seems like the best across > the board? Yup, except for a tiny thing on size=1: # BASELINE ConcatBench.string_string_long: 32.095 ? 0.374 ns/op # INNER ConcatBench.string_string_long: 32.233 ? 0.276 ns/op # INNER_SIZED: ConcatBench.string_string_long: 45.854 ? 0.729 ns/op That's a price you pay for redundantly computing the final length, when the default length (16) is enough. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Thu Jun 4 12:01:15 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 04 Jun 2015 13:01:15 +0100 Subject: String concatenation tweaks In-Reply-To: <55703D03.8050207@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> Message-ID: <55703E0B.5050507@oracle.com> Yeah - noticed that. One more question. I guess baseline is vanilla javac, while all the others are using indy (as you explain in your notes very well). How about also running a benchmark with the original patch proposed in this thread, which doesn't do indy, but only precomputes sizes where possible? Maurizio On 04/06/15 12:56, Aleksey Shipilev wrote: > On 06/04/2015 02:50 PM, Maurizio Cimadamore wrote: >> So, if I parse correctly, it seems that either FULL_MH and >> NAIVE_MH_FILTER_SIZED wins on large size, but are considerably slower at >> lower sizes. On the other hand, INNER_SIZED seems like the best across >> the board? > Yup, except for a tiny thing on size=1: > > # BASELINE > ConcatBench.string_string_long: 32.095 ? 0.374 ns/op > > # INNER > ConcatBench.string_string_long: 32.233 ? 0.276 ns/op > > # INNER_SIZED: > ConcatBench.string_string_long: 45.854 ? 0.729 ns/op > > That's a price you pay for redundantly computing the final length, when > the default length (16) is enough. > > Thanks, > -Aleksey > > > From aleksey.shipilev at oracle.com Thu Jun 4 12:12:58 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 15:12:58 +0300 Subject: String concatenation tweaks In-Reply-To: <55703E0B.5050507@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> Message-ID: <557040CA.1050104@oracle.com> On 06/04/2015 03:01 PM, Maurizio Cimadamore wrote: > One more question. I guess baseline is vanilla javac, while all the > others are using indy (as you explain in your notes very well). How > about also running a benchmark with the original patch proposed in this > thread, which doesn't do indy, but only precomputes sizes where possible? Yes, the baseline is vanilla javac. I don't think Louis had provided a patch, but just described what is being done there, and then asking if he should prepare the patch. I think it would be better to let Louis et al. forward-port their javac changes to StringConcatFactory -- that would be the improvement for our (quite naive) concat translation strategies. This JEP is about letting the development happen without messing with javac all the time :) Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Thu Jun 4 12:35:13 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 04 Jun 2015 13:35:13 +0100 Subject: String concatenation tweaks In-Reply-To: <557040CA.1050104@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> Message-ID: <55704601.2090909@oracle.com> On 04/06/15 13:12, Aleksey Shipilev wrote: > On 06/04/2015 03:01 PM, Maurizio Cimadamore wrote: >> One more question. I guess baseline is vanilla javac, while all the >> others are using indy (as you explain in your notes very well). How >> about also running a benchmark with the original patch proposed in this >> thread, which doesn't do indy, but only precomputes sizes where possible? > Yes, the baseline is vanilla javac. > > I don't think Louis had provided a patch, but just described what is > being done there, and then asking if he should prepare the patch. I > think it would be better to let Louis et al. forward-port their javac > changes to StringConcatFactory -- that would be the improvement for our > (quite naive) concat translation strategies. This JEP is about letting > the development happen without messing with javac all the time :) Well, yes - but adding a new indy is not something that comes for free. We are currently fighting to get specialization to work correctly with lambdas, and it turns out that having an indy, as Brian said, is like having an entirely new bytecode - so, for every new 'officially supported' bootstrap that we add, we will need to find ways to make that work with whatever new feature XYZ we could come up in the future. So, my question remains: how much of that speedup can be obtained w/o indy? I think that's a fair question for the JEP you are filing. Maurizio > > Thanks, > -Aleksey. > > From aleksey.shipilev at oracle.com Thu Jun 4 12:56:50 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 15:56:50 +0300 Subject: String concatenation tweaks In-Reply-To: <55704601.2090909@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> Message-ID: <55704B12.2000905@oracle.com> On 06/04/2015 03:35 PM, Maurizio Cimadamore wrote: > Well, yes - but adding a new indy is not something that comes for free. > We are currently fighting to get specialization to work correctly with > lambdas, and it turns out that having an indy, as Brian said, is like > having an entirely new bytecode - so, for every new 'officially > supported' bootstrap that we add, we will need to find ways to make that > work with whatever new feature XYZ we could come up in the future. Yes. This is why we better spend time figuring if the proposed indy interface is enough/future-proof. > So, my question remains: how much of that speedup can be obtained w/o > indy? I think that's a fair question for the JEP you are filing. And JEP addresses that in "Alternative" section, by talking why changing the javac-generated bytecode sequence is not considered. The considerations for the complexity of testing and/or JVM implementation prevail: multiple bytecode sequences for String concat would mean the JVM, the tools, everyone having another degree of freedom in their testing matrices landing on their laps. Allowing complex static translation schemes in javac would inevitably turn into a performance nightmare, and I, for one, would not like to be responsible for it. In other words, as far as the JVM and tools are concerned, the static bytecode sequence emitted by javac is *as much* the interface as a proposed indy sequence. The difference is whether you change it once (into indy), or multiple times (as you get your static translation right over the years). Therefore, the answer to the question "how much performance can you gain with doing that in plain javac" would not help you. The issue at hand is *not* performance, but is enabling the performance work without exploding the variety of bytecode shapes. Anyhow, the experiment you want is not possible at this point, since there is no alternative "patch" to be tried. Recognizing the shortcomings of static javac-emitted concat sequences, I think the time is best spent elsewhere, rather than trying to build a complicated piece of code that would be thrown away for the reasons above. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Thu Jun 4 13:41:48 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 16:41:48 +0300 Subject: String concatenation tweaks In-Reply-To: <55704B12.2000905@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.co! m> Message-ID: <5570559C.2090201@oracle.com> On 06/04/2015 03:56 PM, Aleksey Shipilev wrote: > On 06/04/2015 03:35 PM, Maurizio Cimadamore wrote: >> Well, yes - but adding a new indy is not something that comes for free. >> We are currently fighting to get specialization to work correctly with >> lambdas, and it turns out that having an indy, as Brian said, is like >> having an entirely new bytecode - so, for every new 'officially >> supported' bootstrap that we add, we will need to find ways to make that >> work with whatever new feature XYZ we could come up in the future. > > Yes. This is why we better spend time figuring if the proposed indy > interface is enough/future-proof. In other words, we do indeed introducing something similar to a new bytecode, a long missing "string concat". Would you argue we need to continue band-aiding the impedance between JLS allowing String concat and JVMS not having the appropriate facilities for it -- and forcing the VM implementations to recognize all these translated forms? Indy allows us to overcome this impedance with one leap. This also opens up the way into using the (potentially unsafe) private APIs for concat on VM side, like fixed-length string builders proposed in this thread. Doing the same on javac side would mean these private APIs have to be leaked into public. Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Thu Jun 4 13:47:47 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 04 Jun 2015 14:47:47 +0100 Subject: String concatenation tweaks In-Reply-To: <5570559C.2090201@oracle.com> References: <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.! com> Message-ID: <55705703.1050009@oracle.com> On 04/06/15 14:41, Aleksey Shipilev wrote: > On 06/04/2015 03:56 PM, Aleksey Shipilev wrote: >> On 06/04/2015 03:35 PM, Maurizio Cimadamore wrote: >>> Well, yes - but adding a new indy is not something that comes for free. >>> We are currently fighting to get specialization to work correctly with >>> lambdas, and it turns out that having an indy, as Brian said, is like >>> having an entirely new bytecode - so, for every new 'officially >>> supported' bootstrap that we add, we will need to find ways to make that >>> work with whatever new feature XYZ we could come up in the future. >> Yes. This is why we better spend time figuring if the proposed indy >> interface is enough/future-proof. > In other words, we do indeed introducing something similar to a new > bytecode, a long missing "string concat". Would you argue we need to > continue band-aiding the impedance between JLS allowing String concat > and JVMS not having the appropriate facilities for it -- and forcing the > VM implementations to recognize all these translated forms? Indy allows > us to overcome this impedance with one leap. You asked for a review :-) My feeling is that this is a game of diminishing returns; and I simply think that before dismissing alternatives, we should take them into account in case there are any surprises. That's what I would do if I had submittted the JEP. I'm sure Louis would be more than happy to provide a patch to add some additional depth to your current benchmarks. Maurizio > > This also opens up the way into using the (potentially unsafe) private > APIs for concat on VM side, like fixed-length string builders proposed > in this thread. Doing the same on javac side would mean these private > APIs have to be leaked into public. > > Thanks, > -Aleksey. > > From ali.ebrahimi1781 at gmail.com Thu Jun 4 13:59:38 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 4 Jun 2015 18:29:38 +0430 Subject: String concatenation tweaks In-Reply-To: <5570559C.2090201@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> Message-ID: Please add String Interpolation and Multi-line String: in that case we would have better answer for problem. On Thu, Jun 4, 2015 at 6:11 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 06/04/2015 03:56 PM, Aleksey Shipilev wrote: > > On 06/04/2015 03:35 PM, Maurizio Cimadamore wrote: > >> Well, yes - but adding a new indy is not something that comes for free. > >> We are currently fighting to get specialization to work correctly with > >> lambdas, and it turns out that having an indy, as Brian said, is like > >> having an entirely new bytecode - so, for every new 'officially > >> supported' bootstrap that we add, we will need to find ways to make that > >> work with whatever new feature XYZ we could come up in the future. > > > > Yes. This is why we better spend time figuring if the proposed indy > > interface is enough/future-proof. > > In other words, we do indeed introducing something similar to a new > bytecode, a long missing "string concat". Would you argue we need to > continue band-aiding the impedance between JLS allowing String concat > and JVMS not having the appropriate facilities for it -- and forcing the > VM implementations to recognize all these translated forms? Indy allows > us to overcome this impedance with one leap. > > This also opens up the way into using the (potentially unsafe) private > APIs for concat on VM side, like fixed-length string builders proposed > in this thread. Doing the same on javac side would mean these private > APIs have to be leaked into public. > > Thanks, > -Aleksey. > > > -- Best Regards, Ali Ebrahimi -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgiy.rakov at oracle.com Thu Jun 4 14:04:32 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 04 Jun 2015 17:04:32 +0300 Subject: Diamond with anonymous classes: invoking non-private methods through reflection Message-ID: <55705AF0.90101@oracle.com> Hello, new feature about diamond with anonymous classes demands every non-private method declared in the anonymous class to override some method from its super type, otherwise compiler error occurs. I understand the intention of it which is specified in this comment : When the diamond form is used, the inferred type arguments may not be as anticipated by the programmer. Consequently, the supertype of the anonymous class may not be as anticipated, and methods declared in the anonymous class may not override supertype methods as intended. Treating such methods as if annotated with @Override (if they are not actually annotated with @Override) helps avoid silently incorrect programs. And this looks reasonable because when some method is declared in the anonymous class the only purpose of declaring it as non-private seems to be overriding since the method cannot be invoked from outside of the anonymous class, at least by the language means. But another purpose still exists, namely, invoking such method through reflection by some framework. For that purpose it actually becomes impossible to declare non-private method in the anonymous class instance created with diamond unless such method is declared in its super type. Could you please tell if you have considered such use case and see it as a shortcoming or maybe not that serious one? Thank you, Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lowasser at google.com Thu Jun 4 16:21:41 2015 From: lowasser at google.com (Louis Wasserman) Date: Thu, 04 Jun 2015 16:21:41 +0000 Subject: String concatenation tweaks In-Reply-To: <55705703.1050009@oracle.com> References: <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> Message-ID: I think I almost certainly would, but I confess I've lost track of what exactly it is you want from me. =) On Thu, Jun 4, 2015 at 6:48 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > > On 04/06/15 14:41, Aleksey Shipilev wrote: > > On 06/04/2015 03:56 PM, Aleksey Shipilev wrote: > >> On 06/04/2015 03:35 PM, Maurizio Cimadamore wrote: > >>> Well, yes - but adding a new indy is not something that comes for free. > >>> We are currently fighting to get specialization to work correctly with > >>> lambdas, and it turns out that having an indy, as Brian said, is like > >>> having an entirely new bytecode - so, for every new 'officially > >>> supported' bootstrap that we add, we will need to find ways to make > that > >>> work with whatever new feature XYZ we could come up in the future. > >> Yes. This is why we better spend time figuring if the proposed indy > >> interface is enough/future-proof. > > In other words, we do indeed introducing something similar to a new > > bytecode, a long missing "string concat". Would you argue we need to > > continue band-aiding the impedance between JLS allowing String concat > > and JVMS not having the appropriate facilities for it -- and forcing the > > VM implementations to recognize all these translated forms? Indy allows > > us to overcome this impedance with one leap. > You asked for a review :-) > > My feeling is that this is a game of diminishing returns; and I simply > think that before dismissing alternatives, we should take them into > account in case there are any surprises. That's what I would do if I had > submittted the JEP. > > I'm sure Louis would be more than happy to provide a patch to add some > additional depth to your current benchmarks. > > Maurizio > > > > This also opens up the way into using the (potentially unsafe) private > > APIs for concat on VM side, like fixed-length string builders proposed > > in this thread. Doing the same on javac side would mean these private > > APIs have to be leaked into public. > > > > Thanks, > > -Aleksey. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Thu Jun 4 16:23:03 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 19:23:03 +0300 Subject: String concatenation tweaks In-Reply-To: <55705703.1050009@oracle.com> References: <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracl! e.com> Message-ID: <55707B67.4060801@oracle.com> On 06/04/2015 04:47 PM, Maurizio Cimadamore wrote: > My feeling is that this is a game of diminishing returns; Hey, this project is 20 years old! Pretty much everything is a game of diminishing returns around here. But think about the scale of it :) > and I simply think that before dismissing alternatives, we should > take them into account in case there are any surprises. That's what I > would do if I had submittted the JEP. My point is that any strategy implemented in javac itself would perform as good as the thing called through the indy. There is no magic: it is still bytecode, whether inlined into the program by javac, or generated and inlined by JVM. The decision should be about the soundness of the approach that opens up future opportunities, not about whether a band-aid solves the issue for now, at the scale we understand is needed now. > I'm sure Louis would be more than happy to provide a patch to add some > additional depth to your current benchmarks. While it maybe an interesting experiment to try, the performance engineering experience tells me to focus on the parts that are relevant, rather than doing every experiment you can come up with, otherwise you will never ever un-bury yourself from the performance work :) -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Thu Jun 4 16:23:47 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 19:23:47 +0300 Subject: String concatenation tweaks In-Reply-To: References: <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> Message-ID: <55707B93.9030801@oracle.com> On 06/04/2015 07:21 PM, Louis Wasserman wrote: > I think I almost certainly would, but I confess I've lost track of what > exactly it is you want from me. =) I'd think a patch that does the pre-computing StringBuilder lengths within the code generated by javac itself. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Thu Jun 4 17:13:30 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 04 Jun 2015 20:13:30 +0300 Subject: String concatenation tweaks In-Reply-To: References: <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> Message-ID: <5570873A.2090400@oracle.com> On 06/04/2015 04:59 PM, Ali Ebrahimi wrote: > Please add String Interpolation and Multi-line String: in that case we > would have better answer for problem. Neither String interpolation nor multi-line Strings are supported by current Java language, so throwing these in mix promotes the issue into extending the language. Not fun. In addition, Multi-line Strings is purely a syntax issue, not the bytecode interface one, and so it seems rather unrelated. Is String interpolation thought as the syntactic sugar for string concatenation? If so, then the proposed bytecode interface is enough to cover this case as well, should that lang feature ever arrive. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Thu Jun 4 17:50:04 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 04 Jun 2015 18:50:04 +0100 Subject: String concatenation tweaks In-Reply-To: <55707B67.4060801@oracle.com> References: <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@orac! le.com> Message-ID: <55708FCC.4040705@oracle.com> On 04/06/15 17:23, Aleksey Shipilev wrote: > While it maybe an interesting experiment to try, the performance > engineering experience tells me to focus on the parts that are relevant, > rather than doing every experiment you can come up with, otherwise you > will never ever un-bury yourself from the performance work:) I don't think this is *any* experiment you can come up with - it's the very foundation for all the JEP work. For the JEP to be viable you need to prove that whatever technique you come up with, it would be almost in the same ballpark as the one implemented in javac. If the numbers are the same, then it's mostly an argument of whether we want to open up the machinery vs. keeping it buried in javac (and the future maintenance cost for any BSM added). But what if the numbers are not the same? Put in other words, if the natively written javac impl was 10x faster with no startup cost (I'm obviously making things up), wouldn't that mean the very death of this JEP? Or, again put in other words, as you have a column in your benchmark called 'BASELINE', I think it'd be nice to also have a column called 'LOWER_BOUND', and see how the various solutions would compare against it. Maurizio From alex.buckley at oracle.com Thu Jun 4 21:01:08 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 04 Jun 2015 14:01:08 -0700 Subject: Diamond with anonymous classes: invoking non-private methods through reflection In-Reply-To: <55705AF0.90101@oracle.com> References: <55705AF0.90101@oracle.com> Message-ID: <5570BC94.2010209@oracle.com> On 6/4/2015 7:04 AM, Georgiy Rakov wrote: > Hello, > > new feature about diamond with anonymous classes demands every > non-private method declared in the anonymous class to override some > method from its super type, otherwise compiler error occurs. I > understand the intention of it which is specified in this comment > : > > When the diamond form is used, the inferred type arguments may not > be as anticipated by the programmer. Consequently, the supertype of > the anonymous class may not be as anticipated, and methods declared > in the anonymous class may not override supertype methods as > intended. Treating such methods as if annotated with @Override (if > they are not actually annotated with @Override) helps avoid silently > incorrect programs. > > And this looks reasonable because when some method is declared in the > anonymous class the only purpose of declaring it as non-private seems to > be overriding since the method cannot be invoked from outside of the > anonymous class, at least by the language means. But another purpose > still exists, namely, invoking such method through reflection by some > framework. For that purpose it actually becomes impossible to declare > non-private method in the anonymous class instance created with diamond > unless such method is declared in its super type. > > Could you please tell if you have considered such use case and see it as > a shortcoming or maybe not that serious one? If you declare a method in an anonymous class as private, then you're not bound by the must-override rule, but since the rule isn't a bad rule, there's no reason to go private just to escape the rule. Simply use the same (non-private) access level in your method declaration as the method in the superclass. No-one can override your non-private method anyway. Of course many people can invoke your non-private method by referring to its signature in the superclass. What if a framework vendor wants to reflectively invoke non-private methods of anonymous classes "directly", without referring to methods in any superclasses? I guess the vendor has told their users to declare non-private non-overriding methods in anonymous classes in order for the framework to call them back occasionally. Probably the framework detects such methods via the presence of framework-specific annotations. Of course this will still work -- we are not proposing to change j.l.r.Method::invoke to insist on must-override for non-private methods in anonymous classes -- but it means the users can't write the diamond form in source. I think this is an acceptable limitation. Alex From aleksey.shipilev at oracle.com Fri Jun 5 08:04:20 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 05 Jun 2015 11:04:20 +0300 Subject: String concatenation tweaks In-Reply-To: <55708FCC.4040705@oracle.com> References: <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> Message-ID: <55715804.8000406@oracle.com> First things first, I added more discussion into the JEP draft: https://bugs.openjdk.java.net/browse/JDK-8085796 On 06/04/2015 08:50 PM, Maurizio Cimadamore wrote: > On 04/06/15 17:23, Aleksey Shipilev wrote: >> While it maybe an interesting experiment to try, the performance >> engineering experience tells me to focus on the parts that are relevant, >> rather than doing every experiment you can come up with, otherwise you >> will never ever un-bury yourself from the performance work:) > I don't think this is *any* experiment you can come up with - it's the > very foundation for all the JEP work. For the JEP to be viable you need > to prove that whatever technique you come up with, it would be almost in > the same ballpark as the one implemented in javac. If you want to assess the technique itself, you have to compare the similar concat approaches used by javac and by indy-based translation strategy. It would be dumb to compare a heavily-optimized javac translation vs. a dumb indy-based translation. This is why we have INNER, it is the (almost) direct rewrite of the code emitted by vanilla javac now, to the runtime. This strategy is actually used to prove the move from compile time to runtime does not experience the throughput hits. *That's* the foundational performance data, already available. > If the numbers are the same, then it's mostly an argument of whether > we want to open up the machinery vs. keeping it buried in javac (and > the future maintenance cost for any BSM added). But what if the > numbers are not the same? But they are the same already! INNER performs the same as vanilla javac (BASELINE) is performing. This means the new infrastructure is not getting in the way, when our translation strategy emits the plain bytecode. Heck, both BASELINE and INNER are recognized by OptimizeStringConcat and are optimized to death. That's what I am trying to tell here: it _is_ the question about the machinery at this point. All other strategies are motivational examples how this can be used to improve the translation strategy without involving javac. > Put in other words, if the natively written javac impl was 10x faster > with no startup cost (I'm obviously making things up), wouldn't that > mean the very death of this JEP? No, it wouldn't. Because really, whatever bytecode you can emit in javac, the same bytecode can be emitted through the indy translation strategy. (The reverse is not true -- JDK-internal StringConcatFactory may use private APIs! -- which makes javac more limiting for this task). If you discover a bytecode sequence that is 10x faster than proposed variants in indy translation strategies, you move it in as additional strategy, and that's it (plus the beauty that you can discover such a bytecode sequence much later). This is why we would certainly like to see Louis' patch, to see if we can/need to move it in under indy translation strategy, and if/what we should adjust at the indy interface. The only plausible concern at this point is startup time, but you can see that even without going with additional javac experiments. And, those costs seem to be related to the initialization of indy infrastructure -- some project would have to suck up those costs, whether it's String Concat, Jigsaw, on any Valhalla-related project. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From forax at univ-mlv.fr Fri Jun 5 09:12:29 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 05 Jun 2015 11:12:29 +0200 Subject: String concatenation metaprotocol Was: String concatenation tweaks In-Reply-To: <555DCC4D.8040505@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> Message-ID: <557167FD.1050006@univ-mlv.fr> Aleksey, there is something that the current translation doesn't do, with by example, "foo" + a + "bar", javac know that "foo" and "bar" are constants but doesn't propagate this information to the bootstrap method, the invokedynamic call will use 3 arguments instead of one ; the only the value of 'a' can changed and the two others can be sent as bootstrap constants. This would help the dynamic part because calculating the length of "foo" and "bar" will be done once in the bootstrap method instead of being done each time. In the example below, if 'a' is a primitive type, it can be a huge win because the total length of the buffer becomes a constant. All we need for that is to define a way to describe how the arguments of the call and the bootstrap arguments are interleaved. Let say we use a String with 'A' for classical argument and 'B' for a bootstrap argument, in that case "foo" + a + "bar" interleaving is "BAB", so the corresponding bytecode is iload 0 // load a invokedynamic "BAB" (I)Ljava/lang/String ["foo", "bar"] And 'null' is a special case because it's a compiler constant but it can not be encoded as a constant pool constant, the best IMO is to consider that instead of trying to encode 'null', it's better to encode "null" as a String. cheers, R?mi On 05/21/2015 02:15 PM, Aleksey Shipilev wrote: > On 05/15/2015 01:06 AM, Aleksey Shipilev wrote: >> It actually does not seem that scary. javac changes seem minimal, >> because they basically mirror [1] what is already done for current >> String concat and lambda desugaring. >> >> JDK side of changes is not too scary as well [2], and it readily lends >> itself to different implementation strategies, including precomputing >> the argument lengths. I realized too late it does not check for argument >> nullity properly, but this is a proof-of-concept patch anyway. > Updated patches: > http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/ > > INNER_SIZED strategy is enabled by default for everything except > java.base. This, and a few other touchups make the patched JDK to build > cleanly, and pass the most java/lang and java/util jtreg tests (there > are seem to be some failures in Indify-based tests). > > Thanks, > -Aleksey > > > From maurizio.cimadamore at oracle.com Fri Jun 5 09:57:35 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 05 Jun 2015 10:57:35 +0100 Subject: String concatenation tweaks In-Reply-To: <55715804.8000406@oracle.com> References: <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> <55715804.8000406@oracle.com> Message-ID: <5571728F.5030005@oracle.com> Hi Alex, I think the bulk of my concern (which has also been expressed by other members of my team in this very thread) is that what you are proposing might be too extreme in practice. Do we have an issue with string concat? Yes, we do - as you pointed out, the mismatch between JLS and JVMS is not negligible and sometimes we pay for that performance-wise. Your solution is to decouple string optimization from the code that's emitted by the static compiler. Of course that's an elegant solution which has proven to be effective with lambda. But, as we learned with lambda, adding new indys in the bytecode is not something that comes from free. Here's a list of potential concerns: * maintenance cost involved (as mentioned in previous emails) in terms of implementing new features * platforms (ME) which don't spell indy (yet?); once we start generating the code suggested here, the only viable option for those platforms would be to introduce yet another hack to desugar away the indys and re-generate statically that very same code that the indy would emit on the fly (as they currently do for lambdas). * what about other compilers - i.e. other than javac? Does this JEP propose that all compiler implementations start spitting the new indys? * bytecode manipulators/weavers would need to handle new indys in places they are not used to even in absence of source code changes - just by virtue of recompilation (we got this A LOT when stackmap attrs were added by default in 7) * static footprint (i.e. increased classfile size) would definitively be an issue in strings-concat heavy code (there are machine-generated files out there which nearly use up all the entries in the CP and do an huge number of string concat); this is also something that we can see with lambdas, but in that case the alternative was inner classes, which, in itself, is another big static footprint killer, so the choice was easier. Again, a static footprint-oriented benchmark on one of such files would be welcome. * while indy is generally a great tool, it has its own performance quirks; while microbenchmarking with JMH is certainly a good start, I think we also need to think about real-world scenario benchmarks, to see if they are affected in a significant way by startup or any other cost. While I fully appreciate the benefits of your proposal, I'm afraid the reality is a bit more complex. That, coupled with the feeling that, at the end of the day, it's not like we're updating the string generation code every other day (at least we never changed in the last 8 years I've been here), leaves me with a bit of mixed feelings. Maurizio On 05/06/15 09:04, Aleksey Shipilev wrote: > First things first, I added more discussion into the JEP draft: > https://bugs.openjdk.java.net/browse/JDK-8085796 > > > On 06/04/2015 08:50 PM, Maurizio Cimadamore wrote: >> On 04/06/15 17:23, Aleksey Shipilev wrote: >>> While it maybe an interesting experiment to try, the performance >>> engineering experience tells me to focus on the parts that are relevant, >>> rather than doing every experiment you can come up with, otherwise you >>> will never ever un-bury yourself from the performance work:) >> I don't think this is *any* experiment you can come up with - it's the >> very foundation for all the JEP work. For the JEP to be viable you need >> to prove that whatever technique you come up with, it would be almost in >> the same ballpark as the one implemented in javac. > If you want to assess the technique itself, you have to compare the > similar concat approaches used by javac and by indy-based translation > strategy. It would be dumb to compare a heavily-optimized javac > translation vs. a dumb indy-based translation. > > This is why we have INNER, it is the (almost) direct rewrite of the code > emitted by vanilla javac now, to the runtime. This strategy is actually > used to prove the move from compile time to runtime does not experience > the throughput hits. *That's* the foundational performance data, already > available. > > >> If the numbers are the same, then it's mostly an argument of whether >> we want to open up the machinery vs. keeping it buried in javac (and >> the future maintenance cost for any BSM added). But what if the >> numbers are not the same? > But they are the same already! INNER performs the same as vanilla javac > (BASELINE) is performing. This means the new infrastructure is not > getting in the way, when our translation strategy emits the plain > bytecode. Heck, both BASELINE and INNER are recognized by > OptimizeStringConcat and are optimized to death. > > That's what I am trying to tell here: it _is_ the question about the > machinery at this point. All other strategies are motivational examples > how this can be used to improve the translation strategy without > involving javac. > > >> Put in other words, if the natively written javac impl was 10x faster >> with no startup cost (I'm obviously making things up), wouldn't that >> mean the very death of this JEP? > No, it wouldn't. Because really, whatever bytecode you can emit in > javac, the same bytecode can be emitted through the indy translation > strategy. (The reverse is not true -- JDK-internal StringConcatFactory > may use private APIs! -- which makes javac more limiting for this task). > > If you discover a bytecode sequence that is 10x faster than proposed > variants in indy translation strategies, you move it in as additional > strategy, and that's it (plus the beauty that you can discover such a > bytecode sequence much later). > > This is why we would certainly like to see Louis' patch, to see if we > can/need to move it in under indy translation strategy, and if/what we > should adjust at the indy interface. > > The only plausible concern at this point is startup time, but you can > see that even without going with additional javac experiments. And, > those costs seem to be related to the initialization of indy > infrastructure -- some project would have to suck up those costs, > whether it's String Concat, Jigsaw, on any Valhalla-related project. > > Thanks, > -Aleksey > From forax at univ-mlv.fr Fri Jun 5 12:56:01 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 05 Jun 2015 14:56:01 +0200 Subject: String concatenation tweaks In-Reply-To: <5571728F.5030005@oracle.com> References: <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> <55715804.8000406@oracle.com> <5571728F.5030005@oracle.com> Message-ID: <55719C61.2060809@univ-mlv.fr> On 06/05/2015 11:57 AM, Maurizio Cimadamore wrote: > Hi Alex, > I think the bulk of my concern (which has also been expressed by other > members of my team in this very thread) is that what you are proposing > might be too extreme in practice. Do we have an issue with string > concat? Yes, we do - as you pointed out, the mismatch between JLS and > JVMS is not negligible and sometimes we pay for that performance-wise. > Your solution is to decouple string optimization from the code that's > emitted by the static compiler. Of course that's an elegant solution > which has proven to be effective with lambda. But, as we learned with > lambda, adding new indys in the bytecode is not something that comes > from free. There is no free lunch but IMO this translation seems to be a good use case to optimize for the Hotspot team. > Here's a list of potential concerns: > > * maintenance cost involved (as mentioned in previous emails) in > terms of implementing new features > * platforms (ME) which don't spell indy (yet?); once we start > generating the code suggested here, the only viable option for those > platforms would be to introduce yet another hack to desugar away the > indys and re-generate statically that very same code that the indy > would emit on the fly (as they currently do for lambdas). yes, it has to be done, the translation will require to insert code in between the calculation of the arguments, so it's a little more work than what is already done for lambdas but not something really hard if the tool uses ASM. > * what about other compilers - i.e. other than javac? Does this JEP > propose that all compiler implementations start spitting the new indys? > * bytecode manipulators/weavers would need to handle new indys in > places they are not used to even in absence of source code changes - > just by virtue of recompilation (we got this A LOT when stackmap attrs > were added by default in 7) not a real issue in my opinion because bytecode tools already need to take care of the invokedynamic calls generated by lambda translations that can happen everywhere in the bytecode. > * static footprint (i.e. increased classfile size) would definitively > be an issue in strings-concat heavy code (there are machine-generated > files out there which nearly use up all the entries in the CP and do > an huge number of string concat); this is also something that we can > see with lambdas, but in that case the alternative was inner classes, > which, in itself, is another big static footprint killer, so the > choice was easier. Again, a static footprint-oriented benchmark on one > of such files would be welcome. javac translation generates a lot of bytecodes but shares a lot in term of constant pool, invokedynamic translations will do the opposite, they use more entries in the CP (mostly due to the method descriptor of invokedynamic) and use far less bytecode. So in term of global static footprint So yes, if the current class uses of most of all possible CP entries, there is a good chance that it will not compile with the invokedynamic translation. There is another limitation, a method call can not have more than 255 arguments, if there are a lot of '+', the invokedynamic translation may fail too. Maybe, the compiler should use the old strategy if there are too many arguments. > * while indy is generally a great tool, it has its own performance > quirks; while microbenchmarking with JMH is certainly a good start, I > think we also need to think about real-world scenario benchmarks, to > see if they are affected in a significant way by startup or any other > cost. You see the glass half empty ! There are ways to improve invokedynamic startup time, put most frequent lambda forms in CDS or the big gun, do an AOT pass on the code when generating the jimage (pre-generate native code if you prefer). These things will have to be implemented to have good startup perf on small devices or to allow to write command tools in Java anyway. > > While I fully appreciate the benefits of your proposal, I'm afraid the > reality is a bit more complex. That, coupled with the feeling that, at > the end of the day, it's not like we're updating the string generation > code every other day (at least we never changed in the last 8 years > I've been here), leaves me with a bit of mixed feelings. > > Maurizio cheers, R?mi From ali.ebrahimi1781 at gmail.com Fri Jun 5 13:45:39 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 5 Jun 2015 18:15:39 +0430 Subject: String concatenation tweaks In-Reply-To: <5570873A.2090400@oracle.com> References: <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <5570873A.2090400@oracle.com> Message-ID: Hi, On Thu, Jun 4, 2015 at 9:43 PM, Aleksey Shipilev < aleksey.shipilev at oracle.com> wrote: > On 06/04/2015 04:59 PM, Ali Ebrahimi wrote: > > Please add String Interpolation and Multi-line String: in that case we > > would have better answer for problem. > > Neither String interpolation nor multi-line Strings are supported by > current Java language, so throwing these in mix promotes the issue into > extending the language. Not fun. > I think, I don't say java already support them, but I beleave java should support them. > > In addition, Multi-line Strings is purely a syntax issue, not the > bytecode interface one, and so it seems rather unrelated. > I don't think so. consider this code: String chart = " var chart = new Highcharts.Chart({\n" + " chart: {\n" + " zoomType: 'x',\n" + " height: " + chartHeight + ",\n" + " width: " + chartWidth + ",\n" + " type: 'column',\n" + " plotBackgroundImage: '',\n" + " renderTo: '" + id + "',\n" + " \tevents: {\n" + " \t\tclick: function(e) {\n" + " \t\t\t//CHARTCLICK_HANDLER_CODE\n" + " \t\t}\n" + " \t}\n" + " },\n"; needs 20 sb.append call vs multi-line string String chart = " var chart = new Highcharts.Chart({\n chart: {\n zoomType: 'x',\n height: " + chartHeight + ",\n width: " + chartWidth + ",\n type: 'column',\n plotBackgroundImage: ' ',\n renderTo: '" + id + "',\n \tevents: {\n \t\tclick: function(e) {\n \t\t\t//CHARTCLICK_HANDLER_CODE\n \t\t}\n \t}\n },\n"; 6 sb.append call vs multi-line string & String Interpolation String chart = $" var chart = new Highcharts.Chart({\n chart: {\n zoomType: 'x',\n height: ${chartHeight },\n width: ${chartWidth },\n type: 'column',\n plotBackgroundImage: ' ',\n renderTo: '${ id }',\n \tevents: {\n \t\tclick: function(e) {\n \t\t\t//CHARTCLICK_HANDLER_CODE\n \t\t}\n \t}\n },\n"; This depend on implementation detail but max 6 sb.append call I think with multi-line string & String Interpolation javac have better view of overall string expressions and can generate optimized bytecode. In other side, we have improved code readability. -- Best Regards, Ali Ebrahimi -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Jun 5 13:52:16 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 05 Jun 2015 15:52:16 +0200 Subject: String concatenation tweaks In-Reply-To: References: <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <5570873A.2090400@oracle.com> Message-ID: <5571A990.4040606@univ-mlv.fr> Ali, javac already concatenates constant strings, so your first example generates only 6 calls to append() :) cheers, R?mi On 06/05/2015 03:45 PM, Ali Ebrahimi wrote: > Hi, > > > On Thu, Jun 4, 2015 at 9:43 PM, Aleksey Shipilev > > wrote: > > On 06/04/2015 04:59 PM, Ali Ebrahimi wrote: > > Please add String Interpolation and Multi-line String: in that > case we > > would have better answer for problem. > > Neither String interpolation nor multi-line Strings are supported by > current Java language, so throwing these in mix promotes the issue > into > extending the language. Not fun. > > I think, I don't say java already support them, but I beleave java > should support them. > > > In addition, Multi-line Strings is purely a syntax issue, not the > bytecode interface one, and so it seems rather unrelated. > > I don't think so. > consider this code: > > String chart = " var chart = new Highcharts.Chart({\n" + > " chart: {\n" + > " zoomType: 'x',\n" + > " height: " + chartHeight + ",\n" + > " width: " + chartWidth + ",\n" + > " type: 'column',\n" + > " plotBackgroundImage: '',\n" + > " renderTo: '" + id + "',\n" + > " \tevents: {\n" + > " \t\tclick: function(e) {\n" + > " \t\t\t//CHARTCLICK_HANDLER_CODE\n" + > " \t\t}\n" + > " \t}\n" + > " },\n"; > needs 20 sb.append call > > vs multi-line string > > String chart = " var chart = new Highcharts.Chart({\n > chart: {\n > zoomType: 'x',\n > height: " + chartHeight + ",\n > width: " + chartWidth + ",\n > type: 'column',\n > plotBackgroundImage: ' ',\n > renderTo: '" + id + "',\n > \tevents: {\n > \t\tclick: function(e) {\n > \t\t\t//CHARTCLICK_HANDLER_CODE\n > \t\t}\n > \t}\n > },\n"; > 6 sb.append call > > vs multi-line string & String Interpolation > > String chart = $" var chart = new Highcharts.Chart({\n > chart: {\n > zoomType: 'x',\n > height: ${chartHeight },\n > width: ${chartWidth },\n > type: 'column',\n > plotBackgroundImage: ' ',\n > renderTo: '${ id }',\n > \tevents: {\n > \t\tclick: function(e) {\n > \t\t\t//CHARTCLICK_HANDLER_CODE\n > \t\t}\n > \t}\n > },\n"; > This depend on implementation detail but max 6 sb.append call > I think with multi-line string & String Interpolation javac have > better view of overall string expressions and can generate optimized > bytecode. > > In other side, we have improved code readability. > > -- > > Best Regards, > Ali Ebrahimi -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Fri Jun 5 14:07:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 05 Jun 2015 16:07:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) Message-ID: <5571AD18.7080701@oracle.com> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 [1] http://openjdk.java.net/jeps/223 From ali.ebrahimi1781 at gmail.com Fri Jun 5 14:31:41 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 5 Jun 2015 19:01:41 +0430 Subject: String concatenation tweaks In-Reply-To: <5571A990.4040606@univ-mlv.fr> References: <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <5570873A.2090400@oracle.com> <5571A990.4040606@univ-mlv.fr> Message-ID: Yes, Of course not completely. This is decompile of javac produced bytecode. String chart = " var chart = new Highcharts.Chart({\n chart: {\n zoomType: 'x',\n height: " + chartHeight + ",\n" + " width: " + chartWidth + ",\n" + " type: 'column',\n" + " plotBackgroundImage: '',\n" + " renderTo: '" + id + "',\n" + " \tevents: {\n" + " \t\tclick: function(e) {\n" + " \t\t\t//CHARTCLICK_HANDLER_CODE\n" + " \t\t}\n" + " \t}\n" + " },\n"; As you can see javac generates more than 6 calls to append() :) On Fri, Jun 5, 2015 at 6:22 PM, Remi Forax wrote: > Ali, > javac already concatenates constant strings, > so your first example generates only 6 calls to append() :) > > cheers, > R?mi > > > On 06/05/2015 03:45 PM, Ali Ebrahimi wrote: > > Hi, > > > On Thu, Jun 4, 2015 at 9:43 PM, Aleksey Shipilev < > aleksey.shipilev at oracle.com> wrote: > >> On 06/04/2015 04:59 PM, Ali Ebrahimi wrote: >> > Please add String Interpolation and Multi-line String: in that case we >> > would have better answer for problem. >> >> Neither String interpolation nor multi-line Strings are supported by >> current Java language, so throwing these in mix promotes the issue into >> extending the language. Not fun. >> > I think, I don't say java already support them, but I beleave java should > support them. > >> >> In addition, Multi-line Strings is purely a syntax issue, not the >> bytecode interface one, and so it seems rather unrelated. >> > I don't think so. > consider this code: > > String chart = " var chart = new Highcharts.Chart({\n" + > " chart: {\n" + > " zoomType: 'x',\n" + > " height: " + chartHeight + ",\n" + > " width: " + chartWidth + ",\n" + > " type: 'column',\n" + > " plotBackgroundImage: '',\n" + > " renderTo: '" + id + "',\n" + > " \tevents: {\n" + > " \t\tclick: function(e) {\n" + > " \t\t\t//CHARTCLICK_HANDLER_CODE\n" + > " \t\t}\n" + > " \t}\n" + > " },\n"; > needs 20 sb.append call > > vs multi-line string > > String chart = " var chart = new Highcharts.Chart({\n > chart: {\n > zoomType: 'x',\n > height: " + chartHeight + ",\n > width: " + chartWidth + ",\n > type: 'column',\n > plotBackgroundImage: ' ',\n > renderTo: '" + id + "',\n > \tevents: {\n > \t\tclick: function(e) {\n > \t\t\t//CHARTCLICK_HANDLER_CODE\n > \t\t}\n > \t}\n > },\n"; > 6 sb.append call > > vs multi-line string & String Interpolation > > String chart = $" var chart = new Highcharts.Chart({\n > chart: {\n > zoomType: 'x',\n > height: ${chartHeight },\n > width: ${chartWidth },\n > type: 'column',\n > plotBackgroundImage: ' ',\n > renderTo: '${ id }',\n > \tevents: {\n > \t\tclick: function(e) {\n > \t\t\t//CHARTCLICK_HANDLER_CODE\n > \t\t}\n > \t}\n > },\n"; > This depend on implementation detail but max 6 sb.append call > I think with multi-line string & String Interpolation javac have better > view of overall string expressions and can generate optimized bytecode. > > In other side, we have improved code readability. > > -- > > Best Regards, > Ali Ebrahimi > > > -- Best Regards, Ali Ebrahimi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.v.stepanov at oracle.com Fri Jun 5 17:56:37 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Fri, 05 Jun 2015 20:56:37 +0300 Subject: RFR [9] 8080880: some docs cleanup for langtools In-Reply-To: <555F0191.1010609@oracle.com> References: <555E02BE.7020407@oracle.com> <555E03FB.40803@oracle.com> <555E2A4C.9010903@oracle.com> <555F0191.1010609@oracle.com> Message-ID: <5571E2D5.9020405@oracle.com> Sorry, just a reminder. Thanks, Alexander On 22.05.2015 13:14, alexander stepanov wrote: > Hello Jonathan, > > Thanks. > > > It is not appropriate to do partial bulk update to the "not a > supported API" > > The responding changes were reverted, please see > http://cr.openjdk.java.net/~avstepan/8080880/webrev.01/ > > Regards, > Alexander > > On 21.05.2015 21:56, Jonathan Gibbons wrote: >> >> On 05/21/2015 09:12 AM, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8080880/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8080880 >>> >>> Just some minor fix for docs, no other code touched. >>> >>> The affected packages should (probably) not be visible in the new >>> modular system, but nevertheless... >>> >>> Thanks, >>> Alexander >> >> Alexander, >> >> It is not appropriate to do partial bulk update to the "not a >> supported API" >> comment at the head of the internal files. It is strongly preferred >> that this >> part of the comment remain consistent across all source files, so >> that it is >> amenable to bulk updates, should we wish to do so. >> >> I would suggest you separate the otherwise useful work to fix individual >> minor doc issues from any work involving the standard "not a supported >> API" comment at the head of each file. >> >> -- Jon > From vicente.romero at oracle.com Fri Jun 5 22:03:01 2015 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 05 Jun 2015 15:03:01 -0700 Subject: [8u60] request for review: 8068489: remove unnecessary complexity in Flow and Bits, after JDK-8064857 Message-ID: <55721C95.4000004@oracle.com> Hi, Please review the backport of bug: 8068489: remove unnecessary complexity in Flow and Bits, after JDK-8064857 JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8068489 backport: https://bugs.openjdk.java.net/browse/JDK-8068547 original patch pushed to 9: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5e500700b168 public review: http://cr.openjdk.java.net/~vromero/8068489/webrev/ The original patch doesn't apply cleanly. There are no major differences but I think that there are enough to deserve a review. Thanks, Vicente From forax at univ-mlv.fr Sat Jun 6 14:41:05 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 06 Jun 2015 16:41:05 +0200 Subject: String concatenation tweaks In-Reply-To: <5571728F.5030005@oracle.com> References: <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> <55715804.8000406@oracle.com> <5571728F.5030005@oracle.com> Message-ID: <55730681.5060609@univ-mlv.fr> I was too tired when I answer to this email so let's try it again. The whole idea to use invokedynamic here is equivalent to create a new bytecode without having to update the JVMS. So this is not a lightweight operation, I think we can all agree with that. There are several places were we know we need a 'new bytecode', String concatenation is one example, varargs at callsite is another [1], support for array of constants and/or collection initialization are in the same ballpark too. Using invokedynamic has the advantage of not requiring to update the JVMS but several drawbacks: 1) some platforms do not support it, so either the compiler need to maintain two translations or those platform need to use a bytecode rewriting tool. 2) a translation scheme based on invokedynamic uses usually more constant pool entries and less bytecodes because instead of routing things to a generic API, the method descriptor of invokedynamic and the bootstrap constants tends to be specific to a callsite (so the runtime part have more precise information). 3) invokedynamic (exactly the way the method handle API is implemented) has a non negligible impact on startup time. In my opinion, 1 and 2 means we need a backup plan, inside the compiler or/and inside the bytecode rewriting tool. 3 is more complex because it requires to tune/teak several parts of the VM, to reduce the number of lambda forms, the JIT must do a better escape analysis in order to remove primitive boxing and array boxing and IMO most common lambda forms should also be pre-computed. Now, I think that the String concatenation based on invokedynamic should be integrated in 9, behind a -XD option of javac at first, because it's a good simple example that exercise method handle combiners with multiple shapes and see if the startup problem can be solved for that case. regards, R?mi [1] https://bugs.openjdk.java.net/browse/JDK-8013269 On 06/05/2015 11:57 AM, Maurizio Cimadamore wrote: > Hi Alex, > I think the bulk of my concern (which has also been expressed by other > members of my team in this very thread) is that what you are proposing > might be too extreme in practice. Do we have an issue with string > concat? Yes, we do - as you pointed out, the mismatch between JLS and > JVMS is not negligible and sometimes we pay for that performance-wise. > Your solution is to decouple string optimization from the code that's > emitted by the static compiler. Of course that's an elegant solution > which has proven to be effective with lambda. But, as we learned with > lambda, adding new indys in the bytecode is not something that comes > from free. Here's a list of potential concerns: > > * maintenance cost involved (as mentioned in previous emails) in > terms of implementing new features > * platforms (ME) which don't spell indy (yet?); once we start > generating the code suggested here, the only viable option for those > platforms would be to introduce yet another hack to desugar away the > indys and re-generate statically that very same code that the indy > would emit on the fly (as they currently do for lambdas). > * what about other compilers - i.e. other than javac? Does this JEP > propose that all compiler implementations start spitting the new indys? > * bytecode manipulators/weavers would need to handle new indys in > places they are not used to even in absence of source code changes - > just by virtue of recompilation (we got this A LOT when stackmap attrs > were added by default in 7) > * static footprint (i.e. increased classfile size) would definitively > be an issue in strings-concat heavy code (there are machine-generated > files out there which nearly use up all the entries in the CP and do > an huge number of string concat); this is also something that we can > see with lambdas, but in that case the alternative was inner classes, > which, in itself, is another big static footprint killer, so the > choice was easier. Again, a static footprint-oriented benchmark on one > of such files would be welcome. > * while indy is generally a great tool, it has its own performance > quirks; while microbenchmarking with JMH is certainly a good start, I > think we also need to think about real-world scenario benchmarks, to > see if they are affected in a significant way by startup or any other > cost. > > While I fully appreciate the benefits of your proposal, I'm afraid the > reality is a bit more complex. That, coupled with the feeling that, at > the end of the day, it's not like we're updating the string generation > code every other day (at least we never changed in the last 8 years > I've been here), leaves me with a bit of mixed feelings. > > Maurizio > > On 05/06/15 09:04, Aleksey Shipilev wrote: >> First things first, I added more discussion into the JEP draft: >> https://bugs.openjdk.java.net/browse/JDK-8085796 >> >> >> On 06/04/2015 08:50 PM, Maurizio Cimadamore wrote: >>> On 04/06/15 17:23, Aleksey Shipilev wrote: >>>> While it maybe an interesting experiment to try, the performance >>>> engineering experience tells me to focus on the parts that are >>>> relevant, >>>> rather than doing every experiment you can come up with, otherwise you >>>> will never ever un-bury yourself from the performance work:) >>> I don't think this is *any* experiment you can come up with - it's the >>> very foundation for all the JEP work. For the JEP to be viable you need >>> to prove that whatever technique you come up with, it would be >>> almost in >>> the same ballpark as the one implemented in javac. >> If you want to assess the technique itself, you have to compare the >> similar concat approaches used by javac and by indy-based translation >> strategy. It would be dumb to compare a heavily-optimized javac >> translation vs. a dumb indy-based translation. >> >> This is why we have INNER, it is the (almost) direct rewrite of the code >> emitted by vanilla javac now, to the runtime. This strategy is actually >> used to prove the move from compile time to runtime does not experience >> the throughput hits. *That's* the foundational performance data, already >> available. >> >> >>> If the numbers are the same, then it's mostly an argument of whether >>> we want to open up the machinery vs. keeping it buried in javac (and >>> the future maintenance cost for any BSM added). But what if the >>> numbers are not the same? >> But they are the same already! INNER performs the same as vanilla javac >> (BASELINE) is performing. This means the new infrastructure is not >> getting in the way, when our translation strategy emits the plain >> bytecode. Heck, both BASELINE and INNER are recognized by >> OptimizeStringConcat and are optimized to death. >> >> That's what I am trying to tell here: it _is_ the question about the >> machinery at this point. All other strategies are motivational examples >> how this can be used to improve the translation strategy without >> involving javac. >> >> >>> Put in other words, if the natively written javac impl was 10x faster >>> with no startup cost (I'm obviously making things up), wouldn't that >>> mean the very death of this JEP? >> No, it wouldn't. Because really, whatever bytecode you can emit in >> javac, the same bytecode can be emitted through the indy translation >> strategy. (The reverse is not true -- JDK-internal StringConcatFactory >> may use private APIs! -- which makes javac more limiting for this task). >> >> If you discover a bytecode sequence that is 10x faster than proposed >> variants in indy translation strategies, you move it in as additional >> strategy, and that's it (plus the beauty that you can discover such a >> bytecode sequence much later). >> >> This is why we would certainly like to see Louis' patch, to see if we >> can/need to move it in under indy translation strategy, and if/what we >> should adjust at the indy interface. >> >> The only plausible concern at this point is startup time, but you can >> see that even without going with additional javac experiments. And, >> those costs seem to be related to the initialization of indy >> infrastructure -- some project would have to suck up those costs, >> whether it's String Concat, Jigsaw, on any Valhalla-related project. >> >> Thanks, >> -Aleksey >> > From maurizio.cimadamore at oracle.com Sat Jun 6 20:37:45 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 06 Jun 2015 21:37:45 +0100 Subject: String concatenation tweaks In-Reply-To: <55730681.5060609@univ-mlv.fr> References: <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> <55715804.8000406@oracle.com> <5571728F.5030005@oracle.com> <55730681.5060609@univ-mlv.fr> Message-ID: <55735A19.8030103@oracle.com> On 06/06/15 15:41, Remi Forax wrote: > Now, I think that the String concatenation based on invokedynamic > should be integrated in 9, behind a -XD option of javac at first, > because it's a good simple example that exercise method handle > combiners with multiple shapes and see if the startup problem can be > solved for that case. This seems like a very sensible plan. At the very least we will have a chance to test the bits and have a better grip on what real world impact is gonna look like. Maurizio From peter.levart at gmail.com Sun Jun 7 13:44:33 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 07 Jun 2015 15:44:33 +0200 Subject: String concatenation metaprotocol Was: String concatenation tweaks In-Reply-To: <557167FD.1050006@univ-mlv.fr> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <557167FD.1050006@univ-mlv.fr> Message-ID: <55744AC1.1070403@gmail.com> On 06/05/2015 11:12 AM, Remi Forax wrote: > Aleksey, > there is something that the current translation doesn't do, > with by example, "foo" + a + "bar", javac know that "foo" and "bar" > are constants but doesn't propagate this information to the bootstrap > method, the invokedynamic call will use 3 arguments instead of one ; > the only the value of 'a' can changed and the two others can be sent > as bootstrap constants. > > This would help the dynamic part because calculating the length of > "foo" and "bar" will be done once in the bootstrap method instead of > being done each time. In the example below, if 'a' is a primitive > type, it can be a huge win because the total length of the buffer > becomes a constant. > > All we need for that is to define a way to describe how the arguments > of the call and the bootstrap arguments are interleaved. Let say we > use a String with 'A' for classical argument and 'B' for a bootstrap > argument, > in that case "foo" + a + "bar" interleaving is "BAB", so the > corresponding bytecode is > iload 0 // load a > invokedynamic "BAB" (I)Ljava/lang/String ["foo", "bar"] > > And 'null' is a special case because it's a compiler constant but it > can not be encoded as a constant pool constant, > the best IMO is to consider that instead of trying to encode 'null', > it's better to encode "null" as a String. Hm, You are building a DSL for string concatenation, right? What about the bootstrap parameters being a single String with all the constant strings concatenated followed by a sequence of indexes (one for each variable parameter) pointing into the constant string to where each of the parameters is to be inserted? Above example would look like: invokedynamic "foobar" (I)Ljava/lang/String; [3] Choosen strategy could use the passed-in constant string itself (constant pool replacement) as the source of characters when building the final concatenated string without splitting it. Is the limit of 255 parameters in invokedynamic including bootstrap arguments or are they separate? Regards, Peter > > cheers, > R?mi > > On 05/21/2015 02:15 PM, Aleksey Shipilev wrote: >> On 05/15/2015 01:06 AM, Aleksey Shipilev wrote: >>> It actually does not seem that scary. javac changes seem minimal, >>> because they basically mirror [1] what is already done for current >>> String concat and lambda desugaring. >>> >>> JDK side of changes is not too scary as well [2], and it readily lends >>> itself to different implementation strategies, including precomputing >>> the argument lengths. I realized too late it does not check for >>> argument >>> nullity properly, but this is a proof-of-concept patch anyway. >> Updated patches: >> http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/ >> >> INNER_SIZED strategy is enabled by default for everything except >> java.base. This, and a few other touchups make the patched JDK to build >> cleanly, and pass the most java/lang and java/util jtreg tests (there >> are seem to be some failures in Indify-based tests). >> >> Thanks, >> -Aleksey >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Sun Jun 7 13:53:30 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 07 Jun 2015 15:53:30 +0200 Subject: String concatenation metaprotocol Was: String concatenation tweaks In-Reply-To: <55744AC1.1070403@gmail.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <557167FD.1050006@univ-mlv.fr> <55744AC1.1070403@gmail.com> Message-ID: <55744CDA.7020805@gmail.com> On 06/07/2015 03:44 PM, Peter Levart wrote: > > > On 06/05/2015 11:12 AM, Remi Forax wrote: >> Aleksey, >> there is something that the current translation doesn't do, >> with by example, "foo" + a + "bar", javac know that "foo" and "bar" >> are constants but doesn't propagate this information to the bootstrap >> method, the invokedynamic call will use 3 arguments instead of one ; >> the only the value of 'a' can changed and the two others can be sent >> as bootstrap constants. >> >> This would help the dynamic part because calculating the length of >> "foo" and "bar" will be done once in the bootstrap method instead of >> being done each time. In the example below, if 'a' is a primitive >> type, it can be a huge win because the total length of the buffer >> becomes a constant. >> >> All we need for that is to define a way to describe how the arguments >> of the call and the bootstrap arguments are interleaved. Let say we >> use a String with 'A' for classical argument and 'B' for a bootstrap >> argument, >> in that case "foo" + a + "bar" interleaving is "BAB", so the >> corresponding bytecode is >> iload 0 // load a >> invokedynamic "BAB" (I)Ljava/lang/String ["foo", "bar"] >> >> And 'null' is a special case because it's a compiler constant but it >> can not be encoded as a constant pool constant, >> the best IMO is to consider that instead of trying to encode 'null', >> it's better to encode "null" as a String. > > Hm, > > You are building a DSL for string concatenation, right? What about the > bootstrap parameters being a single String with all the constant > strings concatenated followed by a sequence of indexes (one for each > variable parameter) pointing into the constant string to where each of > the parameters is to be inserted? > > Above example would look like: > > invokedynamic "foobar" (I)Ljava/lang/String; [3] > > Choosen strategy could use the passed-in constant string itself > (constant pool replacement) as the source of characters when building > the final concatenated string without splitting it. > > Is the limit of 255 parameters in invokedynamic including bootstrap > arguments or are they separate? > > Regards, Peter One thing to watch out is that these could lead to the explosion of shapes. Majority of concatenation expressions do contain at least one constant string and it is rarely equal to some other constant string in an equivalent concatenation expression found somewhere else... Regards, Peter > >> >> cheers, >> R?mi >> >> On 05/21/2015 02:15 PM, Aleksey Shipilev wrote: >>> On 05/15/2015 01:06 AM, Aleksey Shipilev wrote: >>>> It actually does not seem that scary. javac changes seem minimal, >>>> because they basically mirror [1] what is already done for current >>>> String concat and lambda desugaring. >>>> >>>> JDK side of changes is not too scary as well [2], and it readily lends >>>> itself to different implementation strategies, including precomputing >>>> the argument lengths. I realized too late it does not check for >>>> argument >>>> nullity properly, but this is a proof-of-concept patch anyway. >>> Updated patches: >>> http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/ >>> >>> INNER_SIZED strategy is enabled by default for everything except >>> java.base. This, and a few other touchups make the patched JDK to build >>> cleanly, and pass the most java/lang and java/util jtreg tests (there >>> are seem to be some failures in Indify-based tests). >>> >>> Thanks, >>> -Aleksey >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Sun Jun 7 14:40:12 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 07 Jun 2015 16:40:12 +0200 Subject: String concatenation tweaks In-Reply-To: <55719C61.2060809@univ-mlv.fr> References: <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> <55715804.8000406@oracle.com> <5571728F.5030005@oracle.com> <55719C61.2060809@univ-mlv.fr> Message-ID: <557457CC.30906@gmail.com> On 06/05/2015 02:56 PM, Remi Forax wrote: > There is another limitation, a method call can not have more than 255 > arguments, if there are a lot of '+', the invokedynamic translation > may fail too. > > Maybe, the compiler should use the old strategy if there are too many > arguments. ...or do a decomposition: s1 + s2 + .... + sN == s1 + s2 + ... + s254 + (s255 + s256 + ... + sN) ... so a string concatenation expression is converted to (int)((N + 254) / 255) invokedynamic calls... Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Mon Jun 8 06:31:16 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 08 Jun 2015 08:31:16 +0200 Subject: String concatenation tweaks In-Reply-To: <557018AD.1040308@oracle.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> Message-ID: <557536B4.90101@gmail.com> On 06/04/2015 11:21 AM, Aleksey Shipilev wrote: > The patches, notes, benchmarks are moved under the appropriate bug ID: > http://cr.openjdk.java.net/~shade/8085796/ > > The patches now have a complete support in javac (implemented the "s += > concat part as well), passes jtreg and other smoke tests [*], > plus newly developed regression tests. I think this gives us enough > confidence with going forward. > > Thanks, > -Aleksey > > [*] There are few regression tests that start to fail with the change: > one seems Indify-specific, and another is a javac-specific regression > test. Current patches work that around, and we will probably have to fix > these properly before integration. > > Hi Aleksey, I played with this a bit and it's cool. I created a full-MH strategy called EXACT which always calculates upfront exactly what the resulting string length will be so that it never reallocates the building buffer. It doesn't use StringBuilder at all, but directly fills-in a char[] which it then constructs resulting String with without copying the array. Here's how it compares with other strategies in your quick JMH benchmark: -Djava.lang.invoke.stringConcat=INNER_SIZED Benchmark (size) Mode Cnt Score Error Units ConcatBench.string_string 1 avgt 15 15.433 ? 1.430 ns/op ConcatBench.string_string 10 avgt 15 19.479 ? 2.062 ns/op ConcatBench.string_string 100 avgt 15 46.397 ? 2.112 ns/op ConcatBench.string_string_int 1 avgt 15 73.743 ? 3.888 ns/op ConcatBench.string_string_int 10 avgt 15 81.760 ? 5.398 ns/op ConcatBench.string_string_int 100 avgt 15 204.479 ? 11.887 ns/op ConcatBench.string_string_long 1 avgt 15 78.695 ? 6.292 ns/op ConcatBench.string_string_long 10 avgt 15 81.722 ? 6.045 ns/op ConcatBench.string_string_long 100 avgt 15 213.209 ? 33.311 ns/op -Djava.lang.invoke.stringConcat=INNER Benchmark (size) Mode Cnt Score Error Units ConcatBench.string_string 1 avgt 15 13.990 ? 0.795 ns/op ConcatBench.string_string 10 avgt 15 17.306 ? 1.348 ns/op ConcatBench.string_string 100 avgt 15 46.452 ? 2.730 ns/op ConcatBench.string_string_int 1 avgt 15 48.821 ? 3.855 ns/op ConcatBench.string_string_int 10 avgt 15 70.947 ? 5.537 ns/op ConcatBench.string_string_int 100 avgt 15 145.151 ? 9.816 ns/op ConcatBench.string_string_long 1 avgt 15 47.395 ? 3.015 ns/op ConcatBench.string_string_long 10 avgt 15 71.046 ? 3.842 ns/op ConcatBench.string_string_long 100 avgt 15 144.379 ? 9.042 ns/op -Djava.lang.invoke.stringConcat=EXACT Benchmark (size) Mode Cnt Score Error Units ConcatBench.string_string 1 avgt 15 26.940 ? 1.166 ns/op ConcatBench.string_string 10 avgt 15 29.833 ? 2.053 ns/op ConcatBench.string_string 100 avgt 15 54.967 ? 3.610 ns/op ConcatBench.string_string_int 1 avgt 15 32.282 ? 1.868 ns/op ConcatBench.string_string_int 10 avgt 15 34.342 ? 1.677 ns/op ConcatBench.string_string_int 100 avgt 15 59.280 ? 2.661 ns/op ConcatBench.string_string_long 1 avgt 15 35.146 ? 1.911 ns/op ConcatBench.string_string_long 10 avgt 15 35.799 ? 1.862 ns/op ConcatBench.string_string_long 100 avgt 15 60.160 ? 5.329 ns/op -Djava.lang.invoke.stringConcat=FULL_MH Benchmark (size) Mode Cnt Score Error Units ConcatBench.string_string 1 avgt 15 36.820 ? 1.778 ns/op ConcatBench.string_string 10 avgt 15 39.301 ? 1.939 ns/op ConcatBench.string_string 100 avgt 15 96.144 ? 5.151 ns/op ConcatBench.string_string_int 1 avgt 15 55.876 ? 2.802 ns/op ConcatBench.string_string_int 10 avgt 15 63.166 ? 4.442 ns/op ConcatBench.string_string_int 100 avgt 15 110.761 ? 8.146 ns/op ConcatBench.string_string_long 1 avgt 15 57.672 ? 3.732 ns/op ConcatBench.string_string_long 10 avgt 15 61.310 ? 4.416 ns/op ConcatBench.string_string_long 100 avgt 15 109.464 ? 8.979 ns/op It doesn't beat INNER strategies for small sizes, but does quite well with bigger sizes. It is better than Remi's FULL_MH which is also "full-mh". I think it is a good candidate for optimization, since it seems it has a constant overhead which is not caused by sub-optimal algorithm. Perhaps by encoding the algorithm in a spinned inner class? Here's the implementation: http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/webrev.01/ ...encapsulated in StringConcatFactory.ExactStrategy inner class... The algorithm is very unusual as it fills the char[] backwards. It uses a helper package-private class java.lang.StringConcatHelper with a bunch of methods used for measuring the lengths and "prepending" (not appending) to the resulting char[]. The helper class is in java.lang package to have access to internal methods of j.l.Integer and j.l.Long classes which already contain the basic algorithms for lengthing and stringing the int/long values. Their algorithms for converting int/long to characters fill characters backwards, so this is the main reason why the whole strategy uses this approach. byte and short primitives are widened into int as well as truncated into int in the caching key. float and double primitives are converted to String in the strategy, since their basic conversion algorithm is encapsulated in a class that already allocates a thread-local working array and it would be hard to do it otherwise (i.e. the algorithm can not be split into lengthing and stringing part - it is fused). Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon Jun 8 09:05:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Jun 2015 11:05:02 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55755ABE.9010000@oracle.com> Hello, Looks pretty good. Found some typos: jdk_util.c: 99: specia_update_version jdk-version.m4: 31: assing 124, 132: --with--version-pre-base has a dash too many? I see this pattern consistently used though, am I missing something? /Erik On 2015-06-05 16:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From Alan.Bateman at oracle.com Mon Jun 8 09:34:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 10:34:12 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55756194.3080506@oracle.com> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 I looked through the code changes, skipping most of the make files :-) Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Otherwise looks okay to me. -Alan. From magnus.ihse.bursie at oracle.com Mon Jun 8 12:37:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 8 Jun 2015 14:37:01 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55756194.3080506@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> Message-ID: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> > 8 jun 2015 kl. 11:34 skrev Alan Bateman : > >> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >> >> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >> >> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >> >> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > I looked through the code changes, skipping most of the make files :-) > > Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? > > Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". > > The webrev shows a change to this comment in jvm.h: > "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." > I think this comment can be removed because those JVM_* functions were removed some time ago. > > Otherwise looks okay to me. The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. Are you ok with addressing these concerns at such a later time? /Magnus > > -Alan. From sundararajan.athijegannathan at oracle.com Mon Jun 8 12:55:17 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 08 Jun 2015 18:25:17 +0530 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <557590B5.8090906@oracle.com> +1 on Nashorn changes. -Sundar On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote: >> 8 jun 2015 kl. 11:34 skrev Alan Bateman : >> >>> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >>> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >>> >>> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >>> >>> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >>> >>> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> I looked through the code changes, skipping most of the make files :-) >> >> Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? >> >> Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". >> >> The webrev shows a change to this comment in jvm.h: >> "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." >> I think this comment can be removed because those JVM_* functions were removed some time ago. >> >> Otherwise looks okay to me. > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > > /Magnus > >> -Alan. From Alan.Bateman at oracle.com Mon Jun 8 20:41:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 21:41:09 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <5575FDE5.5020002@oracle.com> On 08/06/2015 13:37, Magnus Ihse Bursie wrote: > : > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > Sure, esp. since my comments are indeed in the area that isn't complete in this webrev. -Alan From daniel.daugherty at oracle.com Mon Jun 8 23:31:20 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Jun 2015 17:31:20 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <557625C8.5050200@oracle.com> > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 General comment: Not all copyright years were updated. General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. common/autoconf/configure.ac No comments. common/autoconf/flags.m4 No comments. common/autoconf/generated-configure.sh There are multiple Copyright notices in this file. Why? L4076: # Verify that a given string represent a valid version number, and assing it to L4077: # a variable. Fixed two typos and reformat a bit: # Verify that a given string represents a valid version number, and # assigning it to a variable. L20186-20189: indent for the block is off L20256-20259: indent for the block is off L20262: as_fn_error $? "--with--version-string must have a value" "$LINENO" 5 The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20275: # Unspecified numerical fields is interpreted as 0. Grammar: 'is interpreted' -> 'are interpreted' L20286: as_fn_error $? "Version string contains + but both 'BUILD' and 'OPT' is missing" "$LINENO" 5 Grammar: 'is missing' -> 'are missing' L20292: as_fn_error $? "--with--version-string fails to parse The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20297-L20302: indent for the block is off L20307: as_fn_error $? "--with--version-pre-base must have a value" "$LINENO" 5 L20315: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-base value... L20316: $as_echo "$as_me: WARNING: --with--version-pre-base value... The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20327-20332: indent for the block is off L20337: as_fn_error $? "--with--version-pre-debuglevel must have... L20345: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-debuglevel value... L20346: $as_echo "$as_me: WARNING: --with--version-pre-debuglevel value The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20361-20366: indent for the block is off L20371: as_fn_error $? "--with--version-opt must have... L20379: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-opt value L20380: $as_echo "$as_me: WARNING: --with--version-opt value has been The '--with--version...' part doesn't match previous usages where '--with-version...' is used At this point, I'm going to stop pointing out the '--with-version...' and '--with--version...' differences; don't know which usage is right. L20388-L20388: indent is off by one L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` This assumes that the "USER" variable is set. Should there be a check for "" and perhaps use "no_user_specified" or something like that? Perhaps the build setup always makes sure that "USER" is set to something. Don't know. L20395-L20400: indent for the block is off L20413-L20431: indent of all blocks in this range are off L20444-L20449: indent for the block is off L20457-L20475: indent of all blocks in this range are off L20486-L20491: indent for the block is off L20504-L20522: indent of all blocks in this range are off L20533-L20538: indent for the block is off L20551-L20569: indent of all blocks in this range are off L20580-L20585: indent for the block is off L20598-L20616: indent of all blocks in this range are off common/autoconf/help.m4 No comments. common/autoconf/jdk-options.m4 Don't know why the 'elliptic curve crypto implementation' support is relocated as part of this changeset, but ... No comments. common/autoconf/spec.gmk.in No comments. common/autoconf/version-numbers No comments. common/nb_native/nbproject/configurations.xml No comments. make/Images.gmk No comments. make/Install.gmk No comments. make/Javadoc.gmk Did you mean to remove the 'clean' target? make/JrtfsJar.gmk No comments. make/MacBundles.gmk No comments. make/jprt.properties No comments. hotspot/make/Makefile No comments. hotspot/make/aix/Makefile No comments. hotspot/make/aix/makefiles/buildtree.make No comments. hotspot/make/aix/makefiles/defs.make No comments. hotspot/make/aix/makefiles/vm.make No comments. hotspot/make/bsd/Makefile No comments. hotspot/make/bsd/makefiles/buildtree.make No comments. hotspot/make/bsd/makefiles/defs.make No comments. hotspot/make/bsd/makefiles/vm.make No comments. hotspot/make/defs.make No comments. hotspot/make/jdk_version No comments. hotspot/make/linux/Makefile No comments. hotspot/make/linux/makefiles/buildtree.make No comments. hotspot/make/linux/makefiles/defs.make No comments. hotspot/make/linux/makefiles/vm.make No comments. hotspot/make/solaris/Makefile No comments. hotspot/make/solaris/makefiles/buildtree.make No comments. hotspot/make/solaris/makefiles/defs.make No comments. hotspot/make/solaris/makefiles/sparcWorks.make No comments. hotspot/make/solaris/makefiles/vm.make No comments. hotspot/make/windows/build.make No comments. hotspot/make/windows/makefiles/compile.make No changes in the frames view. Update: udiff view shows a blank line deleted at the end of the file. hotspot/make/windows/makefiles/debug.make No comments. hotspot/make/windows/makefiles/defs.make No comments. hotspot/make/windows/makefiles/fastdebug.make No comments. hotspot/make/windows/makefiles/product.make No comments. hotspot/make/windows/makefiles/vm.make No comments. hotspot/make/windows/projectfiles/common/Makefile No comments. hotspot/src/share/vm/prims/jvm.h No comments. hotspot/src/share/vm/runtime/arguments.cpp No comments. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/java.hpp No comments. hotspot/src/share/vm/runtime/vmStructs.cpp L1240: please make the 'int' parameter align like the rest. hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? hotspot/src/share/vm/runtime/vm_version.hpp No comments. hotspot/test/runtime/6981737/Test6981737.java No comments. jdk/make/CompileDemos.gmk No comments. jdk/make/data/mainmanifest/manifest.mf No comments. jdk/make/gensrc/GensrcMisc.gmk No comments. jdk/make/launcher/Launcher-jdk.accessibility.gmk No comments. jdk/make/launcher/Launcher-jdk.pack200.gmk No comments. jdk/make/launcher/LauncherCommon.gmk No comments. jdk/make/lib/CoreLibraries.gmk No comments. jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. jdk/src/java.base/share/native/include/jvm.h No comments. jdk/src/java.base/share/native/launcher/defines.h No comments. jdk/src/java.base/share/native/launcher/main.c No comments. jdk/src/java.base/share/native/libjava/System.c No comments. jdk/src/java.base/share/native/libjava/Version.c No comments. jdk/src/java.base/share/native/libjava/jdk_util.c No comments. jdk/src/java.base/windows/native/common/version.rc No comments. jdk/src/java.desktop/windows/native/libawt/windows/awt.rc No comments. jdk/src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC No comments. jdk/test/sun/misc/Version/Version.java No comments. langtools/make/gensrc/GensrcCommon.gmk No comments. langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... langtools/test/tools/javac/options/modes/InfoOptsTest.java No comments. langtools/test/tools/javac/options/modes/SourceTargetTest.java No comments. nashorn/make/BuildNashorn.gmk No comments. nashorn/make/build.xml No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Version.java No comments. common/autoconf/jdk-version.m4 No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties.template nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template No comments. common/bin/test_builds.sh hotspot/make/jdk6_hotspot_distro No comments. Dan On 6/5/15 8:07 AM, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From jan.lahoda at oracle.com Tue Jun 9 04:57:58 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 09 Jun 2015 06:57:58 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55767256.3030802@oracle.com> On 9.6.2015 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... > +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) Jan From forax at univ-mlv.fr Tue Jun 9 07:19:42 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 09 Jun 2015 09:19:42 +0200 Subject: String concatenation metaprotocol Was: String concatenation tweaks In-Reply-To: <55744CDA.7020805@gmail.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <557167FD.1050006@univ-mlv.fr> <55744AC1.1070403@gmail.com> <55744CDA.7020805@gmail.com> Message-ID: <5576938E.3030309@univ-mlv.fr> On 06/07/2015 03:53 PM, Peter Levart wrote: > > > On 06/07/2015 03:44 PM, Peter Levart wrote: >> >> >> On 06/05/2015 11:12 AM, Remi Forax wrote: >>> Aleksey, >>> there is something that the current translation doesn't do, >>> with by example, "foo" + a + "bar", javac know that "foo" and "bar" >>> are constants but doesn't propagate this information to the >>> bootstrap method, the invokedynamic call will use 3 arguments >>> instead of one ; the only the value of 'a' can changed and the two >>> others can be sent as bootstrap constants. >>> >>> This would help the dynamic part because calculating the length of >>> "foo" and "bar" will be done once in the bootstrap method instead of >>> being done each time. In the example below, if 'a' is a primitive >>> type, it can be a huge win because the total length of the buffer >>> becomes a constant. >>> >>> All we need for that is to define a way to describe how the >>> arguments of the call and the bootstrap arguments are interleaved. >>> Let say we use a String with 'A' for classical argument and 'B' for >>> a bootstrap argument, >>> in that case "foo" + a + "bar" interleaving is "BAB", so the >>> corresponding bytecode is >>> iload 0 // load a >>> invokedynamic "BAB" (I)Ljava/lang/String ["foo", "bar"] >>> >>> And 'null' is a special case because it's a compiler constant but it >>> can not be encoded as a constant pool constant, >>> the best IMO is to consider that instead of trying to encode 'null', >>> it's better to encode "null" as a String. >> >> Hm, >> >> You are building a DSL for string concatenation, right? What about >> the bootstrap parameters being a single String with all the constant >> strings concatenated followed by a sequence of indexes (one for each >> variable parameter) pointing into the constant string to where each >> of the parameters is to be inserted? >> >> Above example would look like: >> >> invokedynamic "foobar" (I)Ljava/lang/String; [3] >> >> Choosen strategy could use the passed-in constant string itself >> (constant pool replacement) as the source of characters when building >> the final concatenated string without splitting it. >> >> Is the limit of 255 parameters in invokedynamic including bootstrap >> arguments or are they separate? >> >> Regards, Peter > > One thing to watch out is that these could lead to the explosion of > shapes. Majority of concatenation expressions do contain at least one > constant string and it is rarely equal to some other constant string > in an equivalent concatenation expression found somewhere else... > > Regards, Peter Hi Peter, to answer to your question the limit of 255 parameters is applied twice (because at least for the first call through invokedynamic you have two calls). When a bootstrap method is called, you can not pass more than 252 bootstrap constants, 255 - 3 because the first 3 parameters of the bootstrap method are fixed by the spec. Then the invokedynamic call by iteself, which is a function pointer call which is also limited to 255 parameters. so for the string concatenation, you can not have more than 255 variable arguments and 252 constant arguments. regards, R?mi > >> >>> >>> cheers, >>> R?mi >>> >>> On 05/21/2015 02:15 PM, Aleksey Shipilev wrote: >>>> On 05/15/2015 01:06 AM, Aleksey Shipilev wrote: >>>>> It actually does not seem that scary. javac changes seem minimal, >>>>> because they basically mirror [1] what is already done for current >>>>> String concat and lambda desugaring. >>>>> >>>>> JDK side of changes is not too scary as well [2], and it readily >>>>> lends >>>>> itself to different implementation strategies, including precomputing >>>>> the argument lengths. I realized too late it does not check for >>>>> argument >>>>> nullity properly, but this is a proof-of-concept patch anyway. >>>> Updated patches: >>>> http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/ >>>> >>>> INNER_SIZED strategy is enabled by default for everything except >>>> java.base. This, and a few other touchups make the patched JDK to >>>> build >>>> cleanly, and pass the most java/lang and java/util jtreg tests (there >>>> are seem to be some failures in Indify-based tests). >>>> >>>> Thanks, >>>> -Aleksey >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jun 9 07:20:29 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 09 Jun 2015 09:20:29 +0200 Subject: String concatenation tweaks In-Reply-To: <557457CC.30906@gmail.com> References: <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> <55715804.8000406@oracle.com> <5571728F.5030005@oracle.com> <55719C61.2060809@univ-mlv.fr> <557457CC.30906@gmail.com> Message-ID: <557693BD.6080206@univ-mlv.fr> On 06/07/2015 04:40 PM, Peter Levart wrote: > > > On 06/05/2015 02:56 PM, Remi Forax wrote: >> There is another limitation, a method call can not have more than 255 >> arguments, if there are a lot of '+', the invokedynamic translation >> may fail too. >> >> Maybe, the compiler should use the old strategy if there are too many >> arguments. > > > ...or do a decomposition: > > s1 + s2 + .... + sN == s1 + s2 + ... + s254 + (s255 + s256 + ... + sN) > > ... so a string concatenation expression is converted to (int)((N + > 254) / 255) invokedynamic calls... > > Peter yes, good idea ! R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jun 9 07:37:23 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 09 Jun 2015 09:37:23 +0200 Subject: String concatenation tweaks In-Reply-To: <557536B4.90101@gmail.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <557536B4.90101@gmail.com> Message-ID: <557697B3.1040207@univ-mlv.fr> So basically, you bypass the use of StringBuilder and make the JIT's OptoStringConcat optimization useless by rewriting it in Java, that's nice ! if you combine this idea with the fact that the constant Strings can be pass 'out of the band', it will be hard to have something faster. R?mi On 06/08/2015 08:31 AM, Peter Levart wrote: > > > On 06/04/2015 11:21 AM, Aleksey Shipilev wrote: >> The patches, notes, benchmarks are moved under the appropriate bug ID: >> http://cr.openjdk.java.net/~shade/8085796/ >> >> The patches now have a complete support in javac (implemented the "s += >> concat part as well), passes jtreg and other smoke tests [*], >> plus newly developed regression tests. I think this gives us enough >> confidence with going forward. >> >> Thanks, >> -Aleksey >> >> [*] There are few regression tests that start to fail with the change: >> one seems Indify-specific, and another is a javac-specific regression >> test. Current patches work that around, and we will probably have to fix >> these properly before integration. >> >> > > Hi Aleksey, > > I played with this a bit and it's cool. I created a full-MH strategy > called EXACT which always calculates upfront exactly what the > resulting string length will be so that it never reallocates the > building buffer. It doesn't use StringBuilder at all, but directly > fills-in a char[] which it then constructs resulting String with > without copying the array. Here's how it compares with other > strategies in your quick JMH benchmark: > > -Djava.lang.invoke.stringConcat=INNER_SIZED > > Benchmark (size) Mode Cnt Score Error Units > ConcatBench.string_string 1 avgt 15 15.433 ? 1.430 ns/op > ConcatBench.string_string 10 avgt 15 19.479 ? 2.062 ns/op > ConcatBench.string_string 100 avgt 15 46.397 ? 2.112 ns/op > ConcatBench.string_string_int 1 avgt 15 73.743 ? 3.888 ns/op > ConcatBench.string_string_int 10 avgt 15 81.760 ? 5.398 ns/op > ConcatBench.string_string_int 100 avgt 15 204.479 ? 11.887 ns/op > ConcatBench.string_string_long 1 avgt 15 78.695 ? 6.292 ns/op > ConcatBench.string_string_long 10 avgt 15 81.722 ? 6.045 ns/op > ConcatBench.string_string_long 100 avgt 15 213.209 ? 33.311 ns/op > > -Djava.lang.invoke.stringConcat=INNER > > Benchmark (size) Mode Cnt Score Error Units > ConcatBench.string_string 1 avgt 15 13.990 ? 0.795 ns/op > ConcatBench.string_string 10 avgt 15 17.306 ? 1.348 ns/op > ConcatBench.string_string 100 avgt 15 46.452 ? 2.730 ns/op > ConcatBench.string_string_int 1 avgt 15 48.821 ? 3.855 ns/op > ConcatBench.string_string_int 10 avgt 15 70.947 ? 5.537 ns/op > ConcatBench.string_string_int 100 avgt 15 145.151 ? 9.816 ns/op > ConcatBench.string_string_long 1 avgt 15 47.395 ? 3.015 ns/op > ConcatBench.string_string_long 10 avgt 15 71.046 ? 3.842 ns/op > ConcatBench.string_string_long 100 avgt 15 144.379 ? 9.042 ns/op > > -Djava.lang.invoke.stringConcat=EXACT > > Benchmark (size) Mode Cnt Score Error Units > ConcatBench.string_string 1 avgt 15 26.940 ? 1.166 ns/op > ConcatBench.string_string 10 avgt 15 29.833 ? 2.053 ns/op > ConcatBench.string_string 100 avgt 15 54.967 ? 3.610 ns/op > ConcatBench.string_string_int 1 avgt 15 32.282 ? 1.868 ns/op > ConcatBench.string_string_int 10 avgt 15 34.342 ? 1.677 ns/op > ConcatBench.string_string_int 100 avgt 15 59.280 ? 2.661 ns/op > ConcatBench.string_string_long 1 avgt 15 35.146 ? 1.911 ns/op > ConcatBench.string_string_long 10 avgt 15 35.799 ? 1.862 ns/op > ConcatBench.string_string_long 100 avgt 15 60.160 ? 5.329 ns/op > > -Djava.lang.invoke.stringConcat=FULL_MH > > Benchmark (size) Mode Cnt Score Error Units > ConcatBench.string_string 1 avgt 15 36.820 ? 1.778 ns/op > ConcatBench.string_string 10 avgt 15 39.301 ? 1.939 ns/op > ConcatBench.string_string 100 avgt 15 96.144 ? 5.151 ns/op > ConcatBench.string_string_int 1 avgt 15 55.876 ? 2.802 ns/op > ConcatBench.string_string_int 10 avgt 15 63.166 ? 4.442 ns/op > ConcatBench.string_string_int 100 avgt 15 110.761 ? 8.146 ns/op > ConcatBench.string_string_long 1 avgt 15 57.672 ? 3.732 ns/op > ConcatBench.string_string_long 10 avgt 15 61.310 ? 4.416 ns/op > ConcatBench.string_string_long 100 avgt 15 109.464 ? 8.979 ns/op > > > It doesn't beat INNER strategies for small sizes, but does quite well > with bigger sizes. It is better than Remi's FULL_MH which is also > "full-mh". I think it is a good candidate for optimization, since it > seems it has a constant overhead which is not caused by sub-optimal > algorithm. Perhaps by encoding the algorithm in a spinned inner class? > > Here's the implementation: > > http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/webrev.01/ > > > ...encapsulated in StringConcatFactory.ExactStrategy inner class... > > The algorithm is very unusual as it fills the char[] backwards. It > uses a helper package-private class java.lang.StringConcatHelper with > a bunch of methods used for measuring the lengths and "prepending" > (not appending) to the resulting char[]. The helper class is in > java.lang package to have access to internal methods of j.l.Integer > and j.l.Long classes which already contain the basic algorithms for > lengthing and stringing the int/long values. Their algorithms for > converting int/long to characters fill characters backwards, so this > is the main reason why the whole strategy uses this approach. byte and > short primitives are widened into int as well as truncated into int in > the caching key. float and double primitives are converted to String > in the strategy, since their basic conversion algorithm is > encapsulated in a class that already allocates a thread-local working > array and it would be hard to do it otherwise (i.e. the algorithm can > not be split into lengthing and stringing part - it is fused). > > Regards, Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Jun 9 13:12:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:12:19 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <5576E633.9050503@oracle.com> Hi Daniel, Thank you for your thorough review! On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. > General comment: It looks like support for the 'patch' value is not > completely > implemented through all the Makefiles. I didn't audit for this, > but it's > just my impression. You are basically correct. The makefiles all propagate the patch value where needed, but the actual source code changes in hotspot and jdk ignores the patch field as of now. This will be corrected in a later add-on patch, submitted by someone from the jdk and/or hotspot team rather than the build team. > > common/autoconf/generated-configure.sh > There are multiple Copyright notices in this file. Why? Oh dear, you've reviewed the generated file. :-& I'm really impressed by your effort! However, the generated-configure.sh file is automatically created by the autoconf framework from the rest of the files in common/autoconf/*, so we cannot direcly modify it's contents - only indirectly. The reason it's checked in, is that otherwise every user would need to generate it before being able to run configure. In build reviews, we usually either revert changes to generated-configure.sh before posting a review to hide it (and re-generate it before pushing), or we just ignore it during reviews. I should have done that, or pointed out that it was not needed nor possible to review when I cross-posted. I'm sorry. > > L4076: # Verify that a given string represent a valid version > number, and assing it to > L4077: # a variable. > Fixed two typos and reformat a bit: > # Verify that a given string represents a valid version > number, and > # assigning it to a variable. I'll put that fix in the source .m4 file instead. Thanks. > > L20262: as_fn_error $? "--with--version-string must have a > value" "$LINENO" 5 > The '--with--version...' part doesn't match previous usages where > '--with-version...' is used Yes, you're right. Erik pointed it out as well. It's a typo in the error message. It's all over the place due to copied code. I'll fix it in the source .m4 file. (As a side note, I have a half-finished follow-up patch that will reduce the amount of code duplication, but it requires some framework changes so it'll have to be a separate thing.) > > L20275: # Unspecified numerical fields is interpreted as 0. > Grammar: 'is interpreted' -> 'are interpreted' > > L20286: as_fn_error $? "Version string contains + but both > 'BUILD' and 'OPT' is missing" "$LINENO" 5 > Grammar: 'is missing' -> 'are missing' Those darn English plural forms! Why can't you all do as we sensible Swedes and get rid of them? ;-) (I'll fix) > > L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` > This assumes that the "USER" variable is set. Should there > be a check for "" and perhaps use "no_user_specified" or > something like that? Perhaps the build setup always makes > sure that "USER" is set to something. Don't know. Hm. I think the worst thing that'll happen is that the username part of the opt string gets empty. This part is basically copied right off the old build, where we have relied on the $USER variable being present for all the time with no problems, so I think it's quite safe to assume. > > common/autoconf/jdk-options.m4 > Don't know why the 'elliptic curve crypto implementation' support > is relocated as part of this changeset, but ... It was incorrectly placed not at the top indentation level, but in the middle of the function definition where the old versioning code were handled. (Which, mostly by chance, happens to work in autoconf, but is really bad style). > make/Javadoc.gmk > Did you mean to remove the 'clean' target? Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, that's just some dead code. > > hotspot/make/windows/makefiles/compile.make > No changes in the frames view. > Update: udiff view shows a blank line deleted at the end of the file. That's probably the result of some change going forth and then back again during development. But then again, removing extra blank linkes is not a bad thing. (jcheck unfortunately does not enforce any style checks for make files :-( so they tend to detoriate over time.) > > hotspot/src/share/vm/runtime/java.cpp > L661: void JDK_Version::fully_initialize( > L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t > update) { > L663: // This is only called when current is less than 1.6 and > we've gotten > > Since you're ripping out vestigial version support, I think this > function can go away since this is version 9 and newer. Don't > really > know for sure, but based on that comment... It probably can, yes. This and other core changes to the actual .cpp/.java files will be addressed in a follow-up patch. > > hotspot/src/share/vm/runtime/java.hpp > No comments. > > hotspot/src/share/vm/runtime/vmStructs.cpp > L1240: please make the 'int' parameter align like the rest. Are you okay with defering such a change to a follow-up patch? It's likely the entire struct will need changes to be able to handle a theoretically arbitrarily long version number. > > hotspot/src/share/vm/runtime/vm_version.cpp > L84: void Abstract_VM_Version::initialize() { > L85: // FIXME: Initialization can probably be removed now. > I agree, but that would entail also removing the > _initialized and the uses of it... Follow on bug fix? Definitely follow on. > jdk/src/java.base/share/classes/sun/misc/Version.java.template > L149: * Returns the security version of the running JVM if > it's 1.6 or newer > This JavaDoc update is wrong, but it might not be important > if sun.misc.Version class is going away. I'm not sure if it's going to be replaced by, or just complemented by java.util.Version, but in any case it will need a follow-up patch to clean up this and other issues. > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... I'll defer that question to Kumar, who wrote that piece of code. My guess is that when Hotspot express was dropped, the ability to use a JVM from another JDK release bit rotteded away. /Magnus From daniel.daugherty at oracle.com Tue Jun 9 13:20:27 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 09 Jun 2015 07:20:27 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E81B.8050703@oracle.com> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: > Hi Daniel, > > Thank you for your thorough review! This was my (failing) attempt at a "fast pass" review... :-) > > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. >> General comment: It looks like support for the 'patch' value is not >> completely >> implemented through all the Makefiles. I didn't audit for this, >> but it's >> just my impression. > > You are basically correct. The makefiles all propagate the patch value > where needed, but the actual source code changes in hotspot and jdk > ignores the patch field as of now. This will be corrected in a later > add-on patch, submitted by someone from the jdk and/or hotspot team > rather than the build team. > >> >> common/autoconf/generated-configure.sh >> There are multiple Copyright notices in this file. Why? > Oh dear, you've reviewed the generated file. :-& I'm really impressed > by your effort! Ahhh... now that you say it... it sounds familiar... I may have made this same mistake before. I'll try to remember next time. > However, the generated-configure.sh file is automatically created by > the autoconf framework from the rest of the files in > common/autoconf/*, so we cannot direcly modify it's contents - only > indirectly. The reason it's checked in, is that otherwise every user > would need to generate it before being able to run configure. In build > reviews, we usually either revert changes to generated-configure.sh > before posting a review to hide it (and re-generate it before > pushing), or we just ignore it during reviews. I should have done > that, or pointed out that it was not needed nor possible to review > when I cross-posted. I'm sorry. > >> >> L4076: # Verify that a given string represent a valid version >> number, and assing it to >> L4077: # a variable. >> Fixed two typos and reformat a bit: >> # Verify that a given string represents a valid version >> number, and >> # assigning it to a variable. > I'll put that fix in the source .m4 file instead. Thanks. >> >> L20262: as_fn_error $? "--with--version-string must have a >> value" "$LINENO" 5 >> The '--with--version...' part doesn't match previous usages >> where >> '--with-version...' is used > Yes, you're right. Erik pointed it out as well. It's a typo in the > error message. It's all over the place due to copied code. I'll fix it > in the source .m4 file. > > (As a side note, I have a half-finished follow-up patch that will > reduce the amount of code duplication, but it requires some framework > changes so it'll have to be a separate thing.) > >> >> L20275: # Unspecified numerical fields is interpreted as 0. >> Grammar: 'is interpreted' -> 'are interpreted' >> >> L20286: as_fn_error $? "Version string contains + but >> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >> Grammar: 'is missing' -> 'are missing' > Those darn English plural forms! Why can't you all do as we sensible > Swedes and get rid of them? ;-) > > (I'll fix) > >> >> L20388: username=`$ECHO "$USER" | $TR -d -c >> '[a-z][A-Z][0-9]'` >> This assumes that the "USER" variable is set. Should there >> be a check for "" and perhaps use "no_user_specified" or >> something like that? Perhaps the build setup always makes >> sure that "USER" is set to something. Don't know. > Hm. I think the worst thing that'll happen is that the username part > of the opt string gets empty. This part is basically copied right off > the old build, where we have relied on the $USER variable being > present for all the time with no problems, so I think it's quite safe > to assume. >> >> common/autoconf/jdk-options.m4 >> Don't know why the 'elliptic curve crypto implementation' support >> is relocated as part of this changeset, but ... > It was incorrectly placed not at the top indentation level, but in the > middle of the function definition where the old versioning code were > handled. (Which, mostly by chance, happens to work in autoconf, but is > really bad style). > >> make/Javadoc.gmk >> Did you mean to remove the 'clean' target? > Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, > that's just some dead code. > >> >> hotspot/make/windows/makefiles/compile.make >> No changes in the frames view. >> Update: udiff view shows a blank line deleted at the end of the >> file. > > That's probably the result of some change going forth and then back > again during development. But then again, removing extra blank linkes > is not a bad thing. (jcheck unfortunately does not enforce any style > checks for make files :-( so they tend to detoriate over time.) > >> >> hotspot/src/share/vm/runtime/java.cpp >> L661: void JDK_Version::fully_initialize( >> L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t >> update) { >> L663: // This is only called when current is less than 1.6 and >> we've gotten >> >> Since you're ripping out vestigial version support, I think this >> function can go away since this is version 9 and newer. Don't >> really >> know for sure, but based on that comment... > It probably can, yes. This and other core changes to the actual > .cpp/.java files will be addressed in a follow-up patch. >> >> hotspot/src/share/vm/runtime/java.hpp >> No comments. >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> L1240: please make the 'int' parameter align like the rest. > Are you okay with defering such a change to a follow-up patch? Yes. > It's likely the entire struct will need changes to be able to handle a > theoretically arbitrarily long version number. > >> >> hotspot/src/share/vm/runtime/vm_version.cpp >> L84: void Abstract_VM_Version::initialize() { >> L85: // FIXME: Initialization can probably be removed now. >> I agree, but that would entail also removing the >> _initialized and the uses of it... Follow on bug fix? > Definitely follow on. > >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> L149: * Returns the security version of the running JVM if >> it's 1.6 or newer >> This JavaDoc update is wrong, but it might not be important >> if sun.misc.Version class is going away. > I'm not sure if it's going to be replaced by, or just complemented by > java.util.Version, but in any case it will need a follow-up patch to > clean up this and other issues. >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus Dan From magnus.ihse.bursie at oracle.com Tue Jun 9 13:36:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:36:55 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E983.5020902@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E983.5020902@oracle.com> Message-ID: <5576EBF7.40607@oracle.com> On 2015-06-09 15:26, Claes Redestad wrote: > On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > While we know there's no guarantee that swapping in an older VM will > work, in the face of a regression in a promoted build we still > routinely (automatically, even) swap out the VM with a recent VM to > get a rough estimate of whether the regression was caused by a HotSpot > or JDK/tools change, mostly since this currently saves us time in > narrowing down the changes to bisect over/investigate. So, there's at > least some value in not intentionally breaking build-to-build > backwards compatibility, but we don't expect it to always work and > wouldn't make much fuss about it breaking. If an extra case "1.9" is > all it takes to make it work with last week's VM, however... Actually, I think I messed up a bit there. I believe the real question here was not about mixing different versions of Hotspot and the JDK, but mixing different versions of javac and the JDK. I think. :) /Magnus From magnus.ihse.bursie at oracle.com Tue Jun 9 13:52:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:52:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E81B.8050703@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> Message-ID: <5576EF94.3010500@oracle.com> Here's an updated webrev, which fixes the typos that were pointed out by reviewers: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ And here's a (much simpler) delta webrev which shows just these changes: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ /Magnus On 2015-06-09 15:20, Daniel D. Daugherty wrote: > On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >> Hi Daniel, >> >> Thank you for your thorough review! > > This was my (failing) attempt at a "fast pass" review... :-) > > >> >> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>> > >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>> >>> >>> General comment: Not all copyright years were updated. >>> General comment: It looks like support for the 'patch' value is not >>> completely >>> implemented through all the Makefiles. I didn't audit for this, >>> but it's >>> just my impression. >> >> You are basically correct. The makefiles all propagate the patch >> value where needed, but the actual source code changes in hotspot and >> jdk ignores the patch field as of now. This will be corrected in a >> later add-on patch, submitted by someone from the jdk and/or hotspot >> team rather than the build team. >> >>> >>> common/autoconf/generated-configure.sh >>> There are multiple Copyright notices in this file. Why? >> Oh dear, you've reviewed the generated file. :-& I'm really impressed >> by your effort! > > Ahhh... now that you say it... it sounds familiar... I may have > made this same mistake before. I'll try to remember next time. > > >> However, the generated-configure.sh file is automatically created by >> the autoconf framework from the rest of the files in >> common/autoconf/*, so we cannot direcly modify it's contents - only >> indirectly. The reason it's checked in, is that otherwise every user >> would need to generate it before being able to run configure. In >> build reviews, we usually either revert changes to >> generated-configure.sh before posting a review to hide it (and >> re-generate it before pushing), or we just ignore it during reviews. >> I should have done that, or pointed out that it was not needed nor >> possible to review when I cross-posted. I'm sorry. >> >>> >>> L4076: # Verify that a given string represent a valid version >>> number, and assing it to >>> L4077: # a variable. >>> Fixed two typos and reformat a bit: >>> # Verify that a given string represents a valid version >>> number, and >>> # assigning it to a variable. >> I'll put that fix in the source .m4 file instead. Thanks. >>> >>> L20262: as_fn_error $? "--with--version-string must have a >>> value" "$LINENO" 5 >>> The '--with--version...' part doesn't match previous usages >>> where >>> '--with-version...' is used >> Yes, you're right. Erik pointed it out as well. It's a typo in the >> error message. It's all over the place due to copied code. I'll fix >> it in the source .m4 file. >> >> (As a side note, I have a half-finished follow-up patch that will >> reduce the amount of code duplication, but it requires some framework >> changes so it'll have to be a separate thing.) >> >>> >>> L20275: # Unspecified numerical fields is interpreted as 0. >>> Grammar: 'is interpreted' -> 'are interpreted' >>> >>> L20286: as_fn_error $? "Version string contains + but >>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>> Grammar: 'is missing' -> 'are missing' >> Those darn English plural forms! Why can't you all do as we sensible >> Swedes and get rid of them? ;-) >> >> (I'll fix) >> >>> >>> L20388: username=`$ECHO "$USER" | $TR -d -c >>> '[a-z][A-Z][0-9]'` >>> This assumes that the "USER" variable is set. Should there >>> be a check for "" and perhaps use "no_user_specified" or >>> something like that? Perhaps the build setup always makes >>> sure that "USER" is set to something. Don't know. >> Hm. I think the worst thing that'll happen is that the username part >> of the opt string gets empty. This part is basically copied right off >> the old build, where we have relied on the $USER variable being >> present for all the time with no problems, so I think it's quite safe >> to assume. >>> >>> common/autoconf/jdk-options.m4 >>> Don't know why the 'elliptic curve crypto implementation' support >>> is relocated as part of this changeset, but ... >> It was incorrectly placed not at the top indentation level, but in >> the middle of the function definition where the old versioning code >> were handled. (Which, mostly by chance, happens to work in autoconf, >> but is really bad style). >> >>> make/Javadoc.gmk >>> Did you mean to remove the 'clean' target? >> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >> that's just some dead code. >> >>> >>> hotspot/make/windows/makefiles/compile.make >>> No changes in the frames view. >>> Update: udiff view shows a blank line deleted at the end of the >>> file. >> >> That's probably the result of some change going forth and then back >> again during development. But then again, removing extra blank linkes >> is not a bad thing. (jcheck unfortunately does not enforce any style >> checks for make files :-( so they tend to detoriate over time.) >> >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> L661: void JDK_Version::fully_initialize( >>> L662: uint8_t major, uint8_t minor, uint8_t security, >>> uint8_t update) { >>> L663: // This is only called when current is less than 1.6 and >>> we've gotten >>> >>> Since you're ripping out vestigial version support, I think >>> this >>> function can go away since this is version 9 and newer. >>> Don't really >>> know for sure, but based on that comment... >> It probably can, yes. This and other core changes to the actual >> .cpp/.java files will be addressed in a follow-up patch. >>> >>> hotspot/src/share/vm/runtime/java.hpp >>> No comments. >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> L1240: please make the 'int' parameter align like the rest. >> Are you okay with defering such a change to a follow-up patch? > > Yes. > > >> It's likely the entire struct will need changes to be able to handle >> a theoretically arbitrarily long version number. >> >>> >>> hotspot/src/share/vm/runtime/vm_version.cpp >>> L84: void Abstract_VM_Version::initialize() { >>> L85: // FIXME: Initialization can probably be removed now. >>> I agree, but that would entail also removing the >>> _initialized and the uses of it... Follow on bug fix? >> Definitely follow on. >> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> L149: * Returns the security version of the running JVM if >>> it's 1.6 or newer >>> This JavaDoc update is wrong, but it might not be important >>> if sun.misc.Version class is going away. >> I'm not sure if it's going to be replaced by, or just complemented by >> java.util.Version, but in any case it will need a follow-up patch to >> clean up this and other issues. >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > Dan From kumar.x.srinivasan at oracle.com Tue Jun 9 14:25:45 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 09 Jun 2015 07:25:45 -0700 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55767256.3030802@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55767256.3030802@oracle.com> Message-ID: <5576F769.3060002@oracle.com> On 6/8/2015 9:57 PM, Jan Lahoda wrote: > On 9.6.2015 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... >> > > +1 on keeping both "1.9" and "9" here. javac can be used independently > on the rest of JDK to some extent, so support for running it on older > builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 > javac should be prepared for the new version scheme in advance.) Yes, I think for the most part langtools seems to be working in the sandbox repo, with these changes, the remaining work is to align the version and fullversion of langtools/test to be compliant to the JDK version. Kumar > > Jan From konstantin.barzilovich at oracle.com Tue Jun 9 15:00:51 2015 From: konstantin.barzilovich at oracle.com (Konstantin) Date: Tue, 09 Jun 2015 18:00:51 +0300 Subject: Cyclic definition of overriding Message-ID: Hello, I consider this simple case: interface Test1 { int foo(); // m1 } interface Test2{ int foo(); // m2 } class Test implements Test1, Test2{ } I try to understand if m1 is inherited by Test. I follow jls-8.4.8-200. All subassertions are true except jls-8.4.8-200-E. To decide if it is true or not we need to turn to overriding definition jls-8.4.8.1-200. More detailed, I want to be sure that m2 isn't m'. That's why I need to know if m2 overrides m1. And new subassertion jls-8.4.8.1-200-D says about inheriting. "8.4.8.1 C does not inherit mI." So we get a circle. In order to understand if m1 is inherited we need to know if it is inherited. Please correct me if i misunderstand anything. Thanks, Konstantin From claes.redestad at oracle.com Tue Jun 9 13:26:27 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 09 Jun 2015 15:26:27 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E983.5020902@oracle.com> On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus While we know there's no guarantee that swapping in an older VM will work, in the face of a regression in a promoted build we still routinely (automatically, even) swap out the VM with a recent VM to get a rough estimate of whether the regression was caused by a HotSpot or JDK/tools change, mostly since this currently saves us time in narrowing down the changes to bisect over/investigate. So, there's at least some value in not intentionally breaking build-to-build backwards compatibility, but we don't expect it to always work and wouldn't make much fuss about it breaking. If an extra case "1.9" is all it takes to make it work with last week's VM, however... /Claes From peter.levart at gmail.com Tue Jun 9 17:20:53 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 09 Jun 2015 19:20:53 +0200 Subject: String concatenation tweaks In-Reply-To: <557697B3.1040207@univ-mlv.fr> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <557536B4.90101@gmail.com> <557697B3.1040207@univ-mlv.fr> Message-ID: <55772075.5020104@gmail.com> On 06/09/2015 09:37 AM, Remi Forax wrote: > So basically, you bypass the use of StringBuilder and make the JIT's > OptoStringConcat optimization useless by rewriting it in Java, that's > nice ! > > if you combine this idea with the fact that the constant Strings can > be pass 'out of the band', it will be hard to have something faster. I don't think it is realistic to "compile-in" specializations for constant strings. Why? There are too much of them and each distinct specialization takes time to initialize. This is what I found out analyzing string concatenation usages of a real-world program... I asked myself how one could measure and compare startup performance for a real-world program. Ideally one would like to measure just string concatenations as they occur in a real-world program when it starts up. So I thought, why not record string concatenations as they occur and then replay them in a JMH benchmark? Here's what I came-up with: http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/webrev.02/ Analyzer is a generic MethodHandle interceptor that can be used to analyze registrations (call-site linkages) and invocations of method handles that are instrumented. I took Apache Tomcat 8 sources, compiled it with indy-string-concat-enabled javac and started the container with the following system property (defined in Tomcat's setenv.sh): CATALINA_OPTS=-Djava.lang.invoke.stringConcat.analyzer=java.lang.invoke.StringConcatRecorderAgent:/tmp/concats_catalina.txt ...after Tomcat booted, I requested it's home page once and then shut it down. What I got recorded is the following Java source: http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/benchmarks/TomcatStartup.java Running this as part of JMH benchmark is easy: http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/benchmarks/ConcatStartupBench.java The results suggest that caching should always be turned on. The most interesting are "Cold" tests. These are one-shot invocations of a bunch of string-concatenation invocations as they occur in Tomcat startup in a newly started VM. "Warm" tests are one-shot invocations after 10 iterations of warm-up invocations and show how quickly some strategies get optimized by JIT compared to others. Just looking at TomcatStartup.java string concatenations suggests that majority of them are actually concatenations of String(s) and minority of them use other types of arguments. This is where OptoStringConcat does it's best. To see statistics and distributions of string concatenations in Tomcat startup, I fired it up using the following system property (defined in Tomcat's setenv.sh): CATALINA_OPTS=-Djava.lang.invoke.stringConcat.analyzer=java.lang.invoke.StringConcatStatsAgent:/tmp/concat_stats_catalina.txt ...which produces the following file after it is shut down: http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/benchmarks/concat_stats_catalina.txt Should we optimize for Tomcat, optimizing for two String concatenation will cover 90% of call sites and 90% of invocations. Any ideas which program to try next? It should be easy to compile it from sources on JDK9 and run it on JDK9 too. For Tomcat, this was straight-forward. I just had to strip definitions of java.endorsed.dirs system property from startup scripts... So to answer R?mi's proposal on specialization for constant strings: The statistics of running Tomcat show that there are just 18 (17 when types are truncated) distinct shapes of string concatenations in 519 distinct call-sites that are used during Tomcat startup. I don't have evidence currently on which strings are constant and which not, but I have a feeling that much more than 18 distinct constant strings are being used in Tomcat startup. Looking at startup benchmark numbers, I also have a feeling that too-much specialization will hurt startup and overall real-world performance, not improve it. Regards, Peter > > R?mi > > On 06/08/2015 08:31 AM, Peter Levart wrote: >> >> >> On 06/04/2015 11:21 AM, Aleksey Shipilev wrote: >>> The patches, notes, benchmarks are moved under the appropriate bug ID: >>> http://cr.openjdk.java.net/~shade/8085796/ >>> >>> The patches now have a complete support in javac (implemented the "s += >>> concat part as well), passes jtreg and other smoke tests [*], >>> plus newly developed regression tests. I think this gives us enough >>> confidence with going forward. >>> >>> Thanks, >>> -Aleksey >>> >>> [*] There are few regression tests that start to fail with the change: >>> one seems Indify-specific, and another is a javac-specific regression >>> test. Current patches work that around, and we will probably have to fix >>> these properly before integration. >>> >>> >> >> Hi Aleksey, >> >> I played with this a bit and it's cool. I created a full-MH strategy >> called EXACT which always calculates upfront exactly what the >> resulting string length will be so that it never reallocates the >> building buffer. It doesn't use StringBuilder at all, but directly >> fills-in a char[] which it then constructs resulting String with >> without copying the array. Here's how it compares with other >> strategies in your quick JMH benchmark: >> >> -Djava.lang.invoke.stringConcat=INNER_SIZED >> >> Benchmark (size) Mode Cnt Score Error Units >> ConcatBench.string_string 1 avgt 15 15.433 ? 1.430 ns/op >> ConcatBench.string_string 10 avgt 15 19.479 ? 2.062 ns/op >> ConcatBench.string_string 100 avgt 15 46.397 ? 2.112 ns/op >> ConcatBench.string_string_int 1 avgt 15 73.743 ? 3.888 ns/op >> ConcatBench.string_string_int 10 avgt 15 81.760 ? 5.398 ns/op >> ConcatBench.string_string_int 100 avgt 15 204.479 ? 11.887 ns/op >> ConcatBench.string_string_long 1 avgt 15 78.695 ? 6.292 ns/op >> ConcatBench.string_string_long 10 avgt 15 81.722 ? 6.045 ns/op >> ConcatBench.string_string_long 100 avgt 15 213.209 ? 33.311 ns/op >> >> -Djava.lang.invoke.stringConcat=INNER >> >> Benchmark (size) Mode Cnt Score Error Units >> ConcatBench.string_string 1 avgt 15 13.990 ? 0.795 ns/op >> ConcatBench.string_string 10 avgt 15 17.306 ? 1.348 ns/op >> ConcatBench.string_string 100 avgt 15 46.452 ? 2.730 ns/op >> ConcatBench.string_string_int 1 avgt 15 48.821 ? 3.855 ns/op >> ConcatBench.string_string_int 10 avgt 15 70.947 ? 5.537 ns/op >> ConcatBench.string_string_int 100 avgt 15 145.151 ? 9.816 ns/op >> ConcatBench.string_string_long 1 avgt 15 47.395 ? 3.015 ns/op >> ConcatBench.string_string_long 10 avgt 15 71.046 ? 3.842 ns/op >> ConcatBench.string_string_long 100 avgt 15 144.379 ? 9.042 ns/op >> >> -Djava.lang.invoke.stringConcat=EXACT >> >> Benchmark (size) Mode Cnt Score Error Units >> ConcatBench.string_string 1 avgt 15 26.940 ? 1.166 ns/op >> ConcatBench.string_string 10 avgt 15 29.833 ? 2.053 ns/op >> ConcatBench.string_string 100 avgt 15 54.967 ? 3.610 ns/op >> ConcatBench.string_string_int 1 avgt 15 32.282 ? 1.868 ns/op >> ConcatBench.string_string_int 10 avgt 15 34.342 ? 1.677 ns/op >> ConcatBench.string_string_int 100 avgt 15 59.280 ? 2.661 ns/op >> ConcatBench.string_string_long 1 avgt 15 35.146 ? 1.911 ns/op >> ConcatBench.string_string_long 10 avgt 15 35.799 ? 1.862 ns/op >> ConcatBench.string_string_long 100 avgt 15 60.160 ? 5.329 ns/op >> >> -Djava.lang.invoke.stringConcat=FULL_MH >> >> Benchmark (size) Mode Cnt Score Error Units >> ConcatBench.string_string 1 avgt 15 36.820 ? 1.778 ns/op >> ConcatBench.string_string 10 avgt 15 39.301 ? 1.939 ns/op >> ConcatBench.string_string 100 avgt 15 96.144 ? 5.151 ns/op >> ConcatBench.string_string_int 1 avgt 15 55.876 ? 2.802 ns/op >> ConcatBench.string_string_int 10 avgt 15 63.166 ? 4.442 ns/op >> ConcatBench.string_string_int 100 avgt 15 110.761 ? 8.146 ns/op >> ConcatBench.string_string_long 1 avgt 15 57.672 ? 3.732 ns/op >> ConcatBench.string_string_long 10 avgt 15 61.310 ? 4.416 ns/op >> ConcatBench.string_string_long 100 avgt 15 109.464 ? 8.979 ns/op >> >> >> It doesn't beat INNER strategies for small sizes, but does quite well >> with bigger sizes. It is better than Remi's FULL_MH which is also >> "full-mh". I think it is a good candidate for optimization, since it >> seems it has a constant overhead which is not caused by sub-optimal >> algorithm. Perhaps by encoding the algorithm in a spinned inner class? >> >> Here's the implementation: >> >> http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/webrev.01/ >> >> >> ...encapsulated in StringConcatFactory.ExactStrategy inner class... >> >> The algorithm is very unusual as it fills the char[] backwards. It >> uses a helper package-private class java.lang.StringConcatHelper with >> a bunch of methods used for measuring the lengths and "prepending" >> (not appending) to the resulting char[]. The helper class is in >> java.lang package to have access to internal methods of j.l.Integer >> and j.l.Long classes which already contain the basic algorithms for >> lengthing and stringing the int/long values. Their algorithms for >> converting int/long to characters fill characters backwards, so this >> is the main reason why the whole strategy uses this approach. byte >> and short primitives are widened into int as well as truncated into >> int in the caching key. float and double primitives are converted to >> String in the strategy, since their basic conversion algorithm is >> encapsulated in a class that already allocates a thread-local working >> array and it would be hard to do it otherwise (i.e. the algorithm can >> not be split into lengthing and stringing part - it is fused). >> >> Regards, Peter >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Jun 9 19:34:28 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 09 Jun 2015 12:34:28 -0700 Subject: Cyclic definition of overriding In-Reply-To: References: Message-ID: <55773FC4.1070808@oracle.com> I don't know where you're seeing jls-8.4.8.1-200-D -- there is only jls-8.4.8.1-200-{A,B,C} in the HTML and the master files. That said, jls-8.4.8.1-200 says "An instance method mC declared in or inherited by class C, 'overrides from C' another method mI declared in an interface I, iff all of the following are true:" -- so you have to know that foo() is already inherited by class Test (say from Test1) in order to check if Test.foo() overrides Test2.foo(). As you say, we're still trying to figure if foo() is inherited from Test1. This all seems disturbingly tricky for such a simple scenario. Dan, any comments? Alex On 6/9/2015 8:00 AM, Konstantin wrote: > > Hello, > > I consider this simple case: > > interface Test1 { > int foo(); // m1 > } > > interface Test2{ > int foo(); // m2 > } > class Test implements Test1, Test2{ > } > > I try to understand if m1 is inherited by Test. I follow jls-8.4.8-200. > All subassertions are true except jls-8.4.8-200-E. To decide if it is > true or not we need to turn to overriding definition jls-8.4.8.1-200. > More detailed, I want to be sure that m2 isn't m'. That's why I need to > know if m2 overrides m1. > And new subassertion jls-8.4.8.1-200-D says about inheriting. > "8.4.8.1 C does not inherit mI." > So we get a circle. In order to understand if m1 is inherited we need to > know if it is inherited. > Please correct me if i misunderstand anything. > > Thanks, > Konstantin From daniel.smith at oracle.com Tue Jun 9 20:15:02 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Jun 2015 14:15:02 -0600 Subject: Cyclic definition of overriding In-Reply-To: References: Message-ID: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> > On Jun 9, 2015, at 9:00 AM, Konstantin wrote: > > I consider this simple case: > > interface Test1 { > int foo(); // m1 > } > > interface Test2{ > int foo(); // m2 > } > class Test implements Test1, Test2{ > } > > I try to understand if m1 is inherited by Test. I follow jls-8.4.8-200. > All subassertions are true except jls-8.4.8-200-E. To decide if it is true or not we need to turn to overriding definition jls-8.4.8.1-200. Specifically: "There exists no method m' that is a member of the direct superclass or a direct superinterface, D', of C (m distinct from m', D distinct from D'), such that m' from D' overrides the declaration of the method m." We've bound our variables as follows: C=Test D=Test1 m=m1 m'=m2 D'=Test2 The question we are asking: does m2 override m1 from Test2? > More detailed, I want to be sure that m2 isn't m'. That's why I need to know if m2 overrides m1. > And new subassertion jls-8.4.8.1-200-D says about inheriting. > "8.4.8.1 C does not inherit mI." > So we get a circle. Note the question above: we want to know if m2 overrides m1 from Test2. Test2 is an interface, so 8.4.8.1 doesn't apply. Instead, we want 9.4.1.1. "An instance method m1, declared in or inherited by an interface I, overrides from I another instance method, m2, declared in interface J, iff both of the following are true:" The bindings here are tricky, because we happen to have a name clash: m1=m2 I=Test2 m2=m1 J=Test1 Is m2 "declared in or inherited by" Test2? Trivially, yes. Is m1 declared in Test1? Yes. Then we encounter the first bullet: is Test2 a subinterface of Test1? Nope. We're done. > On Jun 9, 2015, at 1:34 PM, Alex Buckley wrote: > > That said, jls-8.4.8.1-200 says "An instance method mC declared in or inherited by class C, 'overrides from C' another method mI declared in an interface I, iff all of the following are true:" -- so you have to know that foo() is already inherited by class Test (say from Test1) in order to check if Test.foo() overrides Test2.foo(). As you say, we're still trying to figure if foo() is inherited from Test1. This all seems disturbingly tricky for such a simple scenario. Dan, any comments? The fact that inheritance depends on overriding is due to how default methods work: you don't inherit a default method if it has already been overridden. But note the "already" -- there's some induction going on here, building up the members of all supertypes before we attempt to decide the members of a subtype. The rules for subtypes depend only on what we already know about supertypes. ?Dan From daniel.smith at oracle.com Tue Jun 9 20:19:20 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Jun 2015 14:19:20 -0600 Subject: Diamond with anonymous classes: invoking non-private methods through reflection In-Reply-To: <5570BC94.2010209@oracle.com> References: <55705AF0.90101@oracle.com> <5570BC94.2010209@oracle.com> Message-ID: > On Jun 4, 2015, at 3:01 PM, Alex Buckley wrote: > > I think this is an acceptable limitation. Yes, I recall considering this case when we were discussing the feature, and agreeing it wasn't important. The workaround is trivial. ?Dan From alex.buckley at oracle.com Tue Jun 9 20:36:18 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 09 Jun 2015 13:36:18 -0700 Subject: Cyclic definition of overriding In-Reply-To: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> Message-ID: <55774E42.1060403@oracle.com> On 6/9/2015 1:15 PM, Dan Smith wrote: >> On Jun 9, 2015, at 9:00 AM, Konstantin wrote: >> >> I consider this simple case: >> >> interface Test1 { >> int foo(); // m1 >> } >> >> interface Test2{ >> int foo(); // m2 >> } >> class Test implements Test1, Test2{ >> } >> >> I try to understand if m1 is inherited by Test. I follow jls-8.4.8-200. >> All subassertions are true except jls-8.4.8-200-E. To decide if it is true or not we need to turn to overriding definition jls-8.4.8.1-200. > > Specifically: > > "There exists no method m' that is a member of the direct superclass or a direct superinterface, D', of C (m distinct from m', D distinct from D'), such that m' from D' overrides the declaration of the method m." > > We've bound our variables as follows: > C=Test > D=Test1 > m=m1 > m'=m2 > D'=Test2 > > The question we are asking: does m2 override m1 from Test2? > >> More detailed, I want to be sure that m2 isn't m'. That's why I need to know if m2 overrides m1. >> And new subassertion jls-8.4.8.1-200-D says about inheriting. >> "8.4.8.1 C does not inherit mI." >> So we get a circle. > > Note the question above: we want to know if m2 overrides m1 from Test2. Test2 is an interface, so 8.4.8.1 doesn't apply. Instead, we want 9.4.1.1. > > "An instance method m1, declared in or inherited by an interface I, overrides from I another instance method, m2, declared in interface J, iff both of the following are true:" Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely subtle. Once you do, it's plain that Test1.foo() does not override-from-Test1 the method foo() declared in Test2, and vice versa, thus class Test inherits both foo() methods (harmlessly). I will add cross-refs from 8.4.8 to both 8.4.8.1 and 9.4.1.1 to clarify. Alex From maurizio.cimadamore at oracle.com Tue Jun 9 20:41:59 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 09 Jun 2015 21:41:59 +0100 Subject: Cyclic definition of overriding In-Reply-To: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> Message-ID: <55774F97.2020009@oracle.com> On 09/06/15 21:15, Dan Smith wrote: > The fact that inheritance depends on overriding is due to how default methods work: you don't inherit a default method if it has already been overridden. But note the "already" -- there's some induction going on here, building up the members of all supertypes before we attempt to decide the members of a subtype. The rules for subtypes depend only on what we already know about supertypes. I thought that membership/inheritance has always depended on overriding - i.e. a method m is inherited from a class C only if m is not overridden in some subclass of C. I think some rules along those lines were there even before default methods? Maurizio From daniel.smith at oracle.com Tue Jun 9 20:57:47 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Jun 2015 14:57:47 -0600 Subject: Anonymous classes with diamond, subexpression excludes bounds of type variable In-Reply-To: <556DE9DC.7000500@oracle.com> References: <556DE9DC.7000500@oracle.com> Message-ID: > On Jun 2, 2015, at 11:37 AM, Georgiy Rakov wrote: > > Hello, > > new assertion for the new "anonymous classes with diamond" feature specified in JDK-8073593 comment states: > The term "subexpression" includes type arguments of parameterized types (4.5), bounds of wildcards (4.5.1), and element types of array types (10.1). It excludes bounds of type variables.*** > The part of assertion I'm interested in is emphasized above. Could you please tell if you consider this part of assertion as testable and if you do could you please provide the example of the code verifying this assertion. So, the test case we're after: inference produces a type variable as a type argument, and that type variable is valid, but it has a bound that is not valid. Something like: void test() { List list = new ArrayList<>(){}; } We know that the bounded variable, T, "was declared as a type parameter", because otherwise the variable itself would be invalid. That limits the set of possible bounds to those that can be declared. So, can the _____ be "A type variable (4.4) that was not declared as a type parameter (such as a type variable produced by capture conversion (5.1.10))"? Nope. Can the _____ be "An intersection type (4.9)"? Maybe -- depends how you interpret the bound. (Is "T extends Foo & Bar" a variable with two bounds, or a variable with a single intersection type bound?) Wouldn't hurt to test this case. (Expected behavior is no error.) Beyond testability, assertions like this are useful for future-proofing -- if somehow we started inferring the bounds of a type parameter declaration, we wouldn't want that to change the nature of this check. ?Dan From alex.buckley at oracle.com Tue Jun 9 21:12:18 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 09 Jun 2015 14:12:18 -0700 Subject: Cyclic definition of overriding In-Reply-To: <55774E42.1060403@oracle.com> References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774E42.1060403@oracle.com> Message-ID: <557756B2.1000007@oracle.com> On 6/9/2015 1:36 PM, Alex Buckley wrote: > Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely subtle. Once > you do, it's plain that Test1.foo() does not override-from-Test1 the > method foo() declared in Test2, and vice versa, thus class Test inherits > both foo() methods (harmlessly). I will add cross-refs from 8.4.8 to > both 8.4.8.1 and 9.4.1.1 to clarify. In particular, the 8.4.8 clause: "such that m' from D' overrides the declaration of the method m." should read: "such that m' overrides from D' (8.4.8.1, 9.4.1.1) the declaration of the method m." -- note the relocation of "from D'". (Plus class Test needs to be abstract of course.) Alex From daniel.smith at oracle.com Tue Jun 9 21:27:23 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Jun 2015 15:27:23 -0600 Subject: Cyclic definition of overriding In-Reply-To: <557756B2.1000007@oracle.com> References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774E42.1060403@oracle.com> <557756B2.1000007@oracle.com> Message-ID: > On Jun 9, 2015, at 3:12 PM, Alex Buckley wrote: > > On 6/9/2015 1:36 PM, Alex Buckley wrote: >> Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely subtle. Once >> you do, it's plain that Test1.foo() does not override-from-Test1 the >> method foo() declared in Test2, and vice versa, thus class Test inherits >> both foo() methods (harmlessly). I will add cross-refs from 8.4.8 to >> both 8.4.8.1 and 9.4.1.1 to clarify. > > In particular, the 8.4.8 clause: > > "such that m' from D' overrides the declaration of the method m." > > should read: > > "such that m' overrides from D' (8.4.8.1, 9.4.1.1) the declaration of the method m." -- note the relocation of "from D'". > > (Plus class Test needs to be abstract of course.) Yes, this is good. "From D' overrides" is awkward. The confusion isn't so much about Chapter 8 vs. Chapter 9 -- both immediately assert that Test1 is a subclass/subinterface of Test2. The problem is in recognizing that D' (Test1) is not the same as D (Test), which this change makes more clear. (Hope I'm not mixing up Test1 and Test2 here, but if so, you know what I mean.) ?Dan From daniel.smith at oracle.com Tue Jun 9 21:31:31 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Jun 2015 15:31:31 -0600 Subject: Anonymous classes with diamond, subexpression excludes bounds of type variable In-Reply-To: References: <556DE9DC.7000500@oracle.com> Message-ID: > On Jun 9, 2015, at 2:57 PM, Dan Smith wrote: > >> On Jun 2, 2015, at 11:37 AM, Georgiy Rakov wrote: >> >> Hello, >> >> new assertion for the new "anonymous classes with diamond" feature specified in JDK-8073593 comment states: >> The term "subexpression" includes type arguments of parameterized types (4.5), bounds of wildcards (4.5.1), and element types of array types (10.1). It excludes bounds of type variables.*** >> The part of assertion I'm interested in is emphasized above. Could you please tell if you consider this part of assertion as testable and if you do could you please provide the example of the code verifying this assertion. > > So, the test case we're after: inference produces a type variable as a type argument, and that type variable is valid, but it has a bound that is not valid. > > Something like: > > void test() { > List list = new ArrayList<>(){}; > } > > We know that the bounded variable, T, "was declared as a type parameter", because otherwise the variable itself would be invalid. That limits the set of possible bounds to those that can be declared. > > So, can the _____ be "A type variable (4.4) that was not declared as a type parameter (such as a type variable produced by capture conversion (5.1.10))"? Nope. > > Can the _____ be "An intersection type (4.9)"? Maybe -- depends how you interpret the bound. (Is "T extends Foo & Bar" a variable with two bounds, or a variable with a single intersection type bound?) Wouldn't hurt to test this case. (Expected behavior is no error.) I forgot this bullet, which was added later in the discussion: Can the _____ be "A class or interface type, where the class or interface declaration is not accessible from the class or interface in which the expression appears"? We know that the anonymous class must appear within the scope of the variable declaration, and that the class is accessible at the point of the variable declaration. So I think this case cannot occur: if a type is accessible at the point of a generic class or method declaration, it must also be accessible within the entire body of that class or variable declaration, including any contained anonymous class expressions. ?Dan From daniel.smith at oracle.com Tue Jun 9 21:36:03 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Jun 2015 15:36:03 -0600 Subject: Cyclic definition of overriding In-Reply-To: <55774F97.2020009@oracle.com> References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774F97.2020009@oracle.com> Message-ID: <1C4E790E-BBD6-490F-9EE5-058B97B6DABF@oracle.com> > On Jun 9, 2015, at 2:41 PM, Maurizio Cimadamore wrote: > > On 09/06/15 21:15, Dan Smith wrote: >> The fact that inheritance depends on overriding is due to how default methods work: you don't inherit a default method if it has already been overridden. But note the "already" -- there's some induction going on here, building up the members of all supertypes before we attempt to decide the members of a subtype. The rules for subtypes depend only on what we already know about supertypes. > I thought that membership/inheritance has always depended on overriding - i.e. a method m is inherited from a class C only if m is not overridden in some subclass of C. I think some rules along those lines were there even before default methods? Yes, you're right, the old spec (e.g., JLS 7) claimed that you inherit things that "are neither overridden nor hidden by a declaration in the class". This did not work very will with overriding by inherited members (e.g., an inherited class method that overrides a superinterface method), which was one of the motivations for revising this in JLS 8. ?Dan From alex.buckley at oracle.com Tue Jun 9 21:38:55 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 09 Jun 2015 14:38:55 -0700 Subject: Cyclic definition of overriding In-Reply-To: References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774E42.1060403@oracle.com> <557756B2.1000007@oracle.com> Message-ID: <55775CEF.8000402@oracle.com> On 6/9/2015 2:27 PM, Dan Smith wrote: >> On Jun 9, 2015, at 3:12 PM, Alex Buckley >> wrote: >> >> On 6/9/2015 1:36 PM, Alex Buckley wrote: >>> Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely subtle. >>> Once you do, it's plain that Test1.foo() does not >>> override-from-Test1 the method foo() declared in Test2, and vice >>> versa, thus class Test inherits both foo() methods (harmlessly). >>> I will add cross-refs from 8.4.8 to both 8.4.8.1 and 9.4.1.1 to >>> clarify. >> >> In particular, the 8.4.8 clause: >> >> "such that m' from D' overrides the declaration of the method m." >> >> should read: >> >> "such that m' overrides from D' (8.4.8.1, 9.4.1.1) the declaration >> of the method m." -- note the relocation of "from D'". >> >> (Plus class Test needs to be abstract of course.) > > Yes, this is good. "From D' overrides" is awkward. > > The confusion isn't so much about Chapter 8 vs. Chapter 9 -- both > immediately assert that Test1 is a subclass/subinterface of Test2. > The problem is in recognizing that D' (Test1) is not the same as D > (Test), which this change makes more clear. (Hope I'm not mixing up > Test1 and Test2 here, but if so, you know what I mean.) ... that D' (Test1) is not the same as D (Test2). (Yes, maybe D is Test1 and D' is Test2.) Konstantin, the scenario would be clearer if the superinterfaces were called I1 and I2 rather than aggressively sharing letters T-e-s-t with the name of the inheriting class. Alex From raffaelesgarro at gmail.com Tue Jun 9 21:43:31 2015 From: raffaelesgarro at gmail.com (Raffaele Sgarro) Date: Tue, 09 Jun 2015 21:43:31 +0000 Subject: Unsuscribe Message-ID: Please unsuscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Tue Jun 9 22:13:50 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 9 Jun 2015 16:13:50 -0600 Subject: Cyclic definition of overriding In-Reply-To: <55775CEF.8000402@oracle.com> References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774E42.1060403@oracle.com> <557756B2.1000007@oracle.com> <55775CEF.8000402@oracle.com> Message-ID: > On Jun 9, 2015, at 3:38 PM, Alex Buckley wrote: > > On 6/9/2015 2:27 PM, Dan Smith wrote: >>> On Jun 9, 2015, at 3:12 PM, Alex Buckley >>> wrote: >>> >>> On 6/9/2015 1:36 PM, Alex Buckley wrote: >>>> Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely subtle. >>>> Once you do, it's plain that Test1.foo() does not >>>> override-from-Test1 the method foo() declared in Test2, and vice >>>> versa, thus class Test inherits both foo() methods (harmlessly). >>>> I will add cross-refs from 8.4.8 to both 8.4.8.1 and 9.4.1.1 to >>>> clarify. >>> >>> In particular, the 8.4.8 clause: >>> >>> "such that m' from D' overrides the declaration of the method m." >>> >>> should read: >>> >>> "such that m' overrides from D' (8.4.8.1, 9.4.1.1) the declaration >>> of the method m." -- note the relocation of "from D'". >>> >>> (Plus class Test needs to be abstract of course.) >> >> Yes, this is good. "From D' overrides" is awkward. >> >> The confusion isn't so much about Chapter 8 vs. Chapter 9 -- both >> immediately assert that Test1 is a subclass/subinterface of Test2. >> The problem is in recognizing that D' (Test1) is not the same as D >> (Test), which this change makes more clear. (Hope I'm not mixing up >> Test1 and Test2 here, but if so, you know what I mean.) > > ... that D' (Test1) is not the same as D (Test2). (Yes, maybe D is Test1 and D' is Test2.) Ugh, sorry. No, I really mean "Test". "Is not the same as C (Test)". That is, the example ceases to be interesting/confusing once you realize that the dependency on overriding is from the perspective of the superinterface, not the class whose members are still being determined. ?Dan From erik.joelsson at oracle.com Wed Jun 10 07:18:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Jun 2015 09:18:03 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <5577E4AB.4090305@oracle.com> Looks good. /Erik On 2015-06-09 15:52, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out > by reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ > > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot >>> and jdk ignores the patch field as of now. This will be corrected in >>> a later add-on patch, submitted by someone from the jdk and/or >>> hotspot team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really >>> impressed by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some >>> framework changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right >>> off the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite >>> safe to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank >>> linkes is not a bad thing. (jcheck unfortunately does not enforce >>> any style checks for make files :-( so they tend to detoriate over >>> time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 >>>> and we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented >>> by java.util.Version, but in any case it will need a follow-up patch >>> to clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From david.holmes at oracle.com Wed Jun 10 09:58:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Jun 2015 19:58:11 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <55780A33.1010302@oracle.com> Hi Magnus, Generally looks good - a few comments/queries below. On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out by > reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ common/autoconf/version-numbers Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of the version info? (Even if all zeroes presently.) --- Looking at hotspot changes I can't convince myself that the new streamlined "version" variables will capture things like "fastdebug". Will that filter through via configure variables? --- make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) --- hotspot/src/share/vm/prims/jvm.h jdk/src/java.base/share/native/include/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. --- hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. --- hotspot/src/share/vm/runtime/vmStructs.cpp Please fix the alignment (3 extra spaces on modified line): 1239 static_field(Abstract_VM_Version, _vm_minor_version, int) \ 1240 static_field(Abstract_VM_Version, _vm_security_version, int) \ --- hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. --- jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. Thanks, David > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot and >>> jdk ignores the patch field as of now. This will be corrected in a >>> later add-on patch, submitted by someone from the jdk and/or hotspot >>> team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really impressed >>> by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some framework >>> changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right off >>> the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite safe >>> to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank linkes >>> is not a bad thing. (jcheck unfortunately does not enforce any style >>> checks for make files :-( so they tend to detoriate over time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 and >>>> we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented by >>> java.util.Version, but in any case it will need a follow-up patch to >>> clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From magnus.ihse.bursie at oracle.com Wed Jun 10 12:13:16 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 14:13:16 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55780A33.1010302@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> Message-ID: <557829DC.8000405@oracle.com> On 2015-06-10 11:58, David Holmes wrote: > Hi Magnus, > > Generally looks good - a few comments/queries below. In general, I believe most issues you found are valid. :-) However, as I said before in this thread, I'd like to see them resolved in the needed follow-up patches. The source code changes in Hotspot and JDK are inadequate to fully implement JEP-223, so these areas will need to be rewritten anyhow. Are you okay with resolving these issues later? > > On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >> Here's an updated webrev, which fixes the typos that were pointed out by >> reviewers: >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >> > > common/autoconf/version-numbers > > Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of > the version info? (Even if all zeroes presently.) So that's a tricky one. :-& The question here is, I think, does it make sense to update version-numbers when we do a security (9.0.1) or minor (9.1.0) release? Looking historically, the version-numbers file have not been changed for the 8u family. The only change was going from 8 to 9 when creating the new jdk9 forest. That was what I based my decition to only have the major number in the file. (The rest of the version string is set by configure flags when building, in Oracle case by the RE team.) If it makes sense to put the minor/security/patch numbers here, I won't oppose it, but I guess we have until the first such release to figure out what's best, and that likely includes discussion with RE and possibly other consumers in the community (RedHat etc). > > --- > > Looking at hotspot changes I can't convince myself that the new > streamlined "version" variables will capture things like "fastdebug". > Will that filter through via configure variables? The "fastdebug" label has been handled as a less valued token in the JEP-223 process. Right now there's no mention of it at all in the version string proposal in the JEP. As I understand it, Iris is about to propose an amendment which will just make fastdebug be a part of the OPT string. I'm not entirely happy with that myself, but that's the way it's decided. So wherever you can see the OPT string, you'll see the debug level tag. Currently, however, that's not how it is implemented in this patch. Since no decision was made on this (and it's still not formally decided), I had to pick a route to go forward. The current patch will instead put the "fastdebug" label as part of the PRE string (that's the reason for the pre-base and pre-debuglevel arguments to configure). If the planned changes goes into the JEP, this'll change to make the debuglevel tag a part of the OPT string instead. > --- > > make/*/makefiles/vm.make > > Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the > VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a > stand-alone hotspot build?) The hotspot JEP-223 work initially made by Alejandro kept support for stand-alone hotspot builds. I made additional changes on top of that, which still tried to cater for stand-alone builds. At this very moment I'm not sure if stand-alone hotspot builds are supposed to work or not, but I've tried to not change the situation with this patch. There are two future changes coming down the pipe: One is the additional JEP-223 work needed for Hotspot. I know Alejandro had plans for redesigning the API between Hotspot and the JDK, so no JDK version strings should be compiled into the JVM, but all of it extracted during an API in runtime. That would make most (all?) of the makefile changes in hotspot irrelevant. However, that implementation is not even started, so it's needed for the time being. The second change is the build-infra hotspot makefile rewrite. When that happens, stand-alone builds will definitely disappear, and if Hotspot still needs make support for version strings, then the logical choice is to use VERSION_CFLAGS. Ok? > > --- > > hotspot/src/share/vm/prims/jvm.h > jdk/src/java.base/share/native/include/jvm.h > > I think this comment is way out of date: > > /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER > is set to bNN) > * It will be zero for internal builds. > */ > > and can be completely removed. Even if still true, mention of an "RE > build" has no place in OpenJDK sources. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/java.cpp > > I think a lot of the modified code is obsolete post Hotspot Express - > which makes it hard to determine if the changes make sense. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/vmStructs.cpp > > Please fix the alignment (3 extra spaces on modified line): > > 1239 static_field(Abstract_VM_Version, _vm_minor_version, > int) \ > 1240 static_field(Abstract_VM_Version, > _vm_security_version, int) \ I was about to say "follow-up patch", but ugly indentation really sucks so I can fix this. Ok if I skip redoing the review for that? > > --- > > hotspot/test/runtime/6981737/Test6981737.java > > This test is really only valid for the new version scheme now, so it > should probably be rewritten - and in that case it really isn't > testing 6981737 but should be replaced by a new test for the new > version format. Yep, agree. Follow-up patch, right? > > --- > > jdk/src/java.base/share/classes/sun/misc/Version.java.template > > This comment is nonsensical: > > /** > ! * Returns the security version of the running JVM if it's 1.6 > or newer > * or any RE VM build. It will return 0 if it's an internal 1.5 or > * 1.4.x build. > * @since 1.6 > */ > > as security version does not exist pre 9. Normally you should be > adding a new method and deprecating the old one. The new one is @since 9. Yep, agree. Follow-up patch, right? > > /** > ! * Returns the security version of the running JDK. > * @since 1.6 > */ > > Ditto: @since 9 (but again old should be deprecated and new method added) > > 253 /** > 254 * Returns the build number of the running JDK if it's a RE > build > 255 * It will return 0 if it's an internal build. > > As with jvm.h this seems obsolete commentary these days - not only RE > builds define a build number. Yep, agree. Follow-up patch, right? /Magnus > > Thanks, > David From magnus.ihse.bursie at oracle.com Wed Jun 10 13:44:41 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 15:44:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55783F49.6030906@oracle.com> On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. I realize I missed that part of the review. :-( I have now updated the copyright years. Here's a delta review: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ Here's the complete review once again: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 Hopefully this is now the final version to be pushed to verona, and that any additional problems can be resolved with follow-up patches. /Magnus From konstantin.barzilovich at oracle.com Wed Jun 10 16:23:34 2015 From: konstantin.barzilovich at oracle.com (Konstantin) Date: Wed, 10 Jun 2015 19:23:34 +0300 Subject: Cyclic definition of overriding In-Reply-To: References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774E42.1060403@oracle.com> <557756B2.1000007@oracle.com> <55775CEF.8000402@oracle.com> Message-ID: Thanks for the answers. First of all, sorry for meaningless names. We can use I1, I2 and SubClass. As I understand, you said that we should use chapter 9, not 8. Could you clarify, why can't I consider I1 with SubClass, which inherit method m2 from I2? Is it important, from what type is overriding? May be jls-8.4.8-200-E should be: There exists no method m' that is a member of the direct superclass or a direct superinterface, D', of C (m distinct from m', D distinct from D'), such that m' from D' overrides the declaration of the method m. If there will be no mention of superinterfaces in this assertion, the problem would be solved. Thanks, Konstantin. >> On Jun 9, 2015, at 3:38 PM, Alex Buckley wrote: >> >> On 6/9/2015 2:27 PM, Dan Smith wrote: >>>> On Jun 9, 2015, at 3:12 PM, Alex Buckley >>>> wrote: >>>> >>>> On 6/9/2015 1:36 PM, Alex Buckley wrote: >>>>> Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely subtle. >>>>> Once you do, it's plain that Test1.foo() does not >>>>> override-from-Test1 the method foo() declared in Test2, and vice >>>>> versa, thus class Test inherits both foo() methods (harmlessly). >>>>> I will add cross-refs from 8.4.8 to both 8.4.8.1 and 9.4.1.1 to >>>>> clarify. >>>> >>>> In particular, the 8.4.8 clause: >>>> >>>> "such that m' from D' overrides the declaration of the method m." >>>> >>>> should read: >>>> >>>> "such that m' overrides from D' (8.4.8.1, 9.4.1.1) the declaration >>>> of the method m." -- note the relocation of "from D'". >>>> >>>> (Plus class Test needs to be abstract of course.) >>> >>> Yes, this is good. "From D' overrides" is awkward. >>> >>> The confusion isn't so much about Chapter 8 vs. Chapter 9 -- both >>> immediately assert that Test1 is a subclass/subinterface of Test2. >>> The problem is in recognizing that D' (Test1) is not the same as D >>> (Test), which this change makes more clear. (Hope I'm not mixing up >>> Test1 and Test2 here, but if so, you know what I mean.) >> >> ... that D' (Test1) is not the same as D (Test2). (Yes, maybe D isTest1 >> and D' is Test2.) > > Ugh, sorry. No, I really mean "Test". "Is not the same as C (Test)".That > is, the example ceases to be interesting/confusing once you realizethat > the dependency on overriding is from the perspective of the > superinterface, not the class whose members are still being determined. > > ?Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Jun 10 18:14:37 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 10 Jun 2015 11:14:37 -0700 Subject: Cyclic definition of overriding In-Reply-To: References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774E42.1060403@oracle.com> <557756B2.1000007@oracle.com> <55775CEF.8000402@oracle.com> Message-ID: <55787E8D.3050106@oracle.com> On 6/9/2015 3:13 PM, Dan Smith wrote: >> On Jun 9, 2015, at 3:38 PM, Alex Buckley >> wrote: >> >> On 6/9/2015 2:27 PM, Dan Smith wrote: >>>> On Jun 9, 2015, at 3:12 PM, Alex Buckley >>>> wrote: >>>> >>>> On 6/9/2015 1:36 PM, Alex Buckley wrote: >>>>> Knowing to apply 9.4.1.1 rather than 8.4.8.1 is extremely >>>>> subtle. Once you do, it's plain that Test1.foo() does not >>>>> override-from-Test1 the method foo() declared in Test2, and >>>>> vice versa, thus class Test inherits both foo() methods >>>>> (harmlessly). I will add cross-refs from 8.4.8 to both >>>>> 8.4.8.1 and 9.4.1.1 to clarify. >>>> >>>> In particular, the 8.4.8 clause: >>>> >>>> "such that m' from D' overrides the declaration of the method >>>> m." >>>> >>>> should read: >>>> >>>> "such that m' overrides from D' (8.4.8.1, 9.4.1.1) the >>>> declaration of the method m." -- note the relocation of "from >>>> D'". >>>> >>>> (Plus class Test needs to be abstract of course.) >>> >>> Yes, this is good. "From D' overrides" is awkward. >>> >>> The confusion isn't so much about Chapter 8 vs. Chapter 9 -- >>> both immediately assert that Test1 is a subclass/subinterface of >>> Test2. The problem is in recognizing that D' (Test1) is not the >>> same as D (Test), which this change makes more clear. (Hope I'm >>> not mixing up Test1 and Test2 here, but if so, you know what I >>> mean.) >> >> ... that D' (Test1) is not the same as D (Test2). (Yes, maybe D is >> Test1 and D' is Test2.) > > Ugh, sorry. No, I really mean "Test". "Is not the same as C > (Test)". That is, the example ceases to be interesting/confusing > once you realize that the dependency on overriding is from the > perspective of the superinterface, not the class whose members are > still being determined. I think it would help to not see one example as more interesting/confusing than any other. An example is what it is. In Konstantin's example, the question of whether class Test inherits foo() from Test1 depends on whether foo() in Test2 overrides-from-Test2 the foo() in Test1. It's obvious that Test1 and Test2 are the sole determinants of the answer; class Test is irrelevant. This aligns with your comment that the overriding (lack of, in this case) is figured from the perspective of superinterface Test1, not class Test. I don't see how it's a problem to recognize that C, D, and D' in the fifth clause are all different entities. Alex From alex.buckley at oracle.com Wed Jun 10 18:36:36 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 10 Jun 2015 11:36:36 -0700 Subject: Cyclic definition of overriding In-Reply-To: References: <38339D06-64D0-48B9-A017-D245E790F554@oracle.com> <55774E42.1060403@oracle.com> <557756B2.1000007@oracle.com> <55775CEF.8000402@oracle.com> Message-ID: <557883B4.1000001@oracle.com> On 6/10/2015 9:23 AM, Konstantin wrote: > First of all, sorry for meaningless names. We can use I1, I2 and SubClass. SubClass is not a good name because we'll end up saying "class SubClass, a subclass of class ..." which is obtuse. Also, the class in this example is NOT a subclass of interface I1 or I2. A class can only be a subclass of another class, not an interface. > As I understand, you said that we should use chapter 9, not 8. > Could you clarify, why can't I consider I1 with SubClass, which inherit > method m2 from I2? > Is it important, from what type is overriding? Yes: interface I1 { void foo(); } interface I2 extends I1 { void foo(); } class C implements I1, I2 {} C does not inherit foo() from I1 because there does exist a method foo() in another superinterface (I2) which overrides-from-I2 the foo() in I1. C does inherit foo() from I2 because there is no method foo() in another superinterface (I1) which overrides-from-I1 the foo() in I2. Someone might say "Who cares which foo() is inherited by C? Both foo() methods are the same." Prior to Java SE 8, that was a fair question. In Java SE 8, it's a poor question because the foo() methods can be default, and therefore have different behavior, and therefore it matters which one is inherited. For example: interface I1 { default void foo() { System.out.println("I1"); } } interface I2 extends I1 { default void foo() { System.out.println("I2"); } } class C implements I1, I2 {} You would really like this to compile (it does), and you would really like new C().foo() to print I2 (it does) rather than I1. > May be jls-8.4.8-200-E should be: > > There exists no method m' that is a member of the direct superclassor a > direct superinterface, D', of C (m distinct from m', D distinct from > D'), such that m' from D' overrides the declaration of the method m. Ummm, that's what 200-E says today. > If there will be no mention of superinterfaces in this assertion, the > problem would be solved. I think you can see that methods in a family of superinterfaces do contribute to the methods inherited by a class, so it is important to mention superinterfaces here. Let's not go further down the road of rewriting assertions. Alex From alejandro.murillo at oracle.com Wed Jun 10 17:21:59 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 10 Jun 2015 11:21:59 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55787237.20802@oracle.com> On 6/10/2015 6:13 AM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as > I said before in this thread, I'd like to see them resolved in the > needed follow-up patches. The source code changes in Hotspot and JDK > are inadequate to fully implement JEP-223, so these areas will need to > be rewritten anyhow. Are you okay with resolving these issues later? > >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed >>> out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it > make sense to update version-numbers when we do a security (9.0.1) or > minor (9.1.0) release? Looking historically, the version-numbers file > have not been changed for the 8u family. The only change was going > from 8 to 9 when creating the new jdk9 forest. That was what I based > my decition to only have the major number in the file. (The rest of > the version string is set by configure flags when building, in Oracle > case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I > won't oppose it, but I guess we have until the first such release to > figure out what's best, and that likely includes discussion with RE > and possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about > to propose an amendment which will just make fastdebug be a part of > the OPT string. I'm not entirely happy with that myself, but that's > the way it's decided. So wherever you can see the OPT string, you'll > see the debug level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's > the reason for the pre-base and pre-debuglevel arguments to > configure). If the planned changes goes into the JEP, this'll change > to make the debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from >> the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or > not, but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the > additional JEP-223 work needed for Hotspot. I know Alejandro had plans > for redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted > during an API in runtime. That would make most (all?) of the makefile > changes in hotspot irrelevant. However, that implementation is not > even started, so it's needed for the time being. There's already an API used by Hotspot to get JDK version values. I'm investigating using that and extend it if required. yes, there is a lot stuff in the hotspot code that should be removed (mostly in the makefiles) and I'm not against making those changes now, I just think they are somewhat out of the scope of this project. And should be done as individual RFEs or as part of the upcoming hotspot makefile refactoring. Alejandro > > The second change is the build-infra hotspot makefile rewrite. When > that happens, stand-alone builds will definitely disappear, and if > Hotspot still needs make support for version strings, then the logical > choice is to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. >> JDK_BUILD_NUMBER is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, _vm_security_version, >> int) \ > > I was about to say "follow-up patch", but ugly indentation really > sucks so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is >> @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method >> added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > -- Alejandro From maurizio.cimadamore at oracle.com Wed Jun 10 23:33:13 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Jun 2015 00:33:13 +0100 Subject: [8u60] request for review: 8068489: remove unnecessary complexity in Flow and Bits, after JDK-8064857 In-Reply-To: <55721C95.4000004@oracle.com> References: <55721C95.4000004@oracle.com> Message-ID: <5578C939.7050305@oracle.com> It generally looks good - I found however some differences with the code in 9: * we seem to have replaced 'new ListBuffer

' with 'new ListBuffer' - the 9 version simply uses diamond; I think we could so the same (also to minimize diffs) * indentation seems to be off (likely as a result of the merge) esp. in AssignAnalyzer.{letInit,visitClassDef,visitMethodDef} Maurizio On 05/06/15 23:03, Vicente-Arturo Romero-Zaldivar wrote: > Hi, > > Please review the backport of bug: > > 8068489: remove unnecessary complexity in Flow and Bits, after > JDK-8064857 > > JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8068489 > backport: https://bugs.openjdk.java.net/browse/JDK-8068547 > original patch pushed to 9: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5e500700b168 > public review: http://cr.openjdk.java.net/~vromero/8068489/webrev/ > > The original patch doesn't apply cleanly. There are no major > differences but I think that there are enough to deserve a review. > > Thanks, > Vicente From vicente.romero at oracle.com Thu Jun 11 01:39:39 2015 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 10 Jun 2015 18:39:39 -0700 Subject: [8u60] request for review: 8068489: remove unnecessary complexity in Flow and Bits, after JDK-8064857 In-Reply-To: <5578C939.7050305@oracle.com> References: <55721C95.4000004@oracle.com> <5578C939.7050305@oracle.com> Message-ID: <5578E6DB.4060202@oracle.com> Hi Maurizio, On 06/10/2015 04:33 PM, Maurizio Cimadamore wrote: > It generally looks good - I found however some differences with the > code in 9: > > * we seem to have replaced 'new ListBuffer

' with 'new > ListBuffer' - the 9 version simply uses diamond; I think > we could so the same (also to minimize diffs) > * indentation seems to be off (likely as a result of the merge) esp. > in AssignAnalyzer.{letInit,visitClassDef,visitMethodDef} yep, good catch! I have fixed those issues. I have published a new review at: http://cr.openjdk.java.net/~vromero/8068489/webrev.01/ Thanks, Vicente > > Maurizio > > On 05/06/15 23:03, Vicente-Arturo Romero-Zaldivar wrote: >> Hi, >> >> Please review the backport of bug: >> >> 8068489: remove unnecessary complexity in Flow and Bits, after >> JDK-8064857 >> >> JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8068489 >> backport: https://bugs.openjdk.java.net/browse/JDK-8068547 >> original patch pushed to 9: >> http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5e500700b168 >> public review: http://cr.openjdk.java.net/~vromero/8068489/webrev/ >> >> The original patch doesn't apply cleanly. There are no major >> differences but I think that there are enough to deserve a review. >> >> Thanks, >> Vicente > From david.holmes at oracle.com Thu Jun 11 04:52:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 14:52:53 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55791425.8070709@oracle.com> Hi Magnus, On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as I > said before in this thread, I'd like to see them resolved in the needed > follow-up patches. The source code changes in Hotspot and JDK are > inadequate to fully implement JEP-223, so these areas will need to be > rewritten anyhow. Are you okay with resolving these issues later? Given this is going to a staging repo I'm okay with deferring things - I just have a concern whether such things may be overlooked given that the integration with the staging repo will not be undergoing a final review. I would prefer to see the Version.java.template doc comments corrected, even if the issue of whether to add and deprecate is deferred, but again as this is to a staging area I can let it slide for now. I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. Thanks, David >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it make > sense to update version-numbers when we do a security (9.0.1) or minor > (9.1.0) release? Looking historically, the version-numbers file have not > been changed for the 8u family. The only change was going from 8 to 9 > when creating the new jdk9 forest. That was what I based my decition to > only have the major number in the file. (The rest of the version string > is set by configure flags when building, in Oracle case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I won't > oppose it, but I guess we have until the first such release to figure > out what's best, and that likely includes discussion with RE and > possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about to > propose an amendment which will just make fastdebug be a part of the OPT > string. I'm not entirely happy with that myself, but that's the way it's > decided. So wherever you can see the OPT string, you'll see the debug > level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's the > reason for the pre-base and pre-debuglevel arguments to configure). If > the planned changes goes into the JEP, this'll change to make the > debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or not, > but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the additional > JEP-223 work needed for Hotspot. I know Alejandro had plans for > redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted during > an API in runtime. That would make most (all?) of the makefile changes > in hotspot irrelevant. However, that implementation is not even started, > so it's needed for the time being. > > The second change is the build-infra hotspot makefile rewrite. When that > happens, stand-alone builds will definitely disappear, and if Hotspot > still needs make support for version strings, then the logical choice is > to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >> is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, >> _vm_security_version, int) \ > > I was about to say "follow-up patch", but ugly indentation really sucks > so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > From erik.joelsson at oracle.com Thu Jun 11 06:58:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 08:58:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55783F49.6030906@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55783F49.6030906@oracle.com> Message-ID: <557931A1.6030406@oracle.com> Looks good. /Erik On 2015-06-10 15:44, Magnus Ihse Bursie wrote: > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. > > I realize I missed that part of the review. :-( > > I have now updated the copyright years. Here's a delta review: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ > > > Here's the complete review once again: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 > > > Hopefully this is now the final version to be pushed to verona, and > that any additional problems can be resolved with follow-up patches. > > /Magnus From magnus.ihse.bursie at oracle.com Thu Jun 11 12:14:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Jun 2015 14:14:59 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55791425.8070709@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> <55791425.8070709@oracle.com> Message-ID: <55797BC3.9080202@oracle.com> On 2015-06-11 06:52, David Holmes wrote: > Hi Magnus, > > On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: >> On 2015-06-10 11:58, David Holmes wrote: >>> Hi Magnus, >>> >>> Generally looks good - a few comments/queries below. >> >> In general, I believe most issues you found are valid. :-) However, as I >> said before in this thread, I'd like to see them resolved in the needed >> follow-up patches. The source code changes in Hotspot and JDK are >> inadequate to fully implement JEP-223, so these areas will need to be >> rewritten anyhow. Are you okay with resolving these issues later? > > Given this is going to a staging repo I'm okay with deferring things - > I just have a concern whether such things may be overlooked given that > the integration with the staging repo will not be undergoing a final > review. I agree completely with your concern. I have summarized the issues that were raised but not addressed during this review, and created JBS bugs, one per component. I will do my best to make sure that fixing them does not get lost from the Verona project agenda. The three bugs are: https://bugs.openjdk.java.net/browse/JDK-8087202 https://bugs.openjdk.java.net/browse/JDK-8087203 https://bugs.openjdk.java.net/browse/JDK-8087205 Here's the core content of them. If I have missed something, please add it to the bug reports: HOTSPOT: Alan Bateman: Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info structure? The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Daniel D. Daugherty: General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? David Holmes: make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) hotspot/src/share/vm/prims/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. JDK: Alan Bateman: Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Daniel D. Daugherty: jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. David Holmes: jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. LANGTOOLS: Daniel D. Daugherty: langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... Jan Lahoda: +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) /Magnus > > I would prefer to see the Version.java.template doc comments > corrected, even if the issue of whether to add and deprecate is > deferred, but again as this is to a staging area I can let it slide > for now. > > I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. > > Thanks, > David > >>> >>> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>>> Here's an updated webrev, which fixes the typos that were pointed >>>> out by >>>> reviewers: >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>>> >>>> >>> >>> common/autoconf/version-numbers >>> >>> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >>> the version info? (Even if all zeroes presently.) >> So that's a tricky one. :-& The question here is, I think, does it make >> sense to update version-numbers when we do a security (9.0.1) or minor >> (9.1.0) release? Looking historically, the version-numbers file have not >> been changed for the 8u family. The only change was going from 8 to 9 >> when creating the new jdk9 forest. That was what I based my decition to >> only have the major number in the file. (The rest of the version string >> is set by configure flags when building, in Oracle case by the RE team.) >> >> If it makes sense to put the minor/security/patch numbers here, I won't >> oppose it, but I guess we have until the first such release to figure >> out what's best, and that likely includes discussion with RE and >> possibly other consumers in the community (RedHat etc). >> >>> >>> --- >>> >>> Looking at hotspot changes I can't convince myself that the new >>> streamlined "version" variables will capture things like "fastdebug". >>> Will that filter through via configure variables? >> >> The "fastdebug" label has been handled as a less valued token in the >> JEP-223 process. Right now there's no mention of it at all in the >> version string proposal in the JEP. As I understand it, Iris is about to >> propose an amendment which will just make fastdebug be a part of the OPT >> string. I'm not entirely happy with that myself, but that's the way it's >> decided. So wherever you can see the OPT string, you'll see the debug >> level tag. >> >> Currently, however, that's not how it is implemented in this patch. >> Since no decision was made on this (and it's still not formally >> decided), I had to pick a route to go forward. The current patch will >> instead put the "fastdebug" label as part of the PRE string (that's the >> reason for the pre-base and pre-debuglevel arguments to configure). If >> the planned changes goes into the JEP, this'll change to make the >> debuglevel tag a part of the OPT string instead. >> >>> --- >>> >>> make/*/makefiles/vm.make >>> >>> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >>> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >>> stand-alone hotspot build?) >> The hotspot JEP-223 work initially made by Alejandro kept support for >> stand-alone hotspot builds. I made additional changes on top of that, >> which still tried to cater for stand-alone builds. At this very moment >> I'm not sure if stand-alone hotspot builds are supposed to work or not, >> but I've tried to not change the situation with this patch. >> >> There are two future changes coming down the pipe: One is the additional >> JEP-223 work needed for Hotspot. I know Alejandro had plans for >> redesigning the API between Hotspot and the JDK, so no JDK version >> strings should be compiled into the JVM, but all of it extracted during >> an API in runtime. That would make most (all?) of the makefile changes >> in hotspot irrelevant. However, that implementation is not even started, >> so it's needed for the time being. >> >> The second change is the build-infra hotspot makefile rewrite. When that >> happens, stand-alone builds will definitely disappear, and if Hotspot >> still needs make support for version strings, then the logical choice is >> to use VERSION_CFLAGS. >> >> Ok? >> >>> >>> --- >>> >>> hotspot/src/share/vm/prims/jvm.h >>> jdk/src/java.base/share/native/include/jvm.h >>> >>> I think this comment is way out of date: >>> >>> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >>> is set to bNN) >>> * It will be zero for internal builds. >>> */ >>> >>> and can be completely removed. Even if still true, mention of an "RE >>> build" has no place in OpenJDK sources. >> Yep, agree. Follow-up patch, right? >> >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> >>> I think a lot of the modified code is obsolete post Hotspot Express - >>> which makes it hard to determine if the changes make sense. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> >>> Please fix the alignment (3 extra spaces on modified line): >>> >>> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >>> int) \ >>> 1240 static_field(Abstract_VM_Version, >>> _vm_security_version, int) \ >> >> I was about to say "follow-up patch", but ugly indentation really sucks >> so I can fix this. Ok if I skip redoing the review for that? >> >>> >>> --- >>> >>> hotspot/test/runtime/6981737/Test6981737.java >>> >>> This test is really only valid for the new version scheme now, so it >>> should probably be rewritten - and in that case it really isn't >>> testing 6981737 but should be replaced by a new test for the new >>> version format. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> >>> This comment is nonsensical: >>> >>> /** >>> ! * Returns the security version of the running JVM if it's 1.6 >>> or newer >>> * or any RE VM build. It will return 0 if it's an internal >>> 1.5 or >>> * 1.4.x build. >>> * @since 1.6 >>> */ >>> >>> as security version does not exist pre 9. Normally you should be >>> adding a new method and deprecating the old one. The new one is >>> @since 9. >> Yep, agree. Follow-up patch, right? >>> >>> /** >>> ! * Returns the security version of the running JDK. >>> * @since 1.6 >>> */ >>> >>> Ditto: @since 9 (but again old should be deprecated and new method >>> added) >>> >>> 253 /** >>> 254 * Returns the build number of the running JDK if it's a RE >>> build >>> 255 * It will return 0 if it's an internal build. >>> >>> As with jvm.h this seems obsolete commentary these days - not only RE >>> builds define a build number. >> Yep, agree. Follow-up patch, right? >> >> /Magnus >> >>> >>> Thanks, >>> David >> From georgiy.rakov at oracle.com Thu Jun 11 14:32:09 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 11 Jun 2015 17:32:09 +0300 Subject: Diamond with anonymous classes: what if anonymous class were generic Message-ID: <55799BE9.3050808@oracle.com> Hello, currently when diamond is used in anonymous class instance creation expression the class being instantiated is not generic. I believe this is the reason why there are exceptions specified in the assertion below: ***It is a compile-time error if the superclass or superinterface type of the anonymous class, T, or any subexpression of T, has one of the following forms: - A type variable (4.4) that was not declared as a type parameter (such as a type variable produced by capture conversion (5.1.10)) - An intersection type (4.9) - A class or interface type, where the class or interface declaration is not accessible from the class or interface in which the expression appears.*** The term "subexpression" includes type arguments of parameterized types (4.5), bounds of wildcards (4.5.1), and element types of array types (10.1). It excludes bounds of type variables.*** What if the anonymous class declaration derived the type parameters from the type specified in the instance creation expression (from super type). In this case the anonymous class would be a generic class and the type of the instance created will be a regular parameterization of that generic class. In this case I believe the situation will be identical to ordinary non-anonymous classes and there would be no needs to specify inferred types in the class signature. For instance: class Foo { } Foo inst = new Foo<>(){}; Here anonymous class would have type parameter T derived from its super type T. The type of instance creation expression will be the parameterization of this generic anonymous class with T inferred as String. I wonder if you considered such option. Thank you, Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgiy.rakov at oracle.com Thu Jun 11 15:53:29 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 11 Jun 2015 18:53:29 +0300 Subject: Anonymous class with parameterized super type, constructor formal parameters Message-ID: <5579AEF9.8000700@oracle.com> Hello, assertion jls-15.9.5.1-100-A.1 specifies: The actual arguments to the class instance creation expression are used to determine a constructor |cs| of S, using the same rules as for method invocations (?15.12 ). /_*The type of each formal parameter of the anonymous constructor must be identical to the corresponding formal parameter of *_//_*|cs|*_/. I'd like to point to the emphasized part of the assertion above which states that the formal parameters of the anonymous class constructor are identical to those of the corresponding super class constructor. However let's consider following example: import java.lang.reflect.Constructor; import java.util.Arrays; import java.util.stream.Stream; class Test7A { Test7A(T t) {} } public class Test7 { public static void main(String[] args) throws NoSuchMethodException { Test7A a = new Test7A<>("a"){}; System.out.println("Diamond case:"); printlnParameters("anonymous class constructor", a.getClass().getDeclaredConstructor(String.class)); printlnParameters("super class constructor", a.getClass().getSuperclass().getDeclaredConstructor(Object.class)); System.out.println(); a = new Test7A("a"){}; System.out.println("Explicit type arguments case:"); printlnParameters("anonymous class constructor", a.getClass().getDeclaredConstructor(String.class)); printlnParameters("super class constructor", a.getClass().getSuperclass().getDeclaredConstructor(Object.class)); } static void printlnParameters(String label, Constructor c) { Stream stream = Arrays.stream(c.getParameters()).map(p -> p.getType().toString()); System.out.println(" " + label + ": " + Arrays.toString(stream.toArray())); } } The output of this program is: Diamond case: anonymous class constructor: [class java.lang.String] super class constructor: [class java.lang.Object] Explicit type arguments case: anonymous class constructor: [class java.lang.String] super class constructor: [class java.lang.Object] As you can see the formal parameters for the anonymous class constructor and those of the corresponding base class constructor are different. Could you please tell if you consider this as a discrepancy between javac and specification which should be fixed. BTW: this alludes to my previous letter, that is, provided the anonymous classes in these cases were generic and its instances were just parameterization of those the formal parameters naturally would be identical, I believe. Thank you, Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- import java.lang.reflect.Constructor; import java.util.Arrays; import java.util.stream.Stream; class Test7A { Test7A(T t) {} } public class Test7 { public static void main(String[] args) throws NoSuchMethodException { Test7A a = new Test7A<>("a"){}; System.out.println("Diamond case:"); printlnParameters("anonymous class constructor", a.getClass().getDeclaredConstructor(String.class)); printlnParameters("super class constructor", a.getClass().getSuperclass().getDeclaredConstructor(Object.class)); System.out.println(); a = new Test7A("a"){}; System.out.println("Explicit type arguments case:"); printlnParameters("anonymous class constructor", a.getClass().getDeclaredConstructor(String.class)); printlnParameters("super class constructor", a.getClass().getSuperclass().getDeclaredConstructor(Object.class)); } static void printlnParameters(String label, Constructor c) { Stream stream = Arrays.stream(c.getParameters()).map(p -> p.getType().toString()); System.out.println(" " + label + ": " + Arrays.toString(stream.toArray())); } } From zhong.j.yu at gmail.com Thu Jun 11 23:40:55 2015 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 11 Jun 2015 18:40:55 -0500 Subject: Wildcard capture with self-referencing bound Message-ID: Elias Vasylenko posted this question on http://stackoverflow.com/questions/30788366 Given declarations class C1> {} class C2 extends C1> {} Are the following parameterization well-formed? C1> C1> According to his interpretation of JLS, which I concur, they are not well-formed, because the bound of the capture variable, T#1, is C2 & C1, which is forbidden by both section $4.9 and $5.1.10. Nothing in JLS will infer that C2 <: C1. However, javac does allow them, which is reasonable, of course. How do we understand this behavior? Another question, if Ck in $4.9 contains wildcard like C2, how can we use it as the superclass of the notional class? How do we derive members of the notional class? Thanks, Zhong Yu bayou.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Fri Jun 12 15:58:51 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 12 Jun 2015 18:58:51 +0300 Subject: String concatenation tweaks In-Reply-To: <557536B4.90101@gmail.com> References: <55014F7C.20201@oracle.com> <553139FA.20601@oracle.com> <55313D3A.10008@univ-mlv.fr> <55551C6F.4000704@oracle.com> <555DCC4D.8040505@oracle.com> <7CDF6C9C-90CE-4D93-9290-10D9CCC29BB9@univ-mlv.fr> <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <557536B4.90101@gmail.com> Message-ID: <557B01BB.2020704@oracle.com> On 06/08/2015 09:31 AM, Peter Levart wrote: > I played with this a bit and it's cool. I created a full-MH strategy > called EXACT which always calculates upfront exactly what the resulting > string length will be so that it never reallocates the building buffer. > It doesn't use StringBuilder at all, but directly fills-in a char[] > which it then constructs resulting String with without copying the > array. > Here's the implementation: > http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/webrev.01/ Sweeeeet! I merged it to my patchset, thanks! The performance is indeed very promising: http://cr.openjdk.java.net/~shade/8085796/notes.txt I have one doubt though. With the advance of Compact Strings (JEP-254), we would need to adjust EXACT strategy, since it would go through the non-optimal String repacking codepath. JEP-254 adjusts StringBuilder and OptoStringConcat for new String shapes. Therefore, I think the default translation strategy for JDK 9 (if we target it) should still be INNER_*. EXACT is a very compelling argument for invokedynamic-based String concat machinery. > It doesn't beat INNER strategies for small sizes, but does quite well > with bigger sizes. Looking briefly at "-prof perfasm" output for EXACT strategy and comparing it against INNER/OptimizeStringConcat, it would seem String.getChars/System.arraycopy is not optimized by this fix: https://bugs.openjdk.java.net/browse/JDK-6912521 E.g. this is one hotspot in EXACT strategy: ;*invokestatic arraycopy ; - java.lang.String::getChars at 12 (line 788) ; java.lang.StringConcatHelper::prepend at 10 (line 87) 0.93% 1.11% 0x00007fe0442b6a60: rep rex.W stos %al,%es:(%rdi) 17.21% 18.27% 0x00007fe0442b6a63: mov %r11d,%ebp > It is better than Remi's FULL_MH which is also > "full-mh". I think it is a good candidate for optimization, since it > seems it has a constant overhead which is not caused by sub-optimal > algorithm. Perhaps by encoding the algorithm in a spinned inner class? Maybe. But I would think Hotspot compiler guys would like to optimize the MH-based version first. Also, quirks like the one explained above should be worked out before going crazy with more inner classes :) Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Fri Jun 12 16:56:34 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 12 Jun 2015 19:56:34 +0300 Subject: String concatenation tweaks In-Reply-To: <55735A19.8030103@oracle.com> References: <555EE8F7.5040007@oracle.com> <5561EF32.8080101@univ-mlv.fr> <556371A0.80600@oracle.com> <556475CF.8090406@univ-mlv.fr> <5567872A.2080902@oracle.com> <556B75FE.8060605@gmail.com> <556B77CA.4050307@gmail.com> <556B7E3E.8050707@gmail.com> <556C0E7F.9090308@oracle.com> <556C6064.5080704@gmail.com> <556C71C8.6090109@oracle.com> <716BCC10-885F-45D2-88E8-6646D7A3E92D@oracle.com> <557018AD.1040308@oracle.com> <55701E61.1050905@oracle.com> <5570224F.8040809@oracle.com> <55703B89.3090804@oracle.com> <55703D03.8050207@oracle.com> <55703E0B.5050507@oracle.com> <557040CA.1050104@oracle.com> <55704601.2090909@oracle.com> <55704B12.2000905@oracle.com> <5570559C.2090201@oracle.com> <55705703.1050009@oracle.com> <55707B67.4060801@oracle.com> <55708FCC.4040705@oracle.com> <55715804.8000406@oracle.com> <5571728F.5030005@oracle.com> <55730681.5060609@univ-mlv.fr> <55735A19.8030103@oracle.com> Message-ID: <557B0F42.2080700@oracle.com> Thanks for the discussion, guys. I added your concerns and answers to the JEP draft: https://bugs.openjdk.java.net/browse/JDK-8085796 My only concern is this: On 06/06/2015 11:37 PM, Maurizio Cimadamore wrote: > On 06/06/15 15:41, Remi Forax wrote: >> Now, I think that the String concatenation based on invokedynamic >> should be integrated in 9, behind a -XD option of javac at first, >> because it's a good simple example that exercise method handle >> combiners with multiple shapes and see if the startup problem can be >> solved for that case. > This seems like a very sensible plan. At the very least we will have a > chance to test the bits and have a better grip on what real world impact > is gonna look like. As far as I can see, there is little sense to integrate the feature into the next major release, and not turn it on by default. What would be the point? You can change the bytecode shape that drastically only in a major release. Which means if we commit it in disabled form for JDK 9, we can only turn in back on in JDK 10. The realistic "dragging our feet" scenario I see with this approach is that we commit the feature disabled under the flag, keep it lingering there, with no one caring enough to use this in production before it is declared "official", fast-forward to Java (N+1) timeframe, have the same discussion about the drawbacks of unleashing the feature into the world by default, N++, rinse and repeat. I think a sensible plan would be to integrate to 9 with the bytecode translation strategy *exactly* dubbing what's done in javac right now (INNER), forcing everyone to adjust to new bytecode shape early, then improve translation strategies in the (minor) update releases. What am I missing here? Are we concerned the javac-bytecode protocol would need more touchups, after we figure it out in the course of the current work? Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Fri Jun 12 21:46:45 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 12 Jun 2015 22:46:45 +0100 Subject: [8u60] request for review: 8068489: remove unnecessary complexity in Flow and Bits, after JDK-8064857 In-Reply-To: <5578E6DB.4060202@oracle.com> References: <55721C95.4000004@oracle.com> <5578C939.7050305@oracle.com> <5578E6DB.4060202@oracle.com> Message-ID: <557B5345.7030803@oracle.com> Looks good - there are still indentation issues if I look at the Udiff, but if I look at the 'New' file indentation looks ok - I wonder if there might be tabs? Maurizio On 11/06/15 02:39, Vicente-Arturo Romero-Zaldivar wrote: > Hi Maurizio, > > On 06/10/2015 04:33 PM, Maurizio Cimadamore wrote: >> It generally looks good - I found however some differences with the >> code in 9: >> >> * we seem to have replaced 'new ListBuffer

' with 'new >> ListBuffer' - the 9 version simply uses diamond; I think >> we could so the same (also to minimize diffs) >> * indentation seems to be off (likely as a result of the merge) esp. >> in AssignAnalyzer.{letInit,visitClassDef,visitMethodDef} > > yep, good catch! > > I have fixed those issues. I have published a new review at: > http://cr.openjdk.java.net/~vromero/8068489/webrev.01/ > > Thanks, > Vicente > >> >> Maurizio >> >> On 05/06/15 23:03, Vicente-Arturo Romero-Zaldivar wrote: >>> Hi, >>> >>> Please review the backport of bug: >>> >>> 8068489: remove unnecessary complexity in Flow and Bits, after >>> JDK-8064857 >>> >>> JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8068489 >>> backport: https://bugs.openjdk.java.net/browse/JDK-8068547 >>> original patch pushed to 9: >>> http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5e500700b168 >>> public review: http://cr.openjdk.java.net/~vromero/8068489/webrev/ >>> >>> The original patch doesn't apply cleanly. There are no major >>> differences but I think that there are enough to deserve a review. >>> >>> Thanks, >>> Vicente >> > From vicente.romero at oracle.com Fri Jun 12 21:54:02 2015 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 12 Jun 2015 14:54:02 -0700 Subject: [8u60] request for review: 8068489: remove unnecessary complexity in Flow and Bits, after JDK-8064857 In-Reply-To: <557B5345.7030803@oracle.com> References: <55721C95.4000004@oracle.com> <5578C939.7050305@oracle.com> <5578E6DB.4060202@oracle.com> <557B5345.7030803@oracle.com> Message-ID: <557B54FA.5040405@oracle.com> On 06/12/2015 02:46 PM, Maurizio Cimadamore wrote: > Looks good - there are still indentation issues if I look at the > Udiff, but if I look at the 'New' file indentation looks ok - I wonder > if there might be tabs? I will double check but I don't think that there are tabs in the patch. Thanks, Vicente > > Maurizio > > On 11/06/15 02:39, Vicente-Arturo Romero-Zaldivar wrote: >> Hi Maurizio, >> >> On 06/10/2015 04:33 PM, Maurizio Cimadamore wrote: >>> It generally looks good - I found however some differences with the >>> code in 9: >>> >>> * we seem to have replaced 'new ListBuffer

' with 'new >>> ListBuffer' - the 9 version simply uses diamond; I >>> think we could so the same (also to minimize diffs) >>> * indentation seems to be off (likely as a result of the merge) esp. >>> in AssignAnalyzer.{letInit,visitClassDef,visitMethodDef} >> >> yep, good catch! >> >> I have fixed those issues. I have published a new review at: >> http://cr.openjdk.java.net/~vromero/8068489/webrev.01/ >> >> Thanks, >> Vicente >> >>> >>> Maurizio >>> >>> On 05/06/15 23:03, Vicente-Arturo Romero-Zaldivar wrote: >>>> Hi, >>>> >>>> Please review the backport of bug: >>>> >>>> 8068489: remove unnecessary complexity in Flow and Bits, after >>>> JDK-8064857 >>>> >>>> JDK9 bug: https://bugs.openjdk.java.net/browse/JDK-8068489 >>>> backport: https://bugs.openjdk.java.net/browse/JDK-8068547 >>>> original patch pushed to 9: >>>> http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5e500700b168 >>>> public review: http://cr.openjdk.java.net/~vromero/8068489/webrev/ >>>> >>>> The original patch doesn't apply cleanly. There are no major >>>> differences but I think that there are enough to deserve a review. >>>> >>>> Thanks, >>>> Vicente >>> >> > From kumar.x.srinivasan at oracle.com Tue Jun 16 20:03:18 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 16 Jun 2015 13:03:18 -0700 Subject: RFR: (XXS): JDK-8087205: Follow-up fix in langtools for JDK-8085822 Message-ID: <55808106.80102@oracle.com> Hello, Please review fix to maintain backward compatibility mainly required by langtools developers who use a pre-verona jdk for quick build/test, and for bug triaging and isolation purposes. https://bugs.openjdk.java.net/browse/JDK-8087205 Thanks Kumar diff --git a/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java b/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java --- a/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java +++ b/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java @@ -169,6 +169,7 @@ switch (specVersion) { case "9": + case "1.9": return RELEASE_9; case "1.8": return RELEASE_8; From joe.darcy at oracle.com Tue Jun 16 21:43:35 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 16 Jun 2015 14:43:35 -0700 Subject: RFR: (XXS): JDK-8087205: Follow-up fix in langtools for JDK-8085822 In-Reply-To: <55808106.80102@oracle.com> References: <55808106.80102@oracle.com> Message-ID: <55809887.2030502@oracle.com> Hi Kumar, This look okay, as least as a transitory measure. If you haven't done so already, please file a follow-up bug to revisit this once the version string has settled. Thanks, -Joe On 6/16/2015 1:03 PM, Kumar Srinivasan wrote: > Hello, > > Please review fix to maintain backward compatibility mainly required > by langtools developers who use a pre-verona jdk for quick build/test, > and for bug triaging and isolation purposes. > > https://bugs.openjdk.java.net/browse/JDK-8087205 > > Thanks > Kumar > > > diff --git > a/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > b/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > --- a/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > +++ b/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > @@ -169,6 +169,7 @@ > > switch (specVersion) { > case "9": > + case "1.9": > return RELEASE_9; > case "1.8": > return RELEASE_8; > From alexander.v.stepanov at oracle.com Thu Jun 18 13:58:12 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Thu, 18 Jun 2015 16:58:12 +0300 Subject: RFR [9] 8080880: some docs cleanup for langtools In-Reply-To: <555F0191.1010609@oracle.com> References: <555E02BE.7020407@oracle.com> <555E03FB.40803@oracle.com> <555E2A4C.9010903@oracle.com> <555F0191.1010609@oracle.com> Message-ID: <5582CE74.5020004@oracle.com> Sorry, just a reminder. Could please anyone finalize the review for this minor fix? Thanks, alexander On 22.05.2015 13:14, alexander stepanov wrote: > Hello Jonathan, > > Thanks. > > > It is not appropriate to do partial bulk update to the "not a > supported API" > > The responding changes were reverted, please see > http://cr.openjdk.java.net/~avstepan/8080880/webrev.01/ > > Regards, > Alexander > > On 21.05.2015 21:56, Jonathan Gibbons wrote: >> >> On 05/21/2015 09:12 AM, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8080880/webrev.00/ >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8080880 >>> >>> Just some minor fix for docs, no other code touched. >>> >>> The affected packages should (probably) not be visible in the new >>> modular system, but nevertheless... >>> >>> Thanks, >>> Alexander >> >> Alexander, >> >> It is not appropriate to do partial bulk update to the "not a >> supported API" >> comment at the head of the internal files. It is strongly preferred >> that this >> part of the comment remain consistent across all source files, so >> that it is >> amenable to bulk updates, should we wish to do so. >> >> I would suggest you separate the otherwise useful work to fix individual >> minor doc issues from any work involving the standard "not a supported >> API" comment at the head of each file. >> >> -- Jon > From jonathan.gibbons at oracle.com Thu Jun 18 16:12:29 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 18 Jun 2015 09:12:29 -0700 Subject: RFR [9] 8080880: some docs cleanup for langtools In-Reply-To: <5582CE74.5020004@oracle.com> References: <555E02BE.7020407@oracle.com> <555E03FB.40803@oracle.com> <555E2A4C.9010903@oracle.com> <555F0191.1010609@oracle.com> <5582CE74.5020004@oracle.com> Message-ID: <5582EDED.2070103@oracle.com> I will do this early next week. -- Jon On 06/18/2015 06:58 AM, alexander stepanov wrote: > Sorry, just a reminder. Could please anyone finalize the review for > this minor fix? > > Thanks, > alexander > > On 22.05.2015 13:14, alexander stepanov wrote: >> Hello Jonathan, >> >> Thanks. >> >> > It is not appropriate to do partial bulk update to the "not a >> supported API" >> >> The responding changes were reverted, please see >> http://cr.openjdk.java.net/~avstepan/8080880/webrev.01/ >> >> Regards, >> Alexander >> >> On 21.05.2015 21:56, Jonathan Gibbons wrote: >>> >>> On 05/21/2015 09:12 AM, alexander stepanov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix >>>> http://cr.openjdk.java.net/~avstepan/8080880/webrev.00/ >>>> for >>>> https://bugs.openjdk.java.net/browse/JDK-8080880 >>>> >>>> Just some minor fix for docs, no other code touched. >>>> >>>> The affected packages should (probably) not be visible in the new >>>> modular system, but nevertheless... >>>> >>>> Thanks, >>>> Alexander >>> >>> Alexander, >>> >>> It is not appropriate to do partial bulk update to the "not a >>> supported API" >>> comment at the head of the internal files. It is strongly preferred >>> that this >>> part of the comment remain consistent across all source files, so >>> that it is >>> amenable to bulk updates, should we wish to do so. >>> >>> I would suggest you separate the otherwise useful work to fix >>> individual >>> minor doc issues from any work involving the standard "not a supported >>> API" comment at the head of each file. >>> >>> -- Jon >> > From georgiy.rakov at oracle.com Mon Jun 22 15:17:01 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Mon, 22 Jun 2015 18:17:01 +0300 Subject: Anonymous classes are not final according to reflection API Message-ID: <558826EC.6060000@oracle.com> Hello, if I understand correctly according to following assertion from JLS 15.9.5 anonymous classes are always final: An anonymous class is always implicitly final (?8.1.1.2). But reflection API reports that the class is not final. Namely let's consider following code: import java.lang.reflect.Modifier; public class Test12 { static class Foo {} public static void main(String argv[]) { Foo foo = new Foo<>() {}; if ( (foo.getClass().getModifiers() & Modifier.FINAL) != 0 ) { System.out.println("final, modifiers: " + foo.getClass().getModifiers()); } else { System.out.println("not final, modifiers: " + foo.getClass().getModifiers()); } } } On JDK9b69 it reports: not final, modifiers: 0 Could you please tell if you consider this as a discrepancy between spec and javac (VM?) which should be fixed. Thank you, Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- import java.lang.reflect.Modifier; public class Test12 { static class Foo {} public static void main(String argv[]) { Foo foo = new Foo<>() {}; if ( (foo.getClass().getModifiers() & Modifier.FINAL) != 0 ) { System.out.println("final, modifiers: " + foo.getClass().getModifiers()); } else { System.out.println("not final, modifiers: " + foo.getClass().getModifiers()); } } } From forax at univ-mlv.fr Mon Jun 22 15:35:35 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 22 Jun 2015 17:35:35 +0200 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <558826EC.6060000@oracle.com> References: <558826EC.6060000@oracle.com> Message-ID: <55882B47.8060001@univ-mlv.fr> I wonder if it's not a reflection bug, did you check with 'javap -c -verbose' the modifiers of the generated class (something like Test12$1.class) ? cheers, R?mi On 06/22/2015 05:17 PM, Georgiy Rakov wrote: > Hello, > > if I understand correctly according to following assertion from JLS > 15.9.5 anonymous classes are always final: > > An anonymous class is always implicitly final (?8.1.1.2). > > But reflection API reports that the class is not final. Namely let's > consider following code: > > import java.lang.reflect.Modifier; > > public class Test12 { > static class Foo {} > > public static void main(String argv[]) { > Foo foo = new Foo<>() {}; > if ( (foo.getClass().getModifiers() & Modifier.FINAL) != 0 ) { > System.out.println("final, modifiers: " + > foo.getClass().getModifiers()); > } else { > System.out.println("not final, modifiers: " + > foo.getClass().getModifiers()); > } > } > } > > On JDK9b69 it reports: > > not final, modifiers: 0 > > Could you please tell if you consider this as a discrepancy between > spec and javac (VM?) which should be fixed. > > Thank you, > Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Victor.Rudometov at oracle.com Mon Jun 22 15:56:59 2015 From: Victor.Rudometov at oracle.com (Victor Rudometov) Date: Mon, 22 Jun 2015 18:56:59 +0300 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <55882B47.8060001@univ-mlv.fr> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> Message-ID: <5588304B.7070709@oracle.com> This seems to be a reflection bug, since ACC_FINAL is present in Test12$1.class file: final class test.Test12$1 extends test.Test12$Foo minor version: 0 major version: 52 flags: ACC_FINAL, ACC_SUPER Thanks. Victor. On 22-Jun-15 18:35, Remi Forax wrote: > I wonder if it's not a reflection bug, > did you check with 'javap -c -verbose' the modifiers of the generated > class (something like Test12$1.class) ? > > cheers, > R?mi > > On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >> Hello, >> >> if I understand correctly according to following assertion from JLS >> 15.9.5 anonymous classes are always final: >> >> An anonymous class is always implicitly final (?8.1.1.2). >> >> But reflection API reports that the class is not final. Namely let's >> consider following code: >> >> import java.lang.reflect.Modifier; >> >> public class Test12 { >> static class Foo {} >> >> public static void main(String argv[]) { >> Foo foo = new Foo<>() {}; >> if ( (foo.getClass().getModifiers() & Modifier.FINAL) != >> 0 ) { >> System.out.println("final, modifiers: " + >> foo.getClass().getModifiers()); >> } else { >> System.out.println("not final, modifiers: " + >> foo.getClass().getModifiers()); >> } >> } >> } >> >> On JDK9b69 it reports: >> >> not final, modifiers: 0 >> >> Could you please tell if you consider this as a discrepancy between >> spec and javac (VM?) which should be fixed. >> >> Thank you, >> Georgiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jun 23 06:50:40 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 23 Jun 2015 08:50:40 +0200 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <5588304B.7070709@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> Message-ID: <558901C0.4080804@univ-mlv.fr> Hi Victor, did you have open a bug for that ? cheers, R?mi On 06/22/2015 05:56 PM, Victor Rudometov wrote: > This seems to be a reflection bug, since ACC_FINAL is present in > Test12$1.class file: > > final class test.Test12$1 extends test.Test12$Foo > minor version: 0 > major version: 52 > flags: ACC_FINAL, ACC_SUPER > > Thanks. > Victor. > > On 22-Jun-15 18:35, Remi Forax wrote: >> I wonder if it's not a reflection bug, >> did you check with 'javap -c -verbose' the modifiers of the generated >> class (something like Test12$1.class) ? >> >> cheers, >> R?mi >> >> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>> Hello, >>> >>> if I understand correctly according to following assertion from JLS >>> 15.9.5 anonymous classes are always final: >>> >>> An anonymous class is always implicitly final (?8.1.1.2). >>> >>> But reflection API reports that the class is not final. Namely let's >>> consider following code: >>> >>> import java.lang.reflect.Modifier; >>> >>> public class Test12 { >>> static class Foo {} >>> >>> public static void main(String argv[]) { >>> Foo foo = new Foo<>() {}; >>> if ( (foo.getClass().getModifiers() & Modifier.FINAL) != >>> 0 ) { >>> System.out.println("final, modifiers: " + >>> foo.getClass().getModifiers()); >>> } else { >>> System.out.println("not final, modifiers: " + >>> foo.getClass().getModifiers()); >>> } >>> } >>> } >>> >>> On JDK9b69 it reports: >>> >>> not final, modifiers: 0 >>> >>> Could you please tell if you consider this as a discrepancy between >>> spec and javac (VM?) which should be fixed. >>> >>> Thank you, >>> Georgiy. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Tue Jun 23 08:35:05 2015 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 23 Jun 2015 14:05:05 +0530 Subject: Anonymous class with parameterized super type, constructor formal parameters In-Reply-To: <5579AEF9.8000700@oracle.com> References: <5579AEF9.8000700@oracle.com> Message-ID: <55891A39.7020207@oracle.com> On Thursday 11 June 2015 09:23 PM, Georgiy Rakov wrote: > Hello, > > assertion jls-15.9.5.1-100-A.1 specifies: > > The actual arguments to the class instance creation expression are > used to determine a constructor |cs| of S, using the same rules as > for method invocations (?15.12 > ). > /_*The type of each formal parameter of the anonymous constructor > must be identical to the corresponding formal parameter of > *_//_*|cs|*_/. > > I'd like to point to the emphasized part of the assertion above which > states that the formal parameters of the anonymous class constructor > are identical to those of the corresponding super class constructor. > > However let's consider following example: > > import java.lang.reflect.Constructor; > import java.util.Arrays; > import java.util.stream.Stream; > > class Test7A { > Test7A(T t) {} > } > public class Test7 { > public static void main(String[] args) throws > NoSuchMethodException { > Test7A a = new Test7A<>("a"){}; > System.out.println("Diamond case:"); > printlnParameters("anonymous class constructor", > a.getClass().getDeclaredConstructor(String.class)); > printlnParameters("super class constructor", > a.getClass().getSuperclass().getDeclaredConstructor(Object.class)); > > System.out.println(); > a = new Test7A("a"){}; > System.out.println("Explicit type arguments case:"); > printlnParameters("anonymous class constructor", > a.getClass().getDeclaredConstructor(String.class)); > printlnParameters("super class constructor", > a.getClass().getSuperclass().getDeclaredConstructor(Object.class)); > } > static void printlnParameters(String label, Constructor c) { > Stream stream = > Arrays.stream(c.getParameters()).map(p -> p.getType().toString()); > System.out.println(" " + label + ": " + > Arrays.toString(stream.toArray())); > } > } > > The output of this program is: > > Diamond case: > anonymous class constructor: [class java.lang.String] > super class constructor: [class java.lang.Object] > > Explicit type arguments case: > anonymous class constructor: [class java.lang.String] > super class constructor: [class java.lang.Object] > > As you can see the formal parameters for the anonymous class > constructor and those of the corresponding base class constructor are > different. Could you please tell if you consider this as a discrepancy > between javac and specification which should be fixed. I believe what you are observing is the intended behaviour which is not contrary in reality to the documented behaviour. You are inspecting the parameters at run time at which point due to erasure the relevant information is lost. The super type of the anonymous class here is NOT (the erased) Test7A, but is Test7A - and when viewed in that light, the assertion you cite holds true. Thanks Srikanth > > BTW: this alludes to my previous letter, that is, provided the > anonymous classes in these cases were generic and its instances were > just parameterization of those the formal parameters naturally would > be identical, I believe. > > Thank you, > Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Tue Jun 23 08:51:53 2015 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Tue, 23 Jun 2015 14:21:53 +0530 Subject: Diamond with anonymous classes: what if anonymous class were generic In-Reply-To: <55799BE9.3050808@oracle.com> References: <55799BE9.3050808@oracle.com> Message-ID: <55891E29.1010006@oracle.com> On Thursday 11 June 2015 08:02 PM, Georgiy Rakov wrote: > Hello, > > currently when diamond is used in anonymous class instance creation > expression the class being instantiated is not generic. I believe this > is the reason why there are exceptions specified in the assertion below: > > ***It is a compile-time error if the superclass or superinterface > type of the anonymous class, T, or any subexpression of T, has one > of the following forms: > - A type variable (4.4) that was not declared as a type parameter > (such as a type variable produced by capture conversion (5.1.10)) > - An intersection type (4.9) > - A class or interface type, where the class or interface > declaration is not accessible from the class or interface in which > the expression appears.*** > The term "subexpression" includes type arguments of parameterized > types (4.5), bounds of wildcards (4.5.1), and element types of > array types (10.1). It excludes bounds of type variables.*** > > What if the anonymous class declaration derived the type parameters > from the type specified in the instance creation expression (from > super type). In this case the anonymous class would be a generic class > and the type of the instance created will be a regular > parameterization of that generic class. In this case I believe the > situation will be identical to ordinary non-anonymous classes and > there would be no needs to specify inferred types in the class signature. > Georgiy, I am not sure I entirely understand what you are saying here - There is no notion of an anonymous class declaration "deriving" its type parameters from its super type. Neither the compiler nor the JLS view the anonymous class as being generic and "type of the instance created will be a regular parameterization of that generic class". Do you have in mind some code that you think should not be compiled, but is or should be but is not ? Is that what the code snippet below is supposed be ??? class Foo { } Foo inst = new Foo<>(){}; In this case, the anonymous type's super type is Foo and I don't see an issue here. Thanks! Srikanth > For instance: > > class Foo {ge > } > > Foo inst = new Foo<>(){}; > > Here anonymous class would have type parameter T derived from its > super type T. The type of instance creation expression will be the > parameterization of this generic anonymous class with T inferred as > String. > > I wonder if you considered such option. > > Thank you, > Georgiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgiy.rakov at oracle.com Tue Jun 23 13:42:57 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Tue, 23 Jun 2015 16:42:57 +0300 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <5588304B.7070709@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> Message-ID: <55896261.9040505@oracle.com> I've filed the issue JDK-8129576. There is following issue in JBS: JDK-4777101 which seems to relate to this one. Thank you, Georgiy. On 22.06.2015 18:56, Victor Rudometov wrote: > This seems to be a reflection bug, since ACC_FINAL is present in > Test12$1.class file: > > final class test.Test12$1 extends test.Test12$Foo > minor version: 0 > major version: 52 > flags: ACC_FINAL, ACC_SUPER > > Thanks. > Victor. > > On 22-Jun-15 18:35, Remi Forax wrote: >> I wonder if it's not a reflection bug, >> did you check with 'javap -c -verbose' the modifiers of the generated >> class (something like Test12$1.class) ? >> >> cheers, >> R?mi >> >> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>> Hello, >>> >>> if I understand correctly according to following assertion from JLS >>> 15.9.5 anonymous classes are always final: >>> >>> An anonymous class is always implicitly final (?8.1.1.2). >>> >>> But reflection API reports that the class is not final. Namely let's >>> consider following code: >>> >>> import java.lang.reflect.Modifier; >>> >>> public class Test12 { >>> static class Foo {} >>> >>> public static void main(String argv[]) { >>> Foo foo = new Foo<>() {}; >>> if ( (foo.getClass().getModifiers() & Modifier.FINAL) != >>> 0 ) { >>> System.out.println("final, modifiers: " + >>> foo.getClass().getModifiers()); >>> } else { >>> System.out.println("not final, modifiers: " + >>> foo.getClass().getModifiers()); >>> } >>> } >>> } >>> >>> On JDK9b69 it reports: >>> >>> not final, modifiers: 0 >>> >>> Could you please tell if you consider this as a discrepancy between >>> spec and javac (VM?) which should be fixed. >>> >>> Thank you, >>> Georgiy. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.shipilev at oracle.com Tue Jun 23 19:02:03 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 23 Jun 2015 22:02:03 +0300 Subject: JEP draft: Indify String Concat Message-ID: <5589AD2B.1010207@oracle.com> Hi guys, Restarting the thread here. Links to the previous discussions are here: http://mail.openjdk.java.net/pipermail/compiler-dev/2015-April/009389.html http://mail.openjdk.java.net/pipermail/compiler-dev/2015-May/009463.html http://mail.openjdk.java.net/pipermail/compiler-dev/2015-June/009508.html Here's a JEP draft, please read and review: https://bugs.openjdk.java.net/browse/JDK-8085796 More thorough discussion: http://cr.openjdk.java.net/~shade/8085796/notes.txt As usual, the current patches are here: http://cr.openjdk.java.net/~shade/8085796/ Recent updates: * Implemented the slicing of large concat chains (required since indy can only take 253 dynamic arguments), added a regression test. * (Maurizio:) Followed up on bytecode footprint with some stress tests, see the notes above. Pending discussion: * String concatenation metaprotocol, as outlined by Remi (http://mail.openjdk.java.net/pipermail/compiler-dev/2015-June/009543.html). It would be interesting to try different incarnations of this thing, but I don't have more time this week. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From maurizio.cimadamore at oracle.com Wed Jun 24 09:26:06 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 24 Jun 2015 10:26:06 +0100 Subject: Wildcard capture with self-referencing bound In-Reply-To: References: Message-ID: <558A77AE.1000001@oracle.com> Hi, these are all areas where the JLS text is a bit underspecified and javac ended up settling on some opportunistic strategy which then, eventually, also got adopted by other compilers too. For instance, w.r.t. generic type well-formedness, the check performed by javac depends on the type-argument kind: * if the type-argument T is invariant (i.e. not a wildcard type) - check that T <: B * if the type argument T is a wildcard: -of the kind ? extends A - check A _is castable_ to B -of the kind ? super A - check that there exist some instantiation of A such that A <: B -of the kind ? - always valid I found a very similar explanation buried in the Java generic forums - and it seemed like, at the time (JSR14), Neal Gafter thought this was a good compromise between safety and expressiveness. The spec ended up being written in a different - much stricter way, as you point out; as a result a lot of programs that are compiled w/o errors by javac are morally rejected by the spec. We might do some work in this area to align the compiler and the spec; note also that the compiler impl is too liberal/fuzzy, while the spec is too strict, so the 'optimal' result is probably somewhere in the middle. Intersection types are also another deeply unspecified area; as you say, it is not clear what happens when the intersection components are wildcard types; we had few issues in javac related to this and we ended up forcing a capture conversion on the intersection type components. Again, this is probably not the behavior we'd like to have in the long run - think of it as an expedient to get things back on track. Cheers Maurizio On 12/06/15 00:40, Zhong Yu wrote: > Elias Vasylenko posted this question on > http://stackoverflow.com/questions/30788366 > > Given declarations > > class C1> {} > class C2 extends C1> {} > > Are the following parameterization well-formed? > > C1> > C1> > > According to his interpretation of JLS, which I concur, they are not > well-formed, because the bound of the capture variable, T#1, is > C2 & C1, which is forbidden by both section $4.9 and > $5.1.10. Nothing in JLS will infer that C2 <: C1. > > However, javac does allow them, which is reasonable, of course. How do > we understand this behavior? > > Another question, if Ck in $4.9 contains wildcard like C2, how can > we use it as the superclass of the notional class? How do we derive > members of the notional class? > > Thanks, > Zhong Yu > bayou.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Wed Jun 24 13:13:15 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 24 Jun 2015 15:13:15 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DDEEC.2000505@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> Message-ID: <558AACEB.8030006@oracle.com> Hello, After some offline discussions, I've somewhat changed the internal API for plugging in the platforms (based on Jon's advices). An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ How does this look? Thanks for all the comments! Jan On 2.6.2015 18:50, Jan Lahoda wrote: > Hello Eric, > > Thanks for the change, this seems definitely better to me. I've folded > your change that into my patch. An updated version (just langtools this > time): > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ > > Thanks! > > Jan > > On 2.6.2015 16:04, Erik Joelsson wrote: >> Hello Jan, >> >> Sorry to bother you with even more build changes, but with these file >> moves, I realized that this new file, ct.sym, is really a part of the >> jdk.compiler module and really not a special case at all. Because of >> this, it should be generated as part of the jdk.compiler-gendata target. >> This also eliminates all the changes in the top level repo and only >> leaves one new makefile in the langtools repo. >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >> >> /Erik >> >> On 2015-06-01 17:56, Jan Lahoda wrote: >>> Hi, >>> >>> I made a somewhat bigger update (partially based on other feedback). >>> Summary of changes: >>> -the history data has been moved into langtools (I also moved the >>> Ctsym.gmk) >>> -there are JDK 6 data now >>> -renamed the "-platform" option to "-release". Code/tests directly >>> related to the option has been also changed as well. I kept the >>> internal PlatformProvider API in javac as is, and also kept related >>> code. >>> -added a note that the is generated by >>> CreateSymbols. >>> >>> Webrevs: >>> top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>> langtools: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>> >>> Delta webrevs are also available. >>> >>> How does this look? >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>> Ah, yes, I did not realize that. Thanks, will fix. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>> don't mention the fact that a side effect of the sym.txt generation is >>>>> the mentioned earlier in the same >>>>> comments >>>>> (so one might wonder where does that come from). >>>>> >>>>> Maurizio >>>>> >>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded another iteration, with these changes: >>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>> OpenJDK case). >>>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>>> description into wrong a file (the "break" -> "break OUTER;" change). >>>>>> -jdk.management module has been split out from java.management >>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>> java.management and jdk.management as well. >>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>> >>>>>> Webrevs: >>>>>> -top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>> -langtools (no changes against the last webrev): >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>> >>>>>> Delta webrevs against the previous iteration are included under >>>>>> "Author comments". >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>> Excellent work. >>>>>>>> >>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>> Probe >>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>> >>>>>>>> /bin/java Probe --> classes-8 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> >>>>>>>> etc. >>>>>>> >>>>>>> Sure, will do. >>>>>>> >>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>> descriptions >>>>>>> automatically, per our offline discussion. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>> top-level repository: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>> langtools: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>> >>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>> differences >>>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>>> "Author's comments") >>>>>>>>> >>>>>>>>> Summary of changes: >>>>>>>>> -applied Eric's build changes >>>>>>>>> -moved CreateSymbols into >>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> great work - couple of comments below: >>>>>>>>>> >>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>> simplified >>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>> checkOptionAllowed >>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>> commonalities >>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>> this a >>>>>>>>>> bit? >>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>> specified >>>>>>>>>> and >>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>> that, >>>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>> logic in >>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>> CreateSymbols >>>>>>>>>> with >>>>>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>>>>> that >>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>> (i.e. 8) >>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>> that's the >>>>>>>>>> use >>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>> order to >>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>> the >>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>> seem to be typically all >>>>>>>>>> identical >>>>>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>>>>> the >>>>>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>>>>> 7 and >>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>> should be >>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>>> there >>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>> >>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>> >>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>> >>>>>>>>>>> These changes also require additional langtools changes as their >>>>>>>>>>> prerequisite: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>> effect as >>>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>>> values >>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>> correspond to >>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>> >>>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>>> N. The >>>>>>>>>>> proposal is to include history data in the textual format inside >>>>>>>>>>> the >>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>> time >>>>>>>>>>> and >>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>> javac >>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>> lib/ct.sym >>>>>>>>>>> file. The input history data are placed >>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>> This >>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>> public >>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>> >>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>> checkout and >>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>> significantly >>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>> would >>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>> >>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>> them as >>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>> Code >>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>> named >>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>> bootclasspath >>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>> 'N' in >>>>>>>>>>> their name. >>>>>>>>>>> >>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>> Concise >>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>> one >>>>>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>>>>> to a >>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>> and the >>>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>>> ct.sym >>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>> independently. >>>>>>>>>>> >>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>> Alan >>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>> matter >>>>>>>>>>> before. >>>>>>>>>>> >>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>> >>>>>>>> >>>>> >> From georgiy.rakov at oracle.com Wed Jun 24 13:51:43 2015 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Wed, 24 Jun 2015 16:51:43 +0300 Subject: Diamond with anonymous classes: what if anonymous class were generic In-Reply-To: <55891E29.1010006@oracle.com> References: <55799BE9.3050808@oracle.com> <55891E29.1010006@oracle.com> Message-ID: <558AB5EE.8040101@oracle.com> It's not the bug or issue what I'm asking about. I'm asking about, say, alternative approach to anonymous classes. Current approach defined by JLS specifies that when super type of the anonymous class is generic and explicit type arguments or diamond is used in the instance creation expression then corresponding anonymous class declaration is declared (implicitly) _as NOT generic_. This is not explicitly specified by JLS but if I understand correctly it happens so in fact. For instance if we consider the example below. class Foo { } Foo inst = new Foo(){}; The declaration of the anonymous class above is identical to the following one: class 1 extends Foo {} //let's imagine that "1" is a valid identifier And the type of the instance creation expression is 1. But one can imagine another approach which might be defined by spec and which would specify that when super type of the anonymous class is generic and explicit type arguments or diamond is used in the instance creation expression then corresponding anonymous class declaration is declared (implicitly) _as generic_. In this case type arguments from its super type would be "derived" by anonymous class declaration. For instance if we consider the example presented above the declaration of the anonymous class would be identical to following one: class 1 extends Foo {} //let's again imagine that "1" is a valid identifier And the type returned by the instance creation expression would be: 1. I'm just wondering if you considered such approach. It seems that provided this approach were implemented there would be no needs for exceptions specified by following assertions: ***It is a compile-time error if the superclass or superinterface type of the anonymous class, T, or any subexpression of T, has one of the following forms: - A type variable (4.4) that was not declared as a type parameter (such as a type variable produced by capture conversion (5.1.10)) - An intersection type (4.9) - A class or interface type, where the class or interface declaration is not accessible from the class or interface in which the expression appears.*** The term "subexpression" includes type arguments of parameterized types (4.5), bounds of wildcards (4.5.1), and element types of array types (10.1). It excludes bounds of type variables.*** Thanks, Georgiy. On 23.06.2015 11:51, Srikanth wrote: > > > On Thursday 11 June 2015 08:02 PM, Georgiy Rakov wrote: >> Hello, >> >> currently when diamond is used in anonymous class instance creation >> expression the class being instantiated is not generic. I believe >> this is the reason why there are exceptions specified in the >> assertion below: >> >> ***It is a compile-time error if the superclass or superinterface >> type of the anonymous class, T, or any subexpression of T, has >> one of the following forms: >> - A type variable (4.4) that was not declared as a type parameter >> (such as a type variable produced by capture conversion (5.1.10)) >> - An intersection type (4.9) >> - A class or interface type, where the class or interface >> declaration is not accessible from the class or interface in >> which the expression appears.*** >> The term "subexpression" includes type arguments of parameterized >> types (4.5), bounds of wildcards (4.5.1), and element types of >> array types (10.1). It excludes bounds of type variables.*** >> >> What if the anonymous class declaration derived the type parameters >> from the type specified in the instance creation expression (from >> super type). In this case the anonymous class would be a generic >> class and the type of the instance created will be a regular >> parameterization of that generic class. In this case I believe the >> situation will be identical to ordinary non-anonymous classes and >> there would be no needs to specify inferred types in the class signature. >> > Georgiy, > > I am not sure I entirely understand what you are saying here - There > is no notion of an anonymous class declaration "deriving" its type > parameters from its super type. Neither the compiler nor the JLS view > the anonymous > class as being generic and "type of the instance created will be a > regular parameterization of that generic class". > > Do you have in mind some code that you think should not be compiled, > but is or should be but is not ? > > Is that what the code snippet below is supposed be ??? > > class Foo { > } > > > Foo inst = new Foo<>(){}; > > In this case, the anonymous type's super type is Foo and I > don't see an issue here. > > Thanks! > Srikanth > > > >> For instance: >> >> class Foo {ge >> } >> >> Foo inst = new Foo<>(){}; >> >> Here anonymous class would have type parameter T derived from its >> super type T. The type of instance creation expression will be the >> parameterization of this generic anonymous class with T inferred as >> String. >> >> I wonder if you considered such option. >> >> Thank you, >> Georgiy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jun 24 17:19:24 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 24 Jun 2015 10:19:24 -0700 Subject: JDK 9 RFR of JDK-8129597: Add tier 3 test definitions to the JDK 9 forest Message-ID: <558AE69C.7090905@oracle.com> Hello, Per the recent email to jdk9-dev, "Test policy follow-up, third testing tier," http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html please review the patch below to address JDK-8129597 : Add tier 3 test definitions to the JDK 9 forest http://cr.openjdk.java.net/~darcy/8129597.0/ (Tests will be added to tier 3 in subsequent changesets.) Thanks, -Joe --- old/jdk/test/TEST.groups 2015-06-23 09:47:53.929026307 -0700 +++ new/jdk/test/TEST.groups 2015-06-23 09:47:53.761110302 -0700 @@ -42,6 +42,9 @@ :jdk_other \ :jdk_svc +# Tier 3 is initially empty +tier3 = + ############################################################################### # # Other test definitions; generally smaller granularity than tiers --- old/langtools/test/TEST.groups 2015-06-23 09:47:54.296842319 -0700 +++ new/langtools/test/TEST.groups 2015-06-23 09:47:54.192894315 -0700 @@ -22,11 +22,14 @@ # Tiered testing definitions -# All langtools tests are tier 1 +# All langtools tests are tier 1. tier1 = \ tools \ com \ lib -# No langtools tests are tier 2 +# No langtools tests are tier 2. tier2 = + +# No langtools tests are tier 3 either. +tier3 = --- old/jaxp/test/TEST.groups 2015-06-23 09:47:54.616682328 -0700 +++ new/jaxp/test/TEST.groups 2015-06-23 09:47:54.528726325 -0700 @@ -29,5 +29,8 @@ tier2 = \ :jaxp_all +# No tier 3 tests. +tier3 = + jaxp_all = \ javax/xml/jaxp --- old/nashorn/test/TEST.groups 2015-06-23 09:47:54.936522337 -0700 +++ new/nashorn/test/TEST.groups 2015-06-23 09:47:54.848566335 -0700 @@ -27,3 +27,6 @@ # All nashorn tests are tier 2. tier2 = src + +# No nashorn tests are tier 3. +tier3 = From zhong.j.yu at gmail.com Wed Jun 24 18:30:53 2015 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 24 Jun 2015 13:30:53 -0500 Subject: Diamond with anonymous classes: what if anonymous class were generic In-Reply-To: <558AB5EE.8040101@oracle.com> References: <55799BE9.3050808@oracle.com> <55891E29.1010006@oracle.com> <558AB5EE.8040101@oracle.com> Message-ID: Currently, people use "super type token" trick [1] to create a sort of "type literal". This trick depends on the fact that an anonymous class is non-generic. Otherwise, the following two cases may share the same class, and defeats the trick. new TypeReference>() {} new TypeReference>() {} [1] http://gafter.blogspot.com/2006/12/super-type-tokens.html PS - it's great to have diamond with anonymous class, particularly because "super type token" would be much simpler in many use cases. Zhong Yu bayou.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Wed Jun 24 20:06:16 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 24 Jun 2015 13:06:16 -0700 Subject: JDK 9 RFR of JDK-8129597: Add tier 3 test definitions to the JDK 9 forest In-Reply-To: <558AE69C.7090905@oracle.com> References: <558AE69C.7090905@oracle.com> Message-ID: <558B0DB8.6030202@oracle.com> Hi Joe, Changes look good to me. I hope the initial tier3 test run passes. :-) s'marks On 6/24/15 10:19 AM, joe darcy wrote: > Hello, > > Per the recent email to jdk9-dev, > > "Test policy follow-up, third testing tier," > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html > > please review the patch below to address > > JDK-8129597 : Add tier 3 test definitions to the JDK 9 forest > http://cr.openjdk.java.net/~darcy/8129597.0/ > > (Tests will be added to tier 3 in subsequent changesets.) > > Thanks, > > -Joe > > --- old/jdk/test/TEST.groups 2015-06-23 09:47:53.929026307 -0700 > +++ new/jdk/test/TEST.groups 2015-06-23 09:47:53.761110302 -0700 > @@ -42,6 +42,9 @@ > :jdk_other \ > :jdk_svc > > +# Tier 3 is initially empty > +tier3 = > + > ############################################################################### > # > # Other test definitions; generally smaller granularity than tiers > --- old/langtools/test/TEST.groups 2015-06-23 09:47:54.296842319 -0700 > +++ new/langtools/test/TEST.groups 2015-06-23 09:47:54.192894315 -0700 > @@ -22,11 +22,14 @@ > > # Tiered testing definitions > > -# All langtools tests are tier 1 > +# All langtools tests are tier 1. > tier1 = \ > tools \ > com \ > lib > > -# No langtools tests are tier 2 > +# No langtools tests are tier 2. > tier2 = > + > +# No langtools tests are tier 3 either. > +tier3 = > --- old/jaxp/test/TEST.groups 2015-06-23 09:47:54.616682328 -0700 > +++ new/jaxp/test/TEST.groups 2015-06-23 09:47:54.528726325 -0700 > @@ -29,5 +29,8 @@ > tier2 = \ > :jaxp_all > > +# No tier 3 tests. > +tier3 = > + > jaxp_all = \ > javax/xml/jaxp > --- old/nashorn/test/TEST.groups 2015-06-23 09:47:54.936522337 -0700 > +++ new/nashorn/test/TEST.groups 2015-06-23 09:47:54.848566335 -0700 > @@ -27,3 +27,6 @@ > > # All nashorn tests are tier 2. > tier2 = src > + > +# No nashorn tests are tier 3. > +tier3 = > From forax at univ-mlv.fr Wed Jun 24 19:02:03 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 24 Jun 2015 21:02:03 +0200 Subject: Diamond with anonymous classes: what if anonymous class were generic In-Reply-To: <558AB5EE.8040101@oracle.com> References: <55799BE9.3050808@oracle.com> <55891E29.1010006@oracle.com> <558AB5EE.8040101@oracle.com> Message-ID: <558AFEAB.6080608@univ-mlv.fr> Hi Georgiy, On 06/24/2015 03:51 PM, Georgiy Rakov wrote: > It's not the bug or issue what I'm asking about. I'm asking about, > say, alternative approach to anonymous classes. > > Current approach defined by JLS specifies > that when super type of the anonymous class is generic and explicit > type arguments or diamond is used in the instance creation expression > then corresponding anonymous class declaration is declared > (implicitly) _as NOT generic_. This is not explicitly specified by JLS > but if I understand correctly it happens so in fact. > For instance if we consider the example below. > > class Foo { > } > > Foo inst = new Foo(){}; > > The declaration of the anonymous class above is identical to the > following one: > > class 1 extends Foo {} //let's imagine that "1" is a valid > identifier > > And the type of the instance creation expression is 1. > > But one can imagine another approach which might be defined by spec > and which would specify > that when super type of the anonymous class is generic and explicit > type arguments or diamond is used in the instance creation expression > then corresponding anonymous class declaration is declared > (implicitly) _as generic_. In this case type arguments from its super > type would be "derived" by anonymous class declaration. > For instance if we consider the example presented above the > declaration of the anonymous class would be identical to following one: > > class 1 extends Foo {} //let's again imagine that "1" is a > valid identifier > > And the type returned by the instance creation expression would be: > 1. > > I'm just wondering if you considered such approach. > > It seems that provided this approach were implemented there would be > no needs for exceptions specified by following assertions: > > ***It is a compile-time error if the superclass or superinterface > type of the anonymous class, T, or any subexpression of T, has one > of the following forms: > - A type variable (4.4) that was not declared as a type parameter > (such as a type variable produced by capture conversion (5.1.10)) > - An intersection type (4.9) > - A class or interface type, where the class or interface > declaration is not accessible from the class or interface in which > the expression appears.*** > The term "subexpression" includes type arguments of parameterized > types (4.5), bounds of wildcards (4.5.1), and element types of > array types (10.1). It excludes bounds of type variables.*** > > Thanks, > Georgiy. It's a very good question :) The problem of the approach you suggest is that because a type variable is considered as its bound your proposal has not the same semantics has the one specified by the JLS. By example, class A { T t; void foo(Object o) { ... } void foo(String s) { ... } void bar() { new A() {{ foo(t); // should call foo(String) and not foo(Object) }}; } } with your semantics, new A is equivalent to new $1 extends A then T = String, so 't' is considered as an Object, the bound of T, so foo(t) will call foo(Object) and not foo(String). regards, R?mi > > On 23.06.2015 11:51, Srikanth wrote: >> >> >> On Thursday 11 June 2015 08:02 PM, Georgiy Rakov wrote: >>> Hello, >>> >>> currently when diamond is used in anonymous class instance creation >>> expression the class being instantiated is not generic. I believe >>> this is the reason why there are exceptions specified in the >>> assertion below: >>> >>> ***It is a compile-time error if the superclass or >>> superinterface type of the anonymous class, T, or any >>> subexpression of T, has one of the following forms: >>> - A type variable (4.4) that was not declared as a type >>> parameter (such as a type variable produced by capture >>> conversion (5.1.10)) >>> - An intersection type (4.9) >>> - A class or interface type, where the class or interface >>> declaration is not accessible from the class or interface in >>> which the expression appears.*** >>> The term "subexpression" includes type arguments of >>> parameterized types (4.5), bounds of wildcards (4.5.1), and >>> element types of array types (10.1). It excludes bounds of type >>> variables.*** >>> >>> What if the anonymous class declaration derived the type parameters >>> from the type specified in the instance creation expression (from >>> super type). In this case the anonymous class would be a generic >>> class and the type of the instance created will be a regular >>> parameterization of that generic class. In this case I believe the >>> situation will be identical to ordinary non-anonymous classes and >>> there would be no needs to specify inferred types in the class >>> signature. >>> >> Georgiy, >> >> I am not sure I entirely understand what you are saying here - There >> is no notion of an anonymous class declaration "deriving" its type >> parameters from its super type. Neither the compiler nor the JLS view >> the anonymous >> class as being generic and "type of the instance created will be a >> regular parameterization of that generic class". >> >> Do you have in mind some code that you think should not be compiled, >> but is or should be but is not ? >> >> Is that what the code snippet below is supposed be ??? >> >> class Foo { >> } >> >> >> Foo inst = new Foo<>(){}; >> >> In this case, the anonymous type's super type is Foo and I >> don't see an issue here. >> >> Thanks! >> Srikanth >> >> >> >>> For instance: >>> >>> class Foo {ge >>> } >>> >>> Foo inst = new Foo<>(){}; >>> >>> Here anonymous class would have type parameter T derived from its >>> super type T. The type of instance creation expression will be the >>> parameterization of this generic anonymous class with T inferred as >>> String. >>> >>> I wonder if you considered such option. >>> >>> Thank you, >>> Georgiy. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Thu Jun 25 14:58:32 2015 From: bsrbnd at gmail.com (bsrbnd) Date: Thu, 25 Jun 2015 16:58:32 +0200 Subject: [PATCH] 8081769: Redundant error message on bad usage of class literal Message-ID: Hi, as described in issue 8081769, the following code produces two errors instead of one plus a wrong end of file error. public class BadClassLiteral { public static void method() { Class c1 = this.class; } } BadClassLiteral.java:3: error: expected Class c1 = this.class; ^ BadClassLiteral.java:3: error: expected Class c1 = this.class; ^ BadClassLiteral.java:5: error: reached end of file while parsing } ^ 3 errors While the first error is ok, the second and third errors occured because the parser goes on with a class definition starting with the "class" token. Method JavacParser.accept(TokenKind) should skip next token ("class" in this case) even if an error occurs, as follows (jdk 9): diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java @@ -485,6 +485,7 @@ } else { setErrorEndPos(token.pos); reportSyntaxError(S.prevToken().endPos, "expected", tk); + nextToken(); } } Regards, bsrbnd From jonathan.gibbons at oracle.com Thu Jun 25 21:32:42 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 25 Jun 2015 14:32:42 -0700 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <558AACEB.8030006@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> <558AACEB.8030006@oracle.com> Message-ID: <558C737A.6010405@oracle.com> Looks good to me :-) -- Jon On 06/24/2015 06:13 AM, Jan Lahoda wrote: > Hello, > > After some offline discussions, I've somewhat changed the internal API > for plugging in the platforms (based on Jon's advices). An updated > webrev is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ > > How does this look? > > Thanks for all the comments! > > Jan > > On 2.6.2015 18:50, Jan Lahoda wrote: >> Hello Eric, >> >> Thanks for the change, this seems definitely better to me. I've folded >> your change that into my patch. An updated version (just langtools this >> time): >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ >> >> Thanks! >> >> Jan >> >> On 2.6.2015 16:04, Erik Joelsson wrote: >>> Hello Jan, >>> >>> Sorry to bother you with even more build changes, but with these file >>> moves, I realized that this new file, ct.sym, is really a part of the >>> jdk.compiler module and really not a special case at all. Because of >>> this, it should be generated as part of the jdk.compiler-gendata >>> target. >>> This also eliminates all the changes in the top level repo and only >>> leaves one new makefile in the langtools repo. >>> >>> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >>> >>> /Erik >>> >>> On 2015-06-01 17:56, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I made a somewhat bigger update (partially based on other feedback). >>>> Summary of changes: >>>> -the history data has been moved into langtools (I also moved the >>>> Ctsym.gmk) >>>> -there are JDK 6 data now >>>> -renamed the "-platform" option to "-release". Code/tests directly >>>> related to the option has been also changed as well. I kept the >>>> internal PlatformProvider API in javac as is, and also kept related >>>> code. >>>> -added a note that the is generated by >>>> CreateSymbols. >>>> >>>> Webrevs: >>>> top-level: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>>> langtools: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>>> >>>> Delta webrevs are also available. >>>> >>>> How does this look? >>>> >>>> Thanks for the comments so far! >>>> >>>> Jan >>>> >>>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>>> Ah, yes, I did not realize that. Thanks, will fix. >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>>> don't mention the fact that a side effect of the sym.txt >>>>>> generation is >>>>>> the mentioned earlier in the same >>>>>> comments >>>>>> (so one might wonder where does that come from). >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've uploaded another iteration, with these changes: >>>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>>> OpenJDK case). >>>>>>> -fixed a minor issue in CreateSymbols that could cause putting >>>>>>> class >>>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>>> change). >>>>>>> -jdk.management module has been split out from java.management >>>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>>> java.management and jdk.management as well. >>>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>>> >>>>>>> Webrevs: >>>>>>> -top-level: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>>> -langtools (no changes against the last webrev): >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>>> >>>>>>> Delta webrevs against the previous iteration are included under >>>>>>> "Author comments". >>>>>>> >>>>>>> Thanks for the comments so far! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>>> Excellent work. >>>>>>>>> >>>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>>> Probe >>>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>>> >>>>>>>>> /bin/java Probe --> classes-8 >>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>> >>>>>>>>> etc. >>>>>>>> >>>>>>>> Sure, will do. >>>>>>>> >>>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>>> descriptions >>>>>>>> automatically, per our offline discussion. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>>> top-level repository: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>>> langtools: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>>> >>>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>>> differences >>>>>>>>>> between .00 and .01 available - see the "Delta webrev" link >>>>>>>>>> under >>>>>>>>>> "Author's comments") >>>>>>>>>> >>>>>>>>>> Summary of changes: >>>>>>>>>> -applied Eric's build changes >>>>>>>>>> -moved CreateSymbols into >>>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>>> Hi Jan, >>>>>>>>>>> great work - couple of comments below: >>>>>>>>>>> >>>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>>> simplified >>>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>>> checkOptionAllowed >>>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>>> commonalities >>>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>>> this a >>>>>>>>>>> bit? >>>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>>> specified >>>>>>>>>>> and >>>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>>> that, >>>>>>>>>>> ignore the platform settings and issue a Lint 'options' >>>>>>>>>>> warning? >>>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>>> logic in >>>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>>> CreateSymbols >>>>>>>>>>> with >>>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>>> mean is >>>>>>>>>>> that >>>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>>> (i.e. 8) >>>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>>> that's the >>>>>>>>>>> use >>>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>>> order to >>>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>>> the >>>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>>> seem to be typically all >>>>>>>>>>> identical >>>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>>> Maybe >>>>>>>>>>> the >>>>>>>>>>> inference logic should be different (i.e. use 8 as a >>>>>>>>>>> baseline for >>>>>>>>>>> 7 and >>>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>>> should be >>>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or >>>>>>>>>>> are >>>>>>>>>>> there >>>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>>> >>>>>>>>>>> Maurizio >>>>>>>>>>> >>>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>>> >>>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>>> their >>>>>>>>>>>> prerequisite: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>>> effect as >>>>>>>>>>>> '-source N -target N -bootclasspath '. The >>>>>>>>>>>> possible >>>>>>>>>>>> values >>>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>>> correspond to >>>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>>> >>>>>>>>>>>> A tricky problem to solve is where to get the APIs for >>>>>>>>>>>> platform >>>>>>>>>>>> N. The >>>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>>> inside >>>>>>>>>>>> the >>>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>>> time >>>>>>>>>>>> and >>>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>>> javac >>>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>>> lib/ct.sym >>>>>>>>>>>> file. The input history data are placed >>>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>>> This >>>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>>> public >>>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>>> >>>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>>> checkout and >>>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>>> significantly >>>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>>> would >>>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>>> >>>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>>> them as >>>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>>> Code >>>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>>> named >>>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>>> bootclasspath >>>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>>> 'N' in >>>>>>>>>>>> their name. >>>>>>>>>>>> >>>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>>> Concise >>>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>>> >>>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>>> one >>>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>>> independent >>>>>>>>>>>> to a >>>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>>> and the >>>>>>>>>>>> top-level changes add the history data and ability to build >>>>>>>>>>>> the >>>>>>>>>>>> ct.sym >>>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>>> independently. >>>>>>>>>>>> >>>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>>> Alan >>>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>>> matter >>>>>>>>>>>> before. >>>>>>>>>>>> >>>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>> >>>>>> >>> From erik.joelsson at oracle.com Fri Jun 26 07:35:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 09:35:21 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DDEEC.2000505@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> Message-ID: <558D00B9.7090706@oracle.com> This looks good to me now. /Erik On 2015-06-02 18:50, Jan Lahoda wrote: > Hello Eric, > > Thanks for the change, this seems definitely better to me. I've folded > your change that into my patch. An updated version (just langtools > this time): > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ > > Thanks! > > Jan > > On 2.6.2015 16:04, Erik Joelsson wrote: >> Hello Jan, >> >> Sorry to bother you with even more build changes, but with these file >> moves, I realized that this new file, ct.sym, is really a part of the >> jdk.compiler module and really not a special case at all. Because of >> this, it should be generated as part of the jdk.compiler-gendata target. >> This also eliminates all the changes in the top level repo and only >> leaves one new makefile in the langtools repo. >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >> >> /Erik >> >> On 2015-06-01 17:56, Jan Lahoda wrote: >>> Hi, >>> >>> I made a somewhat bigger update (partially based on other feedback). >>> Summary of changes: >>> -the history data has been moved into langtools (I also moved the >>> Ctsym.gmk) >>> -there are JDK 6 data now >>> -renamed the "-platform" option to "-release". Code/tests directly >>> related to the option has been also changed as well. I kept the >>> internal PlatformProvider API in javac as is, and also kept related >>> code. >>> -added a note that the is generated by >>> CreateSymbols. >>> >>> Webrevs: >>> top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>> langtools: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>> >>> Delta webrevs are also available. >>> >>> How does this look? >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>> Ah, yes, I did not realize that. Thanks, will fix. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>> don't mention the fact that a side effect of the sym.txt >>>>> generation is >>>>> the mentioned earlier in the same >>>>> comments >>>>> (so one might wonder where does that come from). >>>>> >>>>> Maurizio >>>>> >>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded another iteration, with these changes: >>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>> OpenJDK case). >>>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>> change). >>>>>> -jdk.management module has been split out from java.management >>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>> java.management and jdk.management as well. >>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>> >>>>>> Webrevs: >>>>>> -top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>> -langtools (no changes against the last webrev): >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>> >>>>>> Delta webrevs against the previous iteration are included under >>>>>> "Author comments". >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>> Excellent work. >>>>>>>> >>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>> Probe >>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>> >>>>>>>> /bin/java Probe --> classes-8 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> >>>>>>>> etc. >>>>>>> >>>>>>> Sure, will do. >>>>>>> >>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>> descriptions >>>>>>> automatically, per our offline discussion. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>> top-level repository: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>> langtools: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>> >>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>> differences >>>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>>> "Author's comments") >>>>>>>>> >>>>>>>>> Summary of changes: >>>>>>>>> -applied Eric's build changes >>>>>>>>> -moved CreateSymbols into >>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> great work - couple of comments below: >>>>>>>>>> >>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>> simplified >>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>> checkOptionAllowed >>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>> commonalities >>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>> this a >>>>>>>>>> bit? >>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>> specified >>>>>>>>>> and >>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>> that, >>>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>> logic in >>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>> CreateSymbols >>>>>>>>>> with >>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>> mean is >>>>>>>>>> that >>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>> (i.e. 8) >>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>> that's the >>>>>>>>>> use >>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>> order to >>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>> the >>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>> seem to be typically all >>>>>>>>>> identical >>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>> Maybe >>>>>>>>>> the >>>>>>>>>> inference logic should be different (i.e. use 8 as a baseline >>>>>>>>>> for >>>>>>>>>> 7 and >>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>> should be >>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>>> there >>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>> >>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>> their >>>>>>>>>>> prerequisite: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>> effect as >>>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>>> values >>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>> correspond to >>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>> >>>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>>> N. The >>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>> inside >>>>>>>>>>> the >>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>> time >>>>>>>>>>> and >>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>> javac >>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>> lib/ct.sym >>>>>>>>>>> file. The input history data are placed >>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>> This >>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>> public >>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>> >>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>> checkout and >>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>> significantly >>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>> would >>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>> >>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>> them as >>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>> Code >>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>> named >>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>> bootclasspath >>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>> 'N' in >>>>>>>>>>> their name. >>>>>>>>>>> >>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>> Concise >>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> I am sending this as one review, as the changes together >>>>>>>>>>> make one >>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>> independent >>>>>>>>>>> to a >>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>> and the >>>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>>> ct.sym >>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>> independently. >>>>>>>>>>> >>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>> Alan >>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>> matter >>>>>>>>>>> before. >>>>>>>>>>> >>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>> >>>>>>>> >>>>> >> From maurizio.cimadamore at oracle.com Fri Jun 26 09:49:49 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 26 Jun 2015 10:49:49 +0100 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <558C737A.6010405@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> <558AACEB.8030006@oracle.com> <558C737A.6010405@oracle.com> Message-ID: <558D203D.7090205@oracle.com> Looks good to me too; I like the name choice of the new Provider/Description pair. Maurizio On 25/06/15 22:32, Jonathan Gibbons wrote: > Looks good to me :-) > > -- Jon > > On 06/24/2015 06:13 AM, Jan Lahoda wrote: >> Hello, >> >> After some offline discussions, I've somewhat changed the internal >> API for plugging in the platforms (based on Jon's advices). An >> updated webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ >> >> How does this look? >> >> Thanks for all the comments! >> >> Jan >> >> On 2.6.2015 18:50, Jan Lahoda wrote: >>> Hello Eric, >>> >>> Thanks for the change, this seems definitely better to me. I've folded >>> your change that into my patch. An updated version (just langtools this >>> time): >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ >>> >>> Thanks! >>> >>> Jan >>> >>> On 2.6.2015 16:04, Erik Joelsson wrote: >>>> Hello Jan, >>>> >>>> Sorry to bother you with even more build changes, but with these file >>>> moves, I realized that this new file, ct.sym, is really a part of the >>>> jdk.compiler module and really not a special case at all. Because of >>>> this, it should be generated as part of the jdk.compiler-gendata >>>> target. >>>> This also eliminates all the changes in the top level repo and only >>>> leaves one new makefile in the langtools repo. >>>> >>>> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >>>> >>>> /Erik >>>> >>>> On 2015-06-01 17:56, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I made a somewhat bigger update (partially based on other feedback). >>>>> Summary of changes: >>>>> -the history data has been moved into langtools (I also moved the >>>>> Ctsym.gmk) >>>>> -there are JDK 6 data now >>>>> -renamed the "-platform" option to "-release". Code/tests directly >>>>> related to the option has been also changed as well. I kept the >>>>> internal PlatformProvider API in javac as is, and also kept related >>>>> code. >>>>> -added a note that the is generated by >>>>> CreateSymbols. >>>>> >>>>> Webrevs: >>>>> top-level: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>>>> langtools: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>>>> >>>>> Delta webrevs are also available. >>>>> >>>>> How does this look? >>>>> >>>>> Thanks for the comments so far! >>>>> >>>>> Jan >>>>> >>>>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>>>> Ah, yes, I did not realize that. Thanks, will fix. >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>>> >>>>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>>>> don't mention the fact that a side effect of the sym.txt >>>>>>> generation is >>>>>>> the mentioned earlier in the same >>>>>>> comments >>>>>>> (so one might wonder where does that come from). >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've uploaded another iteration, with these changes: >>>>>>>> -the "symbols" file is now generated automatically (for the >>>>>>>> typical >>>>>>>> OpenJDK case). >>>>>>>> -fixed a minor issue in CreateSymbols that could cause putting >>>>>>>> class >>>>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>>>> change). >>>>>>>> -jdk.management module has been split out from java.management >>>>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>>>> java.management and jdk.management as well. >>>>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>>>> >>>>>>>> Webrevs: >>>>>>>> -top-level: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>>>> -langtools (no changes against the last webrev): >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>>>> >>>>>>>> Delta webrevs against the previous iteration are included under >>>>>>>> "Author comments". >>>>>>>> >>>>>>>> Thanks for the comments so far! >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>>>> Excellent work. >>>>>>>>>> >>>>>>>>>> I think the comment in CreateSymbols could be made clearer >>>>>>>>>> w.r.t. >>>>>>>>>> Probe >>>>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>>>> >>>>>>>>>> /bin/java Probe --> classes-8 >>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>> >>>>>>>>>> etc. >>>>>>>>> >>>>>>>>> Sure, will do. >>>>>>>>> >>>>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>>>> descriptions >>>>>>>>> automatically, per our offline discussion. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>>>> top-level repository: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>>>> >>>>>>>>>>> langtools: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>>>> differences >>>>>>>>>>> between .00 and .01 available - see the "Delta webrev" link >>>>>>>>>>> under >>>>>>>>>>> "Author's comments") >>>>>>>>>>> >>>>>>>>>>> Summary of changes: >>>>>>>>>>> -applied Eric's build changes >>>>>>>>>>> -moved CreateSymbols into >>>>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> great work - couple of comments below: >>>>>>>>>>>> >>>>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>>>> simplified >>>>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>>>> checkOptionAllowed >>>>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>>>> commonalities >>>>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>>>> this a >>>>>>>>>>>> bit? >>>>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>>>> specified >>>>>>>>>>>> and >>>>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>>>> that, >>>>>>>>>>>> ignore the platform settings and issue a Lint 'options' >>>>>>>>>>>> warning? >>>>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>>>> logic in >>>>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>>>> CreateSymbols >>>>>>>>>>>> with >>>>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>>>> mean is >>>>>>>>>>>> that >>>>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>>>> (i.e. 8) >>>>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>>>> that's the >>>>>>>>>>>> use >>>>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>>>> order to >>>>>>>>>>>> explicitly state which of the platform is the baseline one, >>>>>>>>>>>> and >>>>>>>>>>>> the >>>>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>>>> seem to be typically all >>>>>>>>>>>> identical >>>>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>>>> Maybe >>>>>>>>>>>> the >>>>>>>>>>>> inference logic should be different (i.e. use 8 as a >>>>>>>>>>>> baseline for >>>>>>>>>>>> 7 and >>>>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>>>> should be >>>>>>>>>>>> chosen once and for all, and live implicitly in the tool? >>>>>>>>>>>> Or are >>>>>>>>>>>> there >>>>>>>>>>>> reasons as to why it might be handy to customize the >>>>>>>>>>>> baselines? >>>>>>>>>>>> >>>>>>>>>>>> Maurizio >>>>>>>>>>>> >>>>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>>>> >>>>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>>>> their >>>>>>>>>>>>> prerequisite: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>>>> effect as >>>>>>>>>>>>> '-source N -target N -bootclasspath '. The >>>>>>>>>>>>> possible >>>>>>>>>>>>> values >>>>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>>>> correspond to >>>>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>>>> >>>>>>>>>>>>> A tricky problem to solve is where to get the APIs for >>>>>>>>>>>>> platform >>>>>>>>>>>>> N. The >>>>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>>>> inside >>>>>>>>>>>>> the >>>>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>>>> time >>>>>>>>>>>>> and >>>>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>>>> javac >>>>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>>>> lib/ct.sym >>>>>>>>>>>>> file. The input history data are placed >>>>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>>>> This >>>>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>>>> public >>>>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>>>> >>>>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>>>> checkout and >>>>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>>>> significantly >>>>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>>>> would >>>>>>>>>>>>> need to be included). The lib/ct.sym file is currently >>>>>>>>>>>>> ~4.5MB. >>>>>>>>>>>>> >>>>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>>>> them as >>>>>>>>>>>>> classfiles), but are missing some attributes, most notably >>>>>>>>>>>>> the >>>>>>>>>>>>> Code >>>>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>>>> named >>>>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>>>> bootclasspath >>>>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>>>> 'N' in >>>>>>>>>>>>> their name. >>>>>>>>>>>>> >>>>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The same file can also be used to construct the sym.txt >>>>>>>>>>>>> files. >>>>>>>>>>>>> Concise >>>>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>>>> >>>>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>>>> one >>>>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>>>> independent >>>>>>>>>>>>> to a >>>>>>>>>>>>> great degree: the langtools changes add the "-platform" >>>>>>>>>>>>> javac; >>>>>>>>>>>>> and the >>>>>>>>>>>>> top-level changes add the history data and ability to >>>>>>>>>>>>> build the >>>>>>>>>>>>> ct.sym >>>>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>>>> independently. >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>>>> Alan >>>>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>>>> matter >>>>>>>>>>>>> before. >>>>>>>>>>>>> >>>>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>> > From jan.lahoda at oracle.com Fri Jun 26 13:20:34 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jun 2015 15:20:34 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <558D203D.7090205@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> <558AACEB.8030006@oracle.com> <558C737A.6010405@oracle.com> <558D203D.7090205@oracle.com> Message-ID: <558D51A2.7000706@oracle.com> Based on additional Jon's feedback, I made some minor tweaks to the patch. An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.06/langtools/ A delta webrev is available under "Author comments". Unless there are objections, I'll work on pushing this to jdk9/dev. Thanks for all the comments! Jan On 26.6.2015 11:49, Maurizio Cimadamore wrote: > Looks good to me too; I like the name choice of the new > Provider/Description pair. > > Maurizio > > On 25/06/15 22:32, Jonathan Gibbons wrote: >> Looks good to me :-) >> >> -- Jon >> >> On 06/24/2015 06:13 AM, Jan Lahoda wrote: >>> Hello, >>> >>> After some offline discussions, I've somewhat changed the internal >>> API for plugging in the platforms (based on Jon's advices). An >>> updated webrev is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ >>> >>> How does this look? >>> >>> Thanks for all the comments! >>> >>> Jan >>> >>> On 2.6.2015 18:50, Jan Lahoda wrote: >>>> Hello Eric, >>>> >>>> Thanks for the change, this seems definitely better to me. I've folded >>>> your change that into my patch. An updated version (just langtools this >>>> time): >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ >>>> >>>> Thanks! >>>> >>>> Jan >>>> >>>> On 2.6.2015 16:04, Erik Joelsson wrote: >>>>> Hello Jan, >>>>> >>>>> Sorry to bother you with even more build changes, but with these file >>>>> moves, I realized that this new file, ct.sym, is really a part of the >>>>> jdk.compiler module and really not a special case at all. Because of >>>>> this, it should be generated as part of the jdk.compiler-gendata >>>>> target. >>>>> This also eliminates all the changes in the top level repo and only >>>>> leaves one new makefile in the langtools repo. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >>>>> >>>>> /Erik >>>>> >>>>> On 2015-06-01 17:56, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I made a somewhat bigger update (partially based on other feedback). >>>>>> Summary of changes: >>>>>> -the history data has been moved into langtools (I also moved the >>>>>> Ctsym.gmk) >>>>>> -there are JDK 6 data now >>>>>> -renamed the "-platform" option to "-release". Code/tests directly >>>>>> related to the option has been also changed as well. I kept the >>>>>> internal PlatformProvider API in javac as is, and also kept related >>>>>> code. >>>>>> -added a note that the is generated by >>>>>> CreateSymbols. >>>>>> >>>>>> Webrevs: >>>>>> top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>>>>> langtools: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>>>>> >>>>>> Delta webrevs are also available. >>>>>> >>>>>> How does this look? >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>>>>> Ah, yes, I did not realize that. Thanks, will fix. >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>>> >>>>>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>>>>> don't mention the fact that a side effect of the sym.txt >>>>>>>> generation is >>>>>>>> the mentioned earlier in the same >>>>>>>> comments >>>>>>>> (so one might wonder where does that come from). >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded another iteration, with these changes: >>>>>>>>> -the "symbols" file is now generated automatically (for the >>>>>>>>> typical >>>>>>>>> OpenJDK case). >>>>>>>>> -fixed a minor issue in CreateSymbols that could cause putting >>>>>>>>> class >>>>>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>>>>> change). >>>>>>>>> -jdk.management module has been split out from java.management >>>>>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>>>>> java.management and jdk.management as well. >>>>>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>>>>> >>>>>>>>> Webrevs: >>>>>>>>> -top-level: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>>>>> -langtools (no changes against the last webrev): >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>>>>> >>>>>>>>> Delta webrevs against the previous iteration are included under >>>>>>>>> "Author comments". >>>>>>>>> >>>>>>>>> Thanks for the comments so far! >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>>>>> Excellent work. >>>>>>>>>>> >>>>>>>>>>> I think the comment in CreateSymbols could be made clearer >>>>>>>>>>> w.r.t. >>>>>>>>>>> Probe >>>>>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>>>>> >>>>>>>>>>> /bin/java Probe --> classes-8 >>>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>>> >>>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> Sure, will do. >>>>>>>>>> >>>>>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>>>>> descriptions >>>>>>>>>> automatically, per our offline discussion. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Maurizio >>>>>>>>>>> >>>>>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>>>>> top-level repository: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>>>>> >>>>>>>>>>>> langtools: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>>>>> differences >>>>>>>>>>>> between .00 and .01 available - see the "Delta webrev" link >>>>>>>>>>>> under >>>>>>>>>>>> "Author's comments") >>>>>>>>>>>> >>>>>>>>>>>> Summary of changes: >>>>>>>>>>>> -applied Eric's build changes >>>>>>>>>>>> -moved CreateSymbols into >>>>>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>> great work - couple of comments below: >>>>>>>>>>>>> >>>>>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>>>>> simplified >>>>>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>>>>> checkOptionAllowed >>>>>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>>>>> commonalities >>>>>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>>>>> this a >>>>>>>>>>>>> bit? >>>>>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>>>>> specified >>>>>>>>>>>>> and >>>>>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>>>>> that, >>>>>>>>>>>>> ignore the platform settings and issue a Lint 'options' >>>>>>>>>>>>> warning? >>>>>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>>>>> logic in >>>>>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>>>>> CreateSymbols >>>>>>>>>>>>> with >>>>>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>>>>> mean is >>>>>>>>>>>>> that >>>>>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>>>>> (i.e. 8) >>>>>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>>>>> that's the >>>>>>>>>>>>> use >>>>>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>>>>> order to >>>>>>>>>>>>> explicitly state which of the platform is the baseline one, >>>>>>>>>>>>> and >>>>>>>>>>>>> the >>>>>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>>>>> seem to be typically all >>>>>>>>>>>>> identical >>>>>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>>>>> Maybe >>>>>>>>>>>>> the >>>>>>>>>>>>> inference logic should be different (i.e. use 8 as a >>>>>>>>>>>>> baseline for >>>>>>>>>>>>> 7 and >>>>>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>>>>> should be >>>>>>>>>>>>> chosen once and for all, and live implicitly in the tool? >>>>>>>>>>>>> Or are >>>>>>>>>>>>> there >>>>>>>>>>>>> reasons as to why it might be handy to customize the >>>>>>>>>>>>> baselines? >>>>>>>>>>>>> >>>>>>>>>>>>> Maurizio >>>>>>>>>>>>> >>>>>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>>>>> their >>>>>>>>>>>>>> prerequisite: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>>>>> effect as >>>>>>>>>>>>>> '-source N -target N -bootclasspath '. The >>>>>>>>>>>>>> possible >>>>>>>>>>>>>> values >>>>>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>>>>> correspond to >>>>>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A tricky problem to solve is where to get the APIs for >>>>>>>>>>>>>> platform >>>>>>>>>>>>>> N. The >>>>>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>>>>> inside >>>>>>>>>>>>>> the >>>>>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>>>>> time >>>>>>>>>>>>>> and >>>>>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>>>>> javac >>>>>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>>>>> lib/ct.sym >>>>>>>>>>>>>> file. The input history data are placed >>>>>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>>>>> This >>>>>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>>>>> public >>>>>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>>>>> checkout and >>>>>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>>>>> significantly >>>>>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>>>>> would >>>>>>>>>>>>>> need to be included). The lib/ct.sym file is currently >>>>>>>>>>>>>> ~4.5MB. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>>>>> them as >>>>>>>>>>>>>> classfiles), but are missing some attributes, most notably >>>>>>>>>>>>>> the >>>>>>>>>>>>>> Code >>>>>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>>>>> named >>>>>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>>>>> bootclasspath >>>>>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>>>>> 'N' in >>>>>>>>>>>>>> their name. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The same file can also be used to construct the sym.txt >>>>>>>>>>>>>> files. >>>>>>>>>>>>>> Concise >>>>>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>>>>> one >>>>>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>>>>> independent >>>>>>>>>>>>>> to a >>>>>>>>>>>>>> great degree: the langtools changes add the "-platform" >>>>>>>>>>>>>> javac; >>>>>>>>>>>>>> and the >>>>>>>>>>>>>> top-level changes add the history data and ability to >>>>>>>>>>>>>> build the >>>>>>>>>>>>>> ct.sym >>>>>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>>>>> independently. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>>>>> Alan >>>>>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>>>>> matter >>>>>>>>>>>>>> before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Jan >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>> >> > From maurizio.cimadamore at oracle.com Mon Jun 29 13:27:58 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Jun 2015 14:27:58 +0100 Subject: [PATCH] 8081769: Redundant error message on bad usage of class literal In-Reply-To: References: Message-ID: <559147DE.1030404@oracle.com> Thanks - this looks solid; I will double check the patch, run all required tests and integrate it (if all test pass :-)) Regards Maurizio On 25/06/15 15:58, bsrbnd wrote: > Hi, > > as described in issue 8081769, the following code produces two errors > instead of one plus a wrong end of file error. > > public class BadClassLiteral { > public static void method() { > Class c1 = this.class; > } > } > > BadClassLiteral.java:3: error: expected > Class c1 = this.class; > ^ > BadClassLiteral.java:3: error: expected > Class c1 = this.class; > ^ > BadClassLiteral.java:5: error: reached end of file while parsing > } > ^ > 3 errors > > While the first error is ok, the second and third errors occured > because the parser goes on with a class definition starting with the > "class" token. > Method JavacParser.accept(TokenKind) should skip next token ("class" > in this case) even if an error occurs, as follows (jdk 9): > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > @@ -485,6 +485,7 @@ > } else { > setErrorEndPos(token.pos); > reportSyntaxError(S.prevToken().endPos, "expected", tk); > + nextToken(); > } > } > > Regards, > > bsrbnd From maurizio.cimadamore at oracle.com Mon Jun 29 13:29:19 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Jun 2015 14:29:19 +0100 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <55896261.9040505@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> <55896261.9040505@oracle.com> Message-ID: <5591482F.4010106@oracle.com> I've closed it as 'not an issue' - this seems to be an outstanding issue that was fixed for some time and then reverted because of compatibility problems: https://bugs.openjdk.java.net/browse/JDK-6520152 Maurizio On 23/06/15 14:42, Georgiy Rakov wrote: > I've filed the issue JDK-8129576. > > > There is following issue in JBS: JDK-4777101 > which seems to > relate to this one. > > Thank you, > Georgiy. > > On 22.06.2015 18:56, Victor Rudometov wrote: >> This seems to be a reflection bug, since ACC_FINAL is present in >> Test12$1.class file: >> >> final class test.Test12$1 extends test.Test12$Foo >> minor version: 0 >> major version: 52 >> flags: ACC_FINAL, ACC_SUPER >> >> Thanks. >> Victor. >> >> On 22-Jun-15 18:35, Remi Forax wrote: >>> I wonder if it's not a reflection bug, >>> did you check with 'javap -c -verbose' the modifiers of the >>> generated class (something like Test12$1.class) ? >>> >>> cheers, >>> R?mi >>> >>> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>>> Hello, >>>> >>>> if I understand correctly according to following assertion from JLS >>>> 15.9.5 anonymous classes are always final: >>>> >>>> An anonymous class is always implicitly final (?8.1.1.2). >>>> >>>> But reflection API reports that the class is not final. Namely >>>> let's consider following code: >>>> >>>> import java.lang.reflect.Modifier; >>>> >>>> public class Test12 { >>>> static class Foo {} >>>> >>>> public static void main(String argv[]) { >>>> Foo foo = new Foo<>() {}; >>>> if ( (foo.getClass().getModifiers() & Modifier.FINAL) >>>> != 0 ) { >>>> System.out.println("final, modifiers: " + >>>> foo.getClass().getModifiers()); >>>> } else { >>>> System.out.println("not final, modifiers: " + >>>> foo.getClass().getModifiers()); >>>> } >>>> } >>>> } >>>> >>>> On JDK9b69 it reports: >>>> >>>> not final, modifiers: 0 >>>> >>>> Could you please tell if you consider this as a discrepancy between >>>> spec and javac (VM?) which should be fixed. >>>> >>>> Thank you, >>>> Georgiy. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Jun 29 13:36:20 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 29 Jun 2015 15:36:20 +0200 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <5591482F.4010106@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> <55896261.9040505@oracle.com> <5591482F.4010106@oracle.com> Message-ID: <559149D4.4020406@univ-mlv.fr> yes, right, it seems to be a backward compatibility land of mines. R?mi On 06/29/2015 03:29 PM, Maurizio Cimadamore wrote: > I've closed it as 'not an issue' - this seems to be an outstanding > issue that was fixed for some time and then reverted because of > compatibility problems: > > https://bugs.openjdk.java.net/browse/JDK-6520152 > > Maurizio > > On 23/06/15 14:42, Georgiy Rakov wrote: >> I've filed the issue JDK-8129576. >> >> >> There is following issue in JBS: JDK-4777101 >> which seems to >> relate to this one. >> >> Thank you, >> Georgiy. >> >> On 22.06.2015 18:56, Victor Rudometov wrote: >>> This seems to be a reflection bug, since ACC_FINAL is present in >>> Test12$1.class file: >>> >>> final class test.Test12$1 extends test.Test12$Foo >>> minor version: 0 >>> major version: 52 >>> flags: ACC_FINAL, ACC_SUPER >>> >>> Thanks. >>> Victor. >>> >>> On 22-Jun-15 18:35, Remi Forax wrote: >>>> I wonder if it's not a reflection bug, >>>> did you check with 'javap -c -verbose' the modifiers of the >>>> generated class (something like Test12$1.class) ? >>>> >>>> cheers, >>>> R?mi >>>> >>>> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>>>> Hello, >>>>> >>>>> if I understand correctly according to following assertion from >>>>> JLS 15.9.5 anonymous classes are always final: >>>>> >>>>> An anonymous class is always implicitly final (?8.1.1.2). >>>>> >>>>> But reflection API reports that the class is not final. Namely >>>>> let's consider following code: >>>>> >>>>> import java.lang.reflect.Modifier; >>>>> >>>>> public class Test12 { >>>>> static class Foo {} >>>>> >>>>> public static void main(String argv[]) { >>>>> Foo foo = new Foo<>() {}; >>>>> if ( (foo.getClass().getModifiers() & Modifier.FINAL) >>>>> != 0 ) { >>>>> System.out.println("final, modifiers: " + >>>>> foo.getClass().getModifiers()); >>>>> } else { >>>>> System.out.println("not final, modifiers: " + >>>>> foo.getClass().getModifiers()); >>>>> } >>>>> } >>>>> } >>>>> >>>>> On JDK9b69 it reports: >>>>> >>>>> not final, modifiers: 0 >>>>> >>>>> Could you please tell if you consider this as a discrepancy >>>>> between spec and javac (VM?) which should be fixed. >>>>> >>>>> Thank you, >>>>> Georgiy. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Mon Jun 29 13:49:33 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 29 Jun 2015 15:49:33 +0200 Subject: Bad interaction between wildcard and functional interface conversion In-Reply-To: <5565E2C9.7050009@univ-mlv.fr> References: <5565E2C9.7050009@univ-mlv.fr> Message-ID: <55914CED.4080803@univ-mlv.fr> Bitten again by the very same issue :( The following code doesn't compile: static Function factory(Consumer> consumer, Function ifAbsent) { HashMap map = new HashMap<>(); consumer.accept(map::put); return key -> map.computeIfAbsent(key, ifAbsent); } I really think that it's a serious bug, the only workaround is to not use wildcards correctly, i.e. Function factory(Consumer> consumer, Function ifAbsent) cheers, R?mi On 05/27/2015 05:29 PM, Remi Forax wrote: > Hi all, > > The way the conversion between a lambda (or a method reference) and a > functional interface is specified doesn't take wildcard (exactly ? > super) into account making the concept of contravariance of functional > interface less intuitive that it should be. > > The following code compiles: > private static void create(Consumer> consumer) { > consumer.accept(s -> System.out.println(s)); > } > > This one doesn't compile because "? super Consumer" is > not a functional interface: > private static void create2(Consumer String>> consumer) { > consumer.accept(s -> System.out.println(s)); > } > > The workaround is to introduce a cast :( > private static void create3(Consumer String>> consumer) { > consumer.accept((Consumer)s -> System.out.println(s)); > } > which is stupid in this case because there is no ambiguity. > This cast is just here because the JLS doesn't consider that ? super > Consumer<...> is a valid target type > > IMO, this bug is very similar to JDK-6964923 and i think the spec > should be changed to allow ? super Foo to be a valid target type for a > lambda conversion (obviously if Foo is a functional interface). > > regards, > R?mi > From maurizio.cimadamore at oracle.com Mon Jun 29 13:49:50 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Jun 2015 14:49:50 +0100 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <559149D4.4020406@univ-mlv.fr> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> <55896261.9040505@oracle.com> <5591482F.4010106@oracle.com> <559149D4.4020406@univ-mlv.fr> Message-ID: <55914CFE.6090103@oracle.com> More specifically, I was talking about this related issue: https://bugs.openjdk.java.net/browse/JDK-8130032 Popping back one level, I think the issue you are seeing there, is that ACC_FINAL is erroneosuly set by javac for diamond anon classes. This seems to be against all the documentation that can be found on JBS = example: https://bugs.openjdk.java.net/browse/JDK-8023945 I seem to be able to get javac spit out ACC_FINAL reliably on JDK 7/8/9 - so the question is - when did it come back? Was it deliberate? If so, was reflection ever updated to handle this? Maurizio On 29/06/15 14:36, Remi Forax wrote: > yes, right, > it seems to be a backward compatibility land of mines. > > R?mi > > On 06/29/2015 03:29 PM, Maurizio Cimadamore wrote: >> I've closed it as 'not an issue' - this seems to be an outstanding >> issue that was fixed for some time and then reverted because of >> compatibility problems: >> >> https://bugs.openjdk.java.net/browse/JDK-6520152 >> >> Maurizio >> >> On 23/06/15 14:42, Georgiy Rakov wrote: >>> I've filed the issue JDK-8129576. >>> >>> >>> There is following issue in JBS: JDK-4777101 >>> which seems to >>> relate to this one. >>> >>> Thank you, >>> Georgiy. >>> >>> On 22.06.2015 18:56, Victor Rudometov wrote: >>>> This seems to be a reflection bug, since ACC_FINAL is present in >>>> Test12$1.class file: >>>> >>>> final class test.Test12$1 extends test.Test12$Foo >>>> minor version: 0 >>>> major version: 52 >>>> flags: ACC_FINAL, ACC_SUPER >>>> >>>> Thanks. >>>> Victor. >>>> >>>> On 22-Jun-15 18:35, Remi Forax wrote: >>>>> I wonder if it's not a reflection bug, >>>>> did you check with 'javap -c -verbose' the modifiers of the >>>>> generated class (something like Test12$1.class) ? >>>>> >>>>> cheers, >>>>> R?mi >>>>> >>>>> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>>>>> Hello, >>>>>> >>>>>> if I understand correctly according to following assertion from >>>>>> JLS 15.9.5 anonymous classes are always final: >>>>>> >>>>>> An anonymous class is always implicitly final (?8.1.1.2). >>>>>> >>>>>> But reflection API reports that the class is not final. Namely >>>>>> let's consider following code: >>>>>> >>>>>> import java.lang.reflect.Modifier; >>>>>> >>>>>> public class Test12 { >>>>>> static class Foo {} >>>>>> >>>>>> public static void main(String argv[]) { >>>>>> Foo foo = new Foo<>() {}; >>>>>> if ( (foo.getClass().getModifiers() & Modifier.FINAL) >>>>>> != 0 ) { >>>>>> System.out.println("final, modifiers: " + >>>>>> foo.getClass().getModifiers()); >>>>>> } else { >>>>>> System.out.println("not final, modifiers: " + >>>>>> foo.getClass().getModifiers()); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> On JDK9b69 it reports: >>>>>> >>>>>> not final, modifiers: 0 >>>>>> >>>>>> Could you please tell if you consider this as a discrepancy >>>>>> between spec and javac (VM?) which should be fixed. >>>>>> >>>>>> Thank you, >>>>>> Georgiy. >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jun 29 13:57:43 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 29 Jun 2015 14:57:43 +0100 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <55914CFE.6090103@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> <55896261.9040505@oracle.com> <5591482F.4010106@oracle.com> <559149D4.4020406@univ-mlv.fr> <55914CFE.6090103@oracle.com> Message-ID: <55914ED7.9070306@oracle.com> Ouch. It seems like this problem existed for a very long time; the logic used to strip away the ACC_FINAL flag from anon classes is more or less like this: if (c.isInner() && c.name.isEmpty()) { flags &= ~FINAL; } Now, isInner() will only return true _if the class has an enclosing instance_ which is clearly not the case if an anon class appears in a static context. In other words: class Test{ void finalNo() { new Object() { }; //ACC_FINAL not set } static void finalYesy() { new Object() { }; //ACC_FINAL set here } } javap Test\$1.class Compiled from "Main.java" class Test$1 { final Test this$0; Test$1(Test); } javap Test\$2.class Compiled from "Main.java" *final* class Test$2 { Test$2(); } I think this should be fixed so that anon classes (regardless of their context) always have their ACC_FINAL bit unset; this is probably not very hot from a compatibility perspective (given that it's been like that for a long time) - but, given the consistency issue and the fact that reflection cannot handle this anyway, I'd say we should just make this consistent. Thoughts? Maurizio On 29/06/15 14:49, Maurizio Cimadamore wrote: > More specifically, I was talking about this related issue: > > https://bugs.openjdk.java.net/browse/JDK-8130032 > > Popping back one level, I think the issue you are seeing there, is > that ACC_FINAL is erroneosuly set by javac for diamond anon classes. > This seems to be against all the documentation that can be found on > JBS = example: > > https://bugs.openjdk.java.net/browse/JDK-8023945 > > I seem to be able to get javac spit out ACC_FINAL reliably on JDK > 7/8/9 - so the question is - when did it come back? Was it deliberate? > If so, was reflection ever updated to handle this? > > Maurizio > > On 29/06/15 14:36, Remi Forax wrote: >> yes, right, >> it seems to be a backward compatibility land of mines. >> >> R?mi >> >> On 06/29/2015 03:29 PM, Maurizio Cimadamore wrote: >>> I've closed it as 'not an issue' - this seems to be an outstanding >>> issue that was fixed for some time and then reverted because of >>> compatibility problems: >>> >>> https://bugs.openjdk.java.net/browse/JDK-6520152 >>> >>> Maurizio >>> >>> On 23/06/15 14:42, Georgiy Rakov wrote: >>>> I've filed the issue JDK-8129576. >>>> >>>> >>>> There is following issue in JBS: JDK-4777101 >>>> which seems to >>>> relate to this one. >>>> >>>> Thank you, >>>> Georgiy. >>>> >>>> On 22.06.2015 18:56, Victor Rudometov wrote: >>>>> This seems to be a reflection bug, since ACC_FINAL is present in >>>>> Test12$1.class file: >>>>> >>>>> final class test.Test12$1 extends test.Test12$Foo >>>>> minor version: 0 >>>>> major version: 52 >>>>> flags: ACC_FINAL, ACC_SUPER >>>>> >>>>> Thanks. >>>>> Victor. >>>>> >>>>> On 22-Jun-15 18:35, Remi Forax wrote: >>>>>> I wonder if it's not a reflection bug, >>>>>> did you check with 'javap -c -verbose' the modifiers of the >>>>>> generated class (something like Test12$1.class) ? >>>>>> >>>>>> cheers, >>>>>> R?mi >>>>>> >>>>>> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> if I understand correctly according to following assertion from >>>>>>> JLS 15.9.5 anonymous classes are always final: >>>>>>> >>>>>>> An anonymous class is always implicitly final (?8.1.1.2). >>>>>>> >>>>>>> But reflection API reports that the class is not final. Namely >>>>>>> let's consider following code: >>>>>>> >>>>>>> import java.lang.reflect.Modifier; >>>>>>> >>>>>>> public class Test12 { >>>>>>> static class Foo {} >>>>>>> >>>>>>> public static void main(String argv[]) { >>>>>>> Foo foo = new Foo<>() {}; >>>>>>> if ( (foo.getClass().getModifiers() & >>>>>>> Modifier.FINAL) != 0 ) { >>>>>>> System.out.println("final, modifiers: " + >>>>>>> foo.getClass().getModifiers()); >>>>>>> } else { >>>>>>> System.out.println("not final, modifiers: " + >>>>>>> foo.getClass().getModifiers()); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> On JDK9b69 it reports: >>>>>>> >>>>>>> not final, modifiers: 0 >>>>>>> >>>>>>> Could you please tell if you consider this as a discrepancy >>>>>>> between spec and javac (VM?) which should be fixed. >>>>>>> >>>>>>> Thank you, >>>>>>> Georgiy. >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikanth.adayapalam at oracle.com Mon Jun 29 15:00:09 2015 From: srikanth.adayapalam at oracle.com (Srikanth) Date: Mon, 29 Jun 2015 20:30:09 +0530 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <55914ED7.9070306@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> <55896261.9040505@oracle.com> <5591482F.4010106@oracle.com> <559149D4.4020406@univ-mlv.fr> <55914CFE.6090103@oracle.com> <55914ED7.9070306@oracle.com> Message-ID: <55915D79.4000304@oracle.com> On Monday 29 June 2015 07:27 PM, Maurizio Cimadamore wrote: > Ouch. It seems like this problem existed for a very long time; the > logic used to strip away the ACC_FINAL flag from anon classes is more > or less like this: > > if (c.isInner() && c.name.isEmpty()) { > flags &= ~FINAL; > } > > Now, isInner() will only return true _if the class has an enclosing > instance_ which is clearly not the case if an anon class appears in a > static context. > > In other words: > > class Test{ > void finalNo() { > new Object() { }; //ACC_FINAL not set > } > > static void finalYesy() { > new Object() { }; //ACC_FINAL set here > } > } > > javap Test\$1.class > Compiled from "Main.java" > class Test$1 { > final Test this$0; > Test$1(Test); > } > > javap Test\$2.class > Compiled from "Main.java" > *final* class Test$2 { > Test$2(); > } > > I think this should be fixed so that anon classes (regardless of their > context) always have their ACC_FINAL bit unset; this is probably not > very hot from a compatibility perspective (given that it's been like > that for a long time) - but, given the consistency issue and the fact > that reflection cannot handle this anyway, I'd say we should just make > this consistent. > > Thoughts? Alex's comment in https://bugs.openjdk.java.net/browse/JDK-4777101, calls out that for anonymous classes declared in static context this bit is set but *seems* to take a position of leaving that as it is - Don't know why. I also have https://bugs.openjdk.java.net/browse/JDK-8129576 against my name which should closed as not an issue. Here is a query for ACC_FINAL + anonymous: https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22ACC_FINAL%20anonymous%22 Srikanth > > Maurizio > > > On 29/06/15 14:49, Maurizio Cimadamore wrote: >> More specifically, I was talking about this related issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8130032 >> >> Popping back one level, I think the issue you are seeing there, is >> that ACC_FINAL is erroneosuly set by javac for diamond anon classes. >> This seems to be against all the documentation that can be found on >> JBS = example: >> >> https://bugs.openjdk.java.net/browse/JDK-8023945 >> >> I seem to be able to get javac spit out ACC_FINAL reliably on JDK >> 7/8/9 - so the question is - when did it come back? Was it >> deliberate? If so, was reflection ever updated to handle this? >> >> Maurizio >> >> On 29/06/15 14:36, Remi Forax wrote: >>> yes, right, >>> it seems to be a backward compatibility land of mines. >>> >>> R?mi >>> >>> On 06/29/2015 03:29 PM, Maurizio Cimadamore wrote: >>>> I've closed it as 'not an issue' - this seems to be an outstanding >>>> issue that was fixed for some time and then reverted because of >>>> compatibility problems: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-6520152 >>>> >>>> Maurizio >>>> >>>> On 23/06/15 14:42, Georgiy Rakov wrote: >>>>> I've filed the issue JDK-8129576. >>>>> >>>>> >>>>> There is following issue in JBS: JDK-4777101 >>>>> which seems to >>>>> relate to this one. >>>>> >>>>> Thank you, >>>>> Georgiy. >>>>> >>>>> On 22.06.2015 18:56, Victor Rudometov wrote: >>>>>> This seems to be a reflection bug, since ACC_FINAL is present in >>>>>> Test12$1.class file: >>>>>> >>>>>> final class test.Test12$1 extends test.Test12$Foo >>>>>> minor version: 0 >>>>>> major version: 52 >>>>>> flags: ACC_FINAL, ACC_SUPER >>>>>> >>>>>> Thanks. >>>>>> Victor. >>>>>> >>>>>> On 22-Jun-15 18:35, Remi Forax wrote: >>>>>>> I wonder if it's not a reflection bug, >>>>>>> did you check with 'javap -c -verbose' the modifiers of the >>>>>>> generated class (something like Test12$1.class) ? >>>>>>> >>>>>>> cheers, >>>>>>> R?mi >>>>>>> >>>>>>> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> if I understand correctly according to following assertion from >>>>>>>> JLS 15.9.5 anonymous classes are always final: >>>>>>>> >>>>>>>> An anonymous class is always implicitly final (?8.1.1.2). >>>>>>>> >>>>>>>> But reflection API reports that the class is not final. Namely >>>>>>>> let's consider following code: >>>>>>>> >>>>>>>> import java.lang.reflect.Modifier; >>>>>>>> >>>>>>>> public class Test12 { >>>>>>>> static class Foo {} >>>>>>>> >>>>>>>> public static void main(String argv[]) { >>>>>>>> Foo foo = new Foo<>() {}; >>>>>>>> if ( (foo.getClass().getModifiers() & >>>>>>>> Modifier.FINAL) != 0 ) { >>>>>>>> System.out.println("final, modifiers: " + >>>>>>>> foo.getClass().getModifiers()); >>>>>>>> } else { >>>>>>>> System.out.println("not final, modifiers: " + >>>>>>>> foo.getClass().getModifiers()); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> On JDK9b69 it reports: >>>>>>>> >>>>>>>> not final, modifiers: 0 >>>>>>>> >>>>>>>> Could you please tell if you consider this as a discrepancy >>>>>>>> between spec and javac (VM?) which should be fixed. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Georgiy. >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Mon Jun 29 15:30:16 2015 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 29 Jun 2015 17:30:16 +0200 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <55915D79.4000304@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> <55896261.9040505@oracle.com> <5591482F.4010106@oracle.com> <559149D4.4020406@univ-mlv.fr> <55914CFE.6090103@oracle.com> <55914ED7.9070306@oracle.com> <55915D79.4000304@oracle.com> Message-ID: <55916488.50306@gmail.com> On 06/29/2015 05:00 PM, Srikanth wrote: > > > On Monday 29 June 2015 07:27 PM, Maurizio Cimadamore wrote: >> Ouch. It seems like this problem existed for a very long time; the >> logic used to strip away the ACC_FINAL flag from anon classes is more >> or less like this: >> >> if (c.isInner() && c.name.isEmpty()) { >> flags &= ~FINAL; >> } >> >> Now, isInner() will only return true _if the class has an enclosing >> instance_ which is clearly not the case if an anon class appears in a >> static context. >> >> In other words: >> >> class Test{ >> void finalNo() { >> new Object() { }; //ACC_FINAL not set >> } >> >> static void finalYesy() { >> new Object() { }; //ACC_FINAL set here >> } >> } >> >> javap Test\$1.class >> Compiled from "Main.java" >> class Test$1 { >> final Test this$0; >> Test$1(Test); >> } >> >> javap Test\$2.class >> Compiled from "Main.java" >> *final* class Test$2 { >> Test$2(); >> } >> >> I think this should be fixed so that anon classes (regardless of >> their context) always have their ACC_FINAL bit unset; this is >> probably not very hot from a compatibility perspective (given that >> it's been like that for a long time) - but, given the consistency >> issue and the fact that reflection cannot handle this anyway, I'd say >> we should just make this consistent. >> >> Thoughts? > > Alex's comment in https://bugs.openjdk.java.net/browse/JDK-4777101, > calls out that for anonymous classes declared in static context this > bit is set but *seems* to take > a position of leaving that as it is - Don't know why. Probably because the final bit is taken into account for default serialVersionUID computation. Serializable anonymous classes would incompatibly change their serial form if final bit changed. See ObjectStreamClass: private static long computeDefaultSUID(Class cl) { if (!Serializable.class.isAssignableFrom(cl) || Proxy.isProxyClass(cl)) { return 0L; } try { ByteArrayOutputStream bout = new ByteArrayOutputStream(); DataOutputStream dout = new DataOutputStream(bout); dout.writeUTF(cl.getName()); int classMods = cl.getModifiers() & (Modifier.PUBLIC | Modifier.FINAL | // <-- HERE !!! Modifier.INTERFACE | Modifier.ABSTRACT); ... Perhaps the final bit could be changed in anonymous class files of version JDK9 if ObjectStreamClass was also changed to accommodate for backwards compatibility (by simulating what this bit represents now)? Or is this too much complication for too little gain? Regards, Peter > > I also have https://bugs.openjdk.java.net/browse/JDK-8129576 against > my name which should closed as not an issue. > > Here is a query for ACC_FINAL + anonymous: > > https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22ACC_FINAL%20anonymous%22 > > Srikanth > > > > >> >> Maurizio >> >> >> On 29/06/15 14:49, Maurizio Cimadamore wrote: >>> More specifically, I was talking about this related issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8130032 >>> >>> Popping back one level, I think the issue you are seeing there, is >>> that ACC_FINAL is erroneosuly set by javac for diamond anon classes. >>> This seems to be against all the documentation that can be found on >>> JBS = example: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8023945 >>> >>> I seem to be able to get javac spit out ACC_FINAL reliably on JDK >>> 7/8/9 - so the question is - when did it come back? Was it >>> deliberate? If so, was reflection ever updated to handle this? >>> >>> Maurizio >>> >>> On 29/06/15 14:36, Remi Forax wrote: >>>> yes, right, >>>> it seems to be a backward compatibility land of mines. >>>> >>>> R?mi >>>> >>>> On 06/29/2015 03:29 PM, Maurizio Cimadamore wrote: >>>>> I've closed it as 'not an issue' - this seems to be an outstanding >>>>> issue that was fixed for some time and then reverted because of >>>>> compatibility problems: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-6520152 >>>>> >>>>> Maurizio >>>>> >>>>> On 23/06/15 14:42, Georgiy Rakov wrote: >>>>>> I've filed the issue JDK-8129576. >>>>>> >>>>>> >>>>>> There is following issue in JBS: JDK-4777101 >>>>>> which seems to >>>>>> relate to this one. >>>>>> >>>>>> Thank you, >>>>>> Georgiy. >>>>>> >>>>>> On 22.06.2015 18:56, Victor Rudometov wrote: >>>>>>> This seems to be a reflection bug, since ACC_FINAL is present in >>>>>>> Test12$1.class file: >>>>>>> >>>>>>> final class test.Test12$1 extends test.Test12$Foo >>>>>>> minor version: 0 >>>>>>> major version: 52 >>>>>>> flags: ACC_FINAL, ACC_SUPER >>>>>>> >>>>>>> Thanks. >>>>>>> Victor. >>>>>>> >>>>>>> On 22-Jun-15 18:35, Remi Forax wrote: >>>>>>>> I wonder if it's not a reflection bug, >>>>>>>> did you check with 'javap -c -verbose' the modifiers of the >>>>>>>> generated class (something like Test12$1.class) ? >>>>>>>> >>>>>>>> cheers, >>>>>>>> R?mi >>>>>>>> >>>>>>>> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> if I understand correctly according to following assertion >>>>>>>>> from JLS 15.9.5 anonymous classes are always final: >>>>>>>>> >>>>>>>>> An anonymous class is always implicitly final (?8.1.1.2). >>>>>>>>> >>>>>>>>> But reflection API reports that the class is not final. Namely >>>>>>>>> let's consider following code: >>>>>>>>> >>>>>>>>> import java.lang.reflect.Modifier; >>>>>>>>> >>>>>>>>> public class Test12 { >>>>>>>>> static class Foo {} >>>>>>>>> >>>>>>>>> public static void main(String argv[]) { >>>>>>>>> Foo foo = new Foo<>() {}; >>>>>>>>> if ( (foo.getClass().getModifiers() & >>>>>>>>> Modifier.FINAL) != 0 ) { >>>>>>>>> System.out.println("final, modifiers: " + >>>>>>>>> foo.getClass().getModifiers()); >>>>>>>>> } else { >>>>>>>>> System.out.println("not final, modifiers: " + >>>>>>>>> foo.getClass().getModifiers()); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> On JDK9b69 it reports: >>>>>>>>> >>>>>>>>> not final, modifiers: 0 >>>>>>>>> >>>>>>>>> Could you please tell if you consider this as a discrepancy >>>>>>>>> between spec and javac (VM?) which should be fixed. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Georgiy. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Mon Jun 29 20:33:27 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 29 Jun 2015 14:33:27 -0600 Subject: Wildcard capture with self-referencing bound In-Reply-To: <558A77AE.1000001@oracle.com> References: <558A77AE.1000001@oracle.com> Message-ID: <8EEABF9F-333D-44BF-804E-74047CE0266E@oracle.com> See also: https://bugs.openjdk.java.net/browse/JDK-8054937 ?Dan > On Jun 24, 2015, at 3:26 AM, Maurizio Cimadamore wrote: > > Hi, > these are all areas where the JLS text is a bit underspecified and javac ended up settling on some opportunistic strategy which then, eventually, also got adopted by other compilers too. For instance, w.r.t. generic type well-formedness, the check performed by javac depends on the type-argument kind: > > * if the type-argument T is invariant (i.e. not a wildcard type) - check that T <: B > * if the type argument T is a wildcard: > -of the kind ? extends A - check A _is castable_ to B > -of the kind ? super A - check that there exist some instantiation of A such that A <: B > -of the kind ? - always valid > > I found a very similar explanation buried in the Java generic forums - and it seemed like, at the time (JSR14), Neal Gafter thought this was a good compromise between safety and expressiveness. The spec ended up being written in a different - much stricter way, as you point out; as a result a lot of programs that are compiled w/o errors by javac are morally rejected by the spec. We might do some work in this area to align the compiler and the spec; note also that the compiler impl is too liberal/fuzzy, while the spec is too strict, so the 'optimal' result is probably somewhere in the middle. > > Intersection types are also another deeply unspecified area; as you say, it is not clear what happens when the intersection components are wildcard types; we had few issues in javac related to this and we ended up forcing a capture conversion on the intersection type components. Again, this is probably not the behavior we'd like to have in the long run - think of it as an expedient to get things back on track. > > Cheers > Maurizio > > On 12/06/15 00:40, Zhong Yu wrote: >> Elias Vasylenko posted this question on http://stackoverflow.com/questions/30788366 >> >> Given declarations >> >> class C1> {} >> class C2 extends C1> {} >> >> Are the following parameterization well-formed? >> >> C1> >> C1> >> >> According to his interpretation of JLS, which I concur, they are not well-formed, because the bound of the capture variable, T#1, is C2 & C1, which is forbidden by both section $4.9 and $5.1.10. Nothing in JLS will infer that C2 <: C1. >> >> However, javac does allow them, which is reasonable, of course. How do we understand this behavior? >> >> Another question, if Ck in $4.9 contains wildcard like C2, how can we use it as the superclass of the notional class? How do we derive members of the notional class? >> >> Thanks, >> Zhong Yu >> bayou.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Tue Jun 30 21:16:25 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 30 Jun 2015 14:16:25 -0700 Subject: Anonymous classes are not final according to reflection API In-Reply-To: <55915D79.4000304@oracle.com> References: <558826EC.6060000@oracle.com> <55882B47.8060001@univ-mlv.fr> <5588304B.7070709@oracle.com> <55896261.9040505@oracle.com> <5591482F.4010106@oracle.com> <559149D4.4020406@univ-mlv.fr> <55914CFE.6090103@oracle.com> <55914ED7.9070306@oracle.com> <55915D79.4000304@oracle.com> Message-ID: <55930729.3060903@oracle.com> Philosophically I would love to mark all anonymous classes as ACC_FINAL, but JDK-4777101 makes clear that it can't happen for reasons of compatibility. (Hat tip to Peter for his explanatory mail.) If anything, it was a lucky escape that only a subset of anonymous classes (the inner ones) were marked ACC_FINAL by JDK-6219964. In my view, Core Reflection should be changed to "lie" about the class files by showing the 'final' modifier as set for all anonymous classes. However, if it was that easy, it would have been done already, so I bet core-libs-dev will offer their own compatibility concerns. Alex On 6/29/2015 8:00 AM, Srikanth wrote: > On Monday 29 June 2015 07:27 PM, Maurizio Cimadamore wrote: >> Ouch. It seems like this problem existed for a very long time; the >> logic used to strip away the ACC_FINAL flag from anon classes is more >> or less like this: >> >> if (c.isInner() && c.name.isEmpty()) { >> flags &= ~FINAL; >> } >> >> Now, isInner() will only return true _if the class has an enclosing >> instance_ which is clearly not the case if an anon class appears in a >> static context. >> >> In other words: >> >> class Test{ >> void finalNo() { >> new Object() { }; //ACC_FINAL not set >> } >> >> static void finalYesy() { >> new Object() { }; //ACC_FINAL set here >> } >> } >> >> javap Test\$1.class >> Compiled from "Main.java" >> class Test$1 { >> final Test this$0; >> Test$1(Test); >> } >> >> javap Test\$2.class >> Compiled from "Main.java" >> *final* class Test$2 { >> Test$2(); >> } >> >> I think this should be fixed so that anon classes (regardless of their >> context) always have their ACC_FINAL bit unset; this is probably not >> very hot from a compatibility perspective (given that it's been like >> that for a long time) - but, given the consistency issue and the fact >> that reflection cannot handle this anyway, I'd say we should just make >> this consistent. >> >> Thoughts? > > Alex's comment in https://bugs.openjdk.java.net/browse/JDK-4777101, > calls out that for anonymous classes declared in static context this bit > is set but *seems* to take > a position of leaving that as it is - Don't know why. > > I also have https://bugs.openjdk.java.net/browse/JDK-8129576 against my > name which should closed as not an issue. > > Here is a query for ACC_FINAL + anonymous: > > https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22ACC_FINAL%20anonymous%22 > > Srikanth > > > > >> >> Maurizio >> >> >> On 29/06/15 14:49, Maurizio Cimadamore wrote: >>> More specifically, I was talking about this related issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8130032 >>> >>> Popping back one level, I think the issue you are seeing there, is >>> that ACC_FINAL is erroneosuly set by javac for diamond anon classes. >>> This seems to be against all the documentation that can be found on >>> JBS = example: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8023945 >>> >>> I seem to be able to get javac spit out ACC_FINAL reliably on JDK >>> 7/8/9 - so the question is - when did it come back? Was it >>> deliberate? If so, was reflection ever updated to handle this? >>> >>> Maurizio >>> >>> On 29/06/15 14:36, Remi Forax wrote: >>>> yes, right, >>>> it seems to be a backward compatibility land of mines. >>>> >>>> R?mi >>>> >>>> On 06/29/2015 03:29 PM, Maurizio Cimadamore wrote: >>>>> I've closed it as 'not an issue' - this seems to be an outstanding >>>>> issue that was fixed for some time and then reverted because of >>>>> compatibility problems: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-6520152 >>>>> >>>>> Maurizio >>>>> >>>>> On 23/06/15 14:42, Georgiy Rakov wrote: >>>>>> I've filed the issue JDK-8129576. >>>>>> >>>>>> >>>>>> There is following issue in JBS: JDK-4777101 >>>>>> which seems to >>>>>> relate to this one. >>>>>> >>>>>> Thank you, >>>>>> Georgiy. >>>>>> >>>>>> On 22.06.2015 18:56, Victor Rudometov wrote: >>>>>>> This seems to be a reflection bug, since ACC_FINAL is present in >>>>>>> Test12$1.class file: >>>>>>> >>>>>>> final class test.Test12$1 extends test.Test12$Foo >>>>>>> minor version: 0 >>>>>>> major version: 52 >>>>>>> flags: ACC_FINAL, ACC_SUPER >>>>>>> >>>>>>> Thanks. >>>>>>> Victor. >>>>>>> >>>>>>> On 22-Jun-15 18:35, Remi Forax wrote: >>>>>>>> I wonder if it's not a reflection bug, >>>>>>>> did you check with 'javap -c -verbose' the modifiers of the >>>>>>>> generated class (something like Test12$1.class) ? >>>>>>>> >>>>>>>> cheers, >>>>>>>> R?mi >>>>>>>> >>>>>>>> On 06/22/2015 05:17 PM, Georgiy Rakov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> if I understand correctly according to following assertion from >>>>>>>>> JLS 15.9.5 anonymous classes are always final: >>>>>>>>> >>>>>>>>> An anonymous class is always implicitly final (?8.1.1.2). >>>>>>>>> >>>>>>>>> But reflection API reports that the class is not final. Namely >>>>>>>>> let's consider following code: >>>>>>>>> >>>>>>>>> import java.lang.reflect.Modifier; >>>>>>>>> >>>>>>>>> public class Test12 { >>>>>>>>> static class Foo {} >>>>>>>>> >>>>>>>>> public static void main(String argv[]) { >>>>>>>>> Foo foo = new Foo<>() {}; >>>>>>>>> if ( (foo.getClass().getModifiers() & >>>>>>>>> Modifier.FINAL) != 0 ) { >>>>>>>>> System.out.println("final, modifiers: " + >>>>>>>>> foo.getClass().getModifiers()); >>>>>>>>> } else { >>>>>>>>> System.out.println("not final, modifiers: " + >>>>>>>>> foo.getClass().getModifiers()); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> On JDK9b69 it reports: >>>>>>>>> >>>>>>>>> not final, modifiers: 0 >>>>>>>>> >>>>>>>>> Could you please tell if you consider this as a discrepancy >>>>>>>>> between spec and javac (VM?) which should be fixed. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Georgiy. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >