From erik.joelsson at oracle.com Tue Apr 2 21:25:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Apr 2019 14:25:06 -0700 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <8b8673bf-42af-d519-5a57-509d30514b83@oracle.com> Build change looks good. /Erik On 2019-04-02 14:12, Roman Kennke wrote: > (I am cross-posting this to build-dev and compiler-dev because this > contains some (trivial-ish) shared build and C2 changes. The C2 changes > are almost all reversals of Shenandoah-specific paths that have been > introduced in initial Shenandoah push.) > > I would like to propose that we switch to what we came to call 'load > reference barrier' as new barrier scheme for Shenandoah GC. > > The main difference is that instead of ensuring correct invariant when > we store anything into the heap (e.g. read-barrier before reads, > write-barrier before writes, plus a bunch of other stuff), we ensure the > strong invariance on objects when they get loaded, by employing what is > currently our write-barrier. > > The reason why I'm proposing it is: > - simpler barrier interface > - easier to get good performance out of it > ==> good for upcoming Graal (sup)port > - reduced maintenance burden (I intend to backport it all the way) > > This has a number of advantages: > - Strong invariant means it's a lot easier to reason about the state of > GC and objects > - Much simpler barrier interface. Infact, a lot of stuff that we added > to barrier interfaces after JDK11 will now become unused: no need for > barriers on primitives, no need for object equality barriers, no need > for resolve barriers, etc. Also, some C2 stuff that we added for > Shenandoah can now be removed again. (Those are what comprise most > shared C2 changes.) > - Optimization is much easier: we currently put barriers 'down low' > close to their uses (which might be inside a hot loop), and then work > hard to optimize barriers upwards, e.g. out of loops. By using > load-ref-barriers, we would place them at the outermost site already. > Look how much code is removed from shenandoahSupport.cpp! > - No more need for object equals barriers. > - No more need for 'resolve' barriers. > - All barriers are now conditional, which opens up opportunity for > further optimization later on. > - we can re-enable the fast JNI getfield stuff > - we no longer need the nmethod initializer that initializes embedded > oops to to-space > - We no longer have the problem to use two registers for 'the same' > value (pre- and post-barrier). > > The 'only' optimizations that we do in C2 are: > - Look upwards and see if barrier input indicates we don't actually need > the barrier. Would be the case for: constants, nulls, method parameters, > etc (anything that is not like a load). Even though we insert barriers > after loads, you'd be surprised to see how many loads actually disappear. > - Look downwards to check uses of the barrier. If it doesn't feed into > anything that requires a barrier, we can remove it. > > Performance doesn't seem to be negatively impacted at all. Some > benchmarks benefit positively from it. > > Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all > of them many times. This patch has baked in shenandoah/jdk for 1.5 > months, undergone our rigorous CI, received various bug-fixes, we have > had a close look at the generated code to verify it is sane. jdk/submit > job expected good before push. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221766 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ > > Can I please get reviews for this change? > > Roman > > From rkennke at redhat.com Tue Apr 2 21:12:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 23:12:40 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah Message-ID: (I am cross-posting this to build-dev and compiler-dev because this contains some (trivial-ish) shared build and C2 changes. The C2 changes are almost all reversals of Shenandoah-specific paths that have been introduced in initial Shenandoah push.) I would like to propose that we switch to what we came to call 'load reference barrier' as new barrier scheme for Shenandoah GC. The main difference is that instead of ensuring correct invariant when we store anything into the heap (e.g. read-barrier before reads, write-barrier before writes, plus a bunch of other stuff), we ensure the strong invariance on objects when they get loaded, by employing what is currently our write-barrier. The reason why I'm proposing it is: - simpler barrier interface - easier to get good performance out of it ==> good for upcoming Graal (sup)port - reduced maintenance burden (I intend to backport it all the way) This has a number of advantages: - Strong invariant means it's a lot easier to reason about the state of GC and objects - Much simpler barrier interface. Infact, a lot of stuff that we added to barrier interfaces after JDK11 will now become unused: no need for barriers on primitives, no need for object equality barriers, no need for resolve barriers, etc. Also, some C2 stuff that we added for Shenandoah can now be removed again. (Those are what comprise most shared C2 changes.) - Optimization is much easier: we currently put barriers 'down low' close to their uses (which might be inside a hot loop), and then work hard to optimize barriers upwards, e.g. out of loops. By using load-ref-barriers, we would place them at the outermost site already. Look how much code is removed from shenandoahSupport.cpp! - No more need for object equals barriers. - No more need for 'resolve' barriers. - All barriers are now conditional, which opens up opportunity for further optimization later on. - we can re-enable the fast JNI getfield stuff - we no longer need the nmethod initializer that initializes embedded oops to to-space - We no longer have the problem to use two registers for 'the same' value (pre- and post-barrier). The 'only' optimizations that we do in C2 are: - Look upwards and see if barrier input indicates we don't actually need the barrier. Would be the case for: constants, nulls, method parameters, etc (anything that is not like a load). Even though we insert barriers after loads, you'd be surprised to see how many loads actually disappear. - Look downwards to check uses of the barrier. If it doesn't feed into anything that requires a barrier, we can remove it. Performance doesn't seem to be negatively impacted at all. Some benchmarks benefit positively from it. Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all of them many times. This patch has baked in shenandoah/jdk for 1.5 months, undergone our rigorous CI, received various bug-fixes, we have had a close look at the generated code to verify it is sane. jdk/submit job expected good before push. Bug: https://bugs.openjdk.java.net/browse/JDK-8221766 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ Can I please get reviews for this change? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rkennke at redhat.com Tue Apr 2 21:28:02 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 23:28:02 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <8b8673bf-42af-d519-5a57-509d30514b83@oracle.com> References: <8b8673bf-42af-d519-5a57-509d30514b83@oracle.com> Message-ID: Thanks, Erik! Roman > Build change looks good. > > /Erik > > On 2019-04-02 14:12, Roman Kennke wrote: >> (I am cross-posting this to build-dev and compiler-dev because this >> contains some (trivial-ish) shared build and C2 changes. The C2 changes >> are almost all reversals of Shenandoah-specific paths that have been >> introduced in initial Shenandoah push.) >> >> I would like to propose that we switch to what we came to call 'load >> reference barrier' as new barrier scheme for Shenandoah GC. >> >> The main difference is that instead of ensuring correct invariant when >> we store anything into the heap (e.g. read-barrier before reads, >> write-barrier before writes, plus a bunch of other stuff), we ensure the >> strong invariance on objects when they get loaded, by employing what is >> currently our write-barrier. >> >> The reason why I'm proposing it is: >> - simpler barrier interface >> - easier to get good performance out of it >> ?? ==> good for upcoming Graal (sup)port >> - reduced maintenance burden (I intend to backport it all the way) >> >> This has a number of advantages: >> - Strong invariant means it's a lot easier to reason about the state of >> GC and objects >> - Much simpler barrier interface. Infact, a lot of stuff that we added >> to barrier interfaces after JDK11 will now become unused: no need for >> barriers on primitives, no need for object equality barriers, no need >> for resolve barriers, etc. Also, some C2 stuff that we added for >> Shenandoah can now be removed again. (Those are what comprise most >> shared C2 changes.) >> - Optimization is much easier: we currently put barriers 'down low' >> close to their uses (which might be inside a hot loop), and then work >> hard to optimize barriers upwards, e.g. out of loops. By using >> load-ref-barriers, we would place them at the outermost site already. >> Look how much code is removed from shenandoahSupport.cpp! >> - No more need for object equals barriers. >> - No more need for 'resolve' barriers. >> - All barriers are now conditional, which opens up opportunity for >> further optimization later on. >> - we can re-enable the fast JNI getfield stuff >> - we no longer need the nmethod initializer that initializes embedded >> oops to to-space >> - We no longer have the problem to use two registers for 'the same' >> value (pre- and post-barrier). >> >> The 'only' optimizations that we do in C2 are: >> - Look upwards and see if barrier input indicates we don't actually need >> the barrier. Would be the case for: constants, nulls, method parameters, >> etc (anything that is not like a load). Even though we insert barriers >> after loads, you'd be surprised to see how many loads actually disappear. >> - Look downwards to check uses of the barrier. If it doesn't feed into >> anything that requires a barrier, we can remove it. >> >> Performance doesn't seem to be negatively impacted at all. Some >> benchmarks benefit positively from it. >> >> Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all >> of them many times. This patch has baked in shenandoah/jdk for 1.5 >> months, undergone our rigorous CI, received various bug-fixes, we have >> had a close look at the generated code to verify it is sane. jdk/submit >> job expected good before push. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221766 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ >> >> Can I please get reviews for this change? >> >> Roman >> >> From jonathan.gibbons at oracle.com Tue Apr 2 21:28:32 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 2 Apr 2019 14:28:32 -0700 Subject: RFR(13): JDK-8217047: Provide a way to inject missing parameter names In-Reply-To: <5C928E33.6030508@oracle.com> References: <5C45BBE5.6030007@oracle.com> <61878d42-a401-a5a2-3331-d0fa4dd0e77f@oracle.com> <5C928E33.6030508@oracle.com> Message-ID: Looks good to me. The beginning of the comment on ClassReader.java:2586 needs to be updated. It says "returns the name" but the method actually returns a VarSymbol. -- Jon On 03/20/2019 12:02 PM, Jan Lahoda wrote: > Hi Jon, > > Thanks for the comments. I tried to improve the javadoc, added > implNote, and fixed Flags and MissingInfoHandler. > > Regarding ClassReader always creating ParamSymbols, as the ParamSymbol > is not bigger than VarSymbol, I opted for simplicity and a more > uniform representation. But I can change that to use VarSymbol when > the name is known, should be simple. > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8217047/webrev.03/ > > Updated specdiff: > http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.03/overview-summary.html > > > How does this look? > > Thanks, > ??? Jan > > On 16.3.2019 01:32, Jonathan Gibbons wrote: >> Nice.? Minor comments... >> >> The {@linkplain}don't seem to be working as expected;? I suspect you >> need to import the type names. Also, you should use parens and arg types >> on links to methods; if you don't want the `(arg-types)` to show up in >> the docs, use the form of {@linkplain} that allows you to specify the >> text to be linked. >> >> The new method in JavacTask should have an implNote that says, "This >> Implementation does nothing." or words to that effect. >> >> (Aside: we have a more general problem with implNotes, that we have >> places where the default is to do nothing or throw UOE, but the reality >> is that the real-world impl of these methods does something useful. I >> don't know how/where we should document that behavior. But that's a >> bigger question for another time and another review.) >> >> Flags.java >> >> typo: friedly >> >> ClassReader ... just curious, you always create a new ParamSymbol, even >> when you could use a VarSymbol (because you have already filled in the >> name).? I guess the code is neater/more consistent the way you have it. >> >> MissingInfoHandler ... no class-level doc comment. I realize it's an >> internal class but even so ... >> >> -- Jon >> >> >> On 01/21/2019 04:32 AM, Jan Lahoda wrote: >>> Hi, >>> >>> When a type is load from a classfile, and some or all of its methods >>> have neither the MethodParameters or LocalVariableTable attributes, >>> then the parameters of the methods have an artificial synthesized >>> name, which is visible through VariableElement.getSimpleName(). >>> >>> The proposal here is to allow to plug in an external provider that >>> could provide more user-friendly names lazily/on demand. These could >>> originate e.g. in adjacent sources. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217437 >>> Webrev: http://cr.openjdk.java.net/~jlahoda/8217047/webrev.01/ >>> Specdiff: >>> http://cr.openjdk.java.net/~jlahoda/8217047/specdiff.01/overview-summary.html >>> >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8217437 >>> >>> What do you think? >>> >>> Thanks, >>> ??? Jan >> From jonathan.gibbons at oracle.com Tue Apr 2 22:29:16 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 2 Apr 2019 15:29:16 -0700 Subject: RFR 8220792: JavacFileManager.list() performance In-Reply-To: References: <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com> <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com> <825a8a08-5213-ea02-c95e-d07ef5f1d734@oracle.com> Message-ID: <6f0588d7-b93d-985b-12fb-ce28a2acf0c1@oracle.com> OK, thanks for looking into this; I also looked at the code and agree with your assessment. One of these days we'll have some really good unit tests for JavacFileManager ;-)? Until then, this looks good. -- Jon On 03/31/2019 05:04 AM, Ron Shapiro wrote: > My initial inclination was to say that you were right, but that this > would have been the case even before my change, since already > ArchiveContainer did nothing to index parent directories of the > directories that actually have files in the archive. But then I did > some debugging to see what actually happens, and it seems that the > archive filesystem visits all parent directories, and thus those are > also indexed. Here's one example from running jtreg: > > indexing archivePath: .../asmtools.jar > preVisit: / > preVisit: /org > preVisit: /org/openjdk > preVisit: /org/openjdk/asmtools > preVisit: /org/openjdk/asmtools/util > preVisit: /org/openjdk/asmtools/jdis > preVisit: /org/openjdk/asmtools/jdec > preVisit: /org/openjdk/asmtools/jcoder > preVisit: /org/openjdk/asmtools/jcdec > preVisit: /org/openjdk/asmtools/jasm > preVisit: /org/openjdk/asmtools/common > preVisit: /org/openjdk/asmtools/asmutils > preVisit: /META-INF > > I checked the code for ZipFileSystem, and it hard-codes the root > directory as "/" for all zip files no matter the contents. > > So for the example above, list("org", recurse=true) should still recur > properly. > > On Fri, Mar 29, 2019 at 9:21 PM Jonathan Gibbons > > wrote: > > Ron, > > Although I've not checked in deep detail, I think there may be an > inherent problem with the caching you are doing, as regards to > recursive list. > > The list method takes a "recurse" parameter, which can be used to > list the contents of a package /and its subpackages/. > > If you have two containers, one containing package "p", and > another containing package "p.q", if you try a recursive list of > "p", I believe your code may miss the contents of "p.q" in the > second container. If nothing else, this is an important case to be > checked and tested. Although this feature is not typically used in > javac itself, it is used in javadoc, which also uses the same file > manager. > > It may be that the cache needs to be smart enough to handle the > case when an archive has subdirectories of a package, even if it > does not have any direct contents of the package. > > -- Jon > > On 3/29/19 7:10 AM, Ron Shapiro wrote: >> - Added a comment explaining the ordering. LMK if you have a >> better way of explaining it, as I think you grok it better than I do >> - Thanks for the pointer to javacFileManagerOptions. I updated to >> use that. >> Both are in this updated webrev: >> http://cr.openjdk.java.net/~ronsh/8220792/webrev.02/ >> >> >> - Regarding indexing: I don't think today anything would detect >> updates to a jar file if a new RelativeDirectory was added. >> Perhaps that's intentional, because we don't care/don't even want >> to try to support someone updating their jarfile in the middle of >> a compilation. I defer to others about indexing other containers >> - it looks like the JRTImageContainer depends on the JRTIndex >> class, which does a lazy computation of the index, so it looks >> like it would be some additional work to add that to the index. >> But perhaps it's not even worth it - IIUC, there should only be >> one JRTImageContainer, and probably a limited amount of >> DirectoryContainers - the performance issue that I was observing >> was that with many jars, each needed to do some work for every >> call to list. We've now reduced O(O(JRTImageContainer = 1)?+ >> O(DirectoryContainer = likely to be small)?+ O(ArchiveContainer = >> possibly large)) per list() call to?O(O(JRTImageContainer = 1)?+ >> O(DirectoryContainer = likely to be small)?+ O(overlapping >> ArchiveContainers, which is hopefully small)) >> >> >> >> On Wed, Mar 27, 2019 at 1:47 PM Jonathan Gibbons >> > > wrote: >> >> >> On 3/27/19 9:06 AM, Ron Shapiro wrote: >> > >> > > It's not clear to me why you maintain the list of >> PathAndContainer >> > as a sorted list, and hence why you need to use >> java.util.List instead >> > of javac's List. >> > There are some tests that ensure that the classpath that >> javac sees is >> > equivalent to the classpath the JVM sees vis-a-vis >> ordering. Without >> > sorting, javac was seeing a different order, and I presume >> that is >> > because the JRTImageContainer and DirectoryContainers could >> appear >> > anywhere. Sorting solved that issue. >> >> OK, I think I understand the issue and why sorting fixes it. >> >> While some tests may check that "the classpath that javac >> sees is >> equivalent to the classpath the JVM sees vis-a-vis ordering", >> that's not >> the primary issue. The primary issue is that the new cache >> must preserve >> the order in which containers are searched on the classpath >> (i.e just >> within javac, separate from any part set by the JVM). While >> this is not >> so important when looking up classes in "well-behaved" >> packages, it is >> important when handling split packages and resources, where >> the contents >> in one container may hide the contents in another container. >> >> I think this is subtle enough that it is worth a comment in >> the code, >> explaining that it is important to preserve the search order >> used in the >> uncached Location path. >> >> -- Jon >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Tue Apr 2 23:34:43 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 2 Apr 2019 19:34:43 -0400 Subject: RFR 8220792: JavacFileManager.list() performance In-Reply-To: <6f0588d7-b93d-985b-12fb-ce28a2acf0c1@oracle.com> References: <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com> <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com> <825a8a08-5213-ea02-c95e-d07ef5f1d734@oracle.com> <6f0588d7-b93d-985b-12fb-ce28a2acf0c1@oracle.com> Message-ID: Thanks for such a detailed review! I noticed one small thing - javacFileManagerOptions is private in the superclass (BaseFileManager). I changed that reference to Option.getJavaFileManagerOptions() instead, which is what that field is set to also. Here's the updated webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.03/ Or, I can alternatively make the field protected. On Tue, Apr 2, 2019 at 6:31 PM Jonathan Gibbons wrote: > OK, thanks for looking into this; I also looked at the code and agree with > your assessment. > > One of these days we'll have some really good unit tests for > JavacFileManager ;-) Until then, this looks good. > > -- Jon > On 03/31/2019 05:04 AM, Ron Shapiro wrote: > > My initial inclination was to say that you were right, but that this would > have been the case even before my change, since already ArchiveContainer > did nothing to index parent directories of the directories that actually > have files in the archive. But then I did some debugging to see what > actually happens, and it seems that the archive filesystem visits all > parent directories, and thus those are also indexed. Here's one example > from running jtreg: > > indexing archivePath: .../asmtools.jar > preVisit: / > preVisit: /org > preVisit: /org/openjdk > preVisit: /org/openjdk/asmtools > preVisit: /org/openjdk/asmtools/util > preVisit: /org/openjdk/asmtools/jdis > preVisit: /org/openjdk/asmtools/jdec > preVisit: /org/openjdk/asmtools/jcoder > preVisit: /org/openjdk/asmtools/jcdec > preVisit: /org/openjdk/asmtools/jasm > preVisit: /org/openjdk/asmtools/common > preVisit: /org/openjdk/asmtools/asmutils > preVisit: /META-INF > > I checked the code for ZipFileSystem, and it hard-codes the root directory > as "/" for all zip files no matter the contents. > > So for the example above, list("org", recurse=true) should still recur > properly. > > On Fri, Mar 29, 2019 at 9:21 PM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> Ron, >> >> Although I've not checked in deep detail, I think there may be an >> inherent problem with the caching you are doing, as regards to recursive >> list. >> >> The list method takes a "recurse" parameter, which can be used to list >> the contents of a package *and its subpackages*. >> >> If you have two containers, one containing package "p", and another >> containing package "p.q", if you try a recursive list of "p", I believe >> your code may miss the contents of "p.q" in the second container. If >> nothing else, this is an important case to be checked and tested. Although >> this feature is not typically used in javac itself, it is used in javadoc, >> which also uses the same file manager. >> >> It may be that the cache needs to be smart enough to handle the case when >> an archive has subdirectories of a package, even if it does not have any >> direct contents of the package. >> >> -- Jon >> On 3/29/19 7:10 AM, Ron Shapiro wrote: >> >> - Added a comment explaining the ordering. LMK if you have a better way >> of explaining it, as I think you grok it better than I do >> - Thanks for the pointer to javacFileManagerOptions. I updated to use >> that. >> Both are in this updated webrev: >> http://cr.openjdk.java.net/~ronsh/8220792/webrev.02/ >> >> - Regarding indexing: I don't think today anything would detect updates >> to a jar file if a new RelativeDirectory was added. Perhaps that's >> intentional, because we don't care/don't even want to try to support >> someone updating their jarfile in the middle of a compilation. I defer to >> others about indexing other containers - it looks like the >> JRTImageContainer depends on the JRTIndex class, which does a lazy >> computation of the index, so it looks like it would be some additional work >> to add that to the index. But perhaps it's not even worth it - IIUC, there >> should only be one JRTImageContainer, and probably a limited amount of >> DirectoryContainers - the performance issue that I was observing was that >> with many jars, each needed to do some work for every call to list. We've >> now reduced O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to >> be small) + O(ArchiveContainer = possibly large)) per list() call >> to O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to be >> small) + O(overlapping ArchiveContainers, which is hopefully small)) >> >> >> >> On Wed, Mar 27, 2019 at 1:47 PM Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> >>> On 3/27/19 9:06 AM, Ron Shapiro wrote: >>> > >>> > > It's not clear to me why you maintain the list of PathAndContainer >>> > as a sorted list, and hence why you need to use java.util.List instead >>> > of javac's List. >>> > There are some tests that ensure that the classpath that javac sees is >>> > equivalent to the classpath the JVM sees vis-a-vis ordering. Without >>> > sorting, javac was seeing a different order, and I presume that is >>> > because the JRTImageContainer and DirectoryContainers could appear >>> > anywhere. Sorting solved that issue. >>> >>> OK, I think I understand the issue and why sorting fixes it. >>> >>> While some tests may check that "the classpath that javac sees is >>> equivalent to the classpath the JVM sees vis-a-vis ordering", that's not >>> the primary issue. The primary issue is that the new cache must preserve >>> the order in which containers are searched on the classpath (i.e just >>> within javac, separate from any part set by the JVM). While this is not >>> so important when looking up classes in "well-behaved" packages, it is >>> important when handling split packages and resources, where the contents >>> in one container may hide the contents in another container. >>> >>> I think this is subtle enough that it is worth a comment in the code, >>> explaining that it is important to preserve the search order used in the >>> uncached Location path. >>> >>> -- Jon >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Apr 2 23:56:21 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 2 Apr 2019 16:56:21 -0700 Subject: RFR 8220792: JavacFileManager.list() performance In-Reply-To: References: <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com> <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com> <825a8a08-5213-ea02-c95e-d07ef5f1d734@oracle.com> <6f0588d7-b93d-985b-12fb-ce28a2acf0c1@oracle.com> Message-ID: <0023eee3-46ad-24a6-b6ed-1127e18b1105@oracle.com> Ron, In this case, I would just make the field protected. Arguably BaseFileManager has outlived its usefulness; it was introduced when for a while we had two different file managers, one based on java.io.File and another based on java.nio.file.Path.? As you see, that played out to what we have today, where one file manager supports both. I don't foresee any additional need for separate use BaseFileManager, because any additional file manager functionality should be based on using nio Path and FileSystem. Bottom line, BaseFileManager and JavacFileManager are joined at the hip, and may one day be fused together as one.? So it's reasonable for JavacFileManager to use protected fields of BaseFileManager. -- Jon On 04/02/2019 04:34 PM, Ron Shapiro wrote: > Thanks for such a detailed review! > > I noticed one small thing - javacFileManagerOptions is private in the > superclass (BaseFileManager). I changed that reference to > Option.getJavaFileManagerOptions() instead, which is what that field > is set to also. Here's the updated webrev: > http://cr.openjdk.java.net/~ronsh/8220792/webrev.03/ > > > Or, I can alternatively make the field protected. > > On Tue, Apr 2, 2019 at 6:31 PM Jonathan Gibbons > > wrote: > > OK, thanks for looking into this; I also looked at the code and > agree with your assessment. > > One of these days we'll have some really good unit tests for > JavacFileManager ;-)? Until then, this looks good. > > -- Jon > > On 03/31/2019 05:04 AM, Ron Shapiro wrote: >> My initial inclination was to say that you were right, but that >> this would have been the case even before my change, since >> already ArchiveContainer did nothing to index parent directories >> of the directories that actually have files in the archive. But >> then I did some debugging to see what actually happens, and it >> seems that the archive filesystem visits all parent directories, >> and thus those are also indexed. Here's one example from running >> jtreg: >> >> indexing archivePath: .../asmtools.jar >> preVisit: / >> preVisit: /org >> preVisit: /org/openjdk >> preVisit: /org/openjdk/asmtools >> preVisit: /org/openjdk/asmtools/util >> preVisit: /org/openjdk/asmtools/jdis >> preVisit: /org/openjdk/asmtools/jdec >> preVisit: /org/openjdk/asmtools/jcoder >> preVisit: /org/openjdk/asmtools/jcdec >> preVisit: /org/openjdk/asmtools/jasm >> preVisit: /org/openjdk/asmtools/common >> preVisit: /org/openjdk/asmtools/asmutils >> preVisit: /META-INF >> >> I checked the code for ZipFileSystem, and it hard-codes the root >> directory as "/" for all zip files no matter the contents. >> >> So for the example above, list("org", recurse=true) should still >> recur properly. >> >> On Fri, Mar 29, 2019 at 9:21 PM Jonathan Gibbons >> > > wrote: >> >> Ron, >> >> Although I've not checked in deep detail, I think there may >> be an inherent problem with the caching you are doing, as >> regards to recursive list. >> >> The list method takes a "recurse" parameter, which can be >> used to list the contents of a package /and its subpackages/. >> >> If you have two containers, one containing package "p", and >> another containing package "p.q", if you try a recursive list >> of "p", I believe your code may miss the contents of "p.q" in >> the second container. If nothing else, this is an important >> case to be checked and tested. Although this feature is not >> typically used in javac itself, it is used in javadoc, which >> also uses the same file manager. >> >> It may be that the cache needs to be smart enough to handle >> the case when an archive has subdirectories of a package, >> even if it does not have any direct contents of the package. >> >> -- Jon >> >> On 3/29/19 7:10 AM, Ron Shapiro wrote: >>> - Added a comment explaining the ordering. LMK if you have a >>> better way of explaining it, as I think you grok it better >>> than I do >>> - Thanks for the pointer to javacFileManagerOptions. I >>> updated to use that. >>> Both are in this updated webrev: >>> http://cr.openjdk.java.net/~ronsh/8220792/webrev.02/ >>> >>> >>> - Regarding indexing: I don't think today anything would >>> detect updates to a jar file if a new RelativeDirectory was >>> added. Perhaps that's intentional, because we don't >>> care/don't even want to try to support someone updating >>> their jarfile in the middle of a compilation. I defer to >>> others about indexing other containers - it looks like the >>> JRTImageContainer depends on the JRTIndex class, which does >>> a lazy computation of the index, so it looks like it would >>> be some additional work to add that to the index. But >>> perhaps it's not even worth it - IIUC, there should only be >>> one JRTImageContainer, and probably a limited amount of >>> DirectoryContainers - the performance issue that I was >>> observing was that with many jars, each needed to do some >>> work for every call to list. We've now reduced >>> O(O(JRTImageContainer = 1)?+ O(DirectoryContainer = likely >>> to be small)?+ O(ArchiveContainer = possibly large)) per >>> list() call to?O(O(JRTImageContainer = 1)?+ >>> O(DirectoryContainer = likely to be small)?+ O(overlapping >>> ArchiveContainers, which is hopefully small)) >>> >>> >>> >>> On Wed, Mar 27, 2019 at 1:47 PM Jonathan Gibbons >>> >> > wrote: >>> >>> >>> On 3/27/19 9:06 AM, Ron Shapiro wrote: >>> > >>> > > It's not clear to me why you maintain the list of >>> PathAndContainer >>> > as a sorted list, and hence why you need to use >>> java.util.List instead >>> > of javac's List. >>> > There are some tests that ensure that the classpath >>> that javac sees is >>> > equivalent to the classpath the JVM sees vis-a-vis >>> ordering. Without >>> > sorting, javac was seeing a different order, and I >>> presume that is >>> > because the JRTImageContainer and DirectoryContainers >>> could appear >>> > anywhere. Sorting solved that issue. >>> >>> OK, I think I understand the issue and why sorting fixes it. >>> >>> While some tests may check that "the classpath that >>> javac sees is >>> equivalent to the classpath the JVM sees vis-a-vis >>> ordering", that's not >>> the primary issue. The primary issue is that the new >>> cache must preserve >>> the order in which containers are searched on the >>> classpath (i.e just >>> within javac, separate from any part set by the JVM). >>> While this is not >>> so important when looking up classes in "well-behaved" >>> packages, it is >>> important when handling split packages and resources, >>> where the contents >>> in one container may hide the contents in another container. >>> >>> I think this is subtle enough that it is worth a comment >>> in the code, >>> explaining that it is important to preserve the search >>> order used in the >>> uncached Location path. >>> >>> -- Jon >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Wed Apr 3 00:20:06 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 2 Apr 2019 20:20:06 -0400 Subject: RFR 8220792: JavacFileManager.list() performance In-Reply-To: <0023eee3-46ad-24a6-b6ed-1127e18b1105@oracle.com> References: <6ef2bdc4-3ce5-1ef0-c4f2-e195c1ee1842@oracle.com> <86018eba-aecb-0005-390d-0ce2b662a4df@oracle.com> <825a8a08-5213-ea02-c95e-d07ef5f1d734@oracle.com> <6f0588d7-b93d-985b-12fb-ce28a2acf0c1@oracle.com> <0023eee3-46ad-24a6-b6ed-1127e18b1105@oracle.com> Message-ID: Sounds good. Updated webrev: http://cr.openjdk.java.net/~ronsh/8220792/webrev.04/ On Tue, Apr 2, 2019 at 8:00 PM Jonathan Gibbons wrote: > Ron, > > In this case, I would just make the field protected. > > Arguably BaseFileManager has outlived its usefulness; it was introduced > when for a while we had two different file managers, one based on > java.io.File and another based on java.nio.file.Path. As you see, that > played out to what we have today, where one file manager supports both. I > don't foresee any additional need for separate use BaseFileManager, because > any additional file manager functionality should be based on using nio Path > and FileSystem. > > Bottom line, BaseFileManager and JavacFileManager are joined at the hip, > and may one day be fused together as one. So it's reasonable for > JavacFileManager to use protected fields of BaseFileManager. > > -- Jon > > On 04/02/2019 04:34 PM, Ron Shapiro wrote: > > Thanks for such a detailed review! > > I noticed one small thing - javacFileManagerOptions is private in the > superclass (BaseFileManager). I changed that reference to > Option.getJavaFileManagerOptions() instead, which is what that field is set > to also. Here's the updated webrev: > http://cr.openjdk.java.net/~ronsh/8220792/webrev.03/ > > Or, I can alternatively make the field protected. > > On Tue, Apr 2, 2019 at 6:31 PM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> OK, thanks for looking into this; I also looked at the code and agree >> with your assessment. >> >> One of these days we'll have some really good unit tests for >> JavacFileManager ;-) Until then, this looks good. >> >> -- Jon >> On 03/31/2019 05:04 AM, Ron Shapiro wrote: >> >> My initial inclination was to say that you were right, but that this >> would have been the case even before my change, since already >> ArchiveContainer did nothing to index parent directories of the directories >> that actually have files in the archive. But then I did some debugging to >> see what actually happens, and it seems that the archive filesystem visits >> all parent directories, and thus those are also indexed. Here's one example >> from running jtreg: >> >> indexing archivePath: .../asmtools.jar >> preVisit: / >> preVisit: /org >> preVisit: /org/openjdk >> preVisit: /org/openjdk/asmtools >> preVisit: /org/openjdk/asmtools/util >> preVisit: /org/openjdk/asmtools/jdis >> preVisit: /org/openjdk/asmtools/jdec >> preVisit: /org/openjdk/asmtools/jcoder >> preVisit: /org/openjdk/asmtools/jcdec >> preVisit: /org/openjdk/asmtools/jasm >> preVisit: /org/openjdk/asmtools/common >> preVisit: /org/openjdk/asmtools/asmutils >> preVisit: /META-INF >> >> I checked the code for ZipFileSystem, and it hard-codes the root >> directory as "/" for all zip files no matter the contents. >> >> So for the example above, list("org", recurse=true) should still recur >> properly. >> >> On Fri, Mar 29, 2019 at 9:21 PM Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> Ron, >>> >>> Although I've not checked in deep detail, I think there may be an >>> inherent problem with the caching you are doing, as regards to recursive >>> list. >>> >>> The list method takes a "recurse" parameter, which can be used to list >>> the contents of a package *and its subpackages*. >>> >>> If you have two containers, one containing package "p", and another >>> containing package "p.q", if you try a recursive list of "p", I believe >>> your code may miss the contents of "p.q" in the second container. If >>> nothing else, this is an important case to be checked and tested. Although >>> this feature is not typically used in javac itself, it is used in javadoc, >>> which also uses the same file manager. >>> >>> It may be that the cache needs to be smart enough to handle the case >>> when an archive has subdirectories of a package, even if it does not have >>> any direct contents of the package. >>> >>> -- Jon >>> On 3/29/19 7:10 AM, Ron Shapiro wrote: >>> >>> - Added a comment explaining the ordering. LMK if you have a better way >>> of explaining it, as I think you grok it better than I do >>> - Thanks for the pointer to javacFileManagerOptions. I updated to use >>> that. >>> Both are in this updated webrev: >>> http://cr.openjdk.java.net/~ronsh/8220792/webrev.02/ >>> >>> - Regarding indexing: I don't think today anything would detect updates >>> to a jar file if a new RelativeDirectory was added. Perhaps that's >>> intentional, because we don't care/don't even want to try to support >>> someone updating their jarfile in the middle of a compilation. I defer to >>> others about indexing other containers - it looks like the >>> JRTImageContainer depends on the JRTIndex class, which does a lazy >>> computation of the index, so it looks like it would be some additional work >>> to add that to the index. But perhaps it's not even worth it - IIUC, there >>> should only be one JRTImageContainer, and probably a limited amount of >>> DirectoryContainers - the performance issue that I was observing was that >>> with many jars, each needed to do some work for every call to list. We've >>> now reduced O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to >>> be small) + O(ArchiveContainer = possibly large)) per list() call >>> to O(O(JRTImageContainer = 1) + O(DirectoryContainer = likely to be >>> small) + O(overlapping ArchiveContainers, which is hopefully small)) >>> >>> >>> >>> On Wed, Mar 27, 2019 at 1:47 PM Jonathan Gibbons < >>> jonathan.gibbons at oracle.com> wrote: >>> >>>> >>>> On 3/27/19 9:06 AM, Ron Shapiro wrote: >>>> > >>>> > > It's not clear to me why you maintain the list of PathAndContainer >>>> > as a sorted list, and hence why you need to use java.util.List >>>> instead >>>> > of javac's List. >>>> > There are some tests that ensure that the classpath that javac sees >>>> is >>>> > equivalent to the classpath the JVM sees vis-a-vis ordering. Without >>>> > sorting, javac was seeing a different order, and I presume that is >>>> > because the JRTImageContainer and DirectoryContainers could appear >>>> > anywhere. Sorting solved that issue. >>>> >>>> OK, I think I understand the issue and why sorting fixes it. >>>> >>>> While some tests may check that "the classpath that javac sees is >>>> equivalent to the classpath the JVM sees vis-a-vis ordering", that's >>>> not >>>> the primary issue. The primary issue is that the new cache must >>>> preserve >>>> the order in which containers are searched on the classpath (i.e just >>>> within javac, separate from any part set by the JVM). While this is not >>>> so important when looking up classes in "well-behaved" packages, it is >>>> important when handling split packages and resources, where the >>>> contents >>>> in one container may hide the contents in another container. >>>> >>>> I think this is subtle enough that it is worth a comment in the code, >>>> explaining that it is important to preserve the search order used in >>>> the >>>> uncached Location path. >>>> >>>> -- Jon >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Thu Apr 4 09:13:27 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Apr 2019 10:13:27 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> On 4/2/19 10:12 PM, Roman Kennke wrote: > The main difference is that instead of ensuring correct invariant when > we store anything into the heap (e.g. read-barrier before reads, > write-barrier before writes, plus a bunch of other stuff), we ensure the > strong invariance on objects when they get loaded, by employing what is > currently our write-barrier. OK, so how does this work? Sure, the OOP load promotes an object to tospace, but how do you ensure that the OOP doesn't become stale when a later phase occurs? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Thu Apr 4 09:16:34 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 11:16:34 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> Message-ID: <59493b69-6ba6-8dfe-8ddb-97e172d17584@redhat.com> >> The main difference is that instead of ensuring correct invariant when >> we store anything into the heap (e.g. read-barrier before reads, >> write-barrier before writes, plus a bunch of other stuff), we ensure the >> strong invariance on objects when they get loaded, by employing what is >> currently our write-barrier. > > OK, so how does this work? Sure, the OOP load promotes an object to > tospace, but how do you ensure that the OOP doesn't become stale when > a later phase occurs? Whenever we start an evacuation phase, we pre-evacuate everything that's referenced by stack or registers, and update those stack slots and registers. (We did that with the old barrier-scheme too.) Roman From jan.lahoda at oracle.com Thu Apr 4 17:59:54 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 4 Apr 2019 19:59:54 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch Message-ID: <5CA6461A.1000905@oracle.com> Hi, When there is a switch over enum in the code, and is compiled into the bytecode, the meaning of the switch should not change even if the enum's constant are reordered. This is achieved by a map that maps the (current) enum constants to the appropriate case in the switch. This map is stored in a field in an auxiliary class, and filled when that auxiliary class is loaded in. But, if there are multiple switches over distinct enums under a single top-level class, the mapping fields for all the enums are stored in a single class. So, when any of these is needed, the mapping is constructed for all the enums, which may cause enum class initialization even in cases where it shouldn't happen. The proposed fix is to create a separate auxiliary classes for each enum/mapping. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 How does this look? Thanks, Jan From cushon at google.com Thu Apr 4 18:20:00 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 4 Apr 2019 11:20:00 -0700 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CA6461A.1000905@oracle.com> References: <5CA6461A.1000905@oracle.com> Message-ID: Hi Jan, There are a couple of other bugs about enum switch / class initialization issues that I think are addressed by this approach: https://bugs.openjdk.java.net/browse/JDK-7176515 https://bugs.openjdk.java.net/browse/JDK-8169526 Do you have a sense of how many additional auxiliary classes this will create for typical applications? I'm wondering if the number of additional classes might be large enough to effect performance (i.e. binary size, classloading). Were other lazy initialization patterns considered? JDK-7176515 mentions that ecj avoids this by caching the switch map in a field in the same class as the switch. On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda wrote: > Hi, > > When there is a switch over enum in the code, and is compiled into the > bytecode, the meaning of the switch should not change even if the enum's > constant are reordered. This is achieved by a map that maps the > (current) enum constants to the appropriate case in the switch. This map > is stored in a field in an auxiliary class, and filled when that > auxiliary class is loaded in. > > But, if there are multiple switches over distinct enums under a single > top-level class, the mapping fields for all the enums are stored in a > single class. So, when any of these is needed, the mapping is > constructed for all the enums, which may cause enum class initialization > even in cases where it shouldn't happen. > > The proposed fix is to create a separate auxiliary classes for each > enum/mapping. > > Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 > > How does this look? > > Thanks, > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Apr 4 18:39:12 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 4 Apr 2019 20:39:12 +0200 (CEST) Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: References: <5CA6461A.1000905@oracle.com> Message-ID: <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> Hi Jan, it seems like a perfect case for a constant dynamic, the array can be loaded using ldc and the bootstrap method takes the enum names as constant arguments. You doesn't have to create one class per switch, it's lazy initialized like any constant pool item and each switch on the same enum type can reuse the same, compare to the solution implemented by Eclipse, it's not a field but a constant pool constant you you can not mess with it using reflection and you don't need to check if the array was loaded or not in the fastpath. regards, R?mi > De: "Liam Miller-Cushon" > ?: "jan lahoda" > Cc: "compiler-dev" > Envoy?: Jeudi 4 Avril 2019 20:20:00 > Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > Hi Jan, > There are a couple of other bugs about enum switch / class initialization issues > that I think are addressed by this approach: > [ https://bugs.openjdk.java.net/browse/JDK-7176515 | > https://bugs.openjdk.java.net/browse/JDK-7176515 ] > [ https://bugs.openjdk.java.net/browse/JDK-8169526 | > https://bugs.openjdk.java.net/browse/JDK-8169526 ] > Do you have a sense of how many additional auxiliary classes this will create > for typical applications? I'm wondering if the number of additional classes > might be large enough to effect performance (i.e. binary size, classloading). > Were other lazy initialization patterns considered? JDK-7176515 mentions that > ecj avoids this by caching the switch map in a field in the same class as the > switch. > On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda < [ mailto:jan.lahoda at oracle.com | > jan.lahoda at oracle.com ] > wrote: >> Hi, >> When there is a switch over enum in the code, and is compiled into the >> bytecode, the meaning of the switch should not change even if the enum's >> constant are reordered. This is achieved by a map that maps the >> (current) enum constants to the appropriate case in the switch. This map >> is stored in a field in an auxiliary class, and filled when that >> auxiliary class is loaded in. >> But, if there are multiple switches over distinct enums under a single >> top-level class, the mapping fields for all the enums are stored in a >> single class. So, when any of these is needed, the mapping is >> constructed for all the enums, which may cause enum class initialization >> even in cases where it shouldn't happen. >> The proposed fix is to create a separate auxiliary classes for each >> enum/mapping. >> Proposed patch: [ http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ | >> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ ] >> JBS: [ https://bugs.openjdk.java.net/browse/JDK-8219412 | >> https://bugs.openjdk.java.net/browse/JDK-8219412 ] >> How does this look? >> Thanks, >> Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu Apr 4 18:50:38 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 4 Apr 2019 14:50:38 -0400 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CA6461A.1000905@oracle.com> References: <5CA6461A.1000905@oracle.com> Message-ID: <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> Note that when we switch to translating with indy, this can be cached at the indy call site.? (And, in the case where the compile-time and run-time numberings are the same, we can even, if we like, eliminate the indirection through the array.) On 4/4/2019 1:59 PM, Jan Lahoda wrote: > Hi, > > When there is a switch over enum in the code, and is compiled into the > bytecode, the meaning of the switch should not change even if the > enum's constant are reordered. This is achieved by a map that maps the > (current) enum constants to the appropriate case in the switch. This > map is stored in a field in an auxiliary class, and filled when that > auxiliary class is loaded in. > > But, if there are multiple switches over distinct enums under a single > top-level class, the mapping fields for all the enums are stored in a > single class. So, when any of these is needed, the mapping is > constructed for all the enums, which may cause enum class > initialization even in cases where it shouldn't happen. > > The proposed fix is to create a separate auxiliary classes for each > enum/mapping. > > Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 > > How does this look? > > Thanks, > ??? Jan From forax at univ-mlv.fr Fri Apr 5 06:18:55 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 5 Apr 2019 08:18:55 +0200 (CEST) Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> Message-ID: <1226286565.1973420.1554445135317.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "jan lahoda" , "compiler-dev" > Envoy?: Jeudi 4 Avril 2019 20:50:38 > Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > Note that when we switch to translating with indy, this can be cached at > the indy call site.? (And, in the case where the compile-time and > run-time numberings are the same, we can even, if we like, eliminate the > indirection through the array.) yes, you may still need the constant dynamic to share the array if there are several switches on the same enum. R?mi > > On 4/4/2019 1:59 PM, Jan Lahoda wrote: >> Hi, >> >> When there is a switch over enum in the code, and is compiled into the >> bytecode, the meaning of the switch should not change even if the >> enum's constant are reordered. This is achieved by a map that maps the >> (current) enum constants to the appropriate case in the switch. This >> map is stored in a field in an auxiliary class, and filled when that >> auxiliary class is loaded in. >> >> But, if there are multiple switches over distinct enums under a single >> top-level class, the mapping fields for all the enums are stored in a >> single class. So, when any of these is needed, the mapping is >> constructed for all the enums, which may cause enum class >> initialization even in cases where it shouldn't happen. >> >> The proposed fix is to create a separate auxiliary classes for each >> enum/mapping. >> >> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >> >> How does this look? >> >> Thanks, > > ??? Jan From jan.lahoda at oracle.com Fri Apr 5 11:39:29 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 5 Apr 2019 13:39:29 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: References: <5CA6461A.1000905@oracle.com> Message-ID: <5CA73E71.4020901@oracle.com> Hi Liam, On 4.4.2019 20:20, Liam Miller-Cushon wrote: > Hi Jan, > > There are a couple of other bugs about enum switch / class > initialization issues that I think are addressed by this approach: > https://bugs.openjdk.java.net/browse/JDK-7176515 > https://bugs.openjdk.java.net/browse/JDK-8169526 Yes, those should be hopefully fixed as well. > > Do you have a sense of how many additional auxiliary classes this will > create for typical applications? I'm wondering if the number of > additional classes might be large enough to effect performance (i.e. > binary size, classloading). For OpenJDK, there are ~150 additional classes (from 30267 to 30415). > > Were other lazy initialization patterns considered? JDK-7176515 mentions > that ecj avoids this by caching the switch map in a field in the same > class as the switch. I didn't really want to change the balances in the desugaring except as really necessary. The current desugaring shares the mapping for any given enum across the whole top-level class, which cannot (I think) be easily achieved when the field is in the actual class that uses it. This is particularly because of the foreseen change to indy desugaring. Jan > > On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda > wrote: > > Hi, > > When there is a switch over enum in the code, and is compiled into the > bytecode, the meaning of the switch should not change even if the > enum's > constant are reordered. This is achieved by a map that maps the > (current) enum constants to the appropriate case in the switch. This > map > is stored in a field in an auxiliary class, and filled when that > auxiliary class is loaded in. > > But, if there are multiple switches over distinct enums under a single > top-level class, the mapping fields for all the enums are stored in a > single class. So, when any of these is needed, the mapping is > constructed for all the enums, which may cause enum class > initialization > even in cases where it shouldn't happen. > > The proposed fix is to create a separate auxiliary classes for each > enum/mapping. > > Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 > > How does this look? > > Thanks, > Jan > From jan.lahoda at oracle.com Fri Apr 5 11:58:22 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 5 Apr 2019 13:58:22 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> Message-ID: <5CA742DE.2070808@oracle.com> On 4.4.2019 20:50, Brian Goetz wrote: > Note that when we switch to translating with indy, this can be cached at > the indy call site. (And, in the case where the compile-time and > run-time numberings are the same, we can even, if we like, eliminate the > indirection through the array.) Yes, with the indy desugaring this all goes away. But I suspect it will probably take some time before we switch to that, so seemed prudent to fix using the approach we currently have. Jan > > On 4/4/2019 1:59 PM, Jan Lahoda wrote: >> Hi, >> >> When there is a switch over enum in the code, and is compiled into the >> bytecode, the meaning of the switch should not change even if the >> enum's constant are reordered. This is achieved by a map that maps the >> (current) enum constants to the appropriate case in the switch. This >> map is stored in a field in an auxiliary class, and filled when that >> auxiliary class is loaded in. >> >> But, if there are multiple switches over distinct enums under a single >> top-level class, the mapping fields for all the enums are stored in a >> single class. So, when any of these is needed, the mapping is >> constructed for all the enums, which may cause enum class >> initialization even in cases where it shouldn't happen. >> >> The proposed fix is to create a separate auxiliary classes for each >> enum/mapping. >> >> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >> >> How does this look? >> >> Thanks, >> Jan > From jan.lahoda at oracle.com Fri Apr 5 11:56:58 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 5 Apr 2019 13:56:58 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> References: <5CA6461A.1000905@oracle.com> <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> Message-ID: <5CA7428A.9000304@oracle.com> On 4.4.2019 20:39, Remi Forax wrote: > Hi Jan, > it seems like a perfect case for a constant dynamic, > the array can be loaded using ldc and the bootstrap method takes the > enum names as constant arguments. True, I didn't realize that. javac does not currently (AFAIK) have a way to generate condy, so we first need support for condy in javac. This patch strives to do that: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.condy.01/ based on Vicente's: http://hg.openjdk.java.net/amber/amber/rev/8e2f2d280e44 The usage to use that to generate the condy where available (and fall back on generating the holder classes where not available): http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ (The downside of that is that when indy switch desugaring will be implemented, there will be three distinct desugarings for switches over enums.) > > You doesn't have to create one class per switch, it's lazy initialized Please note that neither the original patch, nor the current javac state, creates a class per switch. It creates a field (and with the .00 version of the patch a class) per enum used as switch selector per top-level class. Jan > like any constant pool item and each switch on the same enum type can > reuse the same, > compare to the solution implemented by Eclipse, it's not a field but a > constant pool constant you you can not mess with it using reflection and > you don't need to check if the array was loaded or not in the fastpath. > > regards, > R?mi > > ------------------------------------------------------------------------ > > *De: *"Liam Miller-Cushon" > *?: *"jan lahoda" > *Cc: *"compiler-dev" > *Envoy?: *Jeudi 4 Avril 2019 20:20:00 > *Objet: *Re: RFR: JDK-8219412: Eager enum class initialization with > enum switch > > Hi Jan, > There are a couple of other bugs about enum switch / class > initialization issues that I think are addressed by this approach: > https://bugs.openjdk.java.net/browse/JDK-7176515 > https://bugs.openjdk.java.net/browse/JDK-8169526 > > Do you have a sense of how many additional auxiliary classes this > will create for typical applications? I'm wondering if the number of > additional classes might be large enough to effect performance (i.e. > binary size, classloading). > > Were other lazy initialization patterns considered? JDK-7176515 > mentions that ecj avoids this by caching the switch map in a field > in the same class as the switch. > > On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda > wrote: > > Hi, > > When there is a switch over enum in the code, and is compiled > into the > bytecode, the meaning of the switch should not change even if > the enum's > constant are reordered. This is achieved by a map that maps the > (current) enum constants to the appropriate case in the switch. > This map > is stored in a field in an auxiliary class, and filled when that > auxiliary class is loaded in. > > But, if there are multiple switches over distinct enums under a > single > top-level class, the mapping fields for all the enums are stored > in a > single class. So, when any of these is needed, the mapping is > constructed for all the enums, which may cause enum class > initialization > even in cases where it shouldn't happen. > > The proposed fix is to create a separate auxiliary classes for each > enum/mapping. > > Proposed patch: > http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 > > How does this look? > > Thanks, > Jan > > From forax at univ-mlv.fr Fri Apr 5 17:14:34 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 5 Apr 2019 19:14:34 +0200 (CEST) Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CA7428A.9000304@oracle.com> References: <5CA6461A.1000905@oracle.com> <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> <5CA7428A.9000304@oracle.com> Message-ID: <43405028.2226125.1554484474211.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jan lahoda" > ?: "Remi Forax" > Cc: "compiler-dev" , "Liam Miller-Cushon" > Envoy?: Vendredi 5 Avril 2019 13:56:58 > Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > On 4.4.2019 20:39, Remi Forax wrote: >> Hi Jan, >> it seems like a perfect case for a constant dynamic, >> the array can be loaded using ldc and the bootstrap method takes the >> enum names as constant arguments. > > True, I didn't realize that. javac does not currently (AFAIK) have a way > to generate condy, so we first need support for condy in javac. This > patch strives to do that: > http://cr.openjdk.java.net/~jlahoda/8219412/webrev.condy.01/ > based on Vicente's: > http://hg.openjdk.java.net/amber/amber/rev/8e2f2d280e44 > > The usage to use that to generate the condy where available (and fall > back on generating the holder classes where not available): > http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ The description of an enum (EnumMapping) can be encoded by the enum class and an array of String (in the order of the enum values at compile time). So instead of generating one specific method per enum that initializes the mapping table and using it as a bootstrap method, i believe it's better to have one bootstrap method in the JDK (let say in java.lang.invoke.ConstantBootstraps) that takes the enum class and an array of Strings. This method will use ConstantBootstraps.enumConstant to get the corresponding enum value at runtime (which does the security checks) and a call ordinal() on each enum value in order to dynamically create the mapping table. This will reduce the size of the generated bytecode by removing the need to have one bootstrap method per enum. Also in Target.java, constant dynamic is available since 11 but if there is a need of a new BSM in ConstantBootstraps, it should be since 13 (apart if the patch is backported to 11). > > (The downside of that is that when indy switch desugaring will be > implemented, there will be three distinct desugarings for switches over > enums.) yes, as you said, we may able to share some code in the future, we will see when we get there. > >> >> You doesn't have to create one class per switch, it's lazy initialized > > Please note that neither the original patch, nor the current javac > state, creates a class per switch. It creates a field (and with the .00 > version of the patch a class) per enum used as switch selector per > top-level class. yes > > Jan R?mi > >> like any constant pool item and each switch on the same enum type can >> reuse the same, >> compare to the solution implemented by Eclipse, it's not a field but a >> constant pool constant you you can not mess with it using reflection and >> you don't need to check if the array was loaded or not in the fastpath. >> >> regards, >> R?mi >> >> ------------------------------------------------------------------------ >> >> *De: *"Liam Miller-Cushon" >> *?: *"jan lahoda" >> *Cc: *"compiler-dev" >> *Envoy?: *Jeudi 4 Avril 2019 20:20:00 >> *Objet: *Re: RFR: JDK-8219412: Eager enum class initialization with >> enum switch >> >> Hi Jan, >> There are a couple of other bugs about enum switch / class >> initialization issues that I think are addressed by this approach: >> https://bugs.openjdk.java.net/browse/JDK-7176515 >> https://bugs.openjdk.java.net/browse/JDK-8169526 >> >> Do you have a sense of how many additional auxiliary classes this >> will create for typical applications? I'm wondering if the number of >> additional classes might be large enough to effect performance (i.e. >> binary size, classloading). >> >> Were other lazy initialization patterns considered? JDK-7176515 >> mentions that ecj avoids this by caching the switch map in a field >> in the same class as the switch. >> >> On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda > > wrote: >> >> Hi, >> >> When there is a switch over enum in the code, and is compiled >> into the >> bytecode, the meaning of the switch should not change even if >> the enum's >> constant are reordered. This is achieved by a map that maps the >> (current) enum constants to the appropriate case in the switch. >> This map >> is stored in a field in an auxiliary class, and filled when that >> auxiliary class is loaded in. >> >> But, if there are multiple switches over distinct enums under a >> single >> top-level class, the mapping fields for all the enums are stored >> in a >> single class. So, when any of these is needed, the mapping is >> constructed for all the enums, which may cause enum class >> initialization >> even in cases where it shouldn't happen. >> >> The proposed fix is to create a separate auxiliary classes for each >> enum/mapping. >> >> Proposed patch: >> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >> >> How does this look? >> >> Thanks, >> Jan >> From jan.lahoda at oracle.com Fri Apr 5 17:35:35 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 5 Apr 2019 19:35:35 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <43405028.2226125.1554484474211.JavaMail.zimbra@u-pem.fr> References: <5CA6461A.1000905@oracle.com> <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> <5CA7428A.9000304@oracle.com> <43405028.2226125.1554484474211.JavaMail.zimbra@u-pem.fr> Message-ID: <5CA791E7.6050605@oracle.com> On 5.4.2019 19:14, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "jan lahoda" >> ?: "Remi Forax" >> Cc: "compiler-dev" , "Liam Miller-Cushon" >> Envoy?: Vendredi 5 Avril 2019 13:56:58 >> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > >> On 4.4.2019 20:39, Remi Forax wrote: >>> Hi Jan, >>> it seems like a perfect case for a constant dynamic, >>> the array can be loaded using ldc and the bootstrap method takes the >>> enum names as constant arguments. >> >> True, I didn't realize that. javac does not currently (AFAIK) have a way >> to generate condy, so we first need support for condy in javac. This >> patch strives to do that: >> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.condy.01/ >> based on Vicente's: >> http://hg.openjdk.java.net/amber/amber/rev/8e2f2d280e44 >> >> The usage to use that to generate the condy where available (and fall >> back on generating the holder classes where not available): >> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ > > The description of an enum (EnumMapping) can be encoded by the enum class and an array of String (in the order of the enum values at compile time). > So instead of generating one specific method per enum that initializes the mapping table and using it as a bootstrap method, i believe it's better to have one bootstrap method in the JDK (let say in java.lang.invoke.ConstantBootstraps) that takes the enum class and an array of Strings. This method will use ConstantBootstraps.enumConstant to get the corresponding enum value at runtime (which does the security checks) and a call ordinal() on each enum value in order to dynamically create the mapping table. > This will reduce the size of the generated bytecode by removing the need to have one bootstrap method per enum. Well, this is effectively the "use condy for switch" effort, right? (The enumSwitch method from: http://hg.openjdk.java.net/amber/amber/file/4461b14e6543/src/java.base/share/classes/java/lang/compiler/SwitchBootstraps.java is relevant, as is stringSwitch for switch-over-strings.) Not sure if we have time for that for 13. Jan > > Also in Target.java, constant dynamic is available since 11 but if there is a need of a new BSM in ConstantBootstraps, it should be since 13 (apart if the patch is backported to 11). > > >> >> (The downside of that is that when indy switch desugaring will be >> implemented, there will be three distinct desugarings for switches over >> enums.) > > yes, as you said, we may able to share some code in the future, we will see when we get there. > >> >>> >>> You doesn't have to create one class per switch, it's lazy initialized >> >> Please note that neither the original patch, nor the current javac >> state, creates a class per switch. It creates a field (and with the .00 >> version of the patch a class) per enum used as switch selector per >> top-level class. > > > yes > >> >> Jan > > R?mi > >> >>> like any constant pool item and each switch on the same enum type can >>> reuse the same, >>> compare to the solution implemented by Eclipse, it's not a field but a >>> constant pool constant you you can not mess with it using reflection and >>> you don't need to check if the array was loaded or not in the fastpath. >>> >>> regards, >>> R?mi >>> >>> ------------------------------------------------------------------------ >>> >>> *De: *"Liam Miller-Cushon" >>> *?: *"jan lahoda" >>> *Cc: *"compiler-dev" >>> *Envoy?: *Jeudi 4 Avril 2019 20:20:00 >>> *Objet: *Re: RFR: JDK-8219412: Eager enum class initialization with >>> enum switch >>> >>> Hi Jan, >>> There are a couple of other bugs about enum switch / class >>> initialization issues that I think are addressed by this approach: >>> https://bugs.openjdk.java.net/browse/JDK-7176515 >>> https://bugs.openjdk.java.net/browse/JDK-8169526 >>> >>> Do you have a sense of how many additional auxiliary classes this >>> will create for typical applications? I'm wondering if the number of >>> additional classes might be large enough to effect performance (i.e. >>> binary size, classloading). >>> >>> Were other lazy initialization patterns considered? JDK-7176515 >>> mentions that ecj avoids this by caching the switch map in a field >>> in the same class as the switch. >>> >>> On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda >> > wrote: >>> >>> Hi, >>> >>> When there is a switch over enum in the code, and is compiled >>> into the >>> bytecode, the meaning of the switch should not change even if >>> the enum's >>> constant are reordered. This is achieved by a map that maps the >>> (current) enum constants to the appropriate case in the switch. >>> This map >>> is stored in a field in an auxiliary class, and filled when that >>> auxiliary class is loaded in. >>> >>> But, if there are multiple switches over distinct enums under a >>> single >>> top-level class, the mapping fields for all the enums are stored >>> in a >>> single class. So, when any of these is needed, the mapping is >>> constructed for all the enums, which may cause enum class >>> initialization >>> even in cases where it shouldn't happen. >>> >>> The proposed fix is to create a separate auxiliary classes for each >>> enum/mapping. >>> >>> Proposed patch: >>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>> >>> How does this look? >>> >>> Thanks, >>> Jan >>> From forax at univ-mlv.fr Fri Apr 5 21:23:42 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 5 Apr 2019 23:23:42 +0200 (CEST) Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CA791E7.6050605@oracle.com> References: <5CA6461A.1000905@oracle.com> <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> <5CA7428A.9000304@oracle.com> <43405028.2226125.1554484474211.JavaMail.zimbra@u-pem.fr> <5CA791E7.6050605@oracle.com> Message-ID: <813332466.2247012.1554499422983.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jan lahoda" > ?: "Remi Forax" > Cc: "compiler-dev" , "Liam Miller-Cushon" > Envoy?: Vendredi 5 Avril 2019 19:35:35 > Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > On 5.4.2019 19:14, forax at univ-mlv.fr wrote: >> ----- Mail original ----- >>> De: "jan lahoda" >>> ?: "Remi Forax" >>> Cc: "compiler-dev" , "Liam Miller-Cushon" >>> >>> Envoy?: Vendredi 5 Avril 2019 13:56:58 >>> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch >> >>> On 4.4.2019 20:39, Remi Forax wrote: >>>> Hi Jan, >>>> it seems like a perfect case for a constant dynamic, >>>> the array can be loaded using ldc and the bootstrap method takes the >>>> enum names as constant arguments. >>> >>> True, I didn't realize that. javac does not currently (AFAIK) have a way >>> to generate condy, so we first need support for condy in javac. This >>> patch strives to do that: >>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.condy.01/ >>> based on Vicente's: >>> http://hg.openjdk.java.net/amber/amber/rev/8e2f2d280e44 >>> >>> The usage to use that to generate the condy where available (and fall >>> back on generating the holder classes where not available): >>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ >> >> The description of an enum (EnumMapping) can be encoded by the enum class and an >> array of String (in the order of the enum values at compile time). >> So instead of generating one specific method per enum that initializes the >> mapping table and using it as a bootstrap method, i believe it's better to have >> one bootstrap method in the JDK (let say in >> java.lang.invoke.ConstantBootstraps) that takes the enum class and an array of >> Strings. This method will use ConstantBootstraps.enumConstant to get the >> corresponding enum value at runtime (which does the security checks) and a call >> ordinal() on each enum value in order to dynamically create the mapping table. >> This will reduce the size of the generated bytecode by removing the need to have >> one bootstrap method per enum. > > Well, this is effectively the "use condy for switch" effort, right? yes ! > > (The enumSwitch method from: > http://hg.openjdk.java.net/amber/amber/file/4461b14e6543/src/java.base/share/classes/java/lang/compiler/SwitchBootstraps.java > > is relevant, as is stringSwitch for switch-over-strings.) Not sure if we > have time for that for 13. The switch-over-enum proposed by SwitchBootstraps uses an invokedynamic and understanding the perf of indy is not that simple. The code you are proposing uses condy, i think we should keep it that way. At the same time, your patch generates bytecodes to initialize the array. I think this is an overkill. As shown by SwitchBootstraps.enumSwitch, you can represent the information that the compiler see at compile time with an enum class and an array of enum value names, so what i'm proposing is to still use condy to load the array of enum constants but to only use one bootstrap method that dynamically create the array. For the compiler, it's easier because you generate less bytecodes (it's not fully true because it seems the compiler generate the EnumMapping pretty early), in term of bugs, because you always call the same bootstrap method which is inside the JDK, if there is a bug, you can fix it without changing neither the compiler not the generated code, and it makes the .class slimmer which is usually a win. so the idea is to still use condy but initialize it by sending a call and an array of strings instead of initialize it by a special tailored bootstrap method. to be 100% clear, here is the BSM i think we should use: public static int initEnumMappingArray(Lookup lookup, String name, Class type, // should be int[].class Class enumClass, String... enumNames) { requireNonNull(lookup); requireNonNull(name); requireNonNull(type); validateClassAccess(lookup, enumClass); // does the class that contains the ldc condy can see the array? int length = enumClass.getEnumConstants().length; int[] array = new int[length]; for(int i = 0; i < enumNames.length; i++) { try { Enum enumValue = Enum.valueOf(enumClass, enumNames[i]); array[enumValue.ordinal()] = i + 1; } catch (IllegalArgumentException e) { // empty } } return array; } This is the same code as the code which is generated currently by the compiler, it can be optimized using java.lang.Class internals but this can be done later > > Jan R?mi > >> >> Also in Target.java, constant dynamic is available since 11 but if there is a >> need of a new BSM in ConstantBootstraps, it should be since 13 (apart if the >> patch is backported to 11). >> >> >>> >>> (The downside of that is that when indy switch desugaring will be >>> implemented, there will be three distinct desugarings for switches over >>> enums.) >> >> yes, as you said, we may able to share some code in the future, we will see when >> we get there. >> >>> >>>> >>>> You doesn't have to create one class per switch, it's lazy initialized >>> >>> Please note that neither the original patch, nor the current javac >>> state, creates a class per switch. It creates a field (and with the .00 >>> version of the patch a class) per enum used as switch selector per >>> top-level class. >> >> >> yes >> >>> >>> Jan >> >> R?mi >> >>> >>>> like any constant pool item and each switch on the same enum type can >>>> reuse the same, >>>> compare to the solution implemented by Eclipse, it's not a field but a >>>> constant pool constant you you can not mess with it using reflection and >>>> you don't need to check if the array was loaded or not in the fastpath. >>>> >>>> regards, >>>> R?mi >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *De: *"Liam Miller-Cushon" >>>> *?: *"jan lahoda" >>>> *Cc: *"compiler-dev" >>>> *Envoy?: *Jeudi 4 Avril 2019 20:20:00 >>>> *Objet: *Re: RFR: JDK-8219412: Eager enum class initialization with >>>> enum switch >>>> >>>> Hi Jan, >>>> There are a couple of other bugs about enum switch / class >>>> initialization issues that I think are addressed by this approach: >>>> https://bugs.openjdk.java.net/browse/JDK-7176515 >>>> https://bugs.openjdk.java.net/browse/JDK-8169526 >>>> >>>> Do you have a sense of how many additional auxiliary classes this >>>> will create for typical applications? I'm wondering if the number of >>>> additional classes might be large enough to effect performance (i.e. >>>> binary size, classloading). >>>> >>>> Were other lazy initialization patterns considered? JDK-7176515 >>>> mentions that ecj avoids this by caching the switch map in a field >>>> in the same class as the switch. >>>> >>>> On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda >>> > wrote: >>>> >>>> Hi, >>>> >>>> When there is a switch over enum in the code, and is compiled >>>> into the >>>> bytecode, the meaning of the switch should not change even if >>>> the enum's >>>> constant are reordered. This is achieved by a map that maps the >>>> (current) enum constants to the appropriate case in the switch. >>>> This map >>>> is stored in a field in an auxiliary class, and filled when that >>>> auxiliary class is loaded in. >>>> >>>> But, if there are multiple switches over distinct enums under a >>>> single >>>> top-level class, the mapping fields for all the enums are stored >>>> in a >>>> single class. So, when any of these is needed, the mapping is >>>> constructed for all the enums, which may cause enum class >>>> initialization >>>> even in cases where it shouldn't happen. >>>> >>>> The proposed fix is to create a separate auxiliary classes for each >>>> enum/mapping. >>>> >>>> Proposed patch: >>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> Jan From aph at redhat.com Sun Apr 7 16:47:14 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 7 Apr 2019 17:47:14 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> On 4/2/19 10:12 PM, Roman Kennke wrote: > - No more need for object equals barriers. I'm pleased about that. I really hated the AArch64 Shenandoah CAS! -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Sun Apr 7 18:18:03 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 20:18:03 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> Message-ID: On 4/2/19 10:12 PM, Roman Kennke wrote: > > - No more need for object equals barriers. > > I'm pleased about that. I really hated the AArch64 Shenandoah CAS! I'm sorry to disappoint you, but the CAS barrier is still needed. The memory location may still legally hold a from-space reference, and comparing that to a to-space reference needs some special care. And yes, ZGC has a similar problem as far as I know. Roman From jan.lahoda at oracle.com Mon Apr 8 08:17:05 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 8 Apr 2019 10:17:05 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <813332466.2247012.1554499422983.JavaMail.zimbra@u-pem.fr> References: <5CA6461A.1000905@oracle.com> <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> <5CA7428A.9000304@oracle.com> <43405028.2226125.1554484474211.JavaMail.zimbra@u-pem.fr> <5CA791E7.6050605@oracle.com> <813332466.2247012.1554499422983.JavaMail.zimbra@u-pem.fr> Message-ID: <5CAB0381.3010202@oracle.com> Hi Remi, Even though I understand what you mean, not sure if it is appropriate to do this here (i.e. under an ordinary P3 bug). If we only had the switch-over-enum, then it might be OK. But we even currently have the switch-over-string, and foresee a possibility of more complex switches, and this switch-over-enum bootstrap may the outlier among the other bootstraps (or maybe not; or maybe that is OK; but without a more general consideration, it is difficult to tell). I'd be much more inclined to either: -use a local solution that is not much different from the current state (i.e. version .00 or possibly .01 of this patch), and convert to the switch bootstrap when that's done -work on the complete switch bootstraps effort, and accept it may take some time before this bug is fixed. Thanks, Jan On 5.4.2019 23:23, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "jan lahoda" >> ?: "Remi Forax" >> Cc: "compiler-dev" , "Liam Miller-Cushon" >> Envoy?: Vendredi 5 Avril 2019 19:35:35 >> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > >> On 5.4.2019 19:14, forax at univ-mlv.fr wrote: >>> ----- Mail original ----- >>>> De: "jan lahoda" >>>> ?: "Remi Forax" >>>> Cc: "compiler-dev" , "Liam Miller-Cushon" >>>> >>>> Envoy?: Vendredi 5 Avril 2019 13:56:58 >>>> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch >>> >>>> On 4.4.2019 20:39, Remi Forax wrote: >>>>> Hi Jan, >>>>> it seems like a perfect case for a constant dynamic, >>>>> the array can be loaded using ldc and the bootstrap method takes the >>>>> enum names as constant arguments. >>>> >>>> True, I didn't realize that. javac does not currently (AFAIK) have a way >>>> to generate condy, so we first need support for condy in javac. This >>>> patch strives to do that: >>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.condy.01/ >>>> based on Vicente's: >>>> http://hg.openjdk.java.net/amber/amber/rev/8e2f2d280e44 >>>> >>>> The usage to use that to generate the condy where available (and fall >>>> back on generating the holder classes where not available): >>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ >>> >>> The description of an enum (EnumMapping) can be encoded by the enum class and an >>> array of String (in the order of the enum values at compile time). >>> So instead of generating one specific method per enum that initializes the >>> mapping table and using it as a bootstrap method, i believe it's better to have >>> one bootstrap method in the JDK (let say in >>> java.lang.invoke.ConstantBootstraps) that takes the enum class and an array of >>> Strings. This method will use ConstantBootstraps.enumConstant to get the >>> corresponding enum value at runtime (which does the security checks) and a call >>> ordinal() on each enum value in order to dynamically create the mapping table. >>> This will reduce the size of the generated bytecode by removing the need to have >>> one bootstrap method per enum. >> >> Well, this is effectively the "use condy for switch" effort, right? > > yes ! > >> >> (The enumSwitch method from: >> http://hg.openjdk.java.net/amber/amber/file/4461b14e6543/src/java.base/share/classes/java/lang/compiler/SwitchBootstraps.java >> >> is relevant, as is stringSwitch for switch-over-strings.) Not sure if we >> have time for that for 13. > > The switch-over-enum proposed by SwitchBootstraps uses an invokedynamic and understanding the perf of indy is not that simple. > The code you are proposing uses condy, i think we should keep it that way. > > At the same time, your patch generates bytecodes to initialize the array. I think this is an overkill. > As shown by SwitchBootstraps.enumSwitch, you can represent the information that the compiler see at compile time with an enum class and an array of enum value names, > so what i'm proposing is to still use condy to load the array of enum constants but to only use one bootstrap method that dynamically create the array. > > For the compiler, it's easier because you generate less bytecodes (it's not fully true because it seems the compiler generate the EnumMapping pretty early), > in term of bugs, because you always call the same bootstrap method which is inside the JDK, if there is a bug, you can fix it without changing neither the compiler not the generated code, > and it makes the .class slimmer which is usually a win. > > so the idea is to still use condy but initialize it by sending a call and an array of strings instead of initialize it by a special tailored bootstrap method. > > to be 100% clear, here is the BSM i think we should use: > public static int initEnumMappingArray(Lookup lookup, > String name, > Class type, // should be int[].class > Class enumClass, > String... enumNames) { > requireNonNull(lookup); > requireNonNull(name); > requireNonNull(type); > validateClassAccess(lookup, enumClass); // does the class that contains the ldc condy can see the array? > > int length = enumClass.getEnumConstants().length; > int[] array = new int[length]; > for(int i = 0; i < enumNames.length; i++) { > try { > Enum enumValue = Enum.valueOf(enumClass, enumNames[i]); > array[enumValue.ordinal()] = i + 1; > } catch (IllegalArgumentException e) { > // empty > } > } > return array; > } > > This is the same code as the code which is generated currently by the compiler, > it can be optimized using java.lang.Class internals but this can be done later > >> >> Jan > > R?mi > >> >>> >>> Also in Target.java, constant dynamic is available since 11 but if there is a >>> need of a new BSM in ConstantBootstraps, it should be since 13 (apart if the >>> patch is backported to 11). >>> >>> >>>> >>>> (The downside of that is that when indy switch desugaring will be >>>> implemented, there will be three distinct desugarings for switches over >>>> enums.) >>> >>> yes, as you said, we may able to share some code in the future, we will see when >>> we get there. >>> >>>> >>>>> >>>>> You doesn't have to create one class per switch, it's lazy initialized >>>> >>>> Please note that neither the original patch, nor the current javac >>>> state, creates a class per switch. It creates a field (and with the .00 >>>> version of the patch a class) per enum used as switch selector per >>>> top-level class. >>> >>> >>> yes >>> >>>> >>>> Jan >>> >>> R?mi >>> >>>> >>>>> like any constant pool item and each switch on the same enum type can >>>>> reuse the same, >>>>> compare to the solution implemented by Eclipse, it's not a field but a >>>>> constant pool constant you you can not mess with it using reflection and >>>>> you don't need to check if the array was loaded or not in the fastpath. >>>>> >>>>> regards, >>>>> R?mi >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> *De: *"Liam Miller-Cushon" >>>>> *?: *"jan lahoda" >>>>> *Cc: *"compiler-dev" >>>>> *Envoy?: *Jeudi 4 Avril 2019 20:20:00 >>>>> *Objet: *Re: RFR: JDK-8219412: Eager enum class initialization with >>>>> enum switch >>>>> >>>>> Hi Jan, >>>>> There are a couple of other bugs about enum switch / class >>>>> initialization issues that I think are addressed by this approach: >>>>> https://bugs.openjdk.java.net/browse/JDK-7176515 >>>>> https://bugs.openjdk.java.net/browse/JDK-8169526 >>>>> >>>>> Do you have a sense of how many additional auxiliary classes this >>>>> will create for typical applications? I'm wondering if the number of >>>>> additional classes might be large enough to effect performance (i.e. >>>>> binary size, classloading). >>>>> >>>>> Were other lazy initialization patterns considered? JDK-7176515 >>>>> mentions that ecj avoids this by caching the switch map in a field >>>>> in the same class as the switch. >>>>> >>>>> On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> When there is a switch over enum in the code, and is compiled >>>>> into the >>>>> bytecode, the meaning of the switch should not change even if >>>>> the enum's >>>>> constant are reordered. This is achieved by a map that maps the >>>>> (current) enum constants to the appropriate case in the switch. >>>>> This map >>>>> is stored in a field in an auxiliary class, and filled when that >>>>> auxiliary class is loaded in. >>>>> >>>>> But, if there are multiple switches over distinct enums under a >>>>> single >>>>> top-level class, the mapping fields for all the enums are stored >>>>> in a >>>>> single class. So, when any of these is needed, the mapping is >>>>> constructed for all the enums, which may cause enum class >>>>> initialization >>>>> even in cases where it shouldn't happen. >>>>> >>>>> The proposed fix is to create a separate auxiliary classes for each >>>>> enum/mapping. >>>>> >>>>> Proposed patch: >>>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>>>> >>>>> How does this look? >>>>> >>>>> Thanks, >>>>> Jan From aph at redhat.com Mon Apr 8 08:28:59 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Apr 2019 09:28:59 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> Message-ID: <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> On 4/7/19 7:18 PM, Roman Kennke wrote: > On 4/2/19 10:12 PM, Roman Kennke wrote: >>> - No more need for object equals barriers. >> >> I'm pleased about that. I really hated the AArch64 Shenandoah CAS! > > I'm sorry to disappoint you, but the CAS barrier is still needed. The > memory location may still legally hold a from-space reference, and > comparing that to a to-space reference needs some special care. And > yes, ZGC has a similar problem as far as I know. That's interesting. Could we not simply promote the reference in the reference field we're CASing, then do a normal CAS? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Apr 8 08:36:05 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 10:36:05 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> Message-ID: On 4/7/19 7:18 PM, Roman Kennke wrote: > > On 4/2/19 10:12 PM, Roman Kennke wrote: > > > > - No more need for object equals barriers. > > > > > > I'm pleased about that. I really hated the AArch64 Shenandoah > > > CAS! > > > > I'm sorry to disappoint you, but the CAS barrier is still needed. > > The > > memory location may still legally hold a from-space reference, and > > comparing that to a to-space reference needs some special care. And > > yes, ZGC has a similar problem as far as I know. > > That's interesting. Could we not simply promote the reference in the > reference field we're CASing, then do a normal CAS? Yes. But it requires two CASes in a row. Don't know if that is better than our loop, which is rarely even entered (normally the CAS-construct goes via fast-path with a single CAS). Roman From aph at redhat.com Mon Apr 8 09:19:21 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Apr 2019 10:19:21 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> Message-ID: <0cb44e4b-8967-48bd-5f77-e0c443b63410@redhat.com> On 4/8/19 9:36 AM, Roman Kennke wrote: > On 4/7/19 7:18 PM, Roman Kennke wrote: >>> On 4/2/19 10:12 PM, Roman Kennke wrote: >>>>> - No more need for object equals barriers. >>>> >>>> I'm pleased about that. I really hated the AArch64 Shenandoah >>>> CAS! >>> >>> I'm sorry to disappoint you, but the CAS barrier is still needed. >>> The >>> memory location may still legally hold a from-space reference, and >>> comparing that to a to-space reference needs some special care. And >>> yes, ZGC has a similar problem as far as I know. >> >> That's interesting. Could we not simply promote the reference in the >> reference field we're CASing, then do a normal CAS? > > Yes. But it requires two CASes in a row. Don't know if that is better > than our loop, which is rarely even entered (normally the CAS-construct > goes via fast-path with a single CAS). I think it's better, yes: it's significantly less complex to promote both if needed and then do a normal CAS. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From forax at univ-mlv.fr Mon Apr 8 14:02:42 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 8 Apr 2019 16:02:42 +0200 (CEST) Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CAB0381.3010202@oracle.com> References: <5CA6461A.1000905@oracle.com> <85487550.1882323.1554403152457.JavaMail.zimbra@u-pem.fr> <5CA7428A.9000304@oracle.com> <43405028.2226125.1554484474211.JavaMail.zimbra@u-pem.fr> <5CA791E7.6050605@oracle.com> <813332466.2247012.1554499422983.JavaMail.zimbra@u-pem.fr> <5CAB0381.3010202@oracle.com> Message-ID: <403922026.257283.1554732162026.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "jan lahoda" > ?: "Remi Forax" > Cc: "compiler-dev" , "Liam Miller-Cushon" > Envoy?: Lundi 8 Avril 2019 10:17:05 > Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > Hi Remi, > > Even though I understand what you mean, not sure if it is appropriate to > do this here (i.e. under an ordinary P3 bug). If we only had the > switch-over-enum, then it might be OK. But we even currently have the > switch-over-string, and foresee a possibility of more complex switches, > and this switch-over-enum bootstrap may the outlier among the other > bootstraps (or maybe not; or maybe that is OK; but without a more > general consideration, it is difficult to tell). > > I'd be much more inclined to either: > -use a local solution that is not much different from the current state > (i.e. version .00 or possibly .01 of this patch), and convert to the > switch bootstrap when that's done > -work on the complete switch bootstraps effort, and accept it may take > some time before this bug is fixed. Hi Jan, i've spent some time thinking about that, i believe that the solution i've proposed has the weakness of using an int array as return type of the condy, something that should be abstracted. So i agree with your local solution. The main issue of this solution is that people that maintain tools like a code coverage, a fuzzer, a profiler etc may have to change their tool because the patch introduce a new synthetic method that their tools may not want to be visible from the user POV. But maybe we can introduce the switch on enum using indy in Java 13 too. BTW, i don't believe that we should try to jump from solving the enum switch to let's design a complete switch solution given that a complete switch solution should encompass the enum switch solution and we still don't know what an enum switch that uses indy is. Or said differently, the complete switch should offer the same backward compatibility guarantee that an enum switch has if all the cases are enum values but the switch is on Object. > > Thanks, > Jan regards, R?mi > > On 5.4.2019 23:23, forax at univ-mlv.fr wrote: >> ----- Mail original ----- >>> De: "jan lahoda" >>> ?: "Remi Forax" >>> Cc: "compiler-dev" , "Liam Miller-Cushon" >>> >>> Envoy?: Vendredi 5 Avril 2019 19:35:35 >>> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch >> >>> On 5.4.2019 19:14, forax at univ-mlv.fr wrote: >>>> ----- Mail original ----- >>>>> De: "jan lahoda" >>>>> ?: "Remi Forax" >>>>> Cc: "compiler-dev" , "Liam Miller-Cushon" >>>>> >>>>> Envoy?: Vendredi 5 Avril 2019 13:56:58 >>>>> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch >>>> >>>>> On 4.4.2019 20:39, Remi Forax wrote: >>>>>> Hi Jan, >>>>>> it seems like a perfect case for a constant dynamic, >>>>>> the array can be loaded using ldc and the bootstrap method takes the >>>>>> enum names as constant arguments. >>>>> >>>>> True, I didn't realize that. javac does not currently (AFAIK) have a way >>>>> to generate condy, so we first need support for condy in javac. This >>>>> patch strives to do that: >>>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.condy.01/ >>>>> based on Vicente's: >>>>> http://hg.openjdk.java.net/amber/amber/rev/8e2f2d280e44 >>>>> >>>>> The usage to use that to generate the condy where available (and fall >>>>> back on generating the holder classes where not available): >>>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ >>>> >>>> The description of an enum (EnumMapping) can be encoded by the enum class and an >>>> array of String (in the order of the enum values at compile time). >>>> So instead of generating one specific method per enum that initializes the >>>> mapping table and using it as a bootstrap method, i believe it's better to have >>>> one bootstrap method in the JDK (let say in >>>> java.lang.invoke.ConstantBootstraps) that takes the enum class and an array of >>>> Strings. This method will use ConstantBootstraps.enumConstant to get the >>>> corresponding enum value at runtime (which does the security checks) and a call >>>> ordinal() on each enum value in order to dynamically create the mapping table. >>>> This will reduce the size of the generated bytecode by removing the need to have >>>> one bootstrap method per enum. >>> >>> Well, this is effectively the "use condy for switch" effort, right? >> >> yes ! >> >>> >>> (The enumSwitch method from: >>> http://hg.openjdk.java.net/amber/amber/file/4461b14e6543/src/java.base/share/classes/java/lang/compiler/SwitchBootstraps.java >>> >>> is relevant, as is stringSwitch for switch-over-strings.) Not sure if we >>> have time for that for 13. >> >> The switch-over-enum proposed by SwitchBootstraps uses an invokedynamic and >> understanding the perf of indy is not that simple. >> The code you are proposing uses condy, i think we should keep it that way. >> >> At the same time, your patch generates bytecodes to initialize the array. I >> think this is an overkill. >> As shown by SwitchBootstraps.enumSwitch, you can represent the information that >> the compiler see at compile time with an enum class and an array of enum value >> names, >> so what i'm proposing is to still use condy to load the array of enum constants >> but to only use one bootstrap method that dynamically create the array. >> >> For the compiler, it's easier because you generate less bytecodes (it's not >> fully true because it seems the compiler generate the EnumMapping pretty >> early), >> in term of bugs, because you always call the same bootstrap method which is >> inside the JDK, if there is a bug, you can fix it without changing neither the >> compiler not the generated code, >> and it makes the .class slimmer which is usually a win. >> >> so the idea is to still use condy but initialize it by sending a call and an >> array of strings instead of initialize it by a special tailored bootstrap >> method. >> >> to be 100% clear, here is the BSM i think we should use: >> public static int initEnumMappingArray(Lookup lookup, >> String name, >> Class type, // should be int[].class >> Class enumClass, >> String... enumNames) { >> requireNonNull(lookup); >> requireNonNull(name); >> requireNonNull(type); >> validateClassAccess(lookup, enumClass); // does the class that contains the >> ldc condy can see the array? >> >> int length = enumClass.getEnumConstants().length; >> int[] array = new int[length]; >> for(int i = 0; i < enumNames.length; i++) { >> try { >> Enum enumValue = Enum.valueOf(enumClass, enumNames[i]); >> array[enumValue.ordinal()] = i + 1; >> } catch (IllegalArgumentException e) { >> // empty >> } >> } >> return array; >> } >> >> This is the same code as the code which is generated currently by the compiler, >> it can be optimized using java.lang.Class internals but this can be done later >> >>> >>> Jan >> >> R?mi >> >>> >>>> >>>> Also in Target.java, constant dynamic is available since 11 but if there is a >>>> need of a new BSM in ConstantBootstraps, it should be since 13 (apart if the >>>> patch is backported to 11). >>>> >>>> >>>>> >>>>> (The downside of that is that when indy switch desugaring will be >>>>> implemented, there will be three distinct desugarings for switches over >>>>> enums.) >>>> >>>> yes, as you said, we may able to share some code in the future, we will see when >>>> we get there. >>>> >>>>> >>>>>> >>>>>> You doesn't have to create one class per switch, it's lazy initialized >>>>> >>>>> Please note that neither the original patch, nor the current javac >>>>> state, creates a class per switch. It creates a field (and with the .00 >>>>> version of the patch a class) per enum used as switch selector per >>>>> top-level class. >>>> >>>> >>>> yes >>>> >>>>> >>>>> Jan >>>> >>>> R?mi >>>> >>>>> >>>>>> like any constant pool item and each switch on the same enum type can >>>>>> reuse the same, >>>>>> compare to the solution implemented by Eclipse, it's not a field but a >>>>>> constant pool constant you you can not mess with it using reflection and >>>>>> you don't need to check if the array was loaded or not in the fastpath. >>>>>> >>>>>> regards, >>>>>> R?mi >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> *De: *"Liam Miller-Cushon" >>>>>> *?: *"jan lahoda" >>>>>> *Cc: *"compiler-dev" >>>>>> *Envoy?: *Jeudi 4 Avril 2019 20:20:00 >>>>>> *Objet: *Re: RFR: JDK-8219412: Eager enum class initialization with >>>>>> enum switch >>>>>> >>>>>> Hi Jan, >>>>>> There are a couple of other bugs about enum switch / class >>>>>> initialization issues that I think are addressed by this approach: >>>>>> https://bugs.openjdk.java.net/browse/JDK-7176515 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8169526 >>>>>> >>>>>> Do you have a sense of how many additional auxiliary classes this >>>>>> will create for typical applications? I'm wondering if the number of >>>>>> additional classes might be large enough to effect performance (i.e. >>>>>> binary size, classloading). >>>>>> >>>>>> Were other lazy initialization patterns considered? JDK-7176515 >>>>>> mentions that ecj avoids this by caching the switch map in a field >>>>>> in the same class as the switch. >>>>>> >>>>>> On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> When there is a switch over enum in the code, and is compiled >>>>>> into the >>>>>> bytecode, the meaning of the switch should not change even if >>>>>> the enum's >>>>>> constant are reordered. This is achieved by a map that maps the >>>>>> (current) enum constants to the appropriate case in the switch. >>>>>> This map >>>>>> is stored in a field in an auxiliary class, and filled when that >>>>>> auxiliary class is loaded in. >>>>>> >>>>>> But, if there are multiple switches over distinct enums under a >>>>>> single >>>>>> top-level class, the mapping fields for all the enums are stored >>>>>> in a >>>>>> single class. So, when any of these is needed, the mapping is >>>>>> constructed for all the enums, which may cause enum class >>>>>> initialization >>>>>> even in cases where it shouldn't happen. >>>>>> >>>>>> The proposed fix is to create a separate auxiliary classes for each >>>>>> enum/mapping. >>>>>> >>>>>> Proposed patch: >>>>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>>>>> >>>>>> How does this look? >>>>>> >>>>>> Thanks, > >>>>> Jan From maurizio.cimadamore at oracle.com Mon Apr 8 15:41:28 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 8 Apr 2019 16:41:28 +0100 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CA742DE.2070808@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> Message-ID: <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> It seems to me that it's not worth spending cycles in fixing what is essentially a dead end, translation-strategy wise. Yes, it might take sometime for new pattern translation to settle in, but this issue has been there since Java 5 - is there any reason as to why it is now become a 'must fix' (other than it has been discovered recently) ? On the other hand, the fix is so trivial that it is tempting to 'just go with it', given that it fixes the underlying correctness issue. But, as pointed out by Liam and others, generating a class per enum switch (of given enum type), will now generate more classes than before, so you could make people unhappy by increasing static footprint. So I see two possibilities here - either we wait for better backend story (e.g. switch translation using indy/condy), or we go for the simple fix you proposed (after having done some basic validation exercises that the number of new classes isn't too big). Adding condy support and/or BSM to back up the existing translation story is IMHO a waste of? resources. Maurizio On 05/04/2019 12:58, Jan Lahoda wrote: > On 4.4.2019 20:50, Brian Goetz wrote: >> Note that when we switch to translating with indy, this can be cached at >> the indy call site.? (And, in the case where the compile-time and >> run-time numberings are the same, we can even, if we like, eliminate the >> indirection through the array.) > > Yes, with the indy desugaring this all goes away. But I suspect it > will probably take some time before we switch to that, so seemed > prudent to fix using the approach we currently have. > > Jan > >> >> On 4/4/2019 1:59 PM, Jan Lahoda wrote: >>> Hi, >>> >>> When there is a switch over enum in the code, and is compiled into the >>> bytecode, the meaning of the switch should not change even if the >>> enum's constant are reordered. This is achieved by a map that maps the >>> (current) enum constants to the appropriate case in the switch. This >>> map is stored in a field in an auxiliary class, and filled when that >>> auxiliary class is loaded in. >>> >>> But, if there are multiple switches over distinct enums under a single >>> top-level class, the mapping fields for all the enums are stored in a >>> single class. So, when any of these is needed, the mapping is >>> constructed for all the enums, which may cause enum class >>> initialization even in cases where it shouldn't happen. >>> >>> The proposed fix is to create a separate auxiliary classes for each >>> enum/mapping. >>> >>> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From forax at univ-mlv.fr Tue Apr 9 07:08:31 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 9 Apr 2019 09:08:31 +0200 (CEST) Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> Message-ID: <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> Hi Maurizio, I'm fine with http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ It generates one method per enum instead of one class per enum which is a net win compared to the version 00. There is another reason to go that way, the solution proposed by Jan is very close to the translation we want for the lazy static final (without the retconing of getstatic) Roughly in Java-ish, the translation scheme is switch(anEnum) { case FOO: ... case BAR: ... } is translated to private lazy static final int[] TRANSLATION_TABLE = buildTable(); switch(ldc TRANSLATION_TABLE[anEnum.ordinal]) { case FOO_ORDINAL: ... case BAR_ORDINAL: ... } with the field TRANSLATION_TABLE not needed because all access are inside the class so ldc is enough. cheers, R?mi ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "jan lahoda" , "Brian Goetz" , "compiler-dev" > > Envoy?: Lundi 8 Avril 2019 17:41:28 > Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > It seems to me that it's not worth spending cycles in fixing what is > essentially a dead end, translation-strategy wise. > > Yes, it might take sometime for new pattern translation to settle in, > but this issue has been there since Java 5 - is there any reason as to > why it is now become a 'must fix' (other than it has been discovered > recently) ? > > On the other hand, the fix is so trivial that it is tempting to 'just go > with it', given that it fixes the underlying correctness issue. But, as > pointed out by Liam and others, generating a class per enum switch (of > given enum type), will now generate more classes than before, so you > could make people unhappy by increasing static footprint. > > So I see two possibilities here - either we wait for better backend > story (e.g. switch translation using indy/condy), or we go for the > simple fix you proposed (after having done some basic validation > exercises that the number of new classes isn't too big). Adding condy > support and/or BSM to back up the existing translation story is IMHO a > waste of? resources. > > Maurizio > > On 05/04/2019 12:58, Jan Lahoda wrote: >> On 4.4.2019 20:50, Brian Goetz wrote: >>> Note that when we switch to translating with indy, this can be cached at >>> the indy call site.? (And, in the case where the compile-time and >>> run-time numberings are the same, we can even, if we like, eliminate the >>> indirection through the array.) >> >> Yes, with the indy desugaring this all goes away. But I suspect it >> will probably take some time before we switch to that, so seemed >> prudent to fix using the approach we currently have. >> >> Jan >> >>> >>> On 4/4/2019 1:59 PM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> When there is a switch over enum in the code, and is compiled into the >>>> bytecode, the meaning of the switch should not change even if the >>>> enum's constant are reordered. This is achieved by a map that maps the >>>> (current) enum constants to the appropriate case in the switch. This >>>> map is stored in a field in an auxiliary class, and filled when that >>>> auxiliary class is loaded in. >>>> >>>> But, if there are multiple switches over distinct enums under a single >>>> top-level class, the mapping fields for all the enums are stored in a >>>> single class. So, when any of these is needed, the mapping is >>>> constructed for all the enums, which may cause enum class >>>> initialization even in cases where it shouldn't happen. >>>> >>>> The proposed fix is to create a separate auxiliary classes for each >>>> enum/mapping. >>>> >>>> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> ??? Jan From GROEGES at uk.ibm.com Tue Apr 9 09:02:24 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Tue, 9 Apr 2019 10:02:24 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> Message-ID: Hi Jan, I sent the post below about a month ago but didn't get a response from you as to the review of the new webrevs. Not sure whether you got it or not but I would be grateful if you could take a look at these webrevs and let me know whether they are OK now. If they are OK, please let me know the next steps needed to get these merged into the code base. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Steve Groeger To: Jan Lahoda Cc: compiler-dev at openjdk.java.net Date: 07/03/2019 09:57 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "compiler-dev" Hi Jan, Thanks for providing a possible test for the malformed Annotation Processor. I have taken the code you provided and tweaked it a bit (for jdk) and had to write a similar thing for jdk8u as some of the functionality in the test is not available in the same form in jdk8u (well, not that I could find!!!) I would be grateful if you could review to code in the new webrevs. http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/ http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/ Any issues please let me know. PS. I left the FatalErorr in JavacProcessingEnvironment.java as we wanted Jon to comment on whether this is what is required or whether we go with your previous suggestion. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Apr 9 10:16:49 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Apr 2019 11:16:49 +0100 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> Message-ID: <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> I'm sorry Remi - in terms of complexity, I just don't see v1 being the sweet spot. First, it needs condy support, which, while we have in prototype form, we don't have it available in full in vanilla javac. Secondly, I'm very skeptical that any of that code could be reused when we go to the pattern-match-based implementation. So, overall, I'm not convinced. As mentioned yesterday, I'd like to know, with real code bases (like e.g. the JDK itself), how much extra static footprint are we looking at exactly. Maurizio On 09/04/2019 08:08, Remi Forax wrote: > Hi Maurizio, > > I'm fine with > http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ > > It generates one method per enum instead of one class per enum which is a net win compared to the version 00. > > There is another reason to go that way, the solution proposed by Jan is very close to the translation we want for the lazy static final (without the retconing of getstatic) > > Roughly in Java-ish, the translation scheme is > switch(anEnum) { > case FOO: ... > case BAR: ... > } > > is translated to > private lazy static final int[] TRANSLATION_TABLE = buildTable(); > > switch(ldc TRANSLATION_TABLE[anEnum.ordinal]) { > case FOO_ORDINAL: ... > case BAR_ORDINAL: ... > } > > with the field TRANSLATION_TABLE not needed because all access are inside the class so ldc is enough. > > cheers, > R?mi > > ----- Mail original ----- >> De: "Maurizio Cimadamore" >> ?: "jan lahoda" , "Brian Goetz" , "compiler-dev" >> >> Envoy?: Lundi 8 Avril 2019 17:41:28 >> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch >> It seems to me that it's not worth spending cycles in fixing what is >> essentially a dead end, translation-strategy wise. >> >> Yes, it might take sometime for new pattern translation to settle in, >> but this issue has been there since Java 5 - is there any reason as to >> why it is now become a 'must fix' (other than it has been discovered >> recently) ? >> >> On the other hand, the fix is so trivial that it is tempting to 'just go >> with it', given that it fixes the underlying correctness issue. But, as >> pointed out by Liam and others, generating a class per enum switch (of >> given enum type), will now generate more classes than before, so you >> could make people unhappy by increasing static footprint. >> >> So I see two possibilities here - either we wait for better backend >> story (e.g. switch translation using indy/condy), or we go for the >> simple fix you proposed (after having done some basic validation >> exercises that the number of new classes isn't too big). Adding condy >> support and/or BSM to back up the existing translation story is IMHO a >> waste of? resources. >> >> Maurizio >> >> On 05/04/2019 12:58, Jan Lahoda wrote: >>> On 4.4.2019 20:50, Brian Goetz wrote: >>>> Note that when we switch to translating with indy, this can be cached at >>>> the indy call site.? (And, in the case where the compile-time and >>>> run-time numberings are the same, we can even, if we like, eliminate the >>>> indirection through the array.) >>> Yes, with the indy desugaring this all goes away. But I suspect it >>> will probably take some time before we switch to that, so seemed >>> prudent to fix using the approach we currently have. >>> >>> Jan >>> >>>> On 4/4/2019 1:59 PM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> When there is a switch over enum in the code, and is compiled into the >>>>> bytecode, the meaning of the switch should not change even if the >>>>> enum's constant are reordered. This is achieved by a map that maps the >>>>> (current) enum constants to the appropriate case in the switch. This >>>>> map is stored in a field in an auxiliary class, and filled when that >>>>> auxiliary class is loaded in. >>>>> >>>>> But, if there are multiple switches over distinct enums under a single >>>>> top-level class, the mapping fields for all the enums are stored in a >>>>> single class. So, when any of these is needed, the mapping is >>>>> constructed for all the enums, which may cause enum class >>>>> initialization even in cases where it shouldn't happen. >>>>> >>>>> The proposed fix is to create a separate auxiliary classes for each >>>>> enum/mapping. >>>>> >>>>> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>>>> >>>>> How does this look? >>>>> >>>>> Thanks, >>>>> ??? Jan From jan.lahoda at oracle.com Tue Apr 9 10:32:02 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 9 Apr 2019 12:32:02 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> Message-ID: <5CAC74A2.9050009@oracle.com> On 9.4.2019 12:16, Maurizio Cimadamore wrote: > I'm sorry Remi - in terms of complexity, I just don't see v1 being the > sweet spot. First, it needs condy support, which, while we have in > prototype form, we don't have it available in full in vanilla javac. > Secondly, I'm very skeptical that any of that code could be reused when > we go to the pattern-match-based implementation. So, overall, I'm not > convinced. > > As mentioned yesterday, I'd like to know, with real code bases (like > e.g. the JDK itself), how much extra static footprint are we looking at > exactly. For OpenJDK, there are ~150 additional classes (from 30267 to 30415) with the .00 version of the patch. Jan > > Maurizio > > On 09/04/2019 08:08, Remi Forax wrote: >> Hi Maurizio, >> >> I'm fine with >> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ >> >> It generates one method per enum instead of one class per enum which >> is a net win compared to the version 00. >> >> There is another reason to go that way, the solution proposed by Jan >> is very close to the translation we want for the lazy static final >> (without the retconing of getstatic) >> >> Roughly in Java-ish, the translation scheme is >> switch(anEnum) { >> case FOO: ... >> case BAR: ... >> } >> >> is translated to >> private lazy static final int[] TRANSLATION_TABLE = buildTable(); >> >> switch(ldc TRANSLATION_TABLE[anEnum.ordinal]) { >> case FOO_ORDINAL: ... >> case BAR_ORDINAL: ... >> } >> >> with the field TRANSLATION_TABLE not needed because all access are >> inside the class so ldc is enough. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Maurizio Cimadamore" >>> ?: "jan lahoda" , "Brian Goetz" >>> , "compiler-dev" >>> >>> Envoy?: Lundi 8 Avril 2019 17:41:28 >>> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with >>> enum switch >>> It seems to me that it's not worth spending cycles in fixing what is >>> essentially a dead end, translation-strategy wise. >>> >>> Yes, it might take sometime for new pattern translation to settle in, >>> but this issue has been there since Java 5 - is there any reason as to >>> why it is now become a 'must fix' (other than it has been discovered >>> recently) ? >>> >>> On the other hand, the fix is so trivial that it is tempting to 'just go >>> with it', given that it fixes the underlying correctness issue. But, as >>> pointed out by Liam and others, generating a class per enum switch (of >>> given enum type), will now generate more classes than before, so you >>> could make people unhappy by increasing static footprint. >>> >>> So I see two possibilities here - either we wait for better backend >>> story (e.g. switch translation using indy/condy), or we go for the >>> simple fix you proposed (after having done some basic validation >>> exercises that the number of new classes isn't too big). Adding condy >>> support and/or BSM to back up the existing translation story is IMHO a >>> waste of resources. >>> >>> Maurizio >>> >>> On 05/04/2019 12:58, Jan Lahoda wrote: >>>> On 4.4.2019 20:50, Brian Goetz wrote: >>>>> Note that when we switch to translating with indy, this can be >>>>> cached at >>>>> the indy call site. (And, in the case where the compile-time and >>>>> run-time numberings are the same, we can even, if we like, >>>>> eliminate the >>>>> indirection through the array.) >>>> Yes, with the indy desugaring this all goes away. But I suspect it >>>> will probably take some time before we switch to that, so seemed >>>> prudent to fix using the approach we currently have. >>>> >>>> Jan >>>> >>>>> On 4/4/2019 1:59 PM, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> When there is a switch over enum in the code, and is compiled into >>>>>> the >>>>>> bytecode, the meaning of the switch should not change even if the >>>>>> enum's constant are reordered. This is achieved by a map that maps >>>>>> the >>>>>> (current) enum constants to the appropriate case in the switch. This >>>>>> map is stored in a field in an auxiliary class, and filled when that >>>>>> auxiliary class is loaded in. >>>>>> >>>>>> But, if there are multiple switches over distinct enums under a >>>>>> single >>>>>> top-level class, the mapping fields for all the enums are stored in a >>>>>> single class. So, when any of these is needed, the mapping is >>>>>> constructed for all the enums, which may cause enum class >>>>>> initialization even in cases where it shouldn't happen. >>>>>> >>>>>> The proposed fix is to create a separate auxiliary classes for each >>>>>> enum/mapping. >>>>>> >>>>>> Proposed patch: >>>>>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>>>>> >>>>>> How does this look? >>>>>> >>>>>> Thanks, >>>>>> Jan From forax at univ-mlv.fr Tue Apr 9 10:37:40 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 9 Apr 2019 12:37:40 +0200 (CEST) Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> Message-ID: <1567035194.551955.1554806260589.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Remi Forax" > Cc: "jan lahoda" , "Brian Goetz" , "compiler-dev" > > Envoy?: Mardi 9 Avril 2019 12:16:49 > Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch > I'm sorry Remi - in terms of complexity, I just don't see v1 being the > sweet spot. First, it needs condy support, which, while we have in > prototype form, we don't have it available in full in vanilla javac. > Secondly, I'm very skeptical that any of that code could be reused when > we go to the pattern-match-based implementation. So, overall, I'm not > convinced. Don't be sorry, your in charge :) I don't think we will ever use the object switch to implement the enum switch, the enum switch description of the compile time information is more compact than with we will have with the object switch. At some point in the future the enum switch and the object switch will use a similar mechanism based on invokedynamic, but not the exact same code. I think the support of lazy static final needs exactly the same condy support that this feature, but if the condy support is not ready, it's not ready. > > As mentioned yesterday, I'd like to know, with real code bases (like > e.g. the JDK itself), how much extra static footprint are we looking at > exactly. I'm far more worried about codes that are generated and use enum switches, i've such code in a parser generator, in my case, i think i'm ok because all the switches are in the same classes and i've an alternate strategy because while generating switch is faster that using a parsing table, the generated class can reach the max number of opcodes in a method. But if i have to choose between the version 00 that generates one class per enum or doing nothing, i think i prefer the later option because i know that if you have code generator that generates enum switch, it will be bad. So marking that this bug will be fixed when the support of condy will be introduced in javac is perhaps the best option. > > Maurizio R?mi > > On 09/04/2019 08:08, Remi Forax wrote: >> Hi Maurizio, >> >> I'm fine with >> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.01/ >> >> It generates one method per enum instead of one class per enum which is a net >> win compared to the version 00. >> >> There is another reason to go that way, the solution proposed by Jan is very >> close to the translation we want for the lazy static final (without the >> retconing of getstatic) >> >> Roughly in Java-ish, the translation scheme is >> switch(anEnum) { >> case FOO: ... >> case BAR: ... >> } >> >> is translated to >> private lazy static final int[] TRANSLATION_TABLE = buildTable(); >> >> switch(ldc TRANSLATION_TABLE[anEnum.ordinal]) { >> case FOO_ORDINAL: ... >> case BAR_ORDINAL: ... >> } >> >> with the field TRANSLATION_TABLE not needed because all access are inside the >> class so ldc is enough. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Maurizio Cimadamore" >>> ?: "jan lahoda" , "Brian Goetz" , >>> "compiler-dev" >>> >>> Envoy?: Lundi 8 Avril 2019 17:41:28 >>> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch >>> It seems to me that it's not worth spending cycles in fixing what is >>> essentially a dead end, translation-strategy wise. >>> >>> Yes, it might take sometime for new pattern translation to settle in, >>> but this issue has been there since Java 5 - is there any reason as to >>> why it is now become a 'must fix' (other than it has been discovered >>> recently) ? >>> >>> On the other hand, the fix is so trivial that it is tempting to 'just go >>> with it', given that it fixes the underlying correctness issue. But, as >>> pointed out by Liam and others, generating a class per enum switch (of >>> given enum type), will now generate more classes than before, so you >>> could make people unhappy by increasing static footprint. >>> >>> So I see two possibilities here - either we wait for better backend >>> story (e.g. switch translation using indy/condy), or we go for the >>> simple fix you proposed (after having done some basic validation >>> exercises that the number of new classes isn't too big). Adding condy >>> support and/or BSM to back up the existing translation story is IMHO a >>> waste of? resources. >>> >>> Maurizio >>> >>> On 05/04/2019 12:58, Jan Lahoda wrote: >>>> On 4.4.2019 20:50, Brian Goetz wrote: >>>>> Note that when we switch to translating with indy, this can be cached at >>>>> the indy call site.? (And, in the case where the compile-time and >>>>> run-time numberings are the same, we can even, if we like, eliminate the >>>>> indirection through the array.) >>>> Yes, with the indy desugaring this all goes away. But I suspect it >>>> will probably take some time before we switch to that, so seemed >>>> prudent to fix using the approach we currently have. >>>> >>>> Jan >>>> >>>>> On 4/4/2019 1:59 PM, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> When there is a switch over enum in the code, and is compiled into the >>>>>> bytecode, the meaning of the switch should not change even if the >>>>>> enum's constant are reordered. This is achieved by a map that maps the >>>>>> (current) enum constants to the appropriate case in the switch. This >>>>>> map is stored in a field in an auxiliary class, and filled when that >>>>>> auxiliary class is loaded in. >>>>>> >>>>>> But, if there are multiple switches over distinct enums under a single >>>>>> top-level class, the mapping fields for all the enums are stored in a >>>>>> single class. So, when any of these is needed, the mapping is >>>>>> constructed for all the enums, which may cause enum class >>>>>> initialization even in cases where it shouldn't happen. >>>>>> >>>>>> The proposed fix is to create a separate auxiliary classes for each >>>>>> enum/mapping. >>>>>> >>>>>> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219412 >>>>>> >>>>>> How does this look? >>>>>> >>>>>> Thanks, > >>>>> ??? Jan From jan.lahoda at oracle.com Tue Apr 9 11:43:19 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 9 Apr 2019 13:43:19 +0200 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH Message-ID: <5CAC8557.9090701@oracle.com> Hi, Currently, when compiling an unnamed module, --add-modules ALL-MODULE-PATH adds all modules from the module path to the module graph, so that the unnamed module can refer to them. When compiling a named module, this option is not allowed, as it would be confusing, as it cannot modify the dependencies of the named module. But, when compiling a code in the context of an automatic module using --patch-module, e.g.: javac --module-path --patch-modules = ... The --add-modules ALL-MODULE-PATH is still disallowed, but it may make sense to use it, as it may affect the set of classes available for the sources that are being compiled. Compiling in the context of an automatic module may be useful esp. in when patching multiple modules at once (which is supported by --patch-module), e.g. to build tests. (Seems that also at least the use of javadoc in Maven may lead to a similar setting as well, see the JBS bug.) The proposal is to allow the --add-modules ALL-MODULE-PATH option when compiling code in the context of an automatic module. Proposed patch: http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8220702 What do you think? Thanks, Jan From claes.redestad at oracle.com Tue Apr 9 11:58:37 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Apr 2019 13:58:37 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CAC74A2.9050009@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> <5CAC74A2.9050009@oracle.com> Message-ID: <93d1e34a-df58-149d-0591-fda529a22f94@oracle.com> Hi Jan, On 2019-04-09 12:32, Jan Lahoda wrote: > For OpenJDK, there are ~150 additional classes (from 30267 to 30415) > with the .00 version of the patch. to me it sounds those additional classes will mostly be the result of splitting existing classes, so the static and potential runtime footprint overheads are small. And .01 seems to add a BSM for every enum switch, so while we reduce compiled classes we add other overheads. I think it'd be good, for the sake of argument, to examine the exact size of lib/modules with baseline, .00, and .01. My gut feeling is the gain from the approach in .01 is smaller than it first appears. (That said I think there is intrinsic value in exploring and using condy for things like this.) Thanks! /Claes From jan.lahoda at oracle.com Tue Apr 9 15:23:18 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 9 Apr 2019 17:23:18 +0200 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <93d1e34a-df58-149d-0591-fda529a22f94@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> <5CAC74A2.9050009@oracle.com> <93d1e34a-df58-149d-0591-fda529a22f94@oracle.com> Message-ID: <5CACB8E6.20102@oracle.com> On 9.4.2019 13:58, Claes Redestad wrote: > Hi Jan, > > On 2019-04-09 12:32, Jan Lahoda wrote: >> For OpenJDK, there are ~150 additional classes (from 30267 to 30415) >> with the .00 version of the patch. > > to me it sounds those additional classes will mostly be the result of > splitting existing classes, so the static and potential runtime > footprint overheads are small. And .01 seems to add a BSM for every > enum switch, so while we reduce compiled classes we add other > overheads. > > I think it'd be good, for the sake of argument, to examine the exact > size of lib/modules with baseline, .00, and .01. My gut feeling is the > gain from the approach in .01 is smaller than it first appears. So, I think the outcomes are more interesting than I expected. I ran: find . -name "*.class" | wc -l and find . -name "*.class" | xargs cat | wc -c For the exploded JDK images with version .00 and .01 of the patch and unmodified. Unmodified: 134400902 bytes, 30267 classes, jdk.compiler size: 7746387b patch .00: 134476598 bytes, 30412 classes, jdk.compiler size: 7777182b patch .01: 134637774 bytes, 30270 classes, jdk.compiler size: 7806442b So, with the .01 patch, the total size seems to be bigger than with the .00 patch. This is partly because there is more code in javac (jdk.compiler), but I also took a look at a few classes: with patch version .00: jdk/modules/java.base/java/lang/invoke/VarHandle$2.class: 933 bytes jdk/modules/java.base/java/lang/invoke/VarHandle$3.class: 914 bytes jdk/modules/java.base/java/lang/invoke/VarHandle$VarHandleDesc.class: 4427 bytes with patch version .01: jdk/modules/java.base/java/lang/invoke/VarHandle$2.class: 1847 bytes jdk/modules/java.base/java/lang/invoke/VarHandle$VarHandleDesc.class: 4553 bytes (the VarHandle$2.class here contains code that is in VarHandle$2.class and VarHandle$3.class with patch version .00) The difference in the VarHandle$VarHandleDesc.class appears to be mostly the difference in describing the bootstrap method. It is true currently the generated bootstrap's name is fairly long, so with a shorter name, the difference would be smaller, and version .01 might get even smaller than version .00 (I didn't measure/try that (yet)). So I think you are right that the gain with .01 is probably much smaller than it might appear. Jan > > (That said I think there is intrinsic value in exploring and using > condy for things like this.) > > Thanks! > > /Claes From maurizio.cimadamore at oracle.com Tue Apr 9 15:31:02 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Apr 2019 16:31:02 +0100 Subject: RFR: JDK-8219412: Eager enum class initialization with enum switch In-Reply-To: <5CACB8E6.20102@oracle.com> References: <5CA6461A.1000905@oracle.com> <1d4ca22a-5a73-c3b7-1481-6bcf3eb50ca2@oracle.com> <5CA742DE.2070808@oracle.com> <23bb99de-5257-e2d1-3e91-d66536c11580@oracle.com> <1662810616.391665.1554793711950.JavaMail.zimbra@u-pem.fr> <6552a119-1d82-febd-dc13-6a8ede99b68a@oracle.com> <5CAC74A2.9050009@oracle.com> <93d1e34a-df58-149d-0591-fda529a22f94@oracle.com> <5CACB8E6.20102@oracle.com> Message-ID: <21b0b5f3-b8ad-ea8a-16c3-b4b98a913bb1@oracle.com> Thanks for running these tests, I agree this is a tad surprising. The right way to address this, of course, would be to have a blessed JDK bootstrap method which works on any enum (in which case you don't even need the class?) - but I'm even more concerned about going in that direction for what is supposed to be an 'interim' fix. Maurizio On 09/04/2019 16:23, Jan Lahoda wrote: > On 9.4.2019 13:58, Claes Redestad wrote: >> Hi Jan, >> >> On 2019-04-09 12:32, Jan Lahoda wrote: >>> For OpenJDK, there are ~150 additional classes (from 30267 to 30415) >>> with the .00 version of the patch. >> >> to me it sounds those additional classes will mostly be the result of >> splitting existing classes, so the static and potential runtime >> footprint overheads are small. And .01 seems to add a BSM for every >> enum switch, so while we reduce compiled classes we add other >> overheads. >> >> I think it'd be good, for the sake of argument, to examine the exact >> size of lib/modules with baseline, .00, and .01. My gut feeling is the >> gain from the approach in .01 is smaller than it first appears. > > So, I think the outcomes are more interesting than I expected. I ran: > find . -name "*.class" | wc -l > and > find . -name "*.class" | xargs cat | wc -c > > For the exploded JDK images with version .00 and .01 of the patch and > unmodified. > > Unmodified: 134400902 bytes, 30267 classes, jdk.compiler size: 7746387b > patch .00:? 134476598 bytes, 30412 classes, jdk.compiler size: 7777182b > patch .01:? 134637774 bytes, 30270 classes, jdk.compiler size: 7806442b > > So, with the .01 patch, the total size seems to be bigger than with > the .00 patch. This is partly because there is more code in javac > (jdk.compiler), but I also took a look at a few classes: > with patch version .00: > jdk/modules/java.base/java/lang/invoke/VarHandle$2.class: > 933 bytes > > jdk/modules/java.base/java/lang/invoke/VarHandle$3.class: > 914 bytes > > jdk/modules/java.base/java/lang/invoke/VarHandle$VarHandleDesc.class: > 4427 bytes > > with patch version .01: > jdk/modules/java.base/java/lang/invoke/VarHandle$2.class: > 1847 bytes > > jdk/modules/java.base/java/lang/invoke/VarHandle$VarHandleDesc.class: > 4553 bytes > > (the VarHandle$2.class here contains code that is in VarHandle$2.class > and VarHandle$3.class with patch version .00) > > The difference in the VarHandle$VarHandleDesc.class appears to be > mostly the difference in describing the bootstrap method. It is true > currently the generated bootstrap's name is fairly long, so with a > shorter name, the difference would be smaller, and version .01 might > get even smaller than version .00 (I didn't measure/try that (yet)). > > So I think you are right that the gain with .01 is probably much > smaller than it might appear. > > Jan > >> >> (That said I think there is intrinsic value in exploring and using >> condy for things like this.) >> >> Thanks! >> >> /Claes From vicente.romero at oracle.com Tue Apr 9 16:51:36 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 9 Apr 2019 12:51:36 -0400 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error Message-ID: Hi all, Please review fix for [1] at [2]. The issue is random and very hard to reproduce with a regression test. Apart from the use of non-ordering preserving data structures, the root cause was early resolution of the inference context which was leading, in this case, to inexact instantiation of some inference variables. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8222035 [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ From maurizio.cimadamore at oracle.com Tue Apr 9 16:56:29 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Apr 2019 17:56:29 +0100 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: References: Message-ID: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> Looks good - few comments: * there's an HashSet still used at line 404: Set deps = minMap.getOrDefault(t.qtype, new HashSet<>(Collections.singleton(t.qtype))); This should be fixed too. * In this statement: ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); It would be better to cache the instantiated type outside the loop since it doesn't change. Maurizio On 09/04/2019 17:51, Vicente Romero wrote: > Hi all, > > Please review fix for [1] at [2]. The issue is random and very hard to > reproduce with a regression test. Apart from the use of non-ordering > preserving data structures, the root cause was early resolution of the > inference context which was leading, in this case, to inexact > instantiation of some inference variables. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8222035 > [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ From vicente.romero at oracle.com Tue Apr 9 17:17:46 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 9 Apr 2019 13:17:46 -0400 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> Message-ID: <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> Hi Maurizio, Thanks for your comments, please see the updated webrev at [1] Vicente [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: > Looks good - few comments: > > * there's an HashSet still used at line 404: > > Set deps = minMap.getOrDefault(t.qtype, new > HashSet<>(Collections.singleton(t.qtype))); > > This should be fixed too. > > * In this statement: > > ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); > > It would be better to cache the instantiated type outside the loop > since it doesn't change. > > Maurizio > > > On 09/04/2019 17:51, Vicente Romero wrote: >> Hi all, >> >> Please review fix for [1] at [2]. The issue is random and very hard >> to reproduce with a regression test. Apart from the use of >> non-ordering preserving data structures, the root cause was early >> resolution of the inference context which was leading, in this case, >> to inexact instantiation of some inference variables. >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 >> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ From bsrbnd at gmail.com Tue Apr 9 18:22:04 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 9 Apr 2019 20:22:04 +0200 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> Message-ID: Seems reasonable to me too. I observed similar things some time ago, see: https://bugs.openjdk.java.net/browse/JDK-8189683 Using ordered sets is generally a good practice I believe. Bernard On Tue, 9 Apr 2019 at 19:18, Vicente Romero wrote: > > Hi Maurizio, > > Thanks for your comments, please see the updated webrev at [1] > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ > > > > On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: > > Looks good - few comments: > > > > * there's an HashSet still used at line 404: > > > > Set deps = minMap.getOrDefault(t.qtype, new > > HashSet<>(Collections.singleton(t.qtype))); > > > > This should be fixed too. > > > > * In this statement: > > > > ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); > > > > It would be better to cache the instantiated type outside the loop > > since it doesn't change. > > > > Maurizio > > > > > > On 09/04/2019 17:51, Vicente Romero wrote: > >> Hi all, > >> > >> Please review fix for [1] at [2]. The issue is random and very hard > >> to reproduce with a regression test. Apart from the use of > >> non-ordering preserving data structures, the root cause was early > >> resolution of the inference context which was leading, in this case, > >> to inexact instantiation of some inference variables. > >> > >> Thanks, > >> Vicente > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 > >> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ > From maurizio.cimadamore at oracle.com Tue Apr 9 20:37:25 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Apr 2019 21:37:25 +0100 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> Message-ID: Looks good! Maurizio On 09/04/2019 18:17, Vicente Romero wrote: > Hi Maurizio, > > Thanks for your comments, please see the updated webrev at [1] > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ > > > > On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: >> Looks good - few comments: >> >> * there's an HashSet still used at line 404: >> >> Set deps = minMap.getOrDefault(t.qtype, new >> HashSet<>(Collections.singleton(t.qtype))); >> >> This should be fixed too. >> >> * In this statement: >> >> ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); >> >> It would be better to cache the instantiated type outside the loop >> since it doesn't change. >> >> Maurizio >> >> >> On 09/04/2019 17:51, Vicente Romero wrote: >>> Hi all, >>> >>> Please review fix for [1] at [2]. The issue is random and very hard >>> to reproduce with a regression test. Apart from the use of >>> non-ordering preserving data structures, the root cause was early >>> resolution of the inference context which was leading, in this case, >>> to inexact instantiation of some inference variables. >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 >>> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ > From vicente.romero at oracle.com Tue Apr 9 21:24:21 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 9 Apr 2019 17:24:21 -0400 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> Message-ID: <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> thanks, Vicente On 4/9/19 4:37 PM, Maurizio Cimadamore wrote: > Looks good! > > Maurizio > > On 09/04/2019 18:17, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for your comments, please see the updated webrev at [1] >> >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ >> >> >> >> On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: >>> Looks good - few comments: >>> >>> * there's an HashSet still used at line 404: >>> >>> Set deps = minMap.getOrDefault(t.qtype, new >>> HashSet<>(Collections.singleton(t.qtype))); >>> >>> This should be fixed too. >>> >>> * In this statement: >>> >>> ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); >>> >>> It would be better to cache the instantiated type outside the loop >>> since it doesn't change. >>> >>> Maurizio >>> >>> >>> On 09/04/2019 17:51, Vicente Romero wrote: >>>> Hi all, >>>> >>>> Please review fix for [1] at [2]. The issue is random and very hard >>>> to reproduce with a regression test. Apart from the use of >>>> non-ordering preserving data structures, the root cause was early >>>> resolution of the inference context which was leading, in this >>>> case, to inexact instantiation of some inference variables. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 >>>> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ >> From jan.lahoda at oracle.com Wed Apr 10 08:48:56 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 10 Apr 2019 10:48:56 +0200 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> Message-ID: <933e29f8-7edc-3d36-920a-fed624c51588@oracle.com> Hi Steve, I apologize for a late reply. For the FatalError, seems that this constructor is being called there: public FatalError(JCDiagnostic d, Throwable t) { super(d.toString(), t); } with "d == null". That, I think, will lead to an immediate NPE, which I don't think is desirable, as it will hide the actual exception that was thrown. Or do I miss something? Thanks, Jan On 09. 04. 19 11:02, Steve Groeger wrote: > Hi Jan, > > I sent the post below about a month ago but didn't get a response from > you as to the review of the new webrevs. > Not sure whether you got it or not but I would be grateful if you could > take a look at these webrevs and let me know whether they are OK now. > If they are OK, please let me know the next steps needed to get these > merged into the code base. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Steve Groeger > To: Jan Lahoda > Cc: compiler-dev at openjdk.java.net > Date: 07/03/2019 09:57 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > Sent by: "compiler-dev" > ------------------------------------------------------------------------ > > > > Hi Jan, > > Thanks for providing a possible test for the malformed Annotation Processor. > I have taken the code you provided and tweaked it a bit (for jdk) and > had to > write a similar thing for jdk8u as some of the functionality in the test > is not > available in the same form in jdk8u (well, not that I could find!!!) > > I would be grateful if you could review to code in the new webrevs. > _ > __http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/__ > __http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/_ > > Any issues please let me know. > > PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we > wanted Jon to comment on whether this is what is required or whether > we go with your previous suggestion. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From GROEGES at uk.ibm.com Wed Apr 10 09:58:07 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 10 Apr 2019 10:58:07 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: <933e29f8-7edc-3d36-920a-fed624c51588@oracle.com> References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> Message-ID: Hi Jan, Thanks for responding. I don't think you are missing anything with regards to the use of this: > public FatalError(JCDiagnostic d, Throwable t) {} I think that was me missing the fact this would cause NPE and mask the actual issue. I will probably go with your original suggestion: > Would there be an issue with simply changing the "catch > (Throwable)" to also report the same error as > "catch (ServiceConfigurationError)"? Will make these changes and generate some new webrevs for this and post again when they are available. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Jan Lahoda To: Steve Groeger Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons Date: 10/04/2019 09:51 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Hi Steve, I apologize for a late reply. For the FatalError, seems that this constructor is being called there: public FatalError(JCDiagnostic d, Throwable t) { super(d.toString(), t); } with "d == null". That, I think, will lead to an immediate NPE, which I don't think is desirable, as it will hide the actual exception that was thrown. Or do I miss something? Thanks, Jan On 09. 04. 19 11:02, Steve Groeger wrote: > Hi Jan, > > I sent the post below about a month ago but didn't get a response from > you as to the review of the new webrevs. > Not sure whether you got it or not but I would be grateful if you could > take a look at these webrevs and let me know whether they are OK now. > If they are OK, please let me know the next steps needed to get these > merged into the code base. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Steve Groeger > To: Jan Lahoda > Cc: compiler-dev at openjdk.java.net > Date: 07/03/2019 09:57 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > Sent by: "compiler-dev" > ------------------------------------------------------------------------ > > > > Hi Jan, > > Thanks for providing a possible test for the malformed Annotation Processor. > I have taken the code you provided and tweaked it a bit (for jdk) and > had to > write a similar thing for jdk8u as some of the functionality in the test > is not > available in the same form in jdk8u (well, not that I could find!!!) > > I would be grateful if you could review to code in the new webrevs. > _ > __ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.02_-5F-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=uCg3akeFaW8zN9SsRJe7AlymlgusgBYtdoAIIrc1fdU&s=jWm2HAcUvWNUBxGsKYIxVQTHvgLka4bP9ecl4AGdIvU&e= > __ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.02_-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=uCg3akeFaW8zN9SsRJe7AlymlgusgBYtdoAIIrc1fdU&s=l65q77Htdor8AqiYZojE5bAmUKGwdASX9gNxXpyRZCg&e= > > Any issues please let me know. > > PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we > wanted Jon to comment on whether this is what is required or whether > we go with your previous suggestion. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Wed Apr 10 12:43:59 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 10 Apr 2019 13:43:59 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> Message-ID: Hi Jan, I have made the change to throw the same error as when we get the ServiceConfigurationError and removed the call the FatalError. I have created 2 new webrevs for jdk [1] and for jdk8u [2]. Hopefully these are now OK and in a suitable state to be able to be re-reviewed and then merged. If there is anything else that is needed please do not hesitate to contact me. [1] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.03/ [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.03/ Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Steve Groeger To: Jan Lahoda Cc: compiler-dev at openjdk.java.net Date: 10/04/2019 10:59 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "compiler-dev" Hi Jan, Thanks for responding. I don't think you are missing anything with regards to the use of this: > public FatalError(JCDiagnostic d, Throwable t) {} I think that was me missing the fact this would cause NPE and mask the actual issue. I will probably go with your original suggestion: > Would there be an issue with simply changing the "catch > (Throwable)" to also report the same error as > "catch (ServiceConfigurationError)"? Will make these changes and generate some new webrevs for this and post again when they are available. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Jan Lahoda To: Steve Groeger Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons Date: 10/04/2019 09:51 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Hi Steve, I apologize for a late reply. For the FatalError, seems that this constructor is being called there: public FatalError(JCDiagnostic d, Throwable t) { super(d.toString(), t); } with "d == null". That, I think, will lead to an immediate NPE, which I don't think is desirable, as it will hide the actual exception that was thrown. Or do I miss something? Thanks, Jan On 09. 04. 19 11:02, Steve Groeger wrote: > Hi Jan, > > I sent the post below about a month ago but didn't get a response from > you as to the review of the new webrevs. > Not sure whether you got it or not but I would be grateful if you could > take a look at these webrevs and let me know whether they are OK now. > If they are OK, please let me know the next steps needed to get these > merged into the code base. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Steve Groeger > To: Jan Lahoda > Cc: compiler-dev at openjdk.java.net > Date: 07/03/2019 09:57 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > Sent by: "compiler-dev" > ------------------------------------------------------------------------ > > > > Hi Jan, > > Thanks for providing a possible test for the malformed Annotation Processor. > I have taken the code you provided and tweaked it a bit (for jdk) and > had to > write a similar thing for jdk8u as some of the functionality in the test > is not > available in the same form in jdk8u (well, not that I could find!!!) > > I would be grateful if you could review to code in the new webrevs. > _ > __http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/__ > __http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/_ > > Any issues please let me know. > > PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we > wanted Jon to comment on whether this is what is required or whether > we go with your previous suggestion. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Apr 10 14:16:00 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Apr 2019 07:16:00 -0700 Subject: RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException: String index out of range: -2 In-Reply-To: <5C91EA27.5000209@oracle.com> References: <5C7E9BD7.1070607@oracle.com> <5C7EAB3F.4050402@oracle.com> <44fb40ef-6f77-a389-7559-cbe04ae4e1f1@oracle.com> <5C7FA173.5000707@oracle.com> <5C8FC567.6040407@oracle.com> <7db01736-0cf2-2f99-9afe-fae976155d77@oracle.com> <5C91EA27.5000209@oracle.com> Message-ID: <8088222d-3d97-78ff-b9aa-e6d6bcb90150@oracle.com> Much nicer; looks good to me. -- Jon On 3/20/19 12:22 AM, Jan Lahoda wrote: > On 18.3.2019 23:17, Jonathan Gibbons wrote: >> I think it would be better to put all the name checking together, in >> simpleBinaryName. > > Updated webrev: > http://cr.openjdk.java.net/~jlahoda/8215407/webrev.01/ > > (The only difference compared to the .00 should be in ClassReader.java.) > > Does that look OK? > > Thanks, > ??? Jan > >> >> -- Jon >> >> On 3/18/19 9:20 AM, Jan Lahoda wrote: >>> On 16.3.2019 01:10, Jonathan Gibbons wrote: >>>> OK, I see the additional checks in simpleBinaryName, which is the sort >>>> of check I was expecting. >>>> >>>> I'm a bit surprised you didn't put the check inside simpleBinaryName, >>>> but that would trigger a subsequent question as to why we have >>> >>> I started with the check inside the simpleBinaryName method, but then >>> moved it outside, as the check seemed like a "general" check, not >>> something related to the simple name as such. I don't have a very >>> strong opinion on this, I can move the check inside simpleBinaryName >>> if preferred. >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> 1478 throw badEnclosingMethod(self); >>>> >>>> and ClassReader.simpleBinaryName:1507 >>>> >>>> ???? throw badClassFile("bad.enclosing.method", self); >>>> >>>> I'm OK with either webrev as is or with the check moved into >>>> simpleBinaryName, >>>> >>>> -- Jon >>>> >>>> On 03/06/2019 02:31 AM, Jan Lahoda wrote: >>>>> Hi Jon, >>>>> >>>>> On 5.3.2019 21:20, Jonathan Gibbons wrote: >>>>>> Jan, >>>>>> >>>>>> Is checking for a prefix good enough??? It seems like that would be >>>>>> necessary but not sufficient. >>>>> >>>>> What specific additional checks do you foresee? The >>>>> ClassReader.simpleBinaryName method does some additional checks, like >>>>> that the class suffix is non-empty and starts with '$'. >>>>> >>>>> Thanks, >>>>> ??? Jan >>>>> >>>>>> >>>>>> -- Jon >>>>>> >>>>>> On 3/5/19 9:00 AM, Jan Lahoda wrote: >>>>>>> On 5.3.2019 17:33, Joe Darcy wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> Do you think this issue merits a CSR for the behavioral change? >>>>>>> >>>>>>> Good question! It is true that javac may now refuse to load >>>>>>> classfiles >>>>>>> that didn't lead to the exception before, so I guess a CSR may >>>>>>> be in >>>>>>> order. I've started with it here: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8220167 >>>>>>> >>>>>>> Feedback on the CSR is very welcome as well! >>>>>>> >>>>>>> Thanks, >>>>>>> ??? Jan >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Joe >>>>>>>> >>>>>>>> On 3/5/2019 7:55 AM, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Seems that some classfiles have a weird EnclosingMethod >>>>>>>>> attribute - >>>>>>>>> for (local/anonymous) class A, the EnclosingMethod attribute >>>>>>>>> states >>>>>>>>> the enclosing class is C, but the name of C is not a prefix of >>>>>>>>> the >>>>>>>>> name of A. This appears to be contradictory to JLS 13.1., so the >>>>>>>>> proposal is to reject such classfiles. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/ >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407 >>>>>>>>> >>>>>>>>> How does this look? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> ??? Jan >>>> From jan.lahoda at oracle.com Wed Apr 10 15:11:03 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 10 Apr 2019 17:11:03 +0200 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> Message-ID: <55bd5ddb-4d85-1a36-f067-a33fcc0c14b6@oracle.com> Hi Steve, One more question - do tests pass with this patch, at least the test/langtools tests, or jdk/submit? https://wiki.openjdk.java.net/display/Build/Submit+Repo (adding new diagnostic messages often need adjustments to /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java ) Regarding JDK 8 updates, please note there's a separate for that: https://wiki.openjdk.java.net/display/jdk8u/Main Jan On 10. 04. 19 14:43, Steve Groeger wrote: > Hi Jan, > > I have made the change to throw the same error as when we get the > ServiceConfigurationError and removed the call the FatalError. > I have created 2 new webrevs for jdk [1] and for jdk8u [2]. > Hopefully these are now OK and in a suitable state to be able to be > re-reviewed and then merged. > If there is anything else that is needed please do not hesitate to > contact me. > > [1] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.03/_ > [2] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.03/_ > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Steve Groeger > To: Jan Lahoda > Cc: compiler-dev at openjdk.java.net > Date: 10/04/2019 10:59 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > Sent by: "compiler-dev" > ------------------------------------------------------------------------ > > > > Hi Jan, > > Thanks for responding. > > I don't think you are missing anything with regards to the use of this: >> ? ? public FatalError(JCDiagnostic d, Throwable t) {} > > I think that was me missing the fact this would cause NPE and mask the > actual issue. > > I will probably go with your original suggestion: >> Would there be an issue with simply changing the "catch >> (Throwable)" to also report the same error as >> "catch (ServiceConfigurationError)"? > > Will make these changes and generate some new webrevs for this and post > again when they are available. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Jan Lahoda > To: Steve Groeger > Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons > > Date: 10/04/2019 09:51 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > ------------------------------------------------------------------------ > > > > Hi Steve, > > I apologize for a late reply. For the FatalError, seems that this > constructor is being called there: > ? ?public FatalError(JCDiagnostic d, Throwable t) { > ? ? ? ?super(d.toString(), t); > ? ?} > > with "d == null". That, I think, will lead to an immediate NPE, which I > don't think is desirable, as it will hide the actual exception that was > thrown. Or do I miss something? > > Thanks, > ? ?Jan > > On 09. 04. 19 11:02, Steve Groeger wrote: >> Hi Jan, >> >> I sent the post below about a month ago but didn't get a response from >> you as to the review of the new webrevs. >> Not sure whether you got it or not but I would be grateful if you could >> take a look at these webrevs and let me know whether they are OK now. >> If they are OK, please let me know the next steps needed to get these >> merged into the code base. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Steve Groeger >> To: Jan Lahoda >> Cc: compiler-dev at openjdk.java.net >> Date: 07/03/2019 09:57 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> Sent by: "compiler-dev" >> ------------------------------------------------------------------------ >> >> >> >> Hi Jan, >> >> Thanks for providing a possible test for the malformed Annotation Processor. >> I have taken the code you provided and tweaked it a bit (for jdk) and >> had to >> write a similar thing for jdk8u as some of the functionality in the test >> is not >> available in the same form in jdk8u (well, not that I could find!!!) >> >> I would be grateful if you could review to code in the new webrevs. >> _ >> ___http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/___ >> ___http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/__ >> >> Any issues please let me know. >> >> PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we >> wanted Jon to comment on whether this is what is required or whether >> we go with your previous suggestion. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From cushon at google.com Wed Apr 10 17:03:32 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 10 Apr 2019 10:03:32 -0700 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> Message-ID: I did some testing and a found a single example where this fix rejects code that was previously accepted. Is this change expected? (I don't have any concerns either way: this pattern is not common, it involves rawtypes, and there's an easy work-around.) ``` import java.util.Map; import java.util.function.Function; import java.util.stream.Collector; import java.util.stream.Stream; abstract class A { abstract static class T { abstract String f(); } abstract Function id(); abstract static class ImmutableMap implements Map {} abstract Collector> toImmutableMap( Function k, Function v); ImmutableMap> test(Stream stream) { return stream.collect(toImmutableMap(T::f, id())); } } ``` A.java:20: error: incompatible types: cannot infer type-variable(s) T,K,V,E return stream.collect(toImmutableMap(T::f, id())); ^ (argument mismatch; Function cannot be converted to Function>) where T,K,V,E are type-variables: T extends Object declared in method toImmutableMap(Function,Function) K extends Object declared in method toImmutableMap(Function,Function) V extends Object declared in method toImmutableMap(Function,Function) E extends Object declared in method id() 1 error On Tue, Apr 9, 2019 at 2:24 PM Vicente Romero wrote: > thanks, > Vicente > > On 4/9/19 4:37 PM, Maurizio Cimadamore wrote: > > Looks good! > > > > Maurizio > > > > On 09/04/2019 18:17, Vicente Romero wrote: > >> Hi Maurizio, > >> > >> Thanks for your comments, please see the updated webrev at [1] > >> > >> Vicente > >> > >> [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ > >> > >> > >> > >> On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: > >>> Looks good - few comments: > >>> > >>> * there's an HashSet still used at line 404: > >>> > >>> Set deps = minMap.getOrDefault(t.qtype, new > >>> HashSet<>(Collections.singleton(t.qtype))); > >>> > >>> This should be fixed too. > >>> > >>> * In this statement: > >>> > >>> ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); > >>> > >>> It would be better to cache the instantiated type outside the loop > >>> since it doesn't change. > >>> > >>> Maurizio > >>> > >>> > >>> On 09/04/2019 17:51, Vicente Romero wrote: > >>>> Hi all, > >>>> > >>>> Please review fix for [1] at [2]. The issue is random and very hard > >>>> to reproduce with a regression test. Apart from the use of > >>>> non-ordering preserving data structures, the root cause was early > >>>> resolution of the inference context which was leading, in this > >>>> case, to inexact instantiation of some inference variables. > >>>> > >>>> Thanks, > >>>> Vicente > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 > >>>> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Apr 10 17:25:57 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 10 Apr 2019 13:25:57 -0400 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> Message-ID: <435c3cf9-7986-6430-8826-d61fa36123c5@oracle.com> I think that given that there are raw types in the picture and that there is a workaround we should be fine going for the change, Vicente On 4/10/19 1:03 PM, Liam Miller-Cushon wrote: > I did some testing and a found a single example where this fix rejects > code that was previously accepted. Is this change expected? > > (I don't have any concerns either way: this pattern is not common, it > involves rawtypes, and there's an easy work-around.) > > ``` > import java.util.Map; > import java.util.function.Function; > import java.util.stream.Collector; > import java.util.stream.Stream; > > abstract class A { > > ? abstract static class T { > ? ? abstract String f(); > ? } > > ? abstract Function id(); > > ? abstract static class ImmutableMap implements Map {} > > ? abstract Collector> toImmutableMap( > ? ? ? Function k, Function extends V> v); > > ? ImmutableMap> test(Stream stream) { > ? ? return stream.collect(toImmutableMap(T::f, id())); > ? } > } > ``` > > A.java:20: error: incompatible types: cannot infer type-variable(s) > T,K,V,E > ? ? return stream.collect(toImmutableMap(T::f, id())); > ? ? ? ? ? ? ? ? ? ? ? ? ?^ > ? ? (argument mismatch; Function cannot be converted to > Function>) > ? where T,K,V,E are type-variables: > ? ? T extends Object declared in method > toImmutableMap(Function,Function T,? extends V>) > ? ? K extends Object declared in method > toImmutableMap(Function,Function T,? extends V>) > ? ? V extends Object declared in method > toImmutableMap(Function,Function T,? extends V>) > ? ? E extends Object declared in method id() > 1 error > > On Tue, Apr 9, 2019 at 2:24 PM Vicente Romero > > wrote: > > thanks, > Vicente > > On 4/9/19 4:37 PM, Maurizio Cimadamore wrote: > > Looks good! > > > > Maurizio > > > > On 09/04/2019 18:17, Vicente Romero wrote: > >> Hi Maurizio, > >> > >> Thanks for your comments, please see the updated webrev at [1] > >> > >> Vicente > >> > >> [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ > >> > >> > >> > >> On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: > >>> Looks good - few comments: > >>> > >>> * there's an HashSet still used at line 404: > >>> > >>> Set deps = minMap.getOrDefault(t.qtype, new > >>> HashSet<>(Collections.singleton(t.qtype))); > >>> > >>> This should be fixed too. > >>> > >>> * In this statement: > >>> > >>> > ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); > >>> > >>> It would be better to cache the instantiated type outside the > loop > >>> since it doesn't change. > >>> > >>> Maurizio > >>> > >>> > >>> On 09/04/2019 17:51, Vicente Romero wrote: > >>>> Hi all, > >>>> > >>>> Please review fix for [1] at [2]. The issue is random and > very hard > >>>> to reproduce with a regression test. Apart from the use of > >>>> non-ordering preserving data structures, the root cause was > early > >>>> resolution of the inference context which was leading, in this > >>>> case, to inexact instantiation of some inference variables. > >>>> > >>>> Thanks, > >>>> Vicente > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 > >>>> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Apr 10 17:47:11 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Apr 2019 18:47:11 +0100 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> Message-ID: <6e6fed75-08cb-6a33-3b1e-36c1b81da5c1@oracle.com> Thanks for testing Liam. We will check if disabling the InferenceCOntext::min optimization affects the outcome in this example - if so then I think we have an issue. If not, then it looks like there was an issue before which now got fixed. In other words, the most important bit, in the context of this fix, is that there should be no behavior change introduced by the context optimization. If there is, we have to address it. Maurizio On 10/04/2019 18:03, Liam Miller-Cushon wrote: > I did some testing and a found a single example where this fix rejects > code that was previously accepted. Is this change expected? > > (I don't have any concerns either way: this pattern is not common, it > involves rawtypes, and there's an easy work-around.) > > ``` > import java.util.Map; > import java.util.function.Function; > import java.util.stream.Collector; > import java.util.stream.Stream; > > abstract class A { > > ? abstract static class T { > ? ? abstract String f(); > ? } > > ? abstract Function id(); > > ? abstract static class ImmutableMap implements Map {} > > ? abstract Collector> toImmutableMap( > ? ? ? Function k, Function extends V> v); > > ? ImmutableMap> test(Stream stream) { > ? ? return stream.collect(toImmutableMap(T::f, id())); > ? } > } > ``` > > A.java:20: error: incompatible types: cannot infer type-variable(s) > T,K,V,E > ? ? return stream.collect(toImmutableMap(T::f, id())); > ? ? ? ? ? ? ? ? ? ? ? ? ?^ > ? ? (argument mismatch; Function cannot be converted to > Function>) > ? where T,K,V,E are type-variables: > ? ? T extends Object declared in method > toImmutableMap(Function,Function T,? extends V>) > ? ? K extends Object declared in method > toImmutableMap(Function,Function T,? extends V>) > ? ? V extends Object declared in method > toImmutableMap(Function,Function T,? extends V>) > ? ? E extends Object declared in method id() > 1 error > > On Tue, Apr 9, 2019 at 2:24 PM Vicente Romero > > wrote: > > thanks, > Vicente > > On 4/9/19 4:37 PM, Maurizio Cimadamore wrote: > > Looks good! > > > > Maurizio > > > > On 09/04/2019 18:17, Vicente Romero wrote: > >> Hi Maurizio, > >> > >> Thanks for your comments, please see the updated webrev at [1] > >> > >> Vicente > >> > >> [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ > >> > >> > >> > >> On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: > >>> Looks good - few comments: > >>> > >>> * there's an HashSet still used at line 404: > >>> > >>> Set deps = minMap.getOrDefault(t.qtype, new > >>> HashSet<>(Collections.singleton(t.qtype))); > >>> > >>> This should be fixed too. > >>> > >>> * In this statement: > >>> > >>> > ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); > >>> > >>> It would be better to cache the instantiated type outside the > loop > >>> since it doesn't change. > >>> > >>> Maurizio > >>> > >>> > >>> On 09/04/2019 17:51, Vicente Romero wrote: > >>>> Hi all, > >>>> > >>>> Please review fix for [1] at [2]. The issue is random and > very hard > >>>> to reproduce with a regression test. Apart from the use of > >>>> non-ordering preserving data structures, the root cause was > early > >>>> resolution of the inference context which was leading, in this > >>>> case, to inexact instantiation of some inference variables. > >>>> > >>>> Thanks, > >>>> Vicente > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 > >>>> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Apr 10 17:55:27 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Apr 2019 18:55:27 +0100 Subject: RFR 8222289: Overhaul logic for reading/writing constant pool entries Message-ID: Hi, this patch significantly rewrites the way in which constant pool entries are read/written/handled by javac. A good description of the issues in the current architecture is given in the JBS entry [4]. Webrev: http://cr.openjdk.java.net/~mcimadamore/8222289/ A crucial part of the solution is the new PoolConstant interface. This is an interface that all javac entities that want to be written onto the constant pool must adhere to. The interface has methods for obtaining a pool tag, and, crucially, to obtain a unique key with which the entity can be stored in the pool data structure, so as to quickly check for duplicates. I've also defined a sub-interface of the PoolConstant interface called LoadableConstant, which represents the pool constants that can be loaded with ldc, and stored as static args to bootstrap methods in indy/condy. DynamicMethodSymbol now has been rewritten to express static argument list using LoadableConstant, rather than Object. This patch takes care of most issues in the existing architecture; most notably, thanks to PoolReader, most of the duplication in ModuleNameReader can be removed. Also, I've took great care in removing all eager conversions to pool indices ahead of instruction writing (which then resulted in back-requests to the pool in order to fetch the entry at given address from the Code class). To do this, I tweaked the Code class a bit, so that all methods for emitting opcodes will now take a pool constant object (which can be null if an instruction does not refer to the pool). Some changes were also necessary in Items, more specifically, in order to represent the value of an ImmediateItem as a LoadableConstant, rather than just an Object. The PoolWriter/Reader API is mostly straightforward, with a bunch of putXYZ/getXYZ methods, where XYZ is some Javac entity that needs to be written/read. Among the things to note, PoolWriter needs some special logic to handle the case where a pool entry write request is generated in the middle of another request (a queue has been used to deal with this). The PoolReader uses the same two-phase index + resolution? approach used currently by ClassReader (resolving all entries eagerly is not only a performance nightmare, since not all entries will be used, but also a source of bugs, since javac is very sensitive to when entries - esp. those for classes - are turned into real symbols). Extensive testing has been carried out. All relevant tests pass on the new code. In addition to that, I also compared the output of javac before/after the patch and made sure the results were the same. Since the output in general is different (the CP indices before/after are different), I have put together a javap patch [5] which stabilizes the javap output by normalizing all CP indices. This has proven to be a very useful tool, and we might pursue that on a followup change. Performance testing has also been carried out using our internal tools - all results seem to indicate that, at worst, the new code is 1.5% slower than the old one. Given that the new code is significantly more expressive than the old one, I think the performance difference is totally acceptable. Furthermore, when value types will be available I expect a lot of the cost associated with boxing constants (e.g. from String to LoadableConstant) to fade away. Alternatives considered: * Model the constant pool with a proper hierarchy of classes each of which models a different CP entry. This approach has been tried in Valhalla (see [1], [2] and [3]), but ultimately it was rejected because it was not possible to make it perform in a way that was satisfactory. Also, when reading the pool, fully materializing the entries (even the unused ones) was prohibitive, and was avoided (even in the Valhalla branch) in order to have acceptable performances. * Use the new ConstantDesc; while this approach has the potential to get rid of the nasty boxing for primitive constants (thanks to the fact that e.g. String already implements ConstantDesc), the ConstantDesc API is not sufficiently expressive for modeling an entire constant pool. First, not all entries are modeled (e.g. only loadable constant are, by design); secondly, there's no way to query e.g. the pool tag given a ConstantDesc. We might revise the implementation should some of these issues be addressed in future releases. Cheers Maurizio [1] - http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java [2] - http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java [3] - http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java [4] - https://bugs.openjdk.java.net/browse/JDK-8222289 [5] - http://cr.openjdk.java.net/~mcimadamore/x-javapStableOutput_v3/ From ronshapiro at google.com Wed Apr 10 17:56:50 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 10 Apr 2019 13:56:50 -0400 Subject: Understanding Name and Name.Table Message-ID: Hi, I continuously am seeing Name and Name.Table show up in profiles of annotation processors, and I have a few questions regarding the design of these classes. I first brought this up back in this thread discussing the performance of Name.contentEquals(). That conversation stalled around this comment from Jon . I believe that Javac itself does a good job using the interned Names itself, so there aren't many cases where extra Strings are being recreated internally. But for annotation processors (and maybe also compiler plugins?), which don't have access to Names/the Name.Table, they must resort to many of these suboptimal methods that create Strings. The sense that I get is that most of the Name methods that create String instances do so because class files use a modified version of UTF-8, and so the use of Convert.utf2string() greatly simplifies the implementation of these methods. Is that a correct assumption? Separately, I have some general questions about Name.Table. - Can someone explain the performance goals of it (I presume it's for performance)? Is it to limit memory usage since Strings are UTF-16 and strings in class files are stored as UTF-8, or something else? - Are the initial goals still relevant in 2019? - What is the purpose of interning Name instances? - Are there any predefined benchmarks that are run to verify any of these goals? - What is the rationale of having the SharedNameTable data as one large array? I see the documentation states that "This avoids the overhead incurred by using an array of bytes for each name" but I'm not sure what that overhead is referring to. ----- I have a prototype of a Name.Table implementation that stores Names as Strings instead of their UTF-8 byte[]. This seems to address the performance concerns from my previous thread (it saves 1.2s/build on some of our larger annotation processing builds at Google) without affecting the performance of internal javac (i.e. non-annotation processing). There should be no less overhead than the current Name implementations as it only needs to store a single field for the String, besides for the UTF-8/UTF-16 distinction. Would something like this be a worthwhile contribution? Are there ways I can evaluate whether this satisfies the performance goals of either of the other implementations so we don't need to have yet-another-Name-implementation? Thanks for your help! Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Apr 10 17:57:29 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Apr 2019 18:57:29 +0100 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: <6e6fed75-08cb-6a33-3b1e-36c1b81da5c1@oracle.com> References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> <6e6fed75-08cb-6a33-3b1e-36c1b81da5c1@oracle.com> Message-ID: <0fe0e997-1219-7e98-d2d1-cce2334f2a65@oracle.com> I've tested this against a vanilla javac w/o the optimization and it fails also with same error, which means that the optimization was altering the behavior before Vicente's patch, but doesn't now (which is good!). Liam, if that's ok with you, I think it would be worthwhile to add this test as a regression in javac, to make sure that the behavior stays the same regardless of optimizations. Maurizio On 10/04/2019 18:47, Maurizio Cimadamore wrote: > > Thanks for testing Liam. > > We will check if disabling the InferenceCOntext::min optimization > affects the outcome in this example - if so then I think we have an > issue. If not, then it looks like there was an issue before which now > got fixed. In other words, the most important bit, in the context of > this fix, is that there should be no behavior change introduced by the > context optimization. If there is, we have to address it. > > Maurizio > > On 10/04/2019 18:03, Liam Miller-Cushon wrote: >> I did some testing and a found a single example where this fix >> rejects code that was previously accepted. Is this change expected? >> >> (I don't have any concerns either way: this pattern is not common, it >> involves rawtypes, and there's an easy work-around.) >> >> ``` >> import java.util.Map; >> import java.util.function.Function; >> import java.util.stream.Collector; >> import java.util.stream.Stream; >> >> abstract class A { >> >> ? abstract static class T { >> ? ? abstract String f(); >> ? } >> >> ? abstract Function id(); >> >> ? abstract static class ImmutableMap implements Map {} >> >> ? abstract Collector> toImmutableMap( >> ? ? ? Function k, Function> extends V> v); >> >> ? ImmutableMap> test(Stream stream) { >> ? ? return stream.collect(toImmutableMap(T::f, id())); >> ? } >> } >> ``` >> >> A.java:20: error: incompatible types: cannot infer type-variable(s) >> T,K,V,E >> ? ? return stream.collect(toImmutableMap(T::f, id())); >> ? ? ? ? ? ? ? ? ? ? ? ? ?^ >> ? ? (argument mismatch; Function cannot be converted to >> Function>) >> ? where T,K,V,E are type-variables: >> ? ? T extends Object declared in method >> toImmutableMap(Function,Function> super T,? extends V>) >> ? ? K extends Object declared in method >> toImmutableMap(Function,Function> super T,? extends V>) >> ? ? V extends Object declared in method >> toImmutableMap(Function,Function> super T,? extends V>) >> ? ? E extends Object declared in method id() >> 1 error >> >> On Tue, Apr 9, 2019 at 2:24 PM Vicente Romero >> > wrote: >> >> thanks, >> Vicente >> >> On 4/9/19 4:37 PM, Maurizio Cimadamore wrote: >> > Looks good! >> > >> > Maurizio >> > >> > On 09/04/2019 18:17, Vicente Romero wrote: >> >> Hi Maurizio, >> >> >> >> Thanks for your comments, please see the updated webrev at [1] >> >> >> >> Vicente >> >> >> >> [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.01/ >> >> >> >> >> >> >> >> On 4/9/19 12:56 PM, Maurizio Cimadamore wrote: >> >>> Looks good - few comments: >> >>> >> >>> * there's an HashSet still used at line 404: >> >>> >> >>> Set deps = minMap.getOrDefault(t.qtype, new >> >>> HashSet<>(Collections.singleton(t.qtype))); >> >>> >> >>> This should be fixed too. >> >>> >> >>> * In this statement: >> >>> >> >>> >> ((UndetVar)asUndetVar(eq)).setInst(inferenceContext.asInstType(t)); >> >>> >> >>> It would be better to cache the instantiated type outside the >> loop >> >>> since it doesn't change. >> >>> >> >>> Maurizio >> >>> >> >>> >> >>> On 09/04/2019 17:51, Vicente Romero wrote: >> >>>> Hi all, >> >>>> >> >>>> Please review fix for [1] at [2]. The issue is random and >> very hard >> >>>> to reproduce with a regression test. Apart from the use of >> >>>> non-ordering preserving data structures, the root cause was >> early >> >>>> resolution of the inference context which was leading, in this >> >>>> case, to inexact instantiation of some inference variables. >> >>>> >> >>>> Thanks, >> >>>> Vicente >> >>>> >> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8222035 >> >>>> [2] http://cr.openjdk.java.net/~vromero/8222035/webrev.00/ >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Apr 10 18:37:02 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Apr 2019 11:37:02 -0700 Subject: Understanding Name and Name.Table In-Reply-To: References: Message-ID: <2b1449aa-0681-084e-72f9-545d8c14332e@oracle.com> Some comments inline. On 4/10/19 10:56 AM, Ron Shapiro wrote: > Hi, > > I continuously am seeing Name and Name.Table show up in profiles of > annotation processors, and I have a few questions regarding the design > of these classes. I first brought this up back in this thread > discussing > the performance of Name.contentEquals(). That conversation stalled > around this comment from Jon > . > I believe that Javac itself does a good job using the interned Names > itself, so there aren't many cases where extra Strings are being > recreated internally. But for annotation processors (and maybe also > compiler plugins?), which don't have access to Names/the Name.Table, > they must resort to many of these suboptimal methods that create Strings. Historical note: the use of the internal javac Name class (as compared to the JSR 269 interface of the sane name) goes all the way back to the beginning of this version of javac, round about JDK 1.4 or so. Back then, the design center for javac was to be more independent of JDK API than it is today. > > The sense that I get is that most of the Name methods that create > String instances do so because class files use a modified version of > UTF-8, and so the use of Convert.utf2string() greatly simplifies the > implementation of these methods. Is that a correct assumption? No, I don't think so. The use of modified UTF-8 is an unrelated (but nevertheless important) implementation detail.? I think you're just seeing the result of retrofitting interfaces that require methods to be implemented.? I'm guessing that the methods you are looking at are not used internally within javac itself. > > Separately, I have some general questions about Name.Table. > - Can someone explain the performance goals of it (I presume it's for > performance)? Is it to limit memory usage since Strings are UTF-16 and > strings in class files are stored as UTF-8, or something else? My understanding is that originally it was to save space, and to provide a context for "interned strings" that could be compared with referential equality. > - Are the initial goals still relevant in 2019? Maybe not as relevant as originally the case. > - What is the purpose of interning Name instances? To reduce the size of the name table, and to support referential equality. > - Are there any predefined benchmarks that are run to verify any of > these goals? No. > - What is the rationale of having the SharedNameTable data as one > large array? I see the documentation states that "This avoids the > overhead incurred by using an array of bytes for each name" but I'm > not sure what that overhead is referring to. The overhead is the overhead of having one String instance per name, and/or the overhead of having a separate array of bytes for each name. i.e. the overhead of the "one big array" is amortized over all names, > > ----- > > I have a prototype of a Name.Table implementation that stores Names as > Strings instead of their UTF-8 byte[]. This seems to address the > performance concerns from my previous thread (it saves 1.2s/build on > some of our larger annotation processing builds at Google) without > affecting the performance of internal javac (i.e. non-annotation > processing). There should be no less overhead than the current Name > implementations as it only needs to store a single field for the > String, besides for the UTF-8/UTF-16 distinction. What are the space comparisons? It is certainly the case that Strings are managed more efficiently in the JVM these days, and interned strings are handled better as well.? Your number of 1.2s doesn't mean much without more context that "our larger annotation processing builds."? What percent is that of the overall build time, and/or total time in Name/Name.Table. > > Would something like this be a worthwhile contribution? Are there ways > I can evaluate whether this satisfies the performance goals of either > of the other implementations so we don't need to have > yet-another-Name-implementation? What is now SharedNameTable is the original impl. It used to be plain NameTable, until the advent of clients, like IDEs and other tools, for whom the single shared name table was inconvenient, which is when NameTable was forked into SharedNameTable and UnsharedNameTable. If we can come up with an impl that is fast as the current impl, and as space efficient as the current impl, that would be great, but typically you have to choose one or the other to optimize.? I could believe a new impl might at least replace the current UnsharedNameTable. I think this is a worthwhile direction to investigate further. > > Thanks for your help! > Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Apr 10 18:47:24 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 10 Apr 2019 14:47:24 -0400 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: <0fe0e997-1219-7e98-d2d1-cce2334f2a65@oracle.com> References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> <6e6fed75-08cb-6a33-3b1e-36c1b81da5c1@oracle.com> <0fe0e997-1219-7e98-d2d1-cce2334f2a65@oracle.com> Message-ID: <793dc2d1-bdf0-6d2c-1141-2f36b6c330b3@oracle.com> Hi, For the record I have added the test provided by Liam, thanks, to the patch, please see [1] Vicente [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.02/ From alex.buckley at oracle.com Wed Apr 10 18:51:40 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 10 Apr 2019 11:51:40 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CAC8557.9090701@oracle.com> References: <5CAC8557.9090701@oracle.com> Message-ID: <5CAE3B3C.50704@oracle.com> // Adding jigsaw-dev -- this topic is slightly deeper than it appears. On 4/9/2019 4:43 AM, Jan Lahoda wrote: > Currently, when compiling an unnamed module, --add-modules > ALL-MODULE-PATH adds all modules from the module path to the module > graph, so that the unnamed module can refer to them. (See also http://openjdk.java.net/jeps/261#Root-modules plus the section "Root modules" in the java.lang.module package spec.) > When compiling a named module, this option is not allowed, as it would > be confusing, as it cannot modify the dependencies of the named module. > > But, when compiling a code in the context of an automatic module using > --patch-module, e.g.: > javac --module-path --patch-modules > = ... > > The --add-modules ALL-MODULE-PATH is still disallowed, but it may make > sense to use it, as it may affect the set of classes available for the > sources that are being compiled. Compiling in the context of an > automatic module may be useful esp. in when patching multiple modules at > once (which is supported by --patch-module), e.g. to build tests. (Seems > that also at least the use of javadoc in Maven may lead to a similar > setting as well, see the JBS bug.) JEP 261 doesn't discuss compiling code "in the context of an automatic module", and javac's reference guide doesn't imply that `--patch-module` supports it, but it is clearly a plausible and useful thing to do, so thanks for calling it out. There is a question to be answered: When the compiler compiles code in an automatic module (due to the code being observed in a directory that is specified to --patch-module), then what is the _default set of root modules_ for the automatic module? I expect the answer is: the same as the default set of root modules for the unnamed module. And actually, for the `javac` invocation shown above, which is single-module mode, this answer is given in the "Compile time" section of JEP 261 (http://openjdk.java.net/jeps/261#Compile-time). Unfortunately, the answer is only accidentally right, because the section did not envisage compiling code in an automatic module; for the `javac` invocation above, the section says "source files will be compiled as members of the unnamed module". So, there's another question to be answered: Does `javac` support compiling code in an automatic module in single-module mode, or multi-module both, or either? Once we know this, we can update the "Compile time" section and answer the set-of-root-modules question. > The proposal is to allow the --add-modules ALL-MODULE-PATH option when > compiling code in the context of an automatic module. I support this proposal, subject to the questions raised above. A CSR will be needed; in addition to specifying the things mentioned above, it can clarify the description of ALL-MODULE-PATH w.r.t. when it can be used at compile time. Currently, the description seems unsure about when it can be used. (For reference, the text: "As a final special case, at both run time and link time, if is ALL-MODULE-PATH then all observable modules found on the relevant module paths are added to the root set. ALL-MODULE-PATH is valid at both compile time and run time. This is provided for use by build tools such as Maven, which already ensure that all modules on the module path are needed. It is also a convenient means to add automatic modules to the root set.") Alex > Proposed patch: http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8220702 > > What do you think? > > Thanks, > Jan From maurizio.cimadamore at oracle.com Wed Apr 10 20:18:24 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Apr 2019 21:18:24 +0100 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: <793dc2d1-bdf0-6d2c-1141-2f36b6c330b3@oracle.com> References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> <6e6fed75-08cb-6a33-3b1e-36c1b81da5c1@oracle.com> <0fe0e997-1219-7e98-d2d1-cce2334f2a65@oracle.com> <793dc2d1-bdf0-6d2c-1141-2f36b6c330b3@oracle.com> Message-ID: Looks good to me - as long as Liam is ok with test being contributed and copyright. Maurizio On 10/04/2019 19:47, Vicente Romero wrote: > Hi, > > For the record I have added the test provided by Liam, thanks, to the > patch, please see [1] > > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8222035/webrev.02/ From Alan.Bateman at oracle.com Wed Apr 10 20:24:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Apr 2019 21:24:03 +0100 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CAE3B3C.50704@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> Message-ID: <4a08606c-67d1-812d-9dfd-5b68fde7643b@oracle.com> On 10/04/2019 19:51, Alex Buckley wrote: > : > > There is a question to be answered: When the compiler compiles code in > an automatic module (due to the code being observed in a directory > that is specified to --patch-module), then what is the _default set of > root modules_ for the automatic module? > > I expect the answer is: the same as the default set of root modules > for the unnamed module. This isn't the case at run-time. If the initial module is an automatic module, and there are no additional roots specified with --add-modules, then the automatic module will be the sole root. Whether it is patched or not via --patch-module doesn't change that of course. The module descriptor created for the automatic module will require (mandated) java.base so minimally the automatic module + java.base will be in the module graph. Run-time does service binding and java.base uses a lot of services so the module graph will have ~25 modules when using a JDK run-time image. The addition of service binding at run-time probably means few would notice the difference but if the right answer is the default set of root modules when we should probably change run-time too. -Alan From cushon at google.com Wed Apr 10 20:44:52 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 10 Apr 2019 13:44:52 -0700 Subject: RFR: JDK-8222035: Unused variable declaration causes inference error In-Reply-To: References: <4155f917-6721-bb3b-38f7-1b690844b406@oracle.com> <6be989ec-c453-483a-32f0-54c8fc6add6c@oracle.com> <89e2d9e3-3d62-5064-ee90-56ab443ffebb@oracle.com> <6e6fed75-08cb-6a33-3b1e-36c1b81da5c1@oracle.com> <0fe0e997-1219-7e98-d2d1-cce2334f2a65@oracle.com> <793dc2d1-bdf0-6d2c-1141-2f36b6c330b3@oracle.com> Message-ID: On Wed, Apr 10, 2019 at 1:18 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Looks good to me - as long as Liam is ok with test being contributed and > copyright. > Looks good to me too, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Apr 10 21:51:54 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Apr 2019 14:51:54 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CAE3B3C.50704@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> Message-ID: <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> On 4/10/19 11:51 AM, Alex Buckley wrote: > There is a question to be answered: When the compiler compiles code in > an automatic module (due to the code being observed in a directory > that is specified to --patch-module), then what is the _default set of > root modules_ for the automatic module? > > I expect the answer is: the same as the default set of root modules > for the unnamed module. I would not expect the fact that you're compiling code in one or more automatic modules to have any effect on the module graph. The fact that the definitions of some types have been "patched in" using source code via --patch-module is (or should be) irrelevant. -- Jon From alex.buckley at oracle.com Wed Apr 10 22:07:27 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 10 Apr 2019 15:07:27 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> Message-ID: <5CAE691F.6090709@oracle.com> On 4/10/2019 2:51 PM, Jonathan Gibbons wrote: > On 4/10/19 11:51 AM, Alex Buckley wrote: >> There is a question to be answered: When the compiler compiles code in >> an automatic module (due to the code being observed in a directory >> that is specified to --patch-module), then what is the _default set of >> root modules_ for the automatic module? >> >> I expect the answer is: the same as the default set of root modules >> for the unnamed module. > > I would not expect the fact that you're compiling code in one or more > automatic modules to have any effect on the module graph. The fact that > the definitions of some types have been "patched in" using source code > via --patch-module is (or should be) irrelevant. I'm not sure how anyone compiles code as if in an automatic module, since the automatic module is solely a JAR file, but Jan suggests that it's possible to patch an automatic module's content with the source files being compiled. So, I looked in JEP 261 to see how javac would treat those source files: "If a module descriptor in the form of a module-info.java or module-info.class file is specified on the command line [NO], or is found on the source path [NO] or the class path [NO], then source files will be compiled as members of the module named by that descriptor and that module will be the sole root module. Otherwise if the --module option is present [NO] then source files will be compiled as members of , which will be the root module. Otherwise [I GUESS WE'RE HERE] source files will be compiled as members of the unnamed module, and the root modules will be computed as described above." Alex From jonathan.gibbons at oracle.com Wed Apr 10 22:19:51 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Apr 2019 15:19:51 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CAE691F.6090709@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> Message-ID: <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> On 4/10/19 3:07 PM, Alex Buckley wrote: > On 4/10/2019 2:51 PM, Jonathan Gibbons wrote: >> On 4/10/19 11:51 AM, Alex Buckley wrote: >>> There is a question to be answered: When the compiler compiles code in >>> an automatic module (due to the code being observed in a directory >>> that is specified to --patch-module), then what is the _default set of >>> root modules_ for the automatic module? >>> >>> I expect the answer is: the same as the default set of root modules >>> for the unnamed module. >> >> I would not expect the fact that you're compiling code in one or more >> automatic modules to have any effect on the module graph. The fact that >> the definitions of some types have been "patched in" using source code >> via --patch-module is (or should be) irrelevant. > > I'm not sure how anyone compiles code as if in an automatic module, > since the automatic module is solely a JAR file, but Jan suggests that > it's possible to patch an automatic module's content with the source > files being compiled. So, I looked in JEP 261 to see how javac would > treat those source files: > > "If a module descriptor in the form of a module-info.java or > module-info.class file is specified on the command line [NO], or is > found on the source path [NO] or the class path [NO], then source > files will be compiled as members of the module named by that > descriptor and that module will be the sole root module. Otherwise if > the --module option is present [NO] then source files will be > compiled as members of , which will be the root module. > Otherwise [I GUESS WE'RE HERE] source files will be compiled as > members of the unnamed module, and the root modules will be computed > as described above." > > Alex It sounds like JEP 261 should be updated with more info about patching modules, since "you are not here" where you guess we are. At compilation time, --patch-module allows any content to be "patched in" to any module in the module graph. The content may be provided in source form or compiled form. In either case, the context for any names mentioned in the content is determined by the module being patched, and its dependencies. -- Jon From jan.lahoda at oracle.com Thu Apr 11 08:19:42 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 11 Apr 2019 10:19:42 +0200 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> Message-ID: <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> On 11. 04. 19 0:19, Jonathan Gibbons wrote: > > On 4/10/19 3:07 PM, Alex Buckley wrote: >> On 4/10/2019 2:51 PM, Jonathan Gibbons wrote: >>> On 4/10/19 11:51 AM, Alex Buckley wrote: >>>> There is a question to be answered: When the compiler compiles code in >>>> an automatic module (due to the code being observed in a directory >>>> that is specified to --patch-module), then what is the _default set of >>>> root modules_ for the automatic module? >>>> >>>> I expect the answer is: the same as the default set of root modules >>>> for the unnamed module. >>> >>> I would not expect the fact that you're compiling code in one or more >>> automatic modules to have any effect on the module graph. The fact that >>> the definitions of some types have been "patched in" using source code >>> via --patch-module is (or should be) irrelevant. >> >> I'm not sure how anyone compiles code as if in an automatic module, >> since the automatic module is solely a JAR file, but Jan suggests that >> it's possible to patch an automatic module's content with the source >> files being compiled. So, I looked in JEP 261 to see how javac would >> treat those source files: >> >> "If a module descriptor in the form of a module-info.java or >> module-info.class file is specified on the command line [NO], or is >> found on the source path [NO] or the class path [NO], then source >> files will be compiled as members of the module named by that >> descriptor and that module will be the sole root module. Otherwise if >> the --module option is present [NO] then source files will be >> compiled as members of , which will be the root module. >> Otherwise [I GUESS WE'RE HERE] source files will be compiled as >> members of the unnamed module, and the root modules will be computed >> as described above." >> >> Alex > > It sounds like JEP 261 should be updated with more info about patching > modules, since "you are not here" where you guess we are. Yes, I think JEP 261 may need updates. I'd say this is somewhat unforeseen interaction between automatic modules and --patch-module. When patching a (named) module (or a set of named modules), that module (or modules) become the root module for javac, and the ordinary module graph building algorithm is then used to build the module graph. So the set of modules in the module graph may be different from the set of the modules in the module graph when compiling source in the unnamed module. Jan > > At compilation time, --patch-module allows any content to be "patched > in" to any module in the module graph. The content may be provided in > source form or compiled form. In either case, the context for any names > mentioned in the content is determined by the module being patched, and > its dependencies. > > -- Jon > From maurizio.cimadamore at oracle.com Thu Apr 11 11:51:41 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Apr 2019 12:51:41 +0100 Subject: Understanding Name and Name.Table In-Reply-To: <2b1449aa-0681-084e-72f9-545d8c14332e@oracle.com> References: <2b1449aa-0681-084e-72f9-545d8c14332e@oracle.com> Message-ID: I'm a bit skeptical about String::intern as the cure. From many sources I've seen that performances of String::intern degrades rather quickly with the number of strings being interned (at which point an HashMap-based implementation beats String::intern any day of the week). Look for instance at this great post from Alex Shipilev: https://shipilev.net/jvm/anatomy-quarks/10-string-intern/ Maurizio On 10/04/2019 19:37, Jonathan Gibbons wrote: > > Some comments inline. > > > On 4/10/19 10:56 AM, Ron Shapiro wrote: >> Hi, >> >> I continuously am seeing Name and Name.Table show up in profiles of >> annotation processors, and I have a few questions regarding the >> design of these classes. I first brought this up back in this thread >> discussing >> the performance of Name.contentEquals(). That conversation stalled >> around this comment from Jon >> . >> I believe that Javac itself does a good job using the interned Names >> itself, so there aren't many cases where extra Strings are being >> recreated internally. But for annotation processors (and maybe also >> compiler plugins?), which don't have access to Names/the Name.Table, >> they must resort to many of these suboptimal methods that create Strings. > > Historical note: the use of the internal javac Name class (as compared > to the JSR 269 interface of the sane name) goes all the way back to > the beginning of this version of javac, round about JDK 1.4 or so. > Back then, the design center for javac was to be more independent of > JDK API than it is today. > > >> >> The sense that I get is that most of the Name methods that create >> String instances do so because class files use a modified version of >> UTF-8, and so the use of Convert.utf2string() greatly simplifies the >> implementation of these methods. Is that a correct assumption? > No, I don't think so. The use of modified UTF-8 is an unrelated (but > nevertheless important) implementation detail.? I think you're just > seeing the result of retrofitting interfaces that require methods to > be implemented.? I'm guessing that the methods you are looking at are > not used internally within javac itself. >> >> Separately, I have some general questions about Name.Table. >> - Can someone explain the performance goals of it (I presume it's for >> performance)? Is it to limit memory usage since Strings are UTF-16 >> and strings in class files are stored as UTF-8, or something else? > > My understanding is that originally it was to save space, and to > provide a context for "interned strings" that could be compared with > referential equality. > > >> - Are the initial goals still relevant in 2019? > > Maybe not as relevant as originally the case. > > >> - What is the purpose of interning Name instances? > > To reduce the size of the name table, and to support referential equality. > > >> - Are there any predefined benchmarks that are run to verify any of >> these goals? > > No. > > >> - What is the rationale of having the SharedNameTable data as one >> large array? I see the documentation states that "This avoids the >> overhead incurred by using an array of bytes for each name" but I'm >> not sure what that overhead is referring to. > > The overhead is the overhead of having one String instance per name, > and/or the overhead of having a separate array of bytes for each name. > i.e. the overhead of the "one big array" is amortized over all names, > > >> >> ----- >> >> I have a prototype of a Name.Table implementation that stores Names >> as Strings instead of their UTF-8 byte[]. This seems to address the >> performance concerns from my previous thread (it saves 1.2s/build on >> some of our larger annotation processing builds at Google) without >> affecting the performance of internal javac (i.e. non-annotation >> processing). There should be no less overhead than the current Name >> implementations as it only needs to store a single field for the >> String, besides for the UTF-8/UTF-16 distinction. > > What are the space comparisons? It is certainly the case that Strings > are managed more efficiently in the JVM these days, and interned > strings are handled better as well.? Your number of 1.2s doesn't mean > much without more context that "our larger annotation processing > builds."? What percent is that of the overall build time, and/or total > time in Name/Name.Table. > > >> >> Would something like this be a worthwhile contribution? Are there >> ways I can evaluate whether this satisfies the performance goals of >> either of the other implementations so we don't need to have >> yet-another-Name-implementation? > > > What is now SharedNameTable is the original impl. It used to be plain > NameTable, until the advent of clients, like IDEs and other tools, for > whom the single shared name table was inconvenient, which is when > NameTable was forked into SharedNameTable and UnsharedNameTable. > > If we can come up with an impl that is fast as the current impl, and > as space efficient as the current impl, that would be great, but > typically you have to choose one or the other to optimize.? I could > believe a new impl might at least replace the current UnsharedNameTable. > > I think this is a worthwhile direction to investigate further. > > >> >> Thanks for your help! >> Ron >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Apr 11 18:28:00 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 11 Apr 2019 11:28:00 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> Message-ID: <5CAF8730.6080401@oracle.com> On 4/11/2019 1:19 AM, Jan Lahoda wrote: > Yes, I think JEP 261 may need updates. I'd say this is somewhat > unforeseen interaction between automatic modules and --patch-module. > > When patching a (named) module (or a set of named modules), that module > (or modules) become the root module for javac, and the ordinary module > graph building algorithm is then used to build the module graph. So the > set of modules in the module graph may be different from the set of the > modules in the module graph when compiling source in the unnamed module. OK. It sounds like (i) single-module mode supports source files being compiled as if members of a named module (the module being patched), and (ii) multi-module mode supports source files being compiled as if members of named modules (the modules being patched). Great. Broadly, JEP 261 is correct when it says this in "Root modules": ----- Otherwise, the default set of root modules depends upon the phase: - At compile time it is usually the set of modules being compiled (more on this below); ----- where "below", it is correct for multi-module mode: ----- The set of root modules is the set of modules for which at least one source file is specified. ----- but incorrect for single-module mode: (assuming javac is invoked as shown in your first mail) ----- Otherwise source files will be compiled as members of the unnamed module, and the root modules will be computed as described above. ----- JEP 261 is the ultimate source of truth for the module system, from which all tutorials, blogs, books, etc derive. It's very hard to infer from it that javac supports compiling source as if in a patched module. That's why a CSR to record what javac does (either with no --add-modules or with --add-modules=ALL-MODULE-PATH) will be so valuable. In advance of that, can you share some detailed invocations of javac using --patch-module in single-module and multi-module mode? Alex From martin.doerr at sap.com Thu Apr 11 09:52:57 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 11 Apr 2019 09:52:57 +0000 Subject: RFR(XS): 8220625: tools/javac/classreader/8171132/BadConstantValue.java failed with "did not see expected error" Message-ID: Hi, we have also seen this test failing. I've analyzed the issue and added a comment: https://bugs.openjdk.java.net/browse/JDK-8220625 My suggested fix: http://cr.openjdk.java.net/~mdoerr/8171132_BadConstantValue/webrev.00/ Please check if the ClassReader behavior is as expected (usage of .java file with same timestamp even though .class file was provided). If so, please review my trivial fix. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sormuras at gmail.com Thu Apr 11 19:00:30 2019 From: sormuras at gmail.com (Christian Stein) Date: Thu, 11 Apr 2019 21:00:30 +0200 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CAF8730.6080401@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> Message-ID: On Thu, Apr 11, 2019 at 8:30 PM Alex Buckley wrote: > [...] In advance > of that, can you share some detailed invocations of javac using > --patch-module in single-module and multi-module mode? > I'm not sure if this helps in any regards -- here [1] is a draft PR that adds explicit module descriptors to all JUnit 5 modules. This PR uses javac in multi-module mode and --patch-module to access the already (with --release 8) compiled classes of each module. The "src/modules/build.jsh " jshell script allows an OS-agnostic execution of the javac command. Hope that helps, Christian [1] https://github.com/junit-team/junit5/pull/1848/commits/f8ed9ad6c37bfcf9512f2747874d3974750b9d16 -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Apr 11 20:33:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 11 Apr 2019 20:33:44 +0000 Subject: RFR(XS): 8220625: tools/javac/classreader/8171132/BadConstantValue.java failed with "did not see expected error" In-Reply-To: References: Message-ID: Hi Martin, I think this is a good fix for the issue. You could also try to compile from a source dir that is different to the classes dir that is used later on to load the bad class. I think using the .java file if it is younger than the .class file is correct, when loading the class. Best regards Christoph From: compiler-dev On Behalf Of Doerr, Martin Sent: Donnerstag, 11. April 2019 11:53 To: compiler-dev at openjdk.java.net Subject: [CAUTION] RFR(XS): 8220625: tools/javac/classreader/8171132/BadConstantValue.java failed with "did not see expected error" Hi, we have also seen this test failing. I've analyzed the issue and added a comment: https://bugs.openjdk.java.net/browse/JDK-8220625 My suggested fix: http://cr.openjdk.java.net/~mdoerr/8171132_BadConstantValue/webrev.00/ Please check if the ClassReader behavior is as expected (usage of .java file with same timestamp even though .class file was provided). If so, please review my trivial fix. Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Apr 11 20:40:37 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 11 Apr 2019 13:40:37 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> Message-ID: <5CAFA645.8090305@oracle.com> On 4/11/2019 12:00 PM, Christian Stein wrote: > I'm not sure if this helps in any regards -- here [1] is a draft PR > that adds explicit module descriptors to all JUnit 5 modules. > > This PR uses javac in multi-module mode and --patch-module > to access the already (with --release 8) compiled classes of > each module. Thanks Christian. Ultimately you're invoking javac like so: javac --patch-module org.junit.platform.commons= junit-platform-commons/build/classes/java/main --module-version 1.5.0-SNAPSHOT src/modules/org.junit.platform.commons/module-info.java where it is interesting to see --patch-module indicating the putative content of a module before the module-info.java file which declares the module into existence has been compiled! You even get the benefit of error-checking for module-info.java, e.g., that its `exports` refer to packages which truly exist in the module. I suppose if you just put junit-platform-commons/build/classes/java/main on the --module-path then you would not get this checking. The first point for using --patch-module at compile time goes to Jan for building tests as if members of automatic modules; you get the second point for building module declarations as if members of ... well, themselves. Alex From GROEGES at uk.ibm.com Fri Apr 12 10:37:48 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 12 Apr 2019 11:37:48 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: <55bd5ddb-4d85-1a36-f067-a33fcc0c14b6@oracle.com> References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> <55bd5ddb-4d85-1a36-f067-a33fcc0c14b6@oracle.com> Message-ID: Hi Jan, I didn't know that the /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java test is effected by updates to the diagnostic messages. So thatnks for letting me know. I ran this test and it did fail as you expected. Have added the message to the test/langtools/tools/javac/diags/examples.not-yet.txt files, as that was where the others were. I can't run the tests via: https://wiki.openjdk.java.net/display/Build/Submit+Repo as I dont have authority (i'm not a committer) I have run the test/langtools tests with and without my chnages and the test results are the same, so I can assume that my changes havent broken anything. I made the similar changes on jdk8u to the examples.not-yet.txt file but the CheckExamples.java fails anyway, even without my changes, but making that chnage give it one less error. I have updated the webrevs for jdk [1] and for jdk8u [2] Will follow the jdk8u update process that you mentioned to get those changes updated, but anything you can do for jdk would be great. Thanks [1] http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/ [2] http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.04/ Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Jan Lahoda To: Steve Groeger Cc: compiler-dev at openjdk.java.net Date: 10/04/2019 16:13 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Hi Steve, One more question - do tests pass with this patch, at least the test/langtools tests, or jdk/submit? https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openjdk.java.net_display_Build_Submit-2BRepo&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=kS7bRBMBIrkh29UWtS9hJyM79QP8OAILH2GKfFdP4lU&s=wurqI5Tc-EX4GeOF4yLhxMOq6W_iM0cxglGVYpB8Ytw&e= (adding new diagnostic messages often need adjustments to /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java ) Regarding JDK 8 updates, please note there's a separate for that: https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openjdk.java.net_display_jdk8u_Main&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=kS7bRBMBIrkh29UWtS9hJyM79QP8OAILH2GKfFdP4lU&s=a9N0U_jzcIhnwt02JUvN9FP68zto4FFTSPnOESsvhKQ&e= Jan On 10. 04. 19 14:43, Steve Groeger wrote: > Hi Jan, > > I have made the change to throw the same error as when we get the > ServiceConfigurationError and removed the call the FatalError. > I have created 2 new webrevs for jdk [1] and for jdk8u [2]. > Hopefully these are now OK and in a suitable state to be able to be > re-reviewed and then merged. > If there is anything else that is needed please do not hesitate to > contact me. > > [1] _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.03_-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=kS7bRBMBIrkh29UWtS9hJyM79QP8OAILH2GKfFdP4lU&s=D83AAoEQGJUJOeXsRXAbmxrWWmxw6FtNZZoLAI3z-sk&e= > [2] _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.03_-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=kS7bRBMBIrkh29UWtS9hJyM79QP8OAILH2GKfFdP4lU&s=nku78uykKmH2ul44jJ7nWGywUXnZJkzhLGWShf2K6fY&e= > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Steve Groeger > To: Jan Lahoda > Cc: compiler-dev at openjdk.java.net > Date: 10/04/2019 10:59 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > Sent by: "compiler-dev" > ------------------------------------------------------------------------ > > > > Hi Jan, > > Thanks for responding. > > I don't think you are missing anything with regards to the use of this: >> public FatalError(JCDiagnostic d, Throwable t) {} > > I think that was me missing the fact this would cause NPE and mask the > actual issue. > > I will probably go with your original suggestion: >> Would there be an issue with simply changing the "catch >> (Throwable)" to also report the same error as >> "catch (ServiceConfigurationError)"? > > Will make these changes and generate some new webrevs for this and post > again when they are available. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Jan Lahoda > To: Steve Groeger > Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons > > Date: 10/04/2019 09:51 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > ------------------------------------------------------------------------ > > > > Hi Steve, > > I apologize for a late reply. For the FatalError, seems that this > constructor is being called there: > public FatalError(JCDiagnostic d, Throwable t) { > super(d.toString(), t); > } > > with "d == null". That, I think, will lead to an immediate NPE, which I > don't think is desirable, as it will hide the actual exception that was > thrown. Or do I miss something? > > Thanks, > Jan > > On 09. 04. 19 11:02, Steve Groeger wrote: >> Hi Jan, >> >> I sent the post below about a month ago but didn't get a response from >> you as to the review of the new webrevs. >> Not sure whether you got it or not but I would be grateful if you could >> take a look at these webrevs and let me know whether they are OK now. >> If they are OK, please let me know the next steps needed to get these >> merged into the code base. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Steve Groeger >> To: Jan Lahoda >> Cc: compiler-dev at openjdk.java.net >> Date: 07/03/2019 09:57 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> Sent by: "compiler-dev" >> ------------------------------------------------------------------------ >> >> >> >> Hi Jan, >> >> Thanks for providing a possible test for the malformed Annotation Processor. >> I have taken the code you provided and tweaked it a bit (for jdk) and >> had to >> write a similar thing for jdk8u as some of the functionality in the test >> is not >> available in the same form in jdk8u (well, not that I could find!!!) >> >> I would be grateful if you could review to code in the new webrevs. >> _ >> ___ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.02_-5F-5F-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=kS7bRBMBIrkh29UWtS9hJyM79QP8OAILH2GKfFdP4lU&s=w22WxhlERvQVGCduF_Db7LLuKto_J4qkxJ76EMCimog&e= >> ___ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.02_-5F-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=kS7bRBMBIrkh29UWtS9hJyM79QP8OAILH2GKfFdP4lU&s=-GpxprvGoLZkEGK-MYRAApSJ_QWBVdzQR4805ldJbo8&e= >> >> Any issues please let me know. >> >> PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we >> wanted Jon to comment on whether this is what is required or whether >> we go with your previous suggestion. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Apr 12 12:34:12 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 12 Apr 2019 14:34:12 +0200 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5CAF8730.6080401@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> Message-ID: <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> On 11. 04. 19 20:28, Alex Buckley wrote: > On 4/11/2019 1:19 AM, Jan Lahoda wrote: >> Yes, I think JEP 261 may need updates. I'd say this is somewhat >> unforeseen interaction between automatic modules and --patch-module. >> >> When patching a (named) module (or a set of named modules), that module >> (or modules) become the root module for javac, and the ordinary module >> graph building algorithm is then used to build the module graph. So the >> set of modules in the module graph may be different from the set of the >> modules in the module graph when compiling source in the unnamed module. > > OK. It sounds like (i) single-module mode supports source files being > compiled as if members of a named module (the module being patched), and > (ii) multi-module mode supports source files being compiled as if > members of named modules (the modules being patched). Great. > > Broadly, JEP 261 is correct when it says this in "Root modules": > > ----- > Otherwise, the default set of root modules depends upon the phase: > - At compile time it is usually the set of modules being compiled (more > on this below); > ----- > > where "below", it is correct for multi-module mode: > > ----- > The set of root modules is the set of modules for which at least one > source file is specified. > ----- > > but incorrect for single-module mode: (assuming javac is invoked as > shown in your first mail) > > ----- > Otherwise source files will be compiled as members of the unnamed > module, and the root modules will be computed as described above. > ----- > > JEP 261 is the ultimate source of truth for the module system, from > which all tutorials, blogs, books, etc derive. It's very hard to infer > from it that javac supports compiling source as if in a patched module. > That's why a CSR to record what javac does (either with no --add-modules > or with --add-modules=ALL-MODULE-PATH) will be so valuable. In advance > of that, can you share some detailed invocations of javac using > --patch-module in single-module and multi-module mode? I've started with the CSR here: https://bugs.openjdk.java.net/browse/JDK-8222396 Consider a directory "path" that contains "automatic.jar", which does not have a module-info.class, and "explicit.jar" which has module-info.class. The a compilation in multi-module mode might look like this: $ javac -d out --patch-module automatic=test/automatic/src --patch-module explicit=test/explicit/src --module-path path --module-source-path dummy test/automatic/src/automatic/AutomaticTest.java test/explicit/src/explicit/ExplicitTest.java A compilation in single-module mode might look like: $ javac -d out --patch-module explicit=test/explicit/src --module-path path test/explicit/src/explicit/ExplicitTest.java Jan > > Alex From Alan.Bateman at oracle.com Fri Apr 12 13:19:50 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Apr 2019 14:19:50 +0100 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> Message-ID: <1e7d0fba-c9bd-62b0-e6c5-7402bcffd193@oracle.com> On 12/04/2019 13:34, Jan Lahoda wrote: > : > > Consider a directory "path" that contains "automatic.jar", which does > not have a module-info.class, and "explicit.jar" which has > module-info.class. The a compilation in multi-module mode might look > like this: > $ javac -d out --patch-module automatic=test/automatic/src > --patch-module explicit=test/explicit/src --module-path path > --module-source-path dummy > test/automatic/src/automatic/AutomaticTest.java > test/explicit/src/explicit/ExplicitTest.java I think this mean that "automatic" reads "explicit" and all other modules that the recursive enumeration of "explicit" brings to the graph. This AutomaticTest can refer to any of the public types in any of the packages exported by the modules. There was a suggestion in one of the mails that the set of default modules (all those in the run-time image that export an API) would also be resolved but I don't think this is the case here. -Alan From jan.lahoda at oracle.com Fri Apr 12 13:31:43 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 12 Apr 2019 15:31:43 +0200 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> <55bd5ddb-4d85-1a36-f067-a33fcc0c14b6@oracle.com> Message-ID: <1cfdeabf-23f7-1a51-deac-b5566e60a9c7@oracle.com> On 12. 04. 19 12:37, Steve Groeger wrote: > Hi Jan, > > I didn't know that the > /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java > test is effected by updates to the diagnostic messages. So thatnks for > letting me know. I ran this test and it did fail as you expected. Have > added the message to the > test/langtools/tools/javac/diags/examples.not-yet.txt files, as that was > where the others were. > > I can't run the tests via: > _https://wiki.openjdk.java.net/display/Build/Submit+Repo_as I dont have > authority (i'm not a committer) > I have run the test/langtools tests with and without my chnages and the > test results are the same, so I can assume that my changes havent broken > anything. > > I made the similar changes on jdk8u to the examples.not-yet.txt file but > the CheckExamples.java fails anyway, even without my changes, but making > that chnage give it one less error. > > I have updated the webrevs for jdk [1] and for jdk8u [2] > > Will follow the jdk8u update process that you mentioned to get those > changes updated, but anything you can do for jdk would be great. Thanks > > [1] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/_ I think this looks fine, thanks. Jon, do you want to take a look and/or sponsor the change, or should I? Thanks, Jan > [2] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.04/_ > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Jan Lahoda > To: Steve Groeger > Cc: compiler-dev at openjdk.java.net > Date: 10/04/2019 16:13 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > ------------------------------------------------------------------------ > > > > Hi Steve, > > One more question - do tests pass with this patch, at least the > test/langtools tests, or jdk/submit? > https://wiki.openjdk.java.net/display/Build/Submit+Repo > > (adding new diagnostic messages often need adjustments to > /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java > ) > > Regarding JDK 8 updates, please note there's a separate for that: > https://wiki.openjdk.java.net/display/jdk8u/Main > > Jan > > On 10. 04. 19 14:43, Steve Groeger wrote: >> Hi Jan, >> >> I have made the change to throw the same error as when we get the >> ServiceConfigurationError and removed the call the FatalError. >> I have created 2 new webrevs for jdk [1] and for jdk8u [2]. >> Hopefully these are now OK and in a suitable state to be able to be >> re-reviewed and then merged. >> If there is anything else that is needed please do not hesitate to >> contact me. >> >> [1] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.03/_ >> [2] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.03/_ >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Steve Groeger >> To: Jan Lahoda >> Cc: compiler-dev at openjdk.java.net >> Date: 10/04/2019 10:59 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> Sent by: "compiler-dev" >> ------------------------------------------------------------------------ >> >> >> >> Hi Jan, >> >> Thanks for responding. >> >> I don't think you are missing anything with regards to the use of this: >>> ? ? public FatalError(JCDiagnostic d, Throwable t) {} >> >> I think that was me missing the fact this would cause NPE and mask the >> actual issue. >> >> I will probably go with your original suggestion: >>> Would there be an issue with simply changing the "catch >>> (Throwable)" to also report the same error as >>> "catch (ServiceConfigurationError)"? >> >> Will make these changes and generate some new webrevs for this and post >> again when they are available. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Jan Lahoda >> To: Steve Groeger >> Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons >> >> Date: 10/04/2019 09:51 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> ------------------------------------------------------------------------ >> >> >> >> Hi Steve, >> >> I apologize for a late reply. For the FatalError, seems that this >> constructor is being called there: >> ?? ?public FatalError(JCDiagnostic d, Throwable t) { >> ?? ? ? ?super(d.toString(), t); >> ?? ?} >> >> with "d == null". That, I think, will lead to an immediate NPE, which I >> don't think is desirable, as it will hide the actual exception that was >> thrown. Or do I miss something? >> >> Thanks, >> ?? ?Jan >> >> On 09. 04. 19 11:02, Steve Groeger wrote: >>> Hi Jan, >>> >>> I sent the post below about a month ago but didn't get a response ?from >>> you as to the review of the new webrevs. >>> Not sure whether you got it or not but I would be grateful if you ?could >>> take a look at these webrevs and let me know whether they are OK now. >>> If they are OK, please let me know the next steps needed to get these >>> merged into the code base. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 ?129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >>> >>> >>> >>> From: Steve Groeger >>> To: Jan Lahoda >>> Cc: compiler-dev at openjdk.java.net >>> Date: 07/03/2019 09:57 >>> Subject: Re: RFR: [8218152] javac fails and exits with no error if ?a bad >>> annotation processor is on the classpath >>> Sent by: "compiler-dev" >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Hi Jan, >>> >>> Thanks for providing a possible test for the malformed Annotation ?Processor. >>> I have taken the code you provided and tweaked it a bit (for jdk) ?and >>> had to >>> write a similar thing for jdk8u as some of the functionality in the ?test >>> is not >>> available in the same form in jdk8u (well, not that I could find!!!) >>> >>> I would be grateful if you could review to code in the new webrevs. >>> _ >>> ___http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/___ >>> ___http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/__ >>> >>> Any issues please let me know. >>> >>> PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we >>> wanted Jon to comment on whether this is what is required or whether >>> we go with your previous suggestion. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 ?129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alex.buckley at oracle.com Fri Apr 12 19:03:57 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 12 Apr 2019 12:03:57 -0700 Subject: RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH In-Reply-To: <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> References: <5CAC8557.9090701@oracle.com> <5CAE3B3C.50704@oracle.com> <27406b64-b4a5-761f-8e85-7b48d1296b95@oracle.com> <5CAE691F.6090709@oracle.com> <818cbd8a-d05a-d8be-221a-2d193eccb7bc@oracle.com> <1268fc7d-a685-8990-0d97-fb712eb25b00@oracle.com> <5CAF8730.6080401@oracle.com> <5eb0e33d-7cc9-a2ed-6a3d-95e8dccc992f@oracle.com> Message-ID: <5CB0E11D.8070801@oracle.com> On 4/12/2019 5:34 AM, Jan Lahoda wrote: > I've started with the CSR here: > https://bugs.openjdk.java.net/browse/JDK-8222396 Looks pretty good. I made some edits to record both of your single-module and multi-module invocations of javac. The use case of injecting test code is clear, but the exact connection between automatic modules and test code is pretty opaque. Is the goal to make the automatic test module read the explicit test module so that the former module's code can access the latter module's code? Is the goal to make the automatic module read (and therefore test) at least the same set of modules as the explicit modules `requires`? Alex From joe.darcy at oracle.com Fri Apr 12 20:53:51 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Apr 2019 13:53:51 -0700 Subject: JDK 13 RFR of JDK-8222378: Provide mechanism to query preview feature status for annotation processors Message-ID: <26e8c2e4-e11a-9b6e-d315-d0d3e5c78a4f@oracle.com> Hello, Please review the code changes and CSR to address: ??? JDK-8222378: Provide mechanism to query preview feature status for annotation processors ??? webrev: http://cr.openjdk.java.net/~darcy/8222378.0/ ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8222424 In brief, a isPreviewEnabled predicate default method is added to ProcessingEnvironment to allow processors to query whether or not preview features (JEP 12) are enabled. Thanks, -Joe From joe.darcy at oracle.com Fri Apr 12 21:35:24 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 12 Apr 2019 14:35:24 -0700 Subject: JDK 13 RFR of JDK-8222430: Add tests for ElementKind predicates Message-ID: Hello, Ahead of some amber work, please review the addition of a test for the ElementKind primitives: ??? JDK-8222430: Add tests for ElementKind predicates ??? http://cr.openjdk.java.net/~darcy/8222430.0/ New test sans standard license below. Thanks, -Joe // license omitted here for brevity /* ?* @test ?* @bug 8222430 ?* @summary Test various predicates of ElementKind. ?*/ import java.util.Set; import java.util.function.Predicate; import javax.lang.model.element.ElementKind; /** ?* Test the isClass, isField, and isInterface predicates of ElementKind. ?*/ public class TestElementKindPredicates { ??? public static void main(String... args) { ??????? Set ALL_KINDS = Set.of(ElementKind.values()); ??????? // isClass: Returns true if this is a kind of class: either CLASS or ENUM. ??????? test(ALL_KINDS, ???????????? (ElementKind k) -> Set.of(ElementKind.CLASS, ElementKind.ENUM).contains(k), ???????????? (ElementKind k) -> k.isClass(), "isClass"); ??????? // isField: Returns true if this is a kind of field: either FIELD or ENUM_CONSTANT. ??????? test(ALL_KINDS, ???????????? (ElementKind k) -> Set.of(ElementKind.FIELD, ElementKind.ENUM_CONSTANT).contains(k), ???????????? (ElementKind k) -> k.isField(), "isField"); ??????? // isInterface: Returns true if this is a kind of interface: either INTERFACE or ANNOTATION_TYPE. ??????? test(ALL_KINDS, ???????????? (ElementKind k) -> Set.of(ElementKind.INTERFACE, ElementKind.ANNOTATION_TYPE).contains(k), ???????????? (ElementKind k) -> k.isInterface(), "isInterface"); ??? } ??? private static void test(Set kinds, ???????????????????????????? Predicate expectedPred, ???????????????????????????? Predicate actualPred, ???????????????????????????? String errorMessage) { ??????? for(ElementKind kind : kinds) { ??????????? boolean expected = expectedPred.test(kind); ??????????? boolean actual = actualPred.test(kind); ??????????? if (expected != actual) { ??????????????? throw new RuntimeException("Error testing ElementKind." + errorMessage + "(" +? kind + ?????????????????????????????????????????? "):\texpected " + expected + "\tgot " + actual); ??????????? } ??????? } ??? } } From joe.darcy at oracle.com Mon Apr 15 20:35:10 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 15 Apr 2019 13:35:10 -0700 Subject: JDK 13 RFR of JDK-8222378: Provide mechanism to query preview feature status for annotation processors In-Reply-To: <26e8c2e4-e11a-9b6e-d315-d0d3e5c78a4f@oracle.com> References: <26e8c2e4-e11a-9b6e-d315-d0d3e5c78a4f@oracle.com> Message-ID: PS Updated test to cover the default method in ??? http://cr.openjdk.java.net/~darcy/8222378.1 -Joe On 4/12/2019 1:53 PM, Joe Darcy wrote: > Hello, > > Please review the code changes and CSR to address: > > ??? JDK-8222378: Provide mechanism to query preview feature status for > annotation processors > ??? webrev: http://cr.openjdk.java.net/~darcy/8222378.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8222424 > > In brief, a isPreviewEnabled predicate default method is added to > ProcessingEnvironment to allow processors to query whether or not > preview features (JEP 12) are enabled. > > Thanks, > > -Joe > From jonathan.gibbons at oracle.com Mon Apr 15 21:22:58 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 15 Apr 2019 14:22:58 -0700 Subject: JDK 13 RFR of JDK-8222378: Provide mechanism to query preview feature status for annotation processors In-Reply-To: References: <26e8c2e4-e11a-9b6e-d315-d0d3e5c78a4f@oracle.com> Message-ID: Looks good to me. -- Jon On 04/15/2019 01:35 PM, Joe Darcy wrote: > PS Updated test to cover the default method in > > ??? http://cr.openjdk.java.net/~darcy/8222378.1 > > -Joe > > On 4/12/2019 1:53 PM, Joe Darcy wrote: >> Hello, >> >> Please review the code changes and CSR to address: >> >> ??? JDK-8222378: Provide mechanism to query preview feature status >> for annotation processors >> ??? webrev: http://cr.openjdk.java.net/~darcy/8222378.0/ >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8222424 >> >> In brief, a isPreviewEnabled predicate default method is added to >> ProcessingEnvironment to allow processors to query whether or not >> preview features (JEP 12) are enabled. >> >> Thanks, >> >> -Joe >> From vicente.romero at oracle.com Mon Apr 15 22:04:40 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 15 Apr 2019 18:04:40 -0400 Subject: RFR 8222289: Overhaul logic for reading/writing constant pool entries In-Reply-To: References: Message-ID: Hi, Very interesting code, kudos for the great job. My main concern was if it was possible to get rid of the queue, but after chatting about this offline I understood the reasons why you added the queue. In short to allow future pool writings to be able to write in any order instead of being forced to do a bottom-up writing. The fact that you have hidden this process in the very internals of PoolWriter makes easier to write new code or fix bugs in this area. Also the queue shouldn't grow too big as, even if an entry have dependencies on other entries they don't tend to be more than 3. Also as you mentioned this code will benefit once we have value types in the future, reducing the cost of boxing constants into a LoadableConstant. There are a few references to Valhalla in the code that, I think, should be removed. Thanks, Vicente On 4/10/19 1:55 PM, Maurizio Cimadamore wrote: > Hi, > this patch significantly rewrites the way in which constant pool > entries are read/written/handled by javac. A good description of the > issues in the current architecture is given in the JBS entry [4]. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8222289/ > > A crucial part of the solution is the new PoolConstant interface. This > is an interface that all javac entities that want to be written onto > the constant pool must adhere to. The interface has methods for > obtaining a pool tag, and, crucially, to obtain a unique key with > which the entity can be stored in the pool data structure, so as to > quickly check for duplicates. > > I've also defined a sub-interface of the PoolConstant interface called > LoadableConstant, which represents the pool constants that can be > loaded with ldc, and stored as static args to bootstrap methods in > indy/condy. > > DynamicMethodSymbol now has been rewritten to express static argument > list using LoadableConstant, rather than Object. > > This patch takes care of most issues in the existing architecture; > most notably, thanks to PoolReader, most of the duplication in > ModuleNameReader can be removed. Also, I've took great care in > removing all eager conversions to pool indices ahead of instruction > writing (which then resulted in back-requests to the pool in order to > fetch the entry at given address from the Code class). To do this, I > tweaked the Code class a bit, so that all methods for emitting opcodes > will now take a pool constant object (which can be null if an > instruction does not refer to the pool). > > Some changes were also necessary in Items, more specifically, in order > to represent the value of an ImmediateItem as a LoadableConstant, > rather than just an Object. > > The PoolWriter/Reader API is mostly straightforward, with a bunch of > putXYZ/getXYZ methods, where XYZ is some Javac entity that needs to be > written/read. Among the things to note, PoolWriter needs some special > logic to handle the case where a pool entry write request is generated > in the middle of another request (a queue has been used to deal with > this). The PoolReader uses the same two-phase index + resolution? > approach used currently by ClassReader (resolving all entries eagerly > is not only a performance nightmare, since not all entries will be > used, but also a source of bugs, since javac is very sensitive to when > entries - esp. those for classes - are turned into real symbols). > > Extensive testing has been carried out. All relevant tests pass on the > new code. In addition to that, I also compared the output of javac > before/after the patch and made sure the results were the same. Since > the output in general is different (the CP indices before/after are > different), I have put together a javap patch [5] which stabilizes the > javap output by normalizing all CP indices. This has proven to be a > very useful tool, and we might pursue that on a followup change. > > Performance testing has also been carried out using our internal tools > - all results seem to indicate that, at worst, the new code is 1.5% > slower than the old one. Given that the new code is significantly more > expressive than the old one, I think the performance difference is > totally acceptable. Furthermore, when value types will be available I > expect a lot of the cost associated with boxing constants (e.g. from > String to LoadableConstant) to fade away. > > > Alternatives considered: > > * Model the constant pool with a proper hierarchy of classes each of > which models a different CP entry. This approach has been tried in > Valhalla (see [1], [2] and [3]), but ultimately it was rejected > because it was not possible to make it perform in a way that was > satisfactory. Also, when reading the pool, fully materializing the > entries (even the unused ones) was prohibitive, and was avoided (even > in the Valhalla branch) in order to have acceptable performances. > > * Use the new ConstantDesc; while this approach has the potential to > get rid of the nasty boxing for primitive constants (thanks to the > fact that e.g. String already implements ConstantDesc), the > ConstantDesc API is not sufficiently expressive for modeling an entire > constant pool. First, not all entries are modeled (e.g. only loadable > constant are, by design); secondly, there's no way to query e.g. the > pool tag given a ConstantDesc. We might revise the implementation > should some of these issues be addressed in future releases. > > Cheers > Maurizio > > > [1] - > http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java > [2] - > http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java > [3] - > http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java > [4] - https://bugs.openjdk.java.net/browse/JDK-8222289 > [5] - http://cr.openjdk.java.net/~mcimadamore/x-javapStableOutput_v3/ > > From forax at univ-mlv.fr Mon Apr 15 22:31:47 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 16 Apr 2019 00:31:47 +0200 (CEST) Subject: RFR 8222289: Overhaul logic for reading/writing constant pool entries In-Reply-To: References: Message-ID: <1643843277.351811.1555367507601.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Vicente Romero" > ?: "compiler-dev" > Envoy?: Mardi 16 Avril 2019 00:04:40 > Objet: Re: RFR 8222289: Overhaul logic for reading/writing constant pool entries > Hi, > > Very interesting code, kudos for the great job. My main concern was if > it was possible to get rid of the queue, but after chatting about this > offline I understood the reasons why you added the queue. In short to > allow future pool writings to be able to write in any order instead of > being forced to do a bottom-up writing. The fact that you have hidden > this process in the very internals of PoolWriter makes easier to write > new code or fix bugs in this area. Also the queue shouldn't grow too big > as, even if an entry have dependencies on other entries they don't tend > to be more than 3. Apart if you have a condy that reference a condy that reference a condy, etc A classfile like this will fail with ASM BTW, because we have chosen to use recursive calls instead of a stack/queue. > Also as you mentioned this code will benefit once we > have value types in the future, reducing the cost of boxing constants > into a LoadableConstant. There are a few references to Valhalla in the > code that, I think, should be removed. > > Thanks, > Vicente regards, R?mi > > On 4/10/19 1:55 PM, Maurizio Cimadamore wrote: >> Hi, >> this patch significantly rewrites the way in which constant pool >> entries are read/written/handled by javac. A good description of the >> issues in the current architecture is given in the JBS entry [4]. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8222289/ >> >> A crucial part of the solution is the new PoolConstant interface. This >> is an interface that all javac entities that want to be written onto >> the constant pool must adhere to. The interface has methods for >> obtaining a pool tag, and, crucially, to obtain a unique key with >> which the entity can be stored in the pool data structure, so as to >> quickly check for duplicates. >> >> I've also defined a sub-interface of the PoolConstant interface called >> LoadableConstant, which represents the pool constants that can be >> loaded with ldc, and stored as static args to bootstrap methods in >> indy/condy. >> >> DynamicMethodSymbol now has been rewritten to express static argument >> list using LoadableConstant, rather than Object. >> >> This patch takes care of most issues in the existing architecture; >> most notably, thanks to PoolReader, most of the duplication in >> ModuleNameReader can be removed. Also, I've took great care in >> removing all eager conversions to pool indices ahead of instruction >> writing (which then resulted in back-requests to the pool in order to >> fetch the entry at given address from the Code class). To do this, I >> tweaked the Code class a bit, so that all methods for emitting opcodes >> will now take a pool constant object (which can be null if an >> instruction does not refer to the pool). >> >> Some changes were also necessary in Items, more specifically, in order >> to represent the value of an ImmediateItem as a LoadableConstant, >> rather than just an Object. >> >> The PoolWriter/Reader API is mostly straightforward, with a bunch of >> putXYZ/getXYZ methods, where XYZ is some Javac entity that needs to be >> written/read. Among the things to note, PoolWriter needs some special >> logic to handle the case where a pool entry write request is generated >> in the middle of another request (a queue has been used to deal with >> this). The PoolReader uses the same two-phase index + resolution >> approach used currently by ClassReader (resolving all entries eagerly >> is not only a performance nightmare, since not all entries will be >> used, but also a source of bugs, since javac is very sensitive to when >> entries - esp. those for classes - are turned into real symbols). >> >> Extensive testing has been carried out. All relevant tests pass on the >> new code. In addition to that, I also compared the output of javac >> before/after the patch and made sure the results were the same. Since >> the output in general is different (the CP indices before/after are >> different), I have put together a javap patch [5] which stabilizes the >> javap output by normalizing all CP indices. This has proven to be a >> very useful tool, and we might pursue that on a followup change. >> >> Performance testing has also been carried out using our internal tools >> - all results seem to indicate that, at worst, the new code is 1.5% >> slower than the old one. Given that the new code is significantly more >> expressive than the old one, I think the performance difference is >> totally acceptable. Furthermore, when value types will be available I >> expect a lot of the cost associated with boxing constants (e.g. from >> String to LoadableConstant) to fade away. >> >> >> Alternatives considered: >> >> * Model the constant pool with a proper hierarchy of classes each of >> which models a different CP entry. This approach has been tried in >> Valhalla (see [1], [2] and [3]), but ultimately it was rejected >> because it was not possible to make it perform in a way that was >> satisfactory. Also, when reading the pool, fully materializing the >> entries (even the unused ones) was prohibitive, and was avoided (even >> in the Valhalla branch) in order to have acceptable performances. >> >> * Use the new ConstantDesc; while this approach has the potential to >> get rid of the nasty boxing for primitive constants (thanks to the >> fact that e.g. String already implements ConstantDesc), the >> ConstantDesc API is not sufficiently expressive for modeling an entire >> constant pool. First, not all entries are modeled (e.g. only loadable >> constant are, by design); secondly, there's no way to query e.g. the >> pool tag given a ConstantDesc. We might revise the implementation >> should some of these issues be addressed in future releases. >> >> Cheers >> Maurizio >> >> >> [1] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java >> [2] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java >> [3] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java >> [4] - https://bugs.openjdk.java.net/browse/JDK-8222289 >> [5] - http://cr.openjdk.java.net/~mcimadamore/x-javapStableOutput_v3/ >> From maurizio.cimadamore at oracle.com Mon Apr 15 22:36:18 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 15 Apr 2019 23:36:18 +0100 Subject: RFR 8222289: Overhaul logic for reading/writing constant pool entries In-Reply-To: References: Message-ID: <62a9eaec-a40f-a516-ccf0-6510de4dd268@oracle.com> On 15/04/2019 23:04, Vicente Romero wrote: > Hi, > > Very interesting code, kudos for the great job. My main concern was if > it was possible to get rid of the queue, but after chatting about this > offline I understood the reasons why you added the queue. In short to > allow future pool writings to be able to write in any order instead of > being forced to do a bottom-up writing. The fact that you have hidden > this process in the very internals of PoolWriter makes easier to write > new code or fix bugs in this area. Also the queue shouldn't grow too > big as, even if an entry have dependencies on other entries they don't > tend to be more than 3. Also as you mentioned this code will benefit > once we have value types in the future, reducing the cost of boxing > constants into a LoadableConstant. There are a few references to > Valhalla in the code that, I think, should be removed. Thanks - with the respect to queue I tried 3 approaches: 1) bottom up writing - works, but the PoolWriter::write method has to be very careful at doing things in the right order; right now the entries are trivial, but when Valhalla will kick in in full, we might start generating more complex entries, such as those for parameterized types, which might require visitors or other 'complex' means to write them; in such cases, I believe it's best if the writer doesn't have to worry about the order in which things are written, and just trusts the right thing to happen 2) I then experimented with a version of the code that, instead of using a queue, used some convoluted logic to update the current entry index, so that we could start writing a new entry right in the middle of writing another entry (effectively moving the bytecode cursor back and forth). While this had no queue, there was no evident performance gain, and, at the same time, the code was harder to follow, which led me to the current approach. I too am alergic to ordering and queues when I see them, but here I think it's matter of compromises. I'll take a look at the Valhalla reference - it is very possible that some of them survived in the transplant :-) Maurizio > > Thanks, > Vicente > > On 4/10/19 1:55 PM, Maurizio Cimadamore wrote: >> Hi, >> this patch significantly rewrites the way in which constant pool >> entries are read/written/handled by javac. A good description of the >> issues in the current architecture is given in the JBS entry [4]. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8222289/ >> >> A crucial part of the solution is the new PoolConstant interface. >> This is an interface that all javac entities that want to be written >> onto the constant pool must adhere to. The interface has methods for >> obtaining a pool tag, and, crucially, to obtain a unique key with >> which the entity can be stored in the pool data structure, so as to >> quickly check for duplicates. >> >> I've also defined a sub-interface of the PoolConstant interface >> called LoadableConstant, which represents the pool constants that can >> be loaded with ldc, and stored as static args to bootstrap methods in >> indy/condy. >> >> DynamicMethodSymbol now has been rewritten to express static argument >> list using LoadableConstant, rather than Object. >> >> This patch takes care of most issues in the existing architecture; >> most notably, thanks to PoolReader, most of the duplication in >> ModuleNameReader can be removed. Also, I've took great care in >> removing all eager conversions to pool indices ahead of instruction >> writing (which then resulted in back-requests to the pool in order to >> fetch the entry at given address from the Code class). To do this, I >> tweaked the Code class a bit, so that all methods for emitting >> opcodes will now take a pool constant object (which can be null if an >> instruction does not refer to the pool). >> >> Some changes were also necessary in Items, more specifically, in >> order to represent the value of an ImmediateItem as a >> LoadableConstant, rather than just an Object. >> >> The PoolWriter/Reader API is mostly straightforward, with a bunch of >> putXYZ/getXYZ methods, where XYZ is some Javac entity that needs to >> be written/read. Among the things to note, PoolWriter needs some >> special logic to handle the case where a pool entry write request is >> generated in the middle of another request (a queue has been used to >> deal with this). The PoolReader uses the same two-phase index + >> resolution? approach used currently by ClassReader (resolving all >> entries eagerly is not only a performance nightmare, since not all >> entries will be used, but also a source of bugs, since javac is very >> sensitive to when entries - esp. those for classes - are turned into >> real symbols). >> >> Extensive testing has been carried out. All relevant tests pass on >> the new code. In addition to that, I also compared the output of >> javac before/after the patch and made sure the results were the same. >> Since the output in general is different (the CP indices before/after >> are different), I have put together a javap patch [5] which >> stabilizes the javap output by normalizing all CP indices. This has >> proven to be a very useful tool, and we might pursue that on a >> followup change. >> >> Performance testing has also been carried out using our internal >> tools - all results seem to indicate that, at worst, the new code is >> 1.5% slower than the old one. Given that the new code is >> significantly more expressive than the old one, I think the >> performance difference is totally acceptable. Furthermore, when value >> types will be available I expect a lot of the cost associated with >> boxing constants (e.g. from String to LoadableConstant) to fade away. >> >> >> Alternatives considered: >> >> * Model the constant pool with a proper hierarchy of classes each of >> which models a different CP entry. This approach has been tried in >> Valhalla (see [1], [2] and [3]), but ultimately it was rejected >> because it was not possible to make it perform in a way that was >> satisfactory. Also, when reading the pool, fully materializing the >> entries (even the unused ones) was prohibitive, and was avoided (even >> in the Valhalla branch) in order to have acceptable performances. >> >> * Use the new ConstantDesc; while this approach has the potential to >> get rid of the nasty boxing for primitive constants (thanks to the >> fact that e.g. String already implements ConstantDesc), the >> ConstantDesc API is not sufficiently expressive for modeling an >> entire constant pool. First, not all entries are modeled (e.g. only >> loadable constant are, by design); secondly, there's no way to query >> e.g. the pool tag given a ConstantDesc. We might revise the >> implementation should some of these issues be addressed in future >> releases. >> >> Cheers >> Maurizio >> >> >> [1] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java >> [2] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java >> [3] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java >> [4] - https://bugs.openjdk.java.net/browse/JDK-8222289 >> [5] - http://cr.openjdk.java.net/~mcimadamore/x-javapStableOutput_v3/ >> >> > From jonathan.gibbons at oracle.com Mon Apr 15 22:41:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 15 Apr 2019 15:41:31 -0700 Subject: JDK 13 RFR of JDK-8222430: Add tests for ElementKind predicates In-Reply-To: References: Message-ID: <8ac5746c-3a54-ac58-16ac-7a901c434924@oracle.com> +1 -- Jon On 04/12/2019 02:35 PM, Joe Darcy wrote: > Hello, > > Ahead of some amber work, please review the addition of a test for the > ElementKind primitives: > > ??? JDK-8222430: Add tests for ElementKind predicates > ??? http://cr.openjdk.java.net/~darcy/8222430.0/ > > New test sans standard license below. > > Thanks, > > -Joe > > // license omitted here for brevity > > /* > ?* @test > ?* @bug 8222430 > ?* @summary Test various predicates of ElementKind. > ?*/ > > import java.util.Set; > import java.util.function.Predicate; > import javax.lang.model.element.ElementKind; > > /** > ?* Test the isClass, isField, and isInterface predicates of ElementKind. > ?*/ > public class TestElementKindPredicates { > ??? public static void main(String... args) { > ??????? Set ALL_KINDS = Set.of(ElementKind.values()); > > ??????? // isClass: Returns true if this is a kind of class: either > CLASS or ENUM. > ??????? test(ALL_KINDS, > ???????????? (ElementKind k) -> Set.of(ElementKind.CLASS, > ElementKind.ENUM).contains(k), > ???????????? (ElementKind k) -> k.isClass(), "isClass"); > > ??????? // isField: Returns true if this is a kind of field: either > FIELD or ENUM_CONSTANT. > ??????? test(ALL_KINDS, > ???????????? (ElementKind k) -> Set.of(ElementKind.FIELD, > ElementKind.ENUM_CONSTANT).contains(k), > ???????????? (ElementKind k) -> k.isField(), "isField"); > > ??????? // isInterface: Returns true if this is a kind of interface: > either INTERFACE or ANNOTATION_TYPE. > ??????? test(ALL_KINDS, > ???????????? (ElementKind k) -> Set.of(ElementKind.INTERFACE, > ElementKind.ANNOTATION_TYPE).contains(k), > ???????????? (ElementKind k) -> k.isInterface(), "isInterface"); > ??? } > > ??? private static void test(Set kinds, > ???????????????????????????? Predicate expectedPred, > ???????????????????????????? Predicate actualPred, > ???????????????????????????? String errorMessage) { > ??????? for(ElementKind kind : kinds) { > ??????????? boolean expected = expectedPred.test(kind); > ??????????? boolean actual = actualPred.test(kind); > > ??????????? if (expected != actual) { > ??????????????? throw new RuntimeException("Error testing > ElementKind." + errorMessage + "(" +? kind + > ?????????????????????????????????????????? "):\texpected " + expected > + "\tgot " + actual); > ??????????? } > ??????? } > ??? } > } > From jan.lahoda at oracle.com Tue Apr 16 07:47:19 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 16 Apr 2019 09:47:19 +0200 Subject: JDK 13 RFR of JDK-8222378: Provide mechanism to query preview feature status for annotation processors In-Reply-To: References: <26e8c2e4-e11a-9b6e-d315-d0d3e5c78a4f@oracle.com> Message-ID: Looks OK to me. Jan On 15. 04. 19 22:35, Joe Darcy wrote: > PS Updated test to cover the default method in > > ??? http://cr.openjdk.java.net/~darcy/8222378.1 > > -Joe > > On 4/12/2019 1:53 PM, Joe Darcy wrote: >> Hello, >> >> Please review the code changes and CSR to address: >> >> ??? JDK-8222378: Provide mechanism to query preview feature status for >> annotation processors >> ??? webrev: http://cr.openjdk.java.net/~darcy/8222378.0/ >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8222424 >> >> In brief, a isPreviewEnabled predicate default method is added to >> ProcessingEnvironment to allow processors to query whether or not >> preview features (JEP 12) are enabled. >> >> Thanks, >> >> -Joe >> From maurizio.cimadamore at oracle.com Tue Apr 16 09:56:54 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 16 Apr 2019 10:56:54 +0100 Subject: JDK 13 RFR of JDK-8222378: Provide mechanism to query preview feature status for annotation processors In-Reply-To: <26e8c2e4-e11a-9b6e-d315-d0d3e5c78a4f@oracle.com> References: <26e8c2e4-e11a-9b6e-d315-d0d3e5c78a4f@oracle.com> Message-ID: <2a0c18ce-8302-8662-6644-a398317de378@oracle.com> Looks good! Maurizio On 12/04/2019 21:53, Joe Darcy wrote: > Hello, > > Please review the code changes and CSR to address: > > ??? JDK-8222378: Provide mechanism to query preview feature status for > annotation processors > ??? webrev: http://cr.openjdk.java.net/~darcy/8222378.0/ > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8222424 > > In brief, a isPreviewEnabled predicate default method is added to > ProcessingEnvironment to allow processors to query whether or not > preview features (JEP 12) are enabled. > > Thanks, > > -Joe > From maurizio.cimadamore at oracle.com Wed Apr 17 09:57:07 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 17 Apr 2019 10:57:07 +0100 Subject: RFR 8222289: Overhaul logic for reading/writing constant pool entries In-Reply-To: References: Message-ID: This is? a new revision: http://cr.openjdk.java.net/~mcimadamore/8222289_v2/webrev/ I had to merge against some changes in the same area. Rerun tests, all clean. I also removed the references to Valhalla. Maurizio On 15/04/2019 23:04, Vicente Romero wrote: > Hi, > > Very interesting code, kudos for the great job. My main concern was if > it was possible to get rid of the queue, but after chatting about this > offline I understood the reasons why you added the queue. In short to > allow future pool writings to be able to write in any order instead of > being forced to do a bottom-up writing. The fact that you have hidden > this process in the very internals of PoolWriter makes easier to write > new code or fix bugs in this area. Also the queue shouldn't grow too > big as, even if an entry have dependencies on other entries they don't > tend to be more than 3. Also as you mentioned this code will benefit > once we have value types in the future, reducing the cost of boxing > constants into a LoadableConstant. There are a few references to > Valhalla in the code that, I think, should be removed. > > Thanks, > Vicente > > On 4/10/19 1:55 PM, Maurizio Cimadamore wrote: >> Hi, >> this patch significantly rewrites the way in which constant pool >> entries are read/written/handled by javac. A good description of the >> issues in the current architecture is given in the JBS entry [4]. >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8222289/ >> >> A crucial part of the solution is the new PoolConstant interface. >> This is an interface that all javac entities that want to be written >> onto the constant pool must adhere to. The interface has methods for >> obtaining a pool tag, and, crucially, to obtain a unique key with >> which the entity can be stored in the pool data structure, so as to >> quickly check for duplicates. >> >> I've also defined a sub-interface of the PoolConstant interface >> called LoadableConstant, which represents the pool constants that can >> be loaded with ldc, and stored as static args to bootstrap methods in >> indy/condy. >> >> DynamicMethodSymbol now has been rewritten to express static argument >> list using LoadableConstant, rather than Object. >> >> This patch takes care of most issues in the existing architecture; >> most notably, thanks to PoolReader, most of the duplication in >> ModuleNameReader can be removed. Also, I've took great care in >> removing all eager conversions to pool indices ahead of instruction >> writing (which then resulted in back-requests to the pool in order to >> fetch the entry at given address from the Code class). To do this, I >> tweaked the Code class a bit, so that all methods for emitting >> opcodes will now take a pool constant object (which can be null if an >> instruction does not refer to the pool). >> >> Some changes were also necessary in Items, more specifically, in >> order to represent the value of an ImmediateItem as a >> LoadableConstant, rather than just an Object. >> >> The PoolWriter/Reader API is mostly straightforward, with a bunch of >> putXYZ/getXYZ methods, where XYZ is some Javac entity that needs to >> be written/read. Among the things to note, PoolWriter needs some >> special logic to handle the case where a pool entry write request is >> generated in the middle of another request (a queue has been used to >> deal with this). The PoolReader uses the same two-phase index + >> resolution? approach used currently by ClassReader (resolving all >> entries eagerly is not only a performance nightmare, since not all >> entries will be used, but also a source of bugs, since javac is very >> sensitive to when entries - esp. those for classes - are turned into >> real symbols). >> >> Extensive testing has been carried out. All relevant tests pass on >> the new code. In addition to that, I also compared the output of >> javac before/after the patch and made sure the results were the same. >> Since the output in general is different (the CP indices before/after >> are different), I have put together a javap patch [5] which >> stabilizes the javap output by normalizing all CP indices. This has >> proven to be a very useful tool, and we might pursue that on a >> followup change. >> >> Performance testing has also been carried out using our internal >> tools - all results seem to indicate that, at worst, the new code is >> 1.5% slower than the old one. Given that the new code is >> significantly more expressive than the old one, I think the >> performance difference is totally acceptable. Furthermore, when value >> types will be available I expect a lot of the cost associated with >> boxing constants (e.g. from String to LoadableConstant) to fade away. >> >> >> Alternatives considered: >> >> * Model the constant pool with a proper hierarchy of classes each of >> which models a different CP entry. This approach has been tried in >> Valhalla (see [1], [2] and [3]), but ultimately it was rejected >> because it was not possible to make it perform in a way that was >> satisfactory. Also, when reading the pool, fully materializing the >> entries (even the unused ones) was prohibitive, and was avoided (even >> in the Valhalla branch) in order to have acceptable performances. >> >> * Use the new ConstantDesc; while this approach has the potential to >> get rid of the nasty boxing for primitive constants (thanks to the >> fact that e.g. String already implements ConstantDesc), the >> ConstantDesc API is not sufficiently expressive for modeling an >> entire constant pool. First, not all entries are modeled (e.g. only >> loadable constant are, by design); secondly, there's no way to query >> e.g. the pool tag given a ConstantDesc. We might revise the >> implementation should some of these issues be addressed in future >> releases. >> >> Cheers >> Maurizio >> >> >> [1] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java >> [2] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java >> [3] - >> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java >> [4] - https://bugs.openjdk.java.net/browse/JDK-8222289 >> [5] - http://cr.openjdk.java.net/~mcimadamore/x-javapStableOutput_v3/ >> >> > From vicente.romero at oracle.com Wed Apr 17 12:57:49 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 17 Apr 2019 08:57:49 -0400 Subject: RFR 8222289: Overhaul logic for reading/writing constant pool entries In-Reply-To: References: Message-ID: <65265966-09a0-b992-99be-48e6d58c2dff@oracle.com> looks good, Vicente On 4/17/19 5:57 AM, Maurizio Cimadamore wrote: > This is? a new revision: > > http://cr.openjdk.java.net/~mcimadamore/8222289_v2/webrev/ > > I had to merge against some changes in the same area. Rerun tests, all > clean. > > I also removed the references to Valhalla. > > Maurizio > > On 15/04/2019 23:04, Vicente Romero wrote: >> Hi, >> >> Very interesting code, kudos for the great job. My main concern was >> if it was possible to get rid of the queue, but after chatting about >> this offline I understood the reasons why you added the queue. In >> short to allow future pool writings to be able to write in any order >> instead of being forced to do a bottom-up writing. The fact that you >> have hidden this process in the very internals of PoolWriter makes >> easier to write new code or fix bugs in this area. Also the queue >> shouldn't grow too big as, even if an entry have dependencies on >> other entries they don't tend to be more than 3. Also as you >> mentioned this code will benefit once we have value types in the >> future, reducing the cost of boxing constants into a >> LoadableConstant. There are a few references to Valhalla in the code >> that, I think, should be removed. >> >> Thanks, >> Vicente >> >> On 4/10/19 1:55 PM, Maurizio Cimadamore wrote: >>> Hi, >>> this patch significantly rewrites the way in which constant pool >>> entries are read/written/handled by javac. A good description of the >>> issues in the current architecture is given in the JBS entry [4]. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8222289/ >>> >>> A crucial part of the solution is the new PoolConstant interface. >>> This is an interface that all javac entities that want to be written >>> onto the constant pool must adhere to. The interface has methods for >>> obtaining a pool tag, and, crucially, to obtain a unique key with >>> which the entity can be stored in the pool data structure, so as to >>> quickly check for duplicates. >>> >>> I've also defined a sub-interface of the PoolConstant interface >>> called LoadableConstant, which represents the pool constants that >>> can be loaded with ldc, and stored as static args to bootstrap >>> methods in indy/condy. >>> >>> DynamicMethodSymbol now has been rewritten to express static >>> argument list using LoadableConstant, rather than Object. >>> >>> This patch takes care of most issues in the existing architecture; >>> most notably, thanks to PoolReader, most of the duplication in >>> ModuleNameReader can be removed. Also, I've took great care in >>> removing all eager conversions to pool indices ahead of instruction >>> writing (which then resulted in back-requests to the pool in order >>> to fetch the entry at given address from the Code class). To do >>> this, I tweaked the Code class a bit, so that all methods for >>> emitting opcodes will now take a pool constant object (which can be >>> null if an instruction does not refer to the pool). >>> >>> Some changes were also necessary in Items, more specifically, in >>> order to represent the value of an ImmediateItem as a >>> LoadableConstant, rather than just an Object. >>> >>> The PoolWriter/Reader API is mostly straightforward, with a bunch of >>> putXYZ/getXYZ methods, where XYZ is some Javac entity that needs to >>> be written/read. Among the things to note, PoolWriter needs some >>> special logic to handle the case where a pool entry write request is >>> generated in the middle of another request (a queue has been used to >>> deal with this). The PoolReader uses the same two-phase index + >>> resolution approach used currently by ClassReader (resolving all >>> entries eagerly is not only a performance nightmare, since not all >>> entries will be used, but also a source of bugs, since javac is very >>> sensitive to when entries - esp. those for classes - are turned into >>> real symbols). >>> >>> Extensive testing has been carried out. All relevant tests pass on >>> the new code. In addition to that, I also compared the output of >>> javac before/after the patch and made sure the results were the >>> same. Since the output in general is different (the CP indices >>> before/after are different), I have put together a javap patch [5] >>> which stabilizes the javap output by normalizing all CP indices. >>> This has proven to be a very useful tool, and we might pursue that >>> on a followup change. >>> >>> Performance testing has also been carried out using our internal >>> tools - all results seem to indicate that, at worst, the new code is >>> 1.5% slower than the old one. Given that the new code is >>> significantly more expressive than the old one, I think the >>> performance difference is totally acceptable. Furthermore, when >>> value types will be available I expect a lot of the cost associated >>> with boxing constants (e.g. from String to LoadableConstant) to fade >>> away. >>> >>> >>> Alternatives considered: >>> >>> * Model the constant pool with a proper hierarchy of classes each of >>> which models a different CP entry. This approach has been tried in >>> Valhalla (see [1], [2] and [3]), but ultimately it was rejected >>> because it was not possible to make it perform in a way that was >>> satisfactory. Also, when reading the pool, fully materializing the >>> entries (even the unused ones) was prohibitive, and was avoided >>> (even in the Valhalla branch) in order to have acceptable performances. >>> >>> * Use the new ConstantDesc; while this approach has the potential to >>> get rid of the nasty boxing for primitive constants (thanks to the >>> fact that e.g. String already implements ConstantDesc), the >>> ConstantDesc API is not sufficiently expressive for modeling an >>> entire constant pool. First, not all entries are modeled (e.g. only >>> loadable constant are, by design); secondly, there's no way to query >>> e.g. the pool tag given a ConstantDesc. We might revise the >>> implementation should some of these issues be addressed in future >>> releases. >>> >>> Cheers >>> Maurizio >>> >>> >>> [1] - >>> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java >>> [2] - >>> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java >>> [3] - >>> http://hg.openjdk.java.net/valhalla/valhalla9/langtools/file/85cc92a65da8/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java >>> [4] - https://bugs.openjdk.java.net/browse/JDK-8222289 >>> [5] - http://cr.openjdk.java.net/~mcimadamore/x-javapStableOutput_v3/ >>> >>> >> From joe.darcy at oracle.com Wed Apr 17 23:54:59 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 17 Apr 2019 16:54:59 -0700 Subject: FYI, discussion of javax.lang.model support for records and sealed types on amber-dev Message-ID: <6ed4ec5c-c3ef-6ea2-f062-0a68899c19dc@oracle.com> Hello, FYI, if you are interested in the possible evolution of javax.lang.model, there is? thread on amber-dev on what support for records and sealed types might look like: https://mail.openjdk.java.net/pipermail/amber-dev/2019-April/004322.html Cheers, -Joe From GROEGES at uk.ibm.com Thu Apr 18 08:59:13 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 18 Apr 2019 09:59:13 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: <1cfdeabf-23f7-1a51-deac-b5566e60a9c7@oracle.com> References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> <55bd5ddb-4d85-1a36-f067-a33fcc0c14b6@oracle.com> <1cfdeabf-23f7-1a51-deac-b5566e60a9c7@oracle.com> Message-ID: Hi Jan & Jonathan, Thanks for saying the change now looks good. Any update on getting this sponsored and then merged? Once it is in the jdk repo I would like to go through the process of getting this into jdk8u. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Jan Lahoda To: Steve Groeger , Jonathan Gibbons Cc: compiler-dev at openjdk.java.net Date: 12/04/2019 14:31 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath On 12. 04. 19 12:37, Steve Groeger wrote: > Hi Jan, > > I didn't know that the > /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java > test is effected by updates to the diagnostic messages. So thatnks for > letting me know. I ran this test and it did fail as you expected. Have > added the message to the > test/langtools/tools/javac/diags/examples.not-yet.txt files, as that was > where the others were. > > I can't run the tests via: > _ https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openjdk.java.net_display_Build_Submit-2BRepo-5Fas&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=fhPfaU31pXu1gXSIuCZQppb-686FSpMqSlBs5739G8k&e= I dont have > authority (i'm not a committer) > I have run the test/langtools tests with and without my chnages and the > test results are the same, so I can assume that my changes havent broken > anything. > > I made the similar changes on jdk8u to the examples.not-yet.txt file but > the CheckExamples.java fails anyway, even without my changes, but making > that chnage give it one less error. > > I have updated the webrevs for jdk [1] and for jdk8u [2] > > Will follow the jdk8u update process that you mentioned to get those > changes updated, but anything you can do for jdk would be great. Thanks > > [1] _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.04_-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=C8dsuDx_-vYT40IsstVo8fEDhNgc7XhqCrd1Ph2DWKg&e= I think this looks fine, thanks. Jon, do you want to take a look and/or sponsor the change, or should I? Thanks, Jan > [2] _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.04_-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=5gLtglgdkMNV7RUYpNZsu7DFgSi1wrawYrGcrySoPpg&e= > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Jan Lahoda > To: Steve Groeger > Cc: compiler-dev at openjdk.java.net > Date: 10/04/2019 16:13 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > ------------------------------------------------------------------------ > > > > Hi Steve, > > One more question - do tests pass with this patch, at least the > test/langtools tests, or jdk/submit? > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openjdk.java.net_display_Build_Submit-2BRepo&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=8OHNHgXvlp5sudsIHYKxmlmSLSKBSramyZ0OzrmZYsg&e= > > (adding new diagnostic messages often need adjustments to > /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java > ) > > Regarding JDK 8 updates, please note there's a separate for that: > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openjdk.java.net_display_jdk8u_Main&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=W486tZCcKDhNWGVf3z0hEF23ZoEw-wiQ07FjcAScvUc&e= > > Jan > > On 10. 04. 19 14:43, Steve Groeger wrote: >> Hi Jan, >> >> I have made the change to throw the same error as when we get the >> ServiceConfigurationError and removed the call the FatalError. >> I have created 2 new webrevs for jdk [1] and for jdk8u [2]. >> Hopefully these are now OK and in a suitable state to be able to be >> re-reviewed and then merged. >> If there is anything else that is needed please do not hesitate to >> contact me. >> >> [1] _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.03_-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=b1TFP3CFnRjtk-Bh-jTUxGIMM5ud4OSZrtNiakn3gzA&e= >> [2] _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.03_-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=j_-UMQAbLd9UZUW2ibM6i7m0jUAOyHkWTM5gjl9iau8&e= >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Steve Groeger >> To: Jan Lahoda >> Cc: compiler-dev at openjdk.java.net >> Date: 10/04/2019 10:59 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> Sent by: "compiler-dev" >> ------------------------------------------------------------------------ >> >> >> >> Hi Jan, >> >> Thanks for responding. >> >> I don't think you are missing anything with regards to the use of this: >>> public FatalError(JCDiagnostic d, Throwable t) {} >> >> I think that was me missing the fact this would cause NPE and mask the >> actual issue. >> >> I will probably go with your original suggestion: >>> Would there be an issue with simply changing the "catch >>> (Throwable)" to also report the same error as >>> "catch (ServiceConfigurationError)"? >> >> Will make these changes and generate some new webrevs for this and post >> again when they are available. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Jan Lahoda >> To: Steve Groeger >> Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons >> >> Date: 10/04/2019 09:51 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> ------------------------------------------------------------------------ >> >> >> >> Hi Steve, >> >> I apologize for a late reply. For the FatalError, seems that this >> constructor is being called there: >> public FatalError(JCDiagnostic d, Throwable t) { >> super(d.toString(), t); >> } >> >> with "d == null". That, I think, will lead to an immediate NPE, which I >> don't think is desirable, as it will hide the actual exception that was >> thrown. Or do I miss something? >> >> Thanks, >> Jan >> >> On 09. 04. 19 11:02, Steve Groeger wrote: >>> Hi Jan, >>> >>> I sent the post below about a month ago but didn't get a response from >>> you as to the review of the new webrevs. >>> Not sure whether you got it or not but I would be grateful if you could >>> take a look at these webrevs and let me know whether they are OK now. >>> If they are OK, please let me know the next steps needed to get these >>> merged into the code base. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >>> >>> >>> From: Steve Groeger >>> To: Jan Lahoda >>> Cc: compiler-dev at openjdk.java.net >>> Date: 07/03/2019 09:57 >>> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >>> annotation processor is on the classpath >>> Sent by: "compiler-dev" >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Hi Jan, >>> >>> Thanks for providing a possible test for the malformed Annotation Processor. >>> I have taken the code you provided and tweaked it a bit (for jdk) and >>> had to >>> write a similar thing for jdk8u as some of the functionality in the test >>> is not >>> available in the same form in jdk8u (well, not that I could find!!!) >>> >>> I would be grateful if you could review to code in the new webrevs. >>> _ >>> ___ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.02_-5F-5F-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=P1ZJ6AFoKS3wpDfFUaOnhrwEO81pY558lP6BG6JvLJk&e= >>> ___ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.02_-5F-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=_1As93_NCxiKrHg8BQSZryFE7Fs__pXh8nzlt4OHIwc&s=D7Y6ut09krZEOqsHKqRP9i8NDX1NgOqnQwmlm8dqkWA&e= >>> >>> Any issues please let me know. >>> >>> PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we >>> wanted Jon to comment on whether this is what is required or whether >>> we go with your previous suggestion. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon Apr 22 15:51:26 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 22 Apr 2019 11:51:26 -0400 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName Message-ID: Hi, Please review this small change to improve the performance of PathFileObject.toBinaryName: webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8222806 Thanks! Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Apr 22 17:51:16 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 22 Apr 2019 10:51:16 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: That seems like micro-optimization.? Do you have numbers to back it up? Should this sort of optimization be done in String.replace? -- Jon On 4/22/19 8:51 AM, Ron Shapiro wrote: > Hi, > > Please review this small change to improve the performance of > PathFileObject.toBinaryName: > > webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8222806 > > Thanks! > Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon Apr 22 18:02:25 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 22 Apr 2019 14:02:25 -0400 Subject: Understanding Name and Name.Table In-Reply-To: <2b1449aa-0681-084e-72f9-545d8c14332e@oracle.com> References: <2b1449aa-0681-084e-72f9-545d8c14332e@oracle.com> Message-ID: > > I have a prototype of a Name.Table implementation that stores Names as > Strings instead of their UTF-8 byte[]. This seems to address the > performance concerns from my previous thread (it saves 1.2s/build on some > of our larger annotation processing builds at Google) without affecting the > performance of internal javac (i.e. non-annotation processing). There > should be no less overhead than the current Name implementations as it only > needs to store a single field for the String, besides for the UTF-8/UTF-16 > distinction. > > What are the space comparisons? It is certainly the case that Strings are > managed more efficiently in the JVM these days, and interned strings are > handled better as well. Your number of 1.2s doesn't mean much without more > context that "our larger annotation processing builds." What percent is > that of the overall build time, and/or total time in Name/Name.Table. > The Name.Table implementation is now one HashMap instead of one array of bytes. Each Name implementation has an String field, an int for the index in the table, and a lazily evaluated byte-array for the modified UTF-8 bytes. I could see if removing that would be beneficial or not. SharedNameTable.Name has a pointer to the next name, the int index, and another int for the length. UnsahredNameTable has the same byte array and index as my prototype, but no String, and the table has it's own hash table. An alternative that I raised previously is to keep the (Un)SharedNameTable structure, but to add a lazily-evaluated String to each Name implementation. Do you have a good tool to measure actual memory increases for runs of the compiler? I'm coming from the perspective that as long as memory growth is ~linear and not huge, it's always worthwhile for a boost in time. As for timings, I re-ran things and I'm seeing a 1.5s improvement for a 65.4s compilation. Maurizio - I think there was probably a misunderstanding - I'm not doing anything related to String.intern(). Agreed about HashMap > String.intern at least in this case -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Mon Apr 22 18:07:34 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Mon, 22 Apr 2019 14:07:34 -0400 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: I mentioned in the bug that it had a 300ms improvement for a 30s build. I think it would be reasonable in String.replace() if it was common enough to be worth checking the lengths. I don't know what the benchmarking considerations are there. On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > That seems like micro-optimization. Do you have numbers to back it up? > > Should this sort of optimization be done in String.replace? > > -- Jon > On 4/22/19 8:51 AM, Ron Shapiro wrote: > > Hi, > > Please review this small change to improve the performance of > PathFileObject.toBinaryName: > > webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8222806 > > Thanks! > Ron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Mon Apr 22 18:30:24 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 22 Apr 2019 11:30:24 -0700 Subject: Understanding Name and Name.Table In-Reply-To: References: <2b1449aa-0681-084e-72f9-545d8c14332e@oracle.com> Message-ID: On 04/22/2019 11:02 AM, Ron Shapiro wrote: > > I'm coming from the perspective that as long as memory growth is > ~linear and not huge, it's always worthwhile for a boost in time. A significant use case is for "javac as a component", more than just "javac for a one-shot compilation". That's the reason we changed from a single class to an interface with different implementation characteristics. I would not want to lose that aspect .... but it is reasonable to explore alternative implementations for different use cases. -- Jon From joe.darcy at oracle.com Mon Apr 22 20:49:58 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 22 Apr 2019 13:49:58 -0700 Subject: JDK 13 RFR of JDK-8222817 : Refactor printing processor to use streams Message-ID: <3ec50545-ea2c-57bb-7ba2-4a6ba5a7976f@oracle.com> Hello, Please review the changes to implement: ??? JDK-8222817 : Refactor printing processor to use streams ??? http://cr.openjdk.java.net/~darcy/8222817.0/ The intention is that the string output should be unchanged. Thanks, -Joe From jonathan.gibbons at oracle.com Mon Apr 22 20:58:31 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 22 Apr 2019 13:58:31 -0700 Subject: JDK 13 RFR of JDK-8222817 : Refactor printing processor to use streams In-Reply-To: <3ec50545-ea2c-57bb-7ba2-4a6ba5a7976f@oracle.com> References: <3ec50545-ea2c-57bb-7ba2-4a6ba5a7976f@oracle.com> Message-ID: If you're going all-in modernizing the code, you can use method references for ::toString in a couple of place. -- Jon On 4/22/19 1:49 PM, Joe Darcy wrote: > Hello, > > Please review the changes to implement: > > ??? JDK-8222817 : Refactor printing processor to use streams > ??? http://cr.openjdk.java.net/~darcy/8222817.0/ > > The intention is that the string output should be unchanged. > > Thanks, > > -Joe > From vicente.romero at oracle.com Mon Apr 22 21:16:13 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 22 Apr 2019 17:16:13 -0400 Subject: RFR: JDK-8222744: add support for generating method handles from a variable symbol Message-ID: Please review the fix for [1] at [2]. This is a small follow up after [3] which introduced a new internal constant pool API in javac. We realized that it was not possible to generate with the new API method handles with reference kinds: ?* REF_getField ?* REF_putField ?* REF_getStatic ?* REF_putStatic This patch adds that feature, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8222744 [2] http://cr.openjdk.java.net/~vromero/8222744/ [3] https://bugs.openjdk.java.net/browse/JDK-8222289 From joe.darcy at oracle.com Mon Apr 22 21:57:36 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 22 Apr 2019 14:57:36 -0700 Subject: JDK 13 RFR of JDK-8222817 : Refactor printing processor to use streams In-Reply-To: References: <3ec50545-ea2c-57bb-7ba2-4a6ba5a7976f@oracle.com> Message-ID: <185b9c6e-b1bd-4204-8a3d-4ae2501e8416@oracle.com> On 4/22/2019 1:58 PM, Jonathan Gibbons wrote: > If you're going all-in modernizing the code, you can use method > references for ::toString in a couple of place. > > -- Jon Update as suggested: ??? http://cr.openjdk.java.net/~darcy/8222817.1/ Diff of patches: 22c22 < +???????????????????????????? .map(m -> m.toString()) --- > +???????????????????????????? .map(Modifier::toString) 63c63 < +??????????????? .map(annotationMirror -> annotationMirror.toString()) --- > +??????????????? .map(AnnotationMirror::toString) 86c86 < +???????????????????????????????? .map(interf -> interf.toString()) --- > +???????????????????????????????? .map(TypeMirror::toString) Thanks, -Joe From jonathan.gibbons at oracle.com Mon Apr 22 22:22:05 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 22 Apr 2019 15:22:05 -0700 Subject: JDK 13 RFR of JDK-8222817 : Refactor printing processor to use streams In-Reply-To: <185b9c6e-b1bd-4204-8a3d-4ae2501e8416@oracle.com> References: <3ec50545-ea2c-57bb-7ba2-4a6ba5a7976f@oracle.com> <185b9c6e-b1bd-4204-8a3d-4ae2501e8416@oracle.com> Message-ID: <16b56b06-ac15-4f2f-eec2-898a84e13bda@oracle.com> Looks good to me. -- Jon On 04/22/2019 02:57 PM, Joe Darcy wrote: > On 4/22/2019 1:58 PM, Jonathan Gibbons wrote: >> If you're going all-in modernizing the code, you can use method >> references for ::toString in a couple of place. >> >> -- Jon > > Update as suggested: > > ??? http://cr.openjdk.java.net/~darcy/8222817.1/ > > Diff of patches: > > 22c22 > < +???????????????????????????? .map(m -> m.toString()) > --- > > +???????????????????????????? .map(Modifier::toString) > 63c63 > < +??????????????? .map(annotationMirror -> annotationMirror.toString()) > --- > > +??????????????? .map(AnnotationMirror::toString) > 86c86 > < +???????????????????????????????? .map(interf -> interf.toString()) > --- > > +???????????????????????????????? .map(TypeMirror::toString) > > Thanks, > > -Joe > From cushon at google.com Tue Apr 23 16:14:06 2019 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 23 Apr 2019 09:14:06 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: This does seem like a small trade-off between readability/conciseness/maintainability and performance. Jon, do you have suggestions for how to evaluate that trade-off? re: doing this in String.replace, I suspect that the usage in PathFileObject is unusually biased towards single-character arguments, since we'd only see longer arguments with a non-default filesystem with an unusual path separator. In the general case, String.replace is probably more likely to see longer arguments, and adding the additional logic and branches there may be less of a slam-dunk. On Mon, Apr 22, 2019 at 11:08 AM Ron Shapiro wrote: > I mentioned in the bug that it had a 300ms improvement for a 30s build. > > I think it would be reasonable in String.replace() if it was common enough > to be worth checking the lengths. I don't know what the benchmarking > considerations are there. > > On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> That seems like micro-optimization. Do you have numbers to back it up? >> >> Should this sort of optimization be done in String.replace? >> >> -- Jon >> On 4/22/19 8:51 AM, Ron Shapiro wrote: >> >> Hi, >> >> Please review this small change to improve the performance of >> PathFileObject.toBinaryName: >> >> webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8222806 >> >> Thanks! >> Ron >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Apr 23 16:45:47 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Apr 2019 09:45:47 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: I think we should follow up with folk who understand performance trade-offs. Looking at String.replace, it already computes the length of the replacement string, so the default operational cost is just a single int comparison, but I agree the code would be more complex there, and that would be for the relevant experts to consider. -- Jon On 4/23/19 9:14 AM, Liam Miller-Cushon wrote: > This does seem like a small trade-off between > readability/conciseness/maintainability and performance. Jon, do you > have suggestions for how to evaluate that trade-off? > > re: doing this in String.replace, I suspect that the usage in > PathFileObject is unusually biased towards single-character arguments, > since we'd only see longer arguments with a non-default filesystem > with an unusual path separator. In the general case, String.replace is > probably more likely to see longer arguments, and adding the > additional logic and branches there may be less of a slam-dunk. > > On Mon, Apr 22, 2019 at 11:08 AM Ron Shapiro > wrote: > > I mentioned in the bug that it had a 300ms improvement for a 30s > build. > > I think it would be reasonable in String.replace() if it was > common enough to be worth checking the lengths. I don't know what > the benchmarking considerations are there. > > On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons > > > wrote: > > That seems like micro-optimization.? Do you have numbers to > back it up? > > Should this sort of optimization be done in String.replace? > > -- Jon > > On 4/22/19 8:51 AM, Ron Shapiro wrote: >> Hi, >> >> Please review this small change to improve the performance of >> PathFileObject.toBinaryName: >> >> webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8222806 >> >> Thanks! >> Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronshapiro at google.com Tue Apr 23 19:32:20 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Tue, 23 Apr 2019 15:32:20 -0400 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: Adding two of the latest authors to String.replace(CharSequence, CharSequence) to see if it makes sense to special case when both sequences have length() == 1 to redirect to String.replace(char, char). On Tue, Apr 23, 2019 at 12:47 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > I think we should follow up with folk who understand performance > trade-offs. > > Looking at String.replace, it already computes the length of the > replacement string, so the default operational cost is just a single int > comparison, but I agree the code would be more complex there, and that > would be for the relevant experts to consider. > > -- Jon > On 4/23/19 9:14 AM, Liam Miller-Cushon wrote: > > This does seem like a small trade-off between > readability/conciseness/maintainability and performance. Jon, do you have > suggestions for how to evaluate that trade-off? > > re: doing this in String.replace, I suspect that the usage in > PathFileObject is unusually biased towards single-character arguments, > since we'd only see longer arguments with a non-default filesystem with an > unusual path separator. In the general case, String.replace is probably > more likely to see longer arguments, and adding the additional logic and > branches there may be less of a slam-dunk. > > On Mon, Apr 22, 2019 at 11:08 AM Ron Shapiro > wrote: > >> I mentioned in the bug that it had a 300ms improvement for a 30s build. >> >> I think it would be reasonable in String.replace() if it was common >> enough to be worth checking the lengths. I don't know what the benchmarking >> considerations are there. >> >> On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> That seems like micro-optimization. Do you have numbers to back it up? >>> >>> Should this sort of optimization be done in String.replace? >>> >>> -- Jon >>> On 4/22/19 8:51 AM, Ron Shapiro wrote: >>> >>> Hi, >>> >>> Please review this small change to improve the performance of >>> PathFileObject.toBinaryName: >>> >>> webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8222806 >>> >>> Thanks! >>> Ron >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Apr 23 20:26:57 2019 From: martinrb at google.com (Martin Buchholz) Date: Tue, 23 Apr 2019 13:26:57 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: I'm opposed to adding length-1 special cases to String.replace. OTOH It's reasonable to add a bit of low-level code to javac's toBinaryName to save 1% cpu. I might replace the separator and remove the extension in a single pass, perhaps using StringBuilder. All known filesystems have a separator of length 1, I think. The input filename can have only one "." char, I think. On Tue, Apr 23, 2019 at 12:33 PM Ron Shapiro wrote: > Adding two of the latest authors to String.replace(CharSequence, > CharSequence) to see if it makes sense to special case when both sequences > have length() == 1 to redirect to String.replace(char, char). > > On Tue, Apr 23, 2019 at 12:47 PM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> I think we should follow up with folk who understand performance >> trade-offs. >> >> Looking at String.replace, it already computes the length of the >> replacement string, so the default operational cost is just a single int >> comparison, but I agree the code would be more complex there, and that >> would be for the relevant experts to consider. >> >> -- Jon >> On 4/23/19 9:14 AM, Liam Miller-Cushon wrote: >> >> This does seem like a small trade-off between >> readability/conciseness/maintainability and performance. Jon, do you have >> suggestions for how to evaluate that trade-off? >> >> re: doing this in String.replace, I suspect that the usage in >> PathFileObject is unusually biased towards single-character arguments, >> since we'd only see longer arguments with a non-default filesystem with an >> unusual path separator. In the general case, String.replace is probably >> more likely to see longer arguments, and adding the additional logic and >> branches there may be less of a slam-dunk. >> >> On Mon, Apr 22, 2019 at 11:08 AM Ron Shapiro >> wrote: >> >>> I mentioned in the bug that it had a 300ms improvement for a 30s build. >>> >>> I think it would be reasonable in String.replace() if it was common >>> enough to be worth checking the lengths. I don't know what the benchmarking >>> considerations are there. >>> >>> On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons < >>> jonathan.gibbons at oracle.com> wrote: >>> >>>> That seems like micro-optimization. Do you have numbers to back it up? >>>> >>>> Should this sort of optimization be done in String.replace? >>>> >>>> -- Jon >>>> On 4/22/19 8:51 AM, Ron Shapiro wrote: >>>> >>>> Hi, >>>> >>>> Please review this small change to improve the performance of >>>> PathFileObject.toBinaryName: >>>> >>>> webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8222806 >>>> >>>> Thanks! >>>> Ron >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Tue Apr 23 20:37:23 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Apr 2019 13:37:23 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: > I might replace the separator and remove the extension in a single > pass, perhaps using StringBuilder. That may be worth investigating. -- Jon On 04/23/2019 01:26 PM, Martin Buchholz wrote: > I'm opposed to adding length-1 special cases to String.replace. > > OTOH It's reasonable to add a bit of low-level code to javac's > toBinaryName to save 1% cpu. > I might replace the separator and remove the extension in a single > pass, perhaps using StringBuilder. > All known filesystems have a separator of length 1, I think. > The input filename can have only one "." char, I think. > > On Tue, Apr 23, 2019 at 12:33 PM Ron Shapiro > wrote: > > Adding two of the latest authors to String.replace(CharSequence, > CharSequence) to see if it makes sense to special case when both > sequences have length() == 1 to redirect to String.replace(char, > char). > > On Tue, Apr 23, 2019 at 12:47 PM Jonathan Gibbons > > > wrote: > > I think we should follow up with folk who understand > performance trade-offs. > > Looking at String.replace, it already computes the length of > the replacement string, so the default operational cost is > just a single int comparison, but I agree the code would be > more complex there, and that would be for the relevant experts > to consider. > > -- Jon > > On 4/23/19 9:14 AM, Liam Miller-Cushon wrote: >> This does seem like a small trade-off between >> readability/conciseness/maintainability and performance. Jon, >> do you have suggestions for how to evaluate that trade-off? >> >> re: doing this in String.replace, I suspect that the usage in >> PathFileObject is unusually biased towards single-character >> arguments, since we'd only see longer arguments with a >> non-default filesystem with an unusual path separator. In the >> general case, String.replace is probably more likely to see >> longer arguments, and adding the additional logic and >> branches there may be less of a slam-dunk. >> >> On Mon, Apr 22, 2019 at 11:08 AM Ron Shapiro >> > wrote: >> >> I mentioned in the bug that it had a 300ms improvement >> for a 30s build. >> >> I think it would be reasonable in String.replace() if it >> was common enough to be worth checking the lengths. I >> don't know what the benchmarking considerations are there. >> >> On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons >> > > wrote: >> >> That seems like micro-optimization.? Do you have >> numbers to back it up? >> >> Should this sort of optimization be done in >> String.replace? >> >> -- Jon >> >> On 4/22/19 8:51 AM, Ron Shapiro wrote: >>> Hi, >>> >>> Please review this small change to improve the >>> performance of PathFileObject.toBinaryName: >>> >>> webrev: >>> http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8222806 >>> >>> Thanks! >>> Ron >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Tue Apr 23 21:07:55 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 23 Apr 2019 15:07:55 -0600 Subject: 2019 JVM Language Summit Message-ID: CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, JULY 29-31, 2019 We are pleased to announce the 2019 JVM Language Summit to be held at Oracle?s Santa Clara campus on July 29-31, 2019. Registration is now open for all attendees. Speaker submissions will be accepted through May 24. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public. This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. The Summit will be immediately followed by the OpenJDK Committers' Workshop, August 1-2. This year, the Workshop is a separate event with its own registration process. Please review additional details at http://jvmlangsummit.com. To register: register.jvmlangsummit.com For further information: jvmlangsummit.com Questions: inquire2019 at jvmlangsummit.com From ivan.gerasimov at oracle.com Tue Apr 23 23:09:42 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 23 Apr 2019 16:09:42 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: Hi Ron! If it is known that sep.length() is always == 1, then maybe just add an assert and always use replace(char, char) variant? Also, it seems that you can safely replace fileName.lastIndexOf(".") and s.lastIndexOf("/") with fileName.lastIndexOf('.') and s.lastIndexOf('/'). With kind regards, Ivan On 4/23/19 12:32 PM, Ron Shapiro wrote: > Adding two of the latest authors to String.replace(CharSequence, > CharSequence) to see if it makes sense to special case when both > sequences have length() == 1 to redirect to String.replace(char, char). > > On Tue, Apr 23, 2019 at 12:47 PM Jonathan Gibbons > > wrote: > > I think we should follow up with folk who understand performance > trade-offs. > > Looking at String.replace, it already computes the length of the > replacement string, so the default operational cost is just a > single int comparison, but I agree the code would be more complex > there, and that would be for the relevant experts to consider. > > -- Jon > > On 4/23/19 9:14 AM, Liam Miller-Cushon wrote: >> This does seem like a small trade-off between >> readability/conciseness/maintainability and performance. Jon, do >> you have suggestions for how to evaluate that trade-off? >> >> re: doing this in String.replace, I suspect that the usage in >> PathFileObject is unusually biased towards single-character >> arguments, since we'd only see longer arguments with a >> non-default filesystem with an unusual path separator. In the >> general case, String.replace is probably more likely to see >> longer arguments, and adding the additional logic and branches >> there may be less of a slam-dunk. >> >> On Mon, Apr 22, 2019 at 11:08 AM Ron Shapiro >> > wrote: >> >> I mentioned in the bug that it had a 300ms improvement for a >> 30s build. >> >> I think it would be reasonable in String.replace() if it was >> common enough to be worth checking the lengths. I don't know >> what the benchmarking considerations are there. >> >> On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons >> > > wrote: >> >> That seems like micro-optimization. Do you have numbers >> to back it up? >> >> Should this sort of optimization be done in String.replace? >> >> -- Jon >> >> On 4/22/19 8:51 AM, Ron Shapiro wrote: >>> Hi, >>> >>> Please review this small change to improve the >>> performance of PathFileObject.toBinaryName: >>> >>> webrev: >>> http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8222806 >>> >>> Thanks! >>> Ron >> -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Wed Apr 24 03:49:04 2019 From: john.r.rose at oracle.com (John Rose) Date: Tue, 23 Apr 2019 20:49:04 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: I think it?s a slam dunk. The code for replace(String,String) is so full of branches another predictable branch won?t change the dynamics. It?s already a large JIT method, so inlining won?t change significantly. Having special paths for special lengths in String is typical enough in that code. > On Apr 23, 2019, at 9:14 AM, Liam Miller-Cushon wrote: > > In the general case, String.replace is probably more likely to see longer arguments, and adding the additional logic and branches there may be less of a slam-dunk. From ronshapiro at google.com Wed Apr 24 16:21:54 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Wed, 24 Apr 2019 12:21:54 -0400 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: I tried this, but it was 3.5x slower (320ms vs. 95ms) than the removeExtension().replace(char, char) version. I imagine that's due to something in the JIT for replace() vs. my personal StringBuilder usage. Are we able to assume that the seperator length is always 1? It doesn't seem so from the FileSystem contract, but we could assert that that's all JavacFileManager supports. I'm not sure I see much value in doing so vs. supporting both options since it's trivial to do so. On Tue, Apr 23, 2019 at 4:37 PM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > I might replace the separator and remove the extension in a single pass, > perhaps using StringBuilder. > > That may be worth investigating. > > -- Jon > > On 04/23/2019 01:26 PM, Martin Buchholz wrote: > > I'm opposed to adding length-1 special cases to String.replace. > > OTOH It's reasonable to add a bit of low-level code to javac's > toBinaryName to save 1% cpu. > I might replace the separator and remove the extension in a single pass, > perhaps using StringBuilder. > All known filesystems have a separator of length 1, I think. > The input filename can have only one "." char, I think. > > On Tue, Apr 23, 2019 at 12:33 PM Ron Shapiro > wrote: > >> Adding two of the latest authors to String.replace(CharSequence, >> CharSequence) to see if it makes sense to special case when both sequences >> have length() == 1 to redirect to String.replace(char, char). >> >> On Tue, Apr 23, 2019 at 12:47 PM Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >>> I think we should follow up with folk who understand performance >>> trade-offs. >>> >>> Looking at String.replace, it already computes the length of the >>> replacement string, so the default operational cost is just a single int >>> comparison, but I agree the code would be more complex there, and that >>> would be for the relevant experts to consider. >>> >>> -- Jon >>> On 4/23/19 9:14 AM, Liam Miller-Cushon wrote: >>> >>> This does seem like a small trade-off between >>> readability/conciseness/maintainability and performance. Jon, do you have >>> suggestions for how to evaluate that trade-off? >>> >>> re: doing this in String.replace, I suspect that the usage in >>> PathFileObject is unusually biased towards single-character arguments, >>> since we'd only see longer arguments with a non-default filesystem with an >>> unusual path separator. In the general case, String.replace is probably >>> more likely to see longer arguments, and adding the additional logic and >>> branches there may be less of a slam-dunk. >>> >>> On Mon, Apr 22, 2019 at 11:08 AM Ron Shapiro >>> wrote: >>> >>>> I mentioned in the bug that it had a 300ms improvement for a 30s build. >>>> >>>> I think it would be reasonable in String.replace() if it was common >>>> enough to be worth checking the lengths. I don't know what the benchmarking >>>> considerations are there. >>>> >>>> On Mon, Apr 22, 2019 at 2:03 PM Jonathan Gibbons < >>>> jonathan.gibbons at oracle.com> wrote: >>>> >>>>> That seems like micro-optimization. Do you have numbers to back it up? >>>>> >>>>> Should this sort of optimization be done in String.replace? >>>>> >>>>> -- Jon >>>>> On 4/22/19 8:51 AM, Ron Shapiro wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review this small change to improve the performance of >>>>> PathFileObject.toBinaryName: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ronsh/8222806/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8222806 >>>>> >>>>> Thanks! >>>>> Ron >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Apr 24 19:26:07 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 24 Apr 2019 12:26:07 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: On Wed, Apr 24, 2019 at 9:22 AM Ron Shapiro wrote: > I tried this, but it was 3.5x slower (320ms vs. 95ms) than the > removeExtension().replace(char, char) version. I imagine that's due to > something in the JIT for replace() vs. my personal StringBuilder usage. > String does get some hotspot intrinsics help, but for String.replace(char, char) specifically, it "cheats" by being able to create a String from a byte[] directly without using a public constructor. So I can see why we would want to leverage String.replace(char, char). Still, I'm surprised by 3.5x speed ratio. Anyways, this investigation supports trying to reuse the optimizations that make String.replace(char, char) so fast, and that are unavailable to ordinary java code, even though adding a special length-1 case is distasteful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Apr 25 02:08:03 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 24 Apr 2019 19:08:03 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information Message-ID: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> Hello, Returning to JDK-8146726, based on previous review feedback I've changed the title to "Improve AbstractProcessor to issue warnings for repeated information" and reworked the fix: ??? http://cr.openjdk.java.net/~darcy/8146726.4/ Thanks, -Joe From ivan.gerasimov at oracle.com Thu Apr 25 03:12:02 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 24 Apr 2019 20:12:02 -0700 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: References: Message-ID: <044252de-6e00-3bdc-34bf-c66de5ce47de@oracle.com> FYI. I filed en enhancement JDK-8222955 to do an optimization in somewhat broader case (when all strings are Latin1 encoded). The numbers look promising. I'll send a RFR shortly. Hopefully, with this special case in place, having a separate branch for length-1 arguments wouldn't feel too distasteful :-) With kind regards, Ivan On 4/24/19 12:26 PM, Martin Buchholz wrote: > > > On Wed, Apr 24, 2019 at 9:22 AM Ron Shapiro > wrote: > > I tried this, but it was 3.5x slower (320ms vs. 95ms) than the > removeExtension().replace(char, char) version. I imagine that's > due to something in the JIT for replace() vs. my personal > StringBuilder usage. > > > String does get some hotspot intrinsics help, but for > String.replace(char, char) specifically, it "cheats" by being able to > create a String from a byte[] directly without using a public > constructor. So I can see why we would want to > leverage String.replace(char, char). Still, I'm surprised by 3.5x > speed ratio. > > Anyways, this investigation supports trying to reuse the optimizations > that make String.replace(char, char) so fast, and that are unavailable > to ordinary java code, even though adding a special length-1 case is > distasteful. -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Apr 25 15:56:19 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 25 Apr 2019 08:56:19 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> Message-ID: <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> PS Amended webrev at ??? http://cr.openjdk.java.net/~darcy/8146726.5/ I added a bit of logic to avoid issuing a duplicate warning when the module name is stripped off to avoid spurious warnings in a case like ??? "foo/a.B"??? "bar/a.B" The intention of the revision of the semantics of this method in JDK 9 was to allow convenient and warning-free usage with and without modules. Thanks, -Joe On 4/24/2019 7:08 PM, Joe Darcy wrote: > Hello, > > Returning to JDK-8146726, based on previous review feedback I've > changed the title to "Improve AbstractProcessor to issue warnings for > repeated information" and reworked the fix: > > ??? http://cr.openjdk.java.net/~darcy/8146726.4/ > > Thanks, > > -Joe > > From ronshapiro at google.com Thu Apr 25 16:57:11 2019 From: ronshapiro at google.com (Ron Shapiro) Date: Thu, 25 Apr 2019 12:57:11 -0400 Subject: RFR 8222806: Inefficient String.replace in PathFileObject.toBinaryName In-Reply-To: <044252de-6e00-3bdc-34bf-c66de5ce47de@oracle.com> References: <044252de-6e00-3bdc-34bf-c66de5ce47de@oracle.com> Message-ID: Ok, should I abandon this RFR then? I can close the bug and link to Ivan's if so. On Wed, Apr 24, 2019 at 11:12 PM Ivan Gerasimov wrote: > FYI. > > I filed en enhancement JDK-8222955 > to do an optimization > in somewhat broader case (when all strings are Latin1 encoded). > > The numbers look promising. I'll send a RFR shortly. > > Hopefully, with this special case in place, having a separate branch for > length-1 arguments wouldn't feel too distasteful :-) > With kind regards, > > Ivan > > On 4/24/19 12:26 PM, Martin Buchholz wrote: > > > > On Wed, Apr 24, 2019 at 9:22 AM Ron Shapiro wrote: > >> I tried this, but it was 3.5x slower (320ms vs. 95ms) than the >> removeExtension().replace(char, char) version. I imagine that's due to >> something in the JIT for replace() vs. my personal StringBuilder usage. >> > > String does get some hotspot intrinsics help, but for String.replace(char, > char) specifically, it "cheats" by being able to create a String from a > byte[] directly without using a public constructor. So I can see why we > would want to leverage String.replace(char, char). Still, I'm surprised by > 3.5x speed ratio. > > Anyways, this investigation supports trying to reuse the optimizations > that make String.replace(char, char) so fast, and that are unavailable to > ordinary java code, even though adding a special length-1 case is > distasteful. > > > -- > With kind regards, > Ivan Gerasimov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Apr 25 23:59:52 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 25 Apr 2019 16:59:52 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> Message-ID: <7a3be66f-ee61-a439-bcb7-5260534e3cef@oracle.com> There's bad indentation on line 199. What about localization for the inline English strings? -- Jon On 4/25/19 8:56 AM, Joe Darcy wrote: > PS Amended webrev at > > ??? http://cr.openjdk.java.net/~darcy/8146726.5/ > > I added a bit of logic to avoid issuing a duplicate warning when the > module name is stripped off to avoid spurious warnings in a case like > > ??? "foo/a.B"??? "bar/a.B" > > The intention of the revision of the semantics of this method in JDK 9 > was to allow convenient and warning-free usage with and without modules. > > Thanks, > > -Joe > > On 4/24/2019 7:08 PM, Joe Darcy wrote: >> Hello, >> >> Returning to JDK-8146726, based on previous review feedback I've >> changed the title to "Improve AbstractProcessor to issue warnings for >> repeated information" and reworked the fix: >> >> ??? http://cr.openjdk.java.net/~darcy/8146726.4/ >> >> Thanks, >> >> -Joe >> >> From joe.darcy at oracle.com Fri Apr 26 00:42:23 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 25 Apr 2019 17:42:23 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: <7a3be66f-ee61-a439-bcb7-5260534e3cef@oracle.com> References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> <7a3be66f-ee61-a439-bcb7-5260534e3cef@oracle.com> Message-ID: <73aa56fe-3d1e-1746-2ce6-994a45ab7455@oracle.com> Hi Jon, On 4/25/2019 4:59 PM, Jonathan Gibbons wrote: > There's bad indentation on line 199. Noted; will fix. > > What about localization for the inline English strings? We haven't supported localization of error/warning message from the libraries in contrast with the localization policies for javac. For example, getSupportedSourceVersion can generate a non-localized warning as can getSupportedAnnotationTypes for a different situation. I would view adding localization as out-of-scope for this particular changeset, but something we could consider as a future enhancement. Thanks, -Joe From GROEGES at uk.ibm.com Fri Apr 26 08:44:31 2019 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 26 Apr 2019 09:44:31 +0100 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> <55bd5ddb-4d85-1a36-f067-a33fcc0c14b6@oracle.com> <1cfdeabf-23f7-1a51-deac-b5566e60a9c7@oracle.com> Message-ID: Hi Guys, Sorry to keep hassling you, but is there any chance we can get this change merged. I would like to get this merged before I propose a backport to JDK11 and JDK8. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Steve Groeger To: Jan Lahoda Cc: compiler-dev at openjdk.java.net Date: 18/04/2019 10:00 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath Sent by: "compiler-dev" Hi Jan & Jonathan, Thanks for saying the change now looks good. Any update on getting this sponsored and then merged? Once it is in the jdk repo I would like to go through the process of getting this into jdk8u. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Jan Lahoda To: Steve Groeger , Jonathan Gibbons Cc: compiler-dev at openjdk.java.net Date: 12/04/2019 14:31 Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath On 12. 04. 19 12:37, Steve Groeger wrote: > Hi Jan, > > I didn't know that the > /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java > test is effected by updates to the diagnostic messages. So thatnks for > letting me know. I ran this test and it did fail as you expected. Have > added the message to the > test/langtools/tools/javac/diags/examples.not-yet.txt files, as that was > where the others were. > > I can't run the tests via: > _https://wiki.openjdk.java.net/display/Build/Submit+Repo_as I dont have > authority (i'm not a committer) > I have run the test/langtools tests with and without my chnages and the > test results are the same, so I can assume that my changes havent broken > anything. > > I made the similar changes on jdk8u to the examples.not-yet.txt file but > the CheckExamples.java fails anyway, even without my changes, but making > that chnage give it one less error. > > I have updated the webrevs for jdk [1] and for jdk8u [2] > > Will follow the jdk8u update process that you mentioned to get those > changes updated, but anything you can do for jdk would be great. Thanks > > [1] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/_ I think this looks fine, thanks. Jon, do you want to take a look and/or sponsor the change, or should I? Thanks, Jan > [2] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.04/_ > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Jan Lahoda > To: Steve Groeger > Cc: compiler-dev at openjdk.java.net > Date: 10/04/2019 16:13 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > ------------------------------------------------------------------------ > > > > Hi Steve, > > One more question - do tests pass with this patch, at least the > test/langtools tests, or jdk/submit? > https://wiki.openjdk.java.net/display/Build/Submit+Repo > > (adding new diagnostic messages often need adjustments to > /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java > ) > > Regarding JDK 8 updates, please note there's a separate for that: > https://wiki.openjdk.java.net/display/jdk8u/Main > > Jan > > On 10. 04. 19 14:43, Steve Groeger wrote: >> Hi Jan, >> >> I have made the change to throw the same error as when we get the >> ServiceConfigurationError and removed the call the FatalError. >> I have created 2 new webrevs for jdk [1] and for jdk8u [2]. >> Hopefully these are now OK and in a suitable state to be able to be >> re-reviewed and then merged. >> If there is anything else that is needed please do not hesitate to >> contact me. >> >> [1] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.03/_ >> [2] _http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.03/_ >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Steve Groeger >> To: Jan Lahoda >> Cc: compiler-dev at openjdk.java.net >> Date: 10/04/2019 10:59 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> Sent by: "compiler-dev" >> ------------------------------------------------------------------------ >> >> >> >> Hi Jan, >> >> Thanks for responding. >> >> I don't think you are missing anything with regards to the use of this: >>> public FatalError(JCDiagnostic d, Throwable t) {} >> >> I think that was me missing the fact this would cause NPE and mask the >> actual issue. >> >> I will probably go with your original suggestion: >>> Would there be an issue with simply changing the "catch >>> (Throwable)" to also report the same error as >>> "catch (ServiceConfigurationError)"? >> >> Will make these changes and generate some new webrevs for this and post >> again when they are available. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Jan Lahoda >> To: Steve Groeger >> Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons >> >> Date: 10/04/2019 09:51 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> ------------------------------------------------------------------------ >> >> >> >> Hi Steve, >> >> I apologize for a late reply. For the FatalError, seems that this >> constructor is being called there: >> public FatalError(JCDiagnostic d, Throwable t) { >> super(d.toString(), t); >> } >> >> with "d == null". That, I think, will lead to an immediate NPE, which I >> don't think is desirable, as it will hide the actual exception that was >> thrown. Or do I miss something? >> >> Thanks, >> Jan >> >> On 09. 04. 19 11:02, Steve Groeger wrote: >>> Hi Jan, >>> >>> I sent the post below about a month ago but didn't get a response from >>> you as to the review of the new webrevs. >>> Not sure whether you got it or not but I would be grateful if you could >>> take a look at these webrevs and let me know whether they are OK now. >>> If they are OK, please let me know the next steps needed to get these >>> merged into the code base. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >>> >>> >>> From: Steve Groeger >>> To: Jan Lahoda >>> Cc: compiler-dev at openjdk.java.net >>> Date: 07/03/2019 09:57 >>> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >>> annotation processor is on the classpath >>> Sent by: "compiler-dev" >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Hi Jan, >>> >>> Thanks for providing a possible test for the malformed Annotation Processor. >>> I have taken the code you provided and tweaked it a bit (for jdk) and >>> had to >>> write a similar thing for jdk8u as some of the functionality in the test >>> is not >>> available in the same form in jdk8u (well, not that I could find!!!) >>> >>> I would be grateful if you could review to code in the new webrevs. >>> _ >>> ___http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/___ >>> ___http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/__ >>> >>> Any issues please let me know. >>> >>> PS. I left the FatalErorr in JavacProcessingEnvironment.javaas we >>> wanted Jon to comment on whether this is what is required or whether >>> we go with your previous suggestion. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Apr 26 15:29:02 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 26 Apr 2019 11:29:02 -0400 Subject: RFR: JDK-8219487: j.l.c.ClassDesc spec should contain precise assertions for one parameter's methods Message-ID: Please review the simple fix, javadoc editing, for [1] at [2]. The patch is just changing "_any_ argument" for "_the_ argument" for some methods of java.lang.constant.ClassDesc receiving only one argument. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8219487 [2] http://cr.openjdk.java.net/~vromero/8219487/webrev.00/ From joe.darcy at oracle.com Fri Apr 26 16:35:56 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 26 Apr 2019 09:35:56 -0700 Subject: RFR: JDK-8219487: j.l.c.ClassDesc spec should contain precise assertions for one parameter's methods In-Reply-To: References: Message-ID: <6369f2b4-509d-444b-1ae5-b36dd5d5f0b9@oracle.com> Hi Vicente, Looks fine; cheers, -Joe On 4/26/2019 8:29 AM, Vicente Romero wrote: > Please review the simple fix, javadoc editing, for [1] at [2]. The > patch is just changing "_any_ argument" for "_the_ argument" for some > methods of java.lang.constant.ClassDesc receiving only one argument. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8219487 > [2] http://cr.openjdk.java.net/~vromero/8219487/webrev.00/ From james.laskey at oracle.com Fri Apr 26 16:46:59 2019 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 26 Apr 2019 13:46:59 -0300 Subject: RFR: JDK-8219487: j.l.c.ClassDesc spec should contain precise assertions for one parameter's methods In-Reply-To: References: Message-ID: <995D33FF-11AD-4509-ADAA-D8F4506D4791@oracle.com> +1 > On Apr 26, 2019, at 12:29 PM, Vicente Romero wrote: > > Please review the simple fix, javadoc editing, for [1] at [2]. The patch is just changing "_any_ argument" for "_the_ argument" for some methods of java.lang.constant.ClassDesc receiving only one argument. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8219487 > [2] http://cr.openjdk.java.net/~vromero/8219487/webrev.00/ From jonathan.gibbons at oracle.com Mon Apr 29 14:33:44 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 29 Apr 2019 07:33:44 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: <73aa56fe-3d1e-1746-2ce6-994a45ab7455@oracle.com> References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> <7a3be66f-ee61-a439-bcb7-5260534e3cef@oracle.com> <73aa56fe-3d1e-1746-2ce6-994a45ab7455@oracle.com> Message-ID: <510f60b5-f7d8-8394-bf1e-98eb7668ae8c@oracle.com> OK, it's a bit of a fine distinction between libraries and javac in this case, but you point to precedent. OK by me, -- Jon On 4/25/19 5:42 PM, Joe Darcy wrote: > Hi Jon, > > On 4/25/2019 4:59 PM, Jonathan Gibbons wrote: >> There's bad indentation on line 199. > > Noted; will fix. > >> >> What about localization for the inline English strings? > > We haven't supported localization of error/warning message from the > libraries in contrast with the localization policies for javac. > > For example, getSupportedSourceVersion can generate a non-localized > warning as can getSupportedAnnotationTypes for a different situation. > > I would view adding localization as out-of-scope for this particular > changeset, but something we could consider as a future enhancement. > > Thanks, > > -Joe > > From stuart.marks at oracle.com Tue Apr 30 00:14:08 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 29 Apr 2019 17:14:08 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> Message-ID: Hi Joe, Some nitpicky comments for you in AbstractProcessor.java. :-) I'm finding the boolean flags to be fairly confusing. Consider the 'initialized' field. This has a synchronized getter; getSupportedAnnotationTypes() calls the getter and stores the result in a local for use within this method. However, arrayToSet() accesses the 'initialized' field directly, and it's called (unsynchronized) from getSupportedOptions() as well as getSupportedAnnotationTypes(). First, there's a potential memory visibility problem here, if you're concerned about multithreaded access. (At least some of the code in this class seems to try to handle thread-safety.) Second, the 'initialized' state is accessed from two different levels in the method call hierarchy, e.g. getSupportedAnnotationTypes() and arrayToSet(). This isn't necessarily a problem, but it does make me pause to try to think about what it means. Another flag is 'stripModulePrefixes' (parameter to arrayToSet()) and its dependent local variable 'stripped' which is set if anything was actually stripped from this element. These make arrayToSet() a bit of a puzzle for me. I think the following are true: 1) if we aren't stripping module prefixes, we'll issue a warning on any duplicates. 2) if we are stripping module prefixes, we won't issue a warning if a prefixes was stripped from this element. My first inclination is to think that there are really two different arrayToSet() methods wanted here. The first doesn't strip and may issue warnings, and the second does strip and doesn't issue warnings. It seems to me that two separate methods might be simpler than one bigger method with a bunch of flags. But that's not what the current implementation does. However, the current implementation doesn't quite make sense to me either. For example, the comment says that if module names are stripped, warnings aren't issued because they'd be spurious if the array is ["foo/a.B", "bar/a.B"]. However, I'm not sure this logic makes sense. It seems to me that if the array is ["a.B", "foo/a.B"] then no warning is issued, but if the array is ["foo/a.B", "a.B"] the a warning is issued. Am I reading this correctly, and is this the right behavior? s'marks On 4/25/19 8:56 AM, Joe Darcy wrote: > PS Amended webrev at > > ??? http://cr.openjdk.java.net/~darcy/8146726.5/ > > I added a bit of logic to avoid issuing a duplicate warning when the module name > is stripped off to avoid spurious warnings in a case like > > ??? "foo/a.B"??? "bar/a.B" > > The intention of the revision of the semantics of this method in JDK 9 was to > allow convenient and warning-free usage with and without modules. > > Thanks, > > -Joe > > On 4/24/2019 7:08 PM, Joe Darcy wrote: >> Hello, >> >> Returning to JDK-8146726, based on previous review feedback I've changed the >> title to "Improve AbstractProcessor to issue warnings for repeated >> information" and reworked the fix: >> >> ??? http://cr.openjdk.java.net/~darcy/8146726.4/ >> >> Thanks, >> >> -Joe >> >> From jan.lahoda at oracle.com Tue Apr 30 08:41:43 2019 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 30 Apr 2019 10:41:43 +0200 Subject: RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath In-Reply-To: References: <5C616E68.5050103@oracle.com> <5C6432DB.7070208@oracle.com> <5C7D12B9.5060801@oracle.com> <55bd5ddb-4d85-1a36-f067-a33fcc0c14b6@oracle.com> <1cfdeabf-23f7-1a51-deac-b5566e60a9c7@oracle.com> Message-ID: <764a1529-1b78-9cda-03c7-de7ff4aafac0@oracle.com> Hi Steve, pushed to jdk/jdk: http://hg.openjdk.java.net/jdk/jdk/rev/d9208a660094 Jan On 26. 04. 19 10:44, Steve Groeger wrote: > Hi Guys, > > Sorry to keep hassling you, but is there any chance we can get this > change merged. > I would like to get this merged before I propose a backport to JDK11 and > JDK8. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Steve Groeger > To: Jan Lahoda > Cc: compiler-dev at openjdk.java.net > Date: 18/04/2019 10:00 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > Sent by: "compiler-dev" > ------------------------------------------------------------------------ > > > > Hi Jan & Jonathan, > > Thanks for saying the change now looks good. > Any update on getting this sponsored and then merged? > Once it is in the jdk repo I would like to go through the process of > getting this into jdk8u. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: Jan Lahoda > To: Steve Groeger , Jonathan Gibbons > > Cc: compiler-dev at openjdk.java.net > Date: 12/04/2019 14:31 > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad > annotation processor is on the classpath > ------------------------------------------------------------------------ > > > > On 12. 04. 19 12:37, Steve Groeger wrote: >> Hi Jan, >> >> I didn't know that the >> /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java >> test is effected by updates to the diagnostic messages. So thatnks for >> letting me know. I ran this test and it did fail as you expected. Have >> added the message to the >> test/langtools/tools/javac/diags/examples.not-yet.txt files, as that was >> where the others were. >> >> I can't run the tests via: >> __https://wiki.openjdk.java.net/display/Build/Submit+Repo_as_I dont have >> authority (i'm not a committer) >> I have run the test/langtools tests with and without my chnages and the >> test results are the same, so I can assume that my changes havent broken >> anything. >> >> I made the similar changes on jdk8u to the examples.not-yet.txt file but >> the CheckExamples.java fails anyway, even without my changes, but making >> that chnage give it one less error. >> >> I have updated the webrevs for jdk [1] and for jdk8u [2] >> >> Will follow the jdk8u update process that you mentioned to get those >> changes updated, but anything you can do for jdk would be great. Thanks >> >> [1] __http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.04/__ > > I think this looks fine, thanks. > > Jon, do you want to take a look and/or sponsor the change, or should I? > > Thanks, > ? ?Jan > >> [2] __http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.04/__ >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: Jan Lahoda >> To: Steve Groeger >> Cc: compiler-dev at openjdk.java.net >> Date: 10/04/2019 16:13 >> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad >> annotation processor is on the classpath >> ------------------------------------------------------------------------ >> >> >> >> Hi Steve, >> >> One more question - do tests pass with this patch, at least the >> test/langtools tests, or jdk/submit? >> _https://wiki.openjdk.java.net/display/Build/Submit+Repo_ >> >> (adding new diagnostic messages often need adjustments to >> /home/jlahoda/src/jdk/jdk/test/langtools/tools/javac/diags/CheckExamples.java >> ) >> >> Regarding JDK 8 updates, please note there's a separate for that: >> _https://wiki.openjdk.java.net/display/jdk8u/Main_ >> >> Jan >> >> On 10. 04. 19 14:43, Steve Groeger wrote: >>> Hi Jan, >>> >>> I have made the change to throw the same error as when we get the >>> ServiceConfigurationError and removed the call the FatalError. >>> I have created 2 new webrevs for jdk [1] and for jdk8u [2]. >>> Hopefully these are now OK and in a suitable state to be able to be >>> re-reviewed and then merged. >>> If there is anything else that is needed please do not hesitate to >>> contact me. >>> >>> [1] __http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.03/__ >>> [2] __http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.03/__ >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 ?129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >>> >>> >>> >>> From: Steve Groeger >>> To: Jan Lahoda >>> Cc: compiler-dev at openjdk.java.net >>> Date: 10/04/2019 10:59 >>> Subject: Re: RFR: [8218152] javac fails and exits with no error if ?a bad >>> annotation processor is on the classpath >>> Sent by: "compiler-dev" >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Hi Jan, >>> >>> Thanks for responding. >>> >>> I don't think you are missing anything with regards to the use of ?this: >>>> ? ? public FatalError(JCDiagnostic d, Throwable t) {} >>> >>> I think that was me missing the fact this would cause NPE and mask ?the >>> actual issue. >>> >>> I will probably go with your original suggestion: >>>> Would there be an issue with simply changing the "catch >>>> (Throwable)" to also report the same error as >>>> "catch (ServiceConfigurationError)"? >>> >>> Will make these changes and generate some new webrevs for this and ?post >>> again when they are available. >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, Winchester >>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 ?129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >>> >>> >>> >>> From: Jan Lahoda >>> To: Steve Groeger >>> Cc: compiler-dev at openjdk.java.net, Jonathan Gibbons >>> >>> Date: 10/04/2019 09:51 >>> Subject: Re: RFR: [8218152] javac fails and exits with no error if ?a bad >>> annotation processor is on the classpath >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Hi Steve, >>> >>> I apologize for a late reply. For the FatalError, seems that this >>> constructor is being called there: >>> ? ? public FatalError(JCDiagnostic d, Throwable t) ?{ >>> ? ? ? ? super(d.toString(), t); >>> ? ? } >>> >>> with "d == null". That, I think, will lead to an immediate ?NPE, which I >>> don't think is desirable, as it will hide the actual exception that ?was >>> thrown. Or do I miss something? >>> >>> Thanks, >>> ? ? Jan >>> >>> On 09. 04. 19 11:02, Steve Groeger wrote: >>>> Hi Jan, >>>> >>>> I sent the post below about a month ago but didn't get a response ? from >>>> you as to the review of the new webrevs. >>>> Not sure whether you got it or not but I would be grateful if ?you ?could >>>> take a look at these webrevs and let me know whether they are ?OK now. >>>> If they are OK, please let me know the next steps needed to get ?these >>>> merged into the code base. >>>> >>>> Thanks >>>> Steve Groeger >>>> IBM Runtime Technologies >>>> Hursley, Winchester >>>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 ?517 ?129 >>>> Fax (44) 1962 816800 >>>> Lotus Notes: Steve Groeger/UK/IBM >>>> Internet: groeges at uk.ibm.com >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with ? number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ? PO6 3AU >>>> >>>> >>>> >>>> From: Steve Groeger >>>> To: Jan Lahoda >>>> Cc: compiler-dev at openjdk.java.net >>>> Date: 07/03/2019 09:57 >>>> Subject: Re: RFR: [8218152] javac fails and exits with no error ?if ?a bad >>>> annotation processor is on the classpath >>>> Sent by: "compiler-dev" >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> Hi Jan, >>>> >>>> Thanks for providing a possible test for the malformed Annotation ? Processor. >>>> I have taken the code you provided and tweaked it a bit (for jdk) ? and >>>> had to >>>> write a similar thing for jdk8u as some of the functionality in ?the ?test >>>> is not >>>> available in the same form in jdk8u (well, not that I could find!!!) >>>> >>>> I would be grateful if you could review to code in the new webrevs. >>>> _ >>>> ____http://cr.openjdk.java.net/~sgroeger/8218152/jdk/webrev.02/____ >>>> ____http://cr.openjdk.java.net/~sgroeger/8218152/jdk8u/webrev.02/___ >>>> >>>> Any issues please let me know. >>>> >>>> PS. I left the FatalErorr in JavacProcessingEnvironment.javaas ?we >>>> wanted Jon to comment on whether this is what is required or whether >>>> we go with your previous suggestion. >>>> >>>> Thanks >>>> Steve Groeger >>>> IBM Runtime Technologies >>>> Hursley, Winchester >>>> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 ?517 ?129 >>>> Fax (44) 1962 816800 >>>> Lotus Notes: Steve Groeger/UK/IBM >>>> Internet: groeges at uk.ibm.com >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with ? number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ? PO6 3AU >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with ? number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ? PO6 3AU >>>> >>>> >>>> Unless stated otherwise above: >>>> IBM United Kingdom Limited - Registered in England and Wales with ? number >>>> 741598. >>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ? PO6 3AU >>> >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with ?number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire ?PO6 3AU >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From joe.darcy at oracle.com Tue Apr 30 23:21:26 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 30 Apr 2019 16:21:26 -0700 Subject: JDK 13 RFR of JDK-8146726 : Improve AbstractProcessor to issue warnings for repeated information In-Reply-To: References: <108ebf10-ef2c-c98e-6770-c6b60fb12be5@oracle.com> <825c3947-cc08-3c5c-b963-773800f631e1@oracle.com> Message-ID: Hi Stuart, On 4/29/2019 5:14 PM, Stuart Marks wrote: > Hi Joe, > > Some nitpicky comments for you in AbstractProcessor.java. :-) Thanks for the careful review. > > I'm finding the boolean flags to be fairly confusing. Consider the > 'initialized' field. This has a synchronized getter; > getSupportedAnnotationTypes() calls the getter and stores the result > in a local for use within this method. However, arrayToSet() accesses > the 'initialized' field directly, and it's called (unsynchronized) > from getSupportedOptions() as well as getSupportedAnnotationTypes(). > > First, there's a potential memory visibility problem here, if you're > concerned about multithreaded access. (At least some of the code in > this class seems to try to handle thread-safety.) Second, the > 'initialized' state is accessed from two different levels in the > method call hierarchy, e.g. getSupportedAnnotationTypes() and > arrayToSet(). This isn't necessarily a problem, but it does make me > pause to try to think about what it means. Yes; the is-initialized check should be done using the isInitalized method as done elsewhere in the class; needed update made in ??? http://cr.openjdk.java.net/~darcy/8146726.6/ > > Another flag is 'stripModulePrefixes' (parameter to arrayToSet()) and > its dependent local variable 'stripped' which is set if anything was > actually stripped from this element. These make arrayToSet() a bit of > a puzzle for me. I think the following are true: > > 1) if we aren't stripping module prefixes, we'll issue a warning on > any duplicates. > > 2) if we are stripping module prefixes, we won't issue a warning if a > prefixes was stripped from this element. > > My first inclination is to think that there are really two different > arrayToSet() methods wanted here. The first doesn't strip and may > issue warnings, and the second does strip and doesn't issue warnings. > It seems to me that two separate methods might be simpler than one > bigger method with a bunch of flags. > > But that's not what the current implementation does. However, the > current implementation doesn't quite make sense to me either. For > example, the comment says that if module names are stripped, warnings > aren't issued because they'd be spurious if the array is ["foo/a.B", > "bar/a.B"]. However, I'm not sure this logic makes sense. It seems to > me that if the array is > > ??? ["a.B", "foo/a.B"] > > then no warning is issued, but if the array is > > ??? ["foo/a.B", "a.B"] > > the a warning is issued. Am I reading this correctly, and is this the > right behavior? > > A bit of background on the intention of the AbstractProcessor class. The class was a major usability improvement added in JSR 269 over the apt API . The AbstractProcessor class provides a convenient "JDWIOWTD" - just do what I obviously want to do - approach for common processor tasks. Of most relevance here, it allows annotations on the processor class to succinctly indicate which annotation types and options the processor supports. The semantics of the improved warnings in supported options proposed in this change is straightforward: is there are any repeated elements in the array retrieved from the annotation (and a messager to report a warning is available), report that an element is repeated. Given some existing functionality to support annotation processing and modules, the improved warnings support for the supported annotation types is more subtle. Before modules, basically an annotation type name was an annotation type name, like "a.B", and they could be compared for duplicates just like options The supported annotation type names are a set of strings built from a string array of inputs. Originally pre-modules, the supported syntax of the type names included fully qualified names and some wildcard support. These names could be subject to the same style of duplicate checking as done for option names in this patch. With modules, the recommended syntax for names includes a module prefix, "foo/a.B" as distinct from "bar/a.B". Without a module prefix, "a.B" will match a same-named annotation type in any module. One goal of AbstractProcessor in JDK 9 and later is to allow a processor to smoothly support running in an environment with or without modules. Therefore "a.B" retains its meaning by matching an annotation type in that name in any module. Since the recommendation is to include a module name, if the compilation environment doesn't support modules, AbstractProcesso.getSupportedAnnotationTypes drop the module prefix if present. Therefore, if the the annotation information is ??? @SupportedAnnotationTypes({"foo/a.B", "bar/a.B"}) AbstractProcessor.getSupportedAnnotationTypes treats this as equivalent to ??? @SupportedAnnotationTypes({"a.B", "a.B"}) which is of course semantically the same as "a.B". Now, in this case I think it is acceptable to not get a warning when such a processor is run in an environment without modules. However, the code as it is currently written will *not* warning for ??? {"foo/a.B", "foo/a.B"} when run without modules. That input will get a warning if run *with* module though. The input ??? ??? {"a.B", "a.B"} will generate a warning independent of modules being supported. Having jtreg @compile statements with different source levels allows this behavior to be tested. The current minor complication in the checking loop are in lieu of a more complicated check that would first compare for duplicates on the original set of values and then preform a module stripping step where that was appropriate. I didn't regard the extra warning coverage to be worth the effort, but I'm happy to discuss the matter. HTH, -Joe