From ivan.gerasimov at oracle.com Sun Dec 1 08:44:22 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 1 Dec 2019 00:44:22 -0800 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries In-Reply-To: References: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> <2f1c999e-5d99-e625-644a-399f63b3be27@oracle.com> Message-ID: Thank you Alan for the further review! On 11/27/19 12:53 PM, Alan Bateman wrote: > On 27/11/2019 11:52, Ivan Gerasimov wrote: >> : >> >> It's not clear how to distinguish the classes inside the java.base >> module that do not have to depend on sun.nio.cs.? If you feel strong >> about NTLM and XML, I can replace sun.nio.cs.* instances with >> corresponding java.charset.StandardCharsets.* constants in these >> classes. > There isn't any way to say what is core and non-core in java.base so > you have to use your judgement. My personal view is that the NTLM, > XML, SOCKS and several others in this patch should stick to the > standard APIs if possible as their performance will likely be > dominated by other factors. Personally, I think that using constants sun.nio.cs.xxx.INSTANCE is not too bad even in the code that is unlikely to be executed during the VM startup.? One small advantage is that if the code is copy/pasted within the java.base module, it will not bring the risk of early initialization of StandardCharsets. With NTLM, however, switching to StandardCharsets allows to remove sun.nio.cs.UTF_16LE.INSTANCE and all other corresponding modifications. So, I used StandardCharsets in NTLM (and in XML and SOCKS, as you suggested), and left sun.nio.cs constants in all other places. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8234147/02/webrev/ It builds fine, tests run fine. -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Sun Dec 1 08:51:02 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 1 Dec 2019 00:51:02 -0800 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries In-Reply-To: References: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> Message-ID: <23c08bbc-9ff0-bb8f-8064-4f03596b92a3@oracle.com> Hi Ulf! Thank you for the links! The enhancement requests that you pointed out are about making the lookup faster. My current proposal, however, is to completely avoid the lookup of the standard charsets in certain specific cases. With kind regards, Ivan On 11/30/19 1:32 PM, Ulf Zibis wrote: > Hi Ivan, > > you may compare your proposal with: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6790402 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6850361 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6796087 > > -Ulf > > Am 27.11.19 um 05:39 schrieb Ivan Gerasimov: >> Hello! >> >> It is a cleanup fix with mostly two kinds of changes: >> - when a standard charset is specified by its name, use a >> preinitialized Charset constant instead, >> - replace the usage of StandardCharset.* constants with their >> sun.nio.cs.* equivalents to avoid accidental early initialization of >> rarely-used charsets. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234147 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8234147/00/webrev/ >> >> I also had to modify one regression test that relied on a private >> auxiliary method, which was removed with the fix. >> >> Mach5 control build looks green. >> >> Would you please help review the fix? >> -- With kind regards, Ivan Gerasimov From david.lloyd at redhat.com Sun Dec 1 16:07:14 2019 From: david.lloyd at redhat.com (David Lloyd) Date: Sun, 1 Dec 2019 10:07:14 -0600 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: <45C77E27-AA9A-4E81-858C-6AE52B3F65BF@oracle.com> References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> <34b5594d-0a56-c7fb-0906-c585121d6284@oracle.com> <1e88cab1-a6c7-454b-6cc5-6747c67a80cb@oracle.com> <45C77E27-AA9A-4E81-858C-6AE52B3F65BF@oracle.com> Message-ID: On Fri, Nov 29, 2019 at 5:34 PM John Rose wrote: > > On Nov 29, 2019, at 4:24 AM, David Lloyd wrote: > > > Makes sense, it's still early. But now the seed is planted. :) > > > (It?s better documented. Most of the points made here were not new.) Okay, anyway I'm glad that I'm not the first person to have thought of these use cases. The API looks good! -- - DML From raffaello.giulietti at gmail.com Sun Dec 1 17:00:19 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Sun, 1 Dec 2019 18:00:19 +0100 Subject: wavl based alternative to red-black TreeMap Message-ID: Hi core librarians, did anybody already explore wavl trees as a drop-in replacement to the red-black based TreeMap? If yes, I'm curious about performance comparisons. If not, I would be glad to invest some time on it as they seem to be never worse than red-black trees and in many application (no deletions, only insertions and searching) even better. No promises about delivery... Greetings Raffaello From forax at univ-mlv.fr Sun Dec 1 17:13:33 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 1 Dec 2019 18:13:33 +0100 (CET) Subject: wavl based alternative to red-black TreeMap In-Reply-To: References: Message-ID: <1524522780.1790973.1575220413453.JavaMail.zimbra@u-pem.fr> Nice ! there is a wikipedia article about WAVL tree [1]. I did not know this new kind of balanced tree, worth the exploration i believe. and TreeMap code really needs some love anyway, unlike ArrayList and HashMap, this code has not be updated since a long time. R?mi [1] https://en.wikipedia.org/wiki/WAVL_tree ----- Mail original ----- > De: "raffaello giulietti" > ?: "core-libs-dev" > Envoy?: Dimanche 1 D?cembre 2019 18:00:19 > Objet: wavl based alternative to red-black TreeMap > Hi core librarians, > > did anybody already explore wavl trees as a drop-in replacement to the > red-black based TreeMap? > > If yes, I'm curious about performance comparisons. > > If not, I would be glad to invest some time on it as they seem to be > never worse than red-black trees and in many application (no deletions, > only insertions and searching) even better. > > No promises about delivery... > > > Greetings > Raffaello From raffaello.giulietti at gmail.com Sun Dec 1 17:49:53 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Sun, 1 Dec 2019 18:49:53 +0100 Subject: wavl based alternative to red-black TreeMap Message-ID: <06ba7a6f-3d1d-c399-74eb-cb91cc08fdbb@gmail.com> Not exactly the newest data structure. Wavl trees are with us since 2009 ;-) HashMap could benefit from wavl trees as well. Afaik, it uses red-black trees in presence of collisions, right? R > Nice ! > there is a wikipedia article about WAVL tree [1]. > > I did not know this new kind of balanced tree, worth the exploration i believe. > > and TreeMap code really needs some love anyway, unlike ArrayList and HashMap, this code has not be updated since a long time. > > R?mi > [1] https://en.wikipedia.org/wiki/WAVL_tree > > > ----- Mail original ----- >> De: "raffaello giulietti" >> ?: "core-libs-dev" >> Envoy?: Dimanche 1 D?cembre 2019 18:00:19 >> Objet: wavl based alternative to red-black TreeMap > >> Hi core librarians, >> >> did anybody already explore wavl trees as a drop-in replacement to the >> red-black based TreeMap? >> >> If yes, I'm curious about performance comparisons. >> >> If not, I would be glad to invest some time on it as they seem to be >> never worse than red-black trees and in many application (no deletions, >> only insertions and searching) even better. >> >> No promises about delivery... >> >> >> Greetings >> Raffaello From Alan.Bateman at oracle.com Sun Dec 1 19:10:45 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Dec 2019 19:10:45 +0000 Subject: RFR 8234147 : Avoid looking up standard charsets in core libraries In-Reply-To: References: <8e010258-7a18-3165-1d11-7aa89b996aa4@oracle.com> <2f1c999e-5d99-e625-644a-399f63b3be27@oracle.com> Message-ID: <5a24d6c2-3a56-ebcd-da19-787836d8a1fd@oracle.com> On 01/12/2019 08:44, Ivan Gerasimov wrote: > : > > Personally, I think that using constants sun.nio.cs.xxx.INSTANCE is > not too bad even in the code that is unlikely to be executed during > the VM startup.? One small advantage is that if the code is > copy/pasted within the java.base module, it will not bring the risk of > early initialization of StandardCharsets. > > With NTLM, however, switching to StandardCharsets allows to remove > sun.nio.cs.UTF_16LE.INSTANCE and all other corresponding modifications. > > So, I used StandardCharsets in NTLM (and in XML and SOCKS, as you > suggested), and left sun.nio.cs constants in all other places. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~igerasim/8234147/02/webrev/ > > It builds fine, tests run fine. Okay although my personal view is that a lot of this is unnecessary, e.g. the pack200 Driver class, IllegalAccessMap is not used at run-time with images builds, the InetAddress hosts file requires a special property to enable, and several others. On the other hand, there are several places where the handling of UnsupportedEncodingException goes away so those parts are good. -Alan From fujie at loongson.cn Mon Dec 2 06:00:12 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 2 Dec 2019 14:00:12 +0800 Subject: RFR: 8235169: [TESTBUG] java/nio/channels/DatagramChannel/ManySenders.java fails on Ubuntu18.04 Message-ID: <5a43cedf-cd5e-b894-7a96-991591946b9d@loongson.cn> Hi all, The failure was caused by InetAddress.getLocalHost() which returns "127.0.1.1" on our Ubuntu18.04 machines. JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235169 Webrev: http://cr.openjdk.java.net/~jiefu/8235169/webrev.00/ Could you please review it and give me some advice? Thanks a lot. Best regards, Jie From joe.darcy at oracle.com Mon Dec 2 06:17:06 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 1 Dec 2019 22:17:06 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> Message-ID: <1824646f-00f5-13c0-0873-6ea6f04137c3@oracle.com> Hi Vicente, I took the liberty of adding the necessary directory-level jtreg config files to enable the feature and updated the tests accordingly: ??? https://hg.openjdk.java.net/amber/amber/rev/c91826d62310 (The feature is enabled by default in for the langtools tests, but disabled by default elsewhere.) HTH, -Joe On 11/29/2019 3:12 PM, Vicente Romero wrote: > Hi Joe, > > All the tests that have an explicit -source 14 are that way because > of, I think to remember, a bug in jtreg that doesn't expand the > ${some.property} macro for those tests. I don't remember the details > though > > Thanks, > Vicente > > On 11/29/19 9:59 AM, Joe Darcy wrote: >> Hi Vicente, >> >> Please change all uses of >> >> ??? @compile --enable-preview -source 14 >> >> in jtreg tags to to >> >> ??? @compile --enable-preview -source ${jdk.version} >> >> The former structure will spuriously fail when the JDK 14 -> 15 >> transition occurs. >> >> Also, publishing delta-webrevs between iterations in additional to >> full webrev would help track the incremental changes. >> >> Thanks, >> >> -Joe >> >> On 11/28/2019 8:05 AM, Vicente Romero wrote: >>> Hi again, >>> >>> Sorry but I realized that I forgot to remove some code on the >>> compiler side. The code removed is small, before we were issuing an >>> error if some serialization methods were declared as record members. >>> That section was removed from the spec. I have prepared another >>> iteration with this change at [1] >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >>> >>> On 11/27/19 11:37 PM, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review the code for the records feature at [1]. This webrev >>>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>>> more! Must of the code has been reviewed but there have been some >>>> changes since reviewers saw it. Also this is the first time an >>>> integral webrev is sent out for review. Last changes on top of my >>>> mind since last review iterations: >>>> >>>> On the compiler implementation: >>>> - it has been adapted to the last version of the language spec [2], >>>> as a reference the JVM spec is at [3]. This implied some changes in >>>> determining if a user defined constructor is the canonical or not. >>>> Now if a constructor is override-equivalent to a signature derived >>>> from the record components, then it is considered the canonical >>>> constructor. And any canonical constructor should satisfy a set of >>>> restrictions, see section 8.10.4 Record Constructor Declarations of >>>> the specification. >>>> - It was also added a check to make sure that accessors are not >>>> generic. >>>> - And that the canonical constructor, if user defined, is not >>>> explicitly invoking any other constructor. >>>> - The list of forbidden record component names has also been updated. >>>> - new error messages have been added >>>> >>>> APIs: >>>> - there have been some API editing in java.lang.Record, >>>> java.lang.runtime.ObjectMethods and >>>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>>> javax.lang.model (some visitors were added) >>>> >>>> On the JVM implementation: >>>> - some logging capabilities have been added to classFileParser.cpp >>>> to provide the reason for which the Record attribute has been ignored >>>> >>>> Reflection: >>>> - there are several new changes to the implementation of >>>> java.lang.reflect.RecordComponent apart from the spec changes >>>> mentioned before. >>>> >>>> bug fixes in >>>> - compiler >>>> - serialization, >>>> - JVM, etc >>>> >>>> As a reference the last iteration of the previous reviews can be >>>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>>> reflection and serialization, >>>> >>>> TIA, >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>>> [2] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>>> [3] >>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>>> >>> > From david.holmes at oracle.com Mon Dec 2 06:37:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 2 Dec 2019 16:37:59 +1000 Subject: RFR: 8235169: [TESTBUG] java/nio/channels/DatagramChannel/ManySenders.java fails on Ubuntu18.04 In-Reply-To: <5a43cedf-cd5e-b894-7a96-991591946b9d@loongson.cn> References: <5a43cedf-cd5e-b894-7a96-991591946b9d@loongson.cn> Message-ID: <1e5d5520-95f0-005f-6aa7-8131efd02fd7@oracle.com> Hi Jie, I think this should be reviewed on net-dev. Cheers, David On 2/12/2019 4:00 pm, Jie Fu wrote: > Hi all, > > The failure was caused by InetAddress.getLocalHost() which returns > "127.0.1.1" on our Ubuntu18.04 machines. > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235169 > Webrev: http://cr.openjdk.java.net/~jiefu/8235169/webrev.00/ > > Could you please review it and give me some advice? > > Thanks a lot. > Best regards, > Jie > From Alan.Bateman at oracle.com Mon Dec 2 07:23:22 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Dec 2019 07:23:22 +0000 Subject: RFR: 8235169: [TESTBUG] java/nio/channels/DatagramChannel/ManySenders.java fails on Ubuntu18.04 In-Reply-To: <5a43cedf-cd5e-b894-7a96-991591946b9d@loongson.cn> References: <5a43cedf-cd5e-b894-7a96-991591946b9d@loongson.cn> Message-ID: <13750298-ad5d-c52b-5c80-06f4cd15fabf@oracle.com> On 02/12/2019 06:00, Jie Fu wrote: > Hi all, > > The failure was caused by InetAddress.getLocalHost() which returns > "127.0.1.1" on our Ubuntu18.04 machines. > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235169 > Webrev: http://cr.openjdk.java.net/~jiefu/8235169/webrev.00/ > > Could you please review it and give me some advice? It's okay for getLocalHost to return a loopback address. If I read your bug report correctly, the issue is that the NetworkInterface.getByInetAddress is returning null so we should skip that interface. Can you bring this to nio-dev and we can discuss a cleaner way to do this that shouldn't skip the entire test. -Alan From Alan.Bateman at oracle.com Mon Dec 2 10:12:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Dec 2019 10:12:06 +0000 Subject: JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: On 20/11/2019 19:42, Nikola Grcevski wrote: > : > > Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. -Alan From julia.boes at oracle.com Mon Dec 2 10:54:08 2019 From: julia.boes at oracle.com (Julia Boes) Date: Mon, 2 Dec 2019 10:54:08 +0000 Subject: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux In-Reply-To: References: <9EDBFD2B-226D-40DC-96E5-BD41F4976747@oracle.com> Message-ID: <5b980e67-f567-d161-5b40-dedfd599bedc@oracle.com> Hi, > to make it more consistent w/ other tools, I'd move all ifconfig (incl. one on macOS) to 'net' category, i.e. rename them to net.ifconfig, this will require also moving all netstat.* on macOS and solaris to 'net' as well. I don't insist on it, though. Good point, I made those changes. > Changes looks OK to me although i have one question, in case of > Solaris you use explicit path to ifconfig(ifconfig.app=/sbin/ifconfig). > Does Solaris by default doesn't set the /sbin folder to user's 'PATH' > environment variable ? That's right, /sbin is not on the PATH on the Solaris machines of the test farm, which can be confirmed under the 'env' section of the environment information output. Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234964/webrev.01/ Regards, Julia From vladimir.x.ivanov at oracle.com Mon Dec 2 14:57:00 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 2 Dec 2019 17:57:00 +0300 Subject: [14] RFR (S): 8234923: Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance In-Reply-To: References: <7d4c2ab1-f8ec-8ccc-a442-8401a048b353@oracle.com> Message-ID: <0e177195-9e3e-661e-5dd0-e613f02747c1@oracle.com> Thank you, John. Best regards, Vladimir Ivanov On 30.11.2019 02:30, John Rose wrote: > Reviewed. > >> On Nov 29, 2019, at 7:55 AM, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8234923/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8234923 > From martin.doerr at sap.com Mon Dec 2 15:12:58 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 2 Dec 2019 15:12:58 +0000 Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Message-ID: Hi, I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport): https://bugs.openjdk.java.net/browse/JDK-8220348 Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer. jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted). However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default. I found such issues in the following files: src/java.prefs/windows/native/libprefs/WindowsPreferences.c src/java.security.jgss/share/native/libj2gss/GSSLibStub.c I suggest to use __declspec(align(8)) there. Webrev: http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/ Please review. I think using 8 byte alignment is not a disadvantage for 64 bit. I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix. Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack? Best regards, Martin From coleen.phillimore at oracle.com Mon Dec 2 16:52:54 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 2 Dec 2019 11:52:54 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <1263a30d-a04a-b821-d110-69ba52f1e1f7@oracle.com> (resending to all the lists) Hi, I've looked at the hotspot code again, and it looks good.? Nice work, Harold and Vincente! Coleen On 11/27/19 11:37 PM, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and > more! Must of the code has been reviewed but there have been some > changes since reviewers saw it. Also this is the first time an > integral webrev is sent out for review. Last changes on top of my mind > since last review iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as > a reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from > the record components, then it is considered the canonical > constructor. And any canonical constructor should satisfy a set of > restrictions, see section 8.10.4 Record Constructor Declarations of > the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not > explicitly invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes > mentioned before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection > and serialization, > > TIA, > Vicente > > [1] > http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From bob.vandette at oracle.com Mon Dec 2 17:13:30 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 2 Dec 2019 12:13:30 -0500 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> Message-ID: <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> Sorry for the delay in responding. See comments below: > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: >> Hi, >> >> Could I please get reviews of these core-libs, Linux-only, changes to >> the Metrics subsystem? This patch implements cgroupv2 support for >> Metrics which are currently cgroupv1-only. Fedora 31 switched to >> cgroupv2 by default so it's time to get OpenJDK recognize it. >> >> Note that a couple of metrics are no longer supported with cgroupv2. >> Most notably (not an exhaustive list, though): >> >> Metrics.getKernel*() family of methods. >> Metrics.getTcp*() family of methods. >> Metrics.getBlkIO*() family of methods. >> Metrics.isMemoryOOMKillEnabled() >> >> A couple of open questions with regards to that: >> >> 1) >> Most API docs of Metrics make no distiction between "unlimited" and >> "not supported", both returning -1 for longs, for example. This is a >> problem, because output of "java -XshowSettings:system -version" will >> not distinguish between unlimited and not supported metrics. Would it >> be acceptable to change the API to distinguish those cases so that >> LauncherHelper could display them appropriately? >> >> 2) >> How should we deal with "not supported" for booleans/arrays, etc.? >> Would it make sense to return record objects from the Metrics API so >> that this could be dealt with? E.g. >> >> Metrics m = ... >> MetricResult result = m.getCpuSetCpus(); >> switch(result.getType()) { >> case NOT_SUPPORTED: /* do something */; break; >> case SUPPORTED: int[] val = result.get(); break; >> ... >> } >> >> I'm bringing this up, because the proposed patch doesn't deal with the >> above open questions as of yet. With that being said, it's mostly >> identical to the proposed hotspot changes in [1]. For issue 1 and 2 ? I wonder if we should change the API to throw UnsupportedOperationException for those methods that are not available. This exception is used quite a lot in the java/nio and java/net packages for dealing with functionality not available on a host platform. As an alternate suggestion, we already return -2 for "not supported" for most APIs in the hotspot implementation. We could use this for non boolean values in the Metrics API. For boolean values, we could change the API to return ?Boolean?. A null return would signify not implemented. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 >> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html Should we check to make sure that there are no mixed cgroupv1 and cgroupv2 mounted subsystems since you are not supporting mixing. http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html It looks looks like there may be alternate ways of reporting some of the metrics that you have classified as RETVAL_NOT_SUPPORTED. BlkIOServicedCount (io.stat) KernelMemory (memory.stat) TcpMemory (memory.stat) You could try the same trick for getMemoryAndSwapMaxUsage which keeps track of the highest returned value. for the benefit of other reviewers, you should provide links to the cgroupv1 and v2 docs. https://www.kernel.org/doc/Documentation/cgroup-v2.txt >> Testing: jdk/submit and platform docker tests on Linux x86_64 (with >> hybrid hierarchy, docker/podman) and on Linux x86_64 with unified >> hierarchy (podman only). >> >> Thoughts? Suggestions? Do you think we should check the docker version being used for the tests to make sure it supports cgroupv2? I assume a fairly recent version is required to work with cgroupv2. Bob. > > Ping? > >> Thanks, >> Severin >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html > From henry.jen at oracle.com Mon Dec 2 17:25:33 2019 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 2 Dec 2019 09:25:33 -0800 Subject: JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. As I understand it, the argument validation is done in a later stage after calling JLI_Launch. Cheers, Henry > On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > > On 20/11/2019 19:42, Nikola Grcevski wrote: >> : >> >> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >> > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > -Alan From sgehwolf at redhat.com Mon Dec 2 19:03:04 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Dec 2019 20:03:04 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> Message-ID: <957d74add1eabc8a963b218b98e6350741397b31.camel@redhat.com> Hi Bob, On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: > Sorry for the delay in responding. See comments below: Thanks very much for taking a look at this! > > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: > > > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get reviews of these core-libs, Linux-only, changes to > > > the Metrics subsystem? This patch implements cgroupv2 support for > > > Metrics which are currently cgroupv1-only. Fedora 31 switched to > > > cgroupv2 by default so it's time to get OpenJDK recognize it. > > > > > > Note that a couple of metrics are no longer supported with cgroupv2. > > > Most notably (not an exhaustive list, though): > > > > > > Metrics.getKernel*() family of methods. > > > Metrics.getTcp*() family of methods. > > > Metrics.getBlkIO*() family of methods. > > > Metrics.isMemoryOOMKillEnabled() > > > > > > A couple of open questions with regards to that: > > > > > > 1) > > > Most API docs of Metrics make no distiction between "unlimited" and > > > "not supported", both returning -1 for longs, for example. This is a > > > problem, because output of "java -XshowSettings:system -version" will > > > not distinguish between unlimited and not supported metrics. Would it > > > be acceptable to change the API to distinguish those cases so that > > > LauncherHelper could display them appropriately? > > > > > > 2) > > > How should we deal with "not supported" for booleans/arrays, etc.? > > > Would it make sense to return record objects from the Metrics API so > > > that this could be dealt with? E.g. > > > > > > Metrics m = ... > > > MetricResult result = m.getCpuSetCpus(); > > > switch(result.getType()) { > > > case NOT_SUPPORTED: /* do something */; break; > > > case SUPPORTED: int[] val = result.get(); break; > > > ... > > > } > > > > > > I'm bringing this up, because the proposed patch doesn't deal with the > > > above open questions as of yet. With that being said, it's mostly > > > identical to the proposed hotspot changes in [1]. > > For issue 1 and 2 ? > > I wonder if we should change the API to throw UnsupportedOperationException for those methods > that are not available. This exception is used quite a lot in the java/nio and java/net packages > for dealing with functionality not available on a host platform. > As an alternate suggestion, we already return -2 for "not supported" for most APIs in the hotspot > implementation. We could use this for non boolean values in the Metrics API. For boolean > values, we could change the API to return ?Boolean?. A null return would signify not > implemented. I'd be fine with either way. We just need to pick one. Should I go ahead with UnsupportedOperationException? > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html > > Should we check to make sure that there are no mixed cgroupv1 and cgroupv2 mounted subsystems since > you are not supporting mixing. I'm not sure what you mean. The kernel won't allow for controllers to be used by cgroupv1 *and* cgroupv2 at the same time. Each controller would have to be assigned to a control hierarchy (v1 or v2)[1]. If you mean hybrid, that's basically cgroups v1. The factory will look at the system and detect the version in use: cgroups v1 xor cgroups v2. > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html > > It looks looks like there may be alternate ways of reporting some of the metrics that you have classified as RETVAL_NOT_SUPPORTED. > > BlkIOServicedCount (io.stat) > KernelMemory (memory.stat) > TcpMemory (memory.stat) Could you be more specific, please? What exaclty do you have in mind for KernelMemory from memory.stat? Same for TcpMemory. For BlkIOServicedCount do you mean calculating the sum of all rios+wios for any device? Something else? > You could try the same trick for getMemoryAndSwapMaxUsage which keeps track of the highest returned value. Sure, will do if you insist. I'll note that this is a hack and if getMemoryUsage() is never called, it will be the same as getMemoryUsage() - provided I'll add a call to getMemoryUsage() from getMemoryMaxUsage(). Either way, the value returned is most likely wrong and I'm not a huge fan of it, TBH. > for the benefit of other reviewers, you should provide links to the cgroupv1 and v2 docs. > > https://www.kernel.org/doc/Documentation/cgroup-v2.txt > > > > Testing: jdk/submit and platform docker tests on Linux x86_64 (with > > > hybrid hierarchy, docker/podman) and on Linux x86_64 with unified > > > hierarchy (podman only). > > > > > > Thoughts? Suggestions? > > Do you think we should check the docker version being used for the tests to make sure it > supports cgroupv2? I assume a fairly recent version is required to work with cgroupv2. I don't think that will be needed. The container engine won't start if cgroups v2 isn't supported. So we can be sure that if docker is running, it's either going to be on cgroups v2 or cgroups v1. In both cases the right set of tests will run. Does that make sense? Thanks, Severin > Bob. [1] https://lists.freedesktop.org/archives/systemd-devel/2017-November/039754.html > > > > Ping? > > > > > Thanks, > > > Severin > > > > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html From philip.race at oracle.com Mon Dec 2 19:07:38 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 2 Dec 2019 11:07:38 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <5f88f4a4-4019-db9e-16b1-0efdd9ff0590@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> <5DDDD8F9.3060906@oracle.com> <5f88f4a4-4019-db9e-16b1-0efdd9ff0590@oracle.com> Message-ID: <52a2cb27-2b47-e789-3cca-1ee80b6513bf@oracle.com> This makes it very difficult to do more than a cursory re-review. There is one thing I just spotted. I believe these two scripts http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jdk/tools/jpackage/test_jpackage.sh.html http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jdk/tools/jpackage/run_tests.sh.html Should not be part of what is pushed. They should be removed from the webrev. -phil. On 11/27/19 6:07 AM, Andy Herrick wrote: > > yes - The attempted incremental patch is not much use.? The source > files were moved several times, and despite using "hg addremove -s > 60", many of the files show as a remove and a new file. > > /Andy > > > On 11/26/2019 9:01 PM, Philip Race wrote: >> > I believe otherwise it is an accurate incremental webrev of the >> jpackage changes since EA-5. >> >> It is also not very incremental. >> * >> *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java >> >> is definitely not "new" ... >> >> -phil. >> >> On 11/26/19, 2:17 PM, Andy Herrick wrote: >>> yes,? this incremental webrev contains the JNLPConverter code, which >>> it should not. >>> >>> I believe otherwise it is an accurate incremental webrev of the >>> jpackage changes since EA-5. >>> >>> /Andy >>> >>> On 11/26/2019 4:53 PM, Phil Race wrote: >>>> Andy, >>>> >>>> I am puzzled by what I see here >>>> > The webrev at [3] shows the changes since EA-06 (Build >>>> 13-jpackage+1-49 ) up to the current point. >>>> >>>> > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>> >>>> This includes the JNLPConverter which isn't what I expected to see and >>>> (correctly) isn't in the cumulative webrev .... >>>> >>>> Since [3] seemed like the most obvious thing to do a review of the >>>> recent >>>> changes I'd like to be sure it has the correct content and I am not >>>> sure it does ... >>>> >>>> -phil. >>>> >>>> On 11/26/19 1:36 PM, Kevin Rushforth wrote: >>>>> This all looks good. >>>>> >>>>> +1 >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>>>>> (adding build-dev) >>>>>> >>>>>> Build changes look good. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2019-11-20 09:37, Andy Herrick wrote: >>>>>>> I posted new composite webrev [7], and git patch [8] after >>>>>>> pushing fix for JDK-8234402 [6]. >>>>>>> >>>>>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>>>>> >>>>>>> [8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>>>>> >>>>>>> /Andy >>>>>>> >>>>>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>>>>> applied it, and verified that it is the same as what is in the >>>>>>>> JDK-8200758-branch branch of the sandbox. It builds and runs >>>>>>>> fine for me. >>>>>>>> >>>>>>>> I ran jcheck and it found the following three files with >>>>>>>> whitespace errors that will need to be fixed before you push: >>>>>>>> >>>>>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>>>>> Trailing whitespace >>>>>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>>>>> Trailing whitespace >>>>>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: >>>>>>>> Trailing whitespace >>>>>>>> >>>>>>>> The second of these will go away with the fix for JDK-8234402 >>>>>>>> [6], so you don't need to do anything there. Once the fix for >>>>>>>> JDK-8234402 is pushed to sandbox, I presume you will update the >>>>>>>> webrev, right? >>>>>>>> >>>>>>>> Pending the fix for JDK-8234402 and the needed white-space >>>>>>>> fixes, this is a +1 from me (although I am not a jdk Project >>>>>>>> Reviewer, so you will need at least one review from someone who >>>>>>>> is). >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> [5] >>>>>>>> http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>>>>> >>>>>>>> >>>>>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>>>>> Please review? changes for [1] which is the implementation bug >>>>>>>>> for JEP-343. >>>>>>>>> >>>>>>>>> The webrev at [2] is the total cumulative webrev of changes >>>>>>>>> for the jpackage tool, currently in the JDK-8200758-branch >>>>>>>>> branch of the open sandbox repository. >>>>>>>>> >>>>>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>>>>> >>>>>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>>>>> >>>>>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>>>>> >>>>>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>>>>> >>>>>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>>>>> >>>>>>>>> [4] http://jdk.java.net/jpackage/ >>>>>>>>> >>>>>>>> >>>>> >>>> From bob.vandette at oracle.com Mon Dec 2 19:26:14 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 2 Dec 2019 14:26:14 -0500 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <957d74add1eabc8a963b218b98e6350741397b31.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <957d74add1eabc8a963b218b98e6350741397b31.camel@redhat.com> Message-ID: <93419693-D550-422D-8417-46A375DBA8A2@oracle.com> > On Dec 2, 2019, at 2:03 PM, Severin Gehwolf wrote: > > Hi Bob, > > On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: >> Sorry for the delay in responding. See comments below: > > Thanks very much for taking a look at this! > >>> On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: >>> >>> On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could I please get reviews of these core-libs, Linux-only, changes to >>>> the Metrics subsystem? This patch implements cgroupv2 support for >>>> Metrics which are currently cgroupv1-only. Fedora 31 switched to >>>> cgroupv2 by default so it's time to get OpenJDK recognize it. >>>> >>>> Note that a couple of metrics are no longer supported with cgroupv2. >>>> Most notably (not an exhaustive list, though): >>>> >>>> Metrics.getKernel*() family of methods. >>>> Metrics.getTcp*() family of methods. >>>> Metrics.getBlkIO*() family of methods. >>>> Metrics.isMemoryOOMKillEnabled() >>>> >>>> A couple of open questions with regards to that: >>>> >>>> 1) >>>> Most API docs of Metrics make no distiction between "unlimited" and >>>> "not supported", both returning -1 for longs, for example. This is a >>>> problem, because output of "java -XshowSettings:system -version" will >>>> not distinguish between unlimited and not supported metrics. Would it >>>> be acceptable to change the API to distinguish those cases so that >>>> LauncherHelper could display them appropriately? >>>> >>>> 2) >>>> How should we deal with "not supported" for booleans/arrays, etc.? >>>> Would it make sense to return record objects from the Metrics API so >>>> that this could be dealt with? E.g. >>>> >>>> Metrics m = ... >>>> MetricResult result = m.getCpuSetCpus(); >>>> switch(result.getType()) { >>>> case NOT_SUPPORTED: /* do something */; break; >>>> case SUPPORTED: int[] val = result.get(); break; >>>> ... >>>> } >>>> >>>> I'm bringing this up, because the proposed patch doesn't deal with the >>>> above open questions as of yet. With that being said, it's mostly >>>> identical to the proposed hotspot changes in [1]. >> >> For issue 1 and 2 ? >> >> I wonder if we should change the API to throw UnsupportedOperationException for those methods >> that are not available. This exception is used quite a lot in the java/nio and java/net packages >> for dealing with functionality not available on a host platform. > >> As an alternate suggestion, we already return -2 for "not supported" for most APIs in the hotspot >> implementation. We could use this for non boolean values in the Metrics API. For boolean >> values, we could change the API to return ?Boolean?. A null return would signify not >> implemented. > > I'd be fine with either way. We just need to pick one. Should I go > ahead with UnsupportedOperationException? The change to use -2 and Boolean is less intrusive and more consistent with the hotspot implementation, so I?d pick that one. > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 >>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ >>>> >> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html >> >> Should we check to make sure that there are no mixed cgroupv1 and cgroupv2 mounted subsystems since >> you are not supporting mixing. > > I'm not sure what you mean. The kernel won't allow for controllers to > be used by cgroupv1 *and* cgroupv2 at the same time. Each controller > would have to be assigned to a control hierarchy (v1 or v2)[1]. If you > mean hybrid, that's basically cgroups v1. The factory will look at the > system and detect the version in use: cgroups v1 xor cgroups v2. The memory subsystem for example can?t be assigned to both v1 and v2 controllers but the memory subsystem can be assigned to v1 and the cpu subsystem can be assigned to v2, right? That?s the case I?m concerned about. > >> >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html >> >> It looks looks like there may be alternate ways of reporting some of the metrics that you have classified as RETVAL_NOT_SUPPORTED. >> >> BlkIOServicedCount (io.stat) >> KernelMemory (memory.stat) I was thinking of memory.stat (file+kernel_stack+slab) assuming these aren?t account for in user memory totals. >> TcpMemory (memory.stat) I was thinking of memory.stat (sock) > > Could you be more specific, please? What exaclty do you have in mind > for KernelMemory from memory.stat? Same for TcpMemory. > > For BlkIOServicedCount do you mean calculating the sum of all rios+wios > for any device? Something else? Yes, that?s what I had in mind but since it?s a single value for all I/O, you?d have to sum up all devices. > >> You could try the same trick for getMemoryAndSwapMaxUsage which keeps track of the highest returned value. > > Sure, will do if you insist. I'll note that this is a hack and if > getMemoryUsage() is never called, it will be the same as > getMemoryUsage() - provided I'll add a call to getMemoryUsage() from > getMemoryMaxUsage(). Either way, the value returned is most likely > wrong and I'm not a huge fan of it, TBH. I agree it?s a hack so let?s just make both unsupported. > >> for the benefit of other reviewers, you should provide links to the cgroupv1 and v2 docs. >> >> https://www.kernel.org/doc/Documentation/cgroup-v2.txt >> >>>> Testing: jdk/submit and platform docker tests on Linux x86_64 (with >>>> hybrid hierarchy, docker/podman) and on Linux x86_64 with unified >>>> hierarchy (podman only). >>>> >>>> Thoughts? Suggestions? >> >> Do you think we should check the docker version being used for the tests to make sure it >> supports cgroupv2? I assume a fairly recent version is required to work with cgroupv2. > > I don't think that will be needed. The container engine won't start if > cgroups v2 isn't supported. So we can be sure that if docker is > running, it's either going to be on cgroups v2 or cgroups v1. In both > cases the right set of tests will run. Does that make sense? I?m just thinking of a situation where a kernel is configured to use cgroupv2 and a developer wants to run the jtreg tests. It would be good to skip the container tests if docker can?t run on it. We have a check to see if docker can run before running docker tests ?using docker ps" but AFAIK, it doesn?t test starting a container or verify the version. Bob. > > Thanks, > Severin > >> Bob. > > [1] https://lists.freedesktop.org/archives/systemd-devel/2017-November/039754.html >> >> >>> Ping? >>> >>>> Thanks, >>>> Severin >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html > From Nikola.Grcevski at microsoft.com Mon Dec 2 19:34:00 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Mon, 2 Dec 2019 19:34:00 +0000 Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: Hi Alan and Henry, Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. I created a webrev here for the change, including a new test in Arrrghs.java: https://grcevski.github.io/JDK-8234076/webrev/ I copied the test validation and assertion style of other code inside the test class. Please let me know if you have any comments or suggestions. Thanks again! -----Original Message----- From: Henry Jen Sent: December 2, 2019 12:26 PM To: Alan Bateman Cc: Nikola Grcevski ; core-libs-dev at openjdk.java.net Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. As I understand it, the argument validation is done in a later stage after calling JLI_Launch. Cheers, Henry > On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > > On 20/11/2019 19:42, Nikola Grcevski wrote: >> : >> >> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >> > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > -Alan From sgehwolf at redhat.com Mon Dec 2 20:33:39 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Dec 2019 21:33:39 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <93419693-D550-422D-8417-46A375DBA8A2@oracle.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <957d74add1eabc8a963b218b98e6350741397b31.camel@redhat.com> <93419693-D550-422D-8417-46A375DBA8A2@oracle.com> Message-ID: <4e95bd8bbbe4c33470dc921d30567b96060d91bb.camel@redhat.com> On Mon, 2019-12-02 at 14:26 -0500, Bob Vandette wrote: > > On Dec 2, 2019, at 2:03 PM, Severin Gehwolf wrote: > > > > Hi Bob, > > > > On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: > > > Sorry for the delay in responding. See comments below: > > > > Thanks very much for taking a look at this! > > > > > > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: > > > > > > > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Could I please get reviews of these core-libs, Linux-only, changes to > > > > > the Metrics subsystem? This patch implements cgroupv2 support for > > > > > Metrics which are currently cgroupv1-only. Fedora 31 switched to > > > > > cgroupv2 by default so it's time to get OpenJDK recognize it. > > > > > > > > > > Note that a couple of metrics are no longer supported with cgroupv2. > > > > > Most notably (not an exhaustive list, though): > > > > > > > > > > Metrics.getKernel*() family of methods. > > > > > Metrics.getTcp*() family of methods. > > > > > Metrics.getBlkIO*() family of methods. > > > > > Metrics.isMemoryOOMKillEnabled() > > > > > > > > > > A couple of open questions with regards to that: > > > > > > > > > > 1) > > > > > Most API docs of Metrics make no distiction between "unlimited" and > > > > > "not supported", both returning -1 for longs, for example. This is a > > > > > problem, because output of "java -XshowSettings:system -version" will > > > > > not distinguish between unlimited and not supported metrics. Would it > > > > > be acceptable to change the API to distinguish those cases so that > > > > > LauncherHelper could display them appropriately? > > > > > > > > > > 2) > > > > > How should we deal with "not supported" for booleans/arrays, etc.? > > > > > Would it make sense to return record objects from the Metrics API so > > > > > that this could be dealt with? E.g. > > > > > > > > > > Metrics m = ... > > > > > MetricResult result = m.getCpuSetCpus(); > > > > > switch(result.getType()) { > > > > > case NOT_SUPPORTED: /* do something */; break; > > > > > case SUPPORTED: int[] val = result.get(); break; > > > > > ... > > > > > } > > > > > > > > > > I'm bringing this up, because the proposed patch doesn't deal with the > > > > > above open questions as of yet. With that being said, it's mostly > > > > > identical to the proposed hotspot changes in [1]. > > > > > > For issue 1 and 2 ? > > > > > > I wonder if we should change the API to throw UnsupportedOperationException for those methods > > > that are not available. This exception is used quite a lot in the java/nio and java/net packages > > > for dealing with functionality not available on a host platform. > > > As an alternate suggestion, we already return -2 for "not supported" for most APIs in the hotspot > > > implementation. We could use this for non boolean values in the Metrics API. For boolean > > > values, we could change the API to return ?Boolean?. A null return would signify not > > > implemented. > > > > I'd be fine with either way. We just need to pick one. Should I go > > ahead with UnsupportedOperationException? > > The change to use -2 and Boolean is less intrusive and more consistent with the hotspot > implementation, so I?d pick that one. OK. I'm travelling currently, so expect a bit of delay for the update. > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ > > > > > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html > > > > > > Should we check to make sure that there are no mixed cgroupv1 and cgroupv2 mounted subsystems since > > > you are not supporting mixing. > > > > I'm not sure what you mean. The kernel won't allow for controllers to > > be used by cgroupv1 *and* cgroupv2 at the same time. Each controller > > would have to be assigned to a control hierarchy (v1 or v2)[1]. If you > > mean hybrid, that's basically cgroups v1. The factory will look at the > > system and detect the version in use: cgroups v1 xor cgroups v2. > > The memory subsystem for example can?t be assigned to both v1 and v2 controllers but the > memory subsystem can be assigned to v1 and the cpu subsystem can be assigned to > v2, right? > > That?s the case I?m concerned about. I see. What exactly would you want to happen if mixing is being detected? Should it return null (no metrics)? I can do that. TBH, I'm not sure what would happen currently (prior this patch). There seems to be some inconsistency how hotspot/core libs are dealing with this. For hotspot, if any one of the controllers is not available, no controller is being used. That's different to how core libs works right now. Any thoughts about this? > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html > > > > > > It looks looks like there may be alternate ways of reporting some of the metrics that you have classified as RETVAL_NOT_SUPPORTED. > > > > > > BlkIOServicedCount (io.stat) > > > KernelMemory (memory.stat) > I was thinking of memory.stat (file+kernel_stack+slab) assuming these > aren?t account for in user memory totals. It's not clear whether they are. So this seems to be getting into some guesswork, which I'd rather avoid. The memory controller mentions this: """" While not completely water-tight, all major memory usages by a given cgroup are tracked so that the total memory consumption can be accounted and controlled to a reasonable extent. Currently, the following types of memory usages are tracked. - Userland memory - page cache and anonymous memory. - Kernel data structures such as dentries and inodes. - TCP socket buffers. The above list may expand in the future for better coverage. """" Given the above and the description of 'slab' for memory.stat it's not clear there is overlap. > > > TcpMemory (memory.stat) > I was thinking of memory.stat (sock) OK. Sure. > > Could you be more specific, please? What exaclty do you have in mind > > for KernelMemory from memory.stat? Same for TcpMemory. > > > > For BlkIOServicedCount do you mean calculating the sum of all rios+wios > > for any device? Something else? > Yes, that?s what I had in mind but since it?s a single value for all I/O, you?d have to > sum up all devices. OK. Let's do that then. > > > You could try the same trick for getMemoryAndSwapMaxUsage which keeps track of the highest returned value. > > > > Sure, will do if you insist. I'll note that this is a hack and if > > getMemoryUsage() is never called, it will be the same as > > getMemoryUsage() - provided I'll add a call to getMemoryUsage() from > > getMemoryMaxUsage(). Either way, the value returned is most likely > > wrong and I'm not a huge fan of it, TBH. > > I agree it?s a hack so let?s just make both unsupported. Sounds good! > > > for the benefit of other reviewers, you should provide links to the cgroupv1 and v2 docs. > > > > > > https://www.kernel.org/doc/Documentation/cgroup-v2.txt > > > > > > > > Testing: jdk/submit and platform docker tests on Linux x86_64 (with > > > > > hybrid hierarchy, docker/podman) and on Linux x86_64 with unified > > > > > hierarchy (podman only). > > > > > > > > > > Thoughts? Suggestions? > > > > > > Do you think we should check the docker version being used for the tests to make sure it > > > supports cgroupv2? I assume a fairly recent version is required to work with cgroupv2. > > > > I don't think that will be needed. The container engine won't start if > > cgroups v2 isn't supported. So we can be sure that if docker is > > running, it's either going to be on cgroups v2 or cgroups v1. In both > > cases the right set of tests will run. Does that make sense? > > I?m just thinking of a situation where a kernel is configured to use cgroupv2 > and a developer wants to run the jtreg tests. It would be good to skip the > container tests if docker can?t run on it. We have a check to see if docker can > run before running docker tests ?using docker ps" but AFAIK, it doesn?t test starting > a container or verify the version. Right. My thinking is that "using docker ps" won't work on cgroups v2 if docker isn't supporting it in the first place. There is also some logic to skip the test if building the container fails: http://hg.openjdk.java.net/jdk/jdk/file/d8b5e32ffa2f/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java#l178 Assuming that docker builds pass again gives one reasonable assurance that cgroups (whatever version) is supported. I'm not a great fan to have some arbitrary docker version check which would be useless in the podman case anyway. In all likelihood it would be covered by current logic anyway. More thoughts? Thanks, Severin > Bob. > > > > Thanks, > > Severin > > > > > Bob. > > > > [1] https://lists.freedesktop.org/archives/systemd-devel/2017-November/039754.html > > > > > > > Ping? > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html From john.r.rose at oracle.com Mon Dec 2 20:42:20 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 2 Dec 2019 12:42:20 -0800 Subject: New candidate JEP: 370: Foreign-Memory Access API In-Reply-To: References: <20191125172756.29B2330F46E@eggemoggin.niobe.net> <34b5594d-0a56-c7fb-0906-c585121d6284@oracle.com> <1e88cab1-a6c7-454b-6cc5-6747c67a80cb@oracle.com> <45C77E27-AA9A-4E81-858C-6AE52B3F65BF@oracle.com> Message-ID: <15EA1BD7-0C88-4D68-95B3-00AC29E3BE58@oracle.com> On Dec 1, 2019, at 8:07 AM, David Lloyd wrote: > > Okay, anyway I'm glad that I'm not the first person to have thought of > these use cases. The API looks good! Thanks for reviewing and commenting! We need to ?shake out? our designs exactly like that. ? John From bob.vandette at oracle.com Mon Dec 2 21:06:30 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 2 Dec 2019 16:06:30 -0500 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <4e95bd8bbbe4c33470dc921d30567b96060d91bb.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <957d74add1eabc8a963b218b98e6350741397b31.camel@redhat.com> <93419693-D550-422D-8417-46A375DBA8A2@oracle.com> <4e95bd8bbbe4c33470dc921d30567b96060d91bb.camel@redhat.com> Message-ID: > On Dec 2, 2019, at 3:33 PM, Severin Gehwolf wrote: > > On Mon, 2019-12-02 at 14:26 -0500, Bob Vandette wrote: >>> On Dec 2, 2019, at 2:03 PM, Severin Gehwolf wrote: >>> >>> Hi Bob, >>> >>> On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: >>>> Sorry for the delay in responding. See comments below: >>> >>> Thanks very much for taking a look at this! >>> >>>>> On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: >>>>> >>>>> On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Could I please get reviews of these core-libs, Linux-only, changes to >>>>>> the Metrics subsystem? This patch implements cgroupv2 support for >>>>>> Metrics which are currently cgroupv1-only. Fedora 31 switched to >>>>>> cgroupv2 by default so it's time to get OpenJDK recognize it. >>>>>> >>>>>> Note that a couple of metrics are no longer supported with cgroupv2. >>>>>> Most notably (not an exhaustive list, though): >>>>>> >>>>>> Metrics.getKernel*() family of methods. >>>>>> Metrics.getTcp*() family of methods. >>>>>> Metrics.getBlkIO*() family of methods. >>>>>> Metrics.isMemoryOOMKillEnabled() >>>>>> >>>>>> A couple of open questions with regards to that: >>>>>> >>>>>> 1) >>>>>> Most API docs of Metrics make no distiction between "unlimited" and >>>>>> "not supported", both returning -1 for longs, for example. This is a >>>>>> problem, because output of "java -XshowSettings:system -version" will >>>>>> not distinguish between unlimited and not supported metrics. Would it >>>>>> be acceptable to change the API to distinguish those cases so that >>>>>> LauncherHelper could display them appropriately? >>>>>> >>>>>> 2) >>>>>> How should we deal with "not supported" for booleans/arrays, etc.? >>>>>> Would it make sense to return record objects from the Metrics API so >>>>>> that this could be dealt with? E.g. >>>>>> >>>>>> Metrics m = ... >>>>>> MetricResult result = m.getCpuSetCpus(); >>>>>> switch(result.getType()) { >>>>>> case NOT_SUPPORTED: /* do something */; break; >>>>>> case SUPPORTED: int[] val = result.get(); break; >>>>>> ... >>>>>> } >>>>>> >>>>>> I'm bringing this up, because the proposed patch doesn't deal with the >>>>>> above open questions as of yet. With that being said, it's mostly >>>>>> identical to the proposed hotspot changes in [1]. >>>> >>>> For issue 1 and 2 ? >>>> >>>> I wonder if we should change the API to throw UnsupportedOperationException for those methods >>>> that are not available. This exception is used quite a lot in the java/nio and java/net packages >>>> for dealing with functionality not available on a host platform. >>>> As an alternate suggestion, we already return -2 for "not supported" for most APIs in the hotspot >>>> implementation. We could use this for non boolean values in the Metrics API. For boolean >>>> values, we could change the API to return ?Boolean?. A null return would signify not >>>> implemented. >>> >>> I'd be fine with either way. We just need to pick one. Should I go >>> ahead with UnsupportedOperationException? >> >> The change to use -2 and Boolean is less intrusive and more consistent with the hotspot >> implementation, so I?d pick that one. > > OK. I'm travelling currently, so expect a bit of delay for the update. No prob. > >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 >>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ >>>>>> >>>> >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html >>>> >>>> Should we check to make sure that there are no mixed cgroupv1 and cgroupv2 mounted subsystems since >>>> you are not supporting mixing. >>> >>> I'm not sure what you mean. The kernel won't allow for controllers to >>> be used by cgroupv1 *and* cgroupv2 at the same time. Each controller >>> would have to be assigned to a control hierarchy (v1 or v2)[1]. If you >>> mean hybrid, that's basically cgroups v1. The factory will look at the >>> system and detect the version in use: cgroups v1 xor cgroups v2. >> >> The memory subsystem for example can?t be assigned to both v1 and v2 controllers but the >> memory subsystem can be assigned to v1 and the cpu subsystem can be assigned to >> v2, right? >> >> That?s the case I?m concerned about. > > I see. What exactly would you want to happen if mixing is being > detected? Should it return null (no metrics)? I can do that. It would be good to provide a warning and return null. > > TBH, I'm not sure what would happen currently (prior this patch). There > seems to be some inconsistency how hotspot/core libs are dealing with > this. For hotspot, if any one of the controllers is not available, no > controller is being used. That's different to how core libs works right > now. > > Any thoughts about this? In order for Hotspot to implement container ergonomics it needs memory and the cpu* subsystems. The Metrics methods are merely informative so it can continue with as many subsystems it can find as long as the others return not available. > >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html >>>> >>>> It looks looks like there may be alternate ways of reporting some of the metrics that you have classified as RETVAL_NOT_SUPPORTED. >>>> >>>> BlkIOServicedCount (io.stat) >>>> KernelMemory (memory.stat) >> I was thinking of memory.stat (file+kernel_stack+slab) assuming these >> aren?t account for in user memory totals. > > It's not clear whether they are. So this seems to be getting into some > guesswork, which I'd rather avoid. The memory controller mentions this: > > """" > While not completely water-tight, all major memory usages by a given > cgroup are tracked so that the total memory consumption can be > accounted and controlled to a reasonable extent. Currently, the > following types of memory usages are tracked. > > - Userland memory - page cache and anonymous memory. > > - Kernel data structures such as dentries and inodes. > > - TCP socket buffers. > > The above list may expand in the future for better coverage. > """" > > Given the above and the description of 'slab' for memory.stat it's not > clear there is overlap. Rather than guessing, maybe some kernel source exploration might confirm the right files to use. Are there any kernel guys you know that can help? It seems pretty clear from the description that that kernel_stack and slab are kernel specific. > >>>> TcpMemory (memory.stat) >> I was thinking of memory.stat (sock) > > OK. Sure. > >>> Could you be more specific, please? What exaclty do you have in mind >>> for KernelMemory from memory.stat? Same for TcpMemory. >>> >>> For BlkIOServicedCount do you mean calculating the sum of all rios+wios >>> for any device? Something else? >> Yes, that?s what I had in mind but since it?s a single value for all I/O, you?d have to >> sum up all devices. > > OK. Let's do that then. > >>>> You could try the same trick for getMemoryAndSwapMaxUsage which keeps track of the highest returned value. >>> >>> Sure, will do if you insist. I'll note that this is a hack and if >>> getMemoryUsage() is never called, it will be the same as >>> getMemoryUsage() - provided I'll add a call to getMemoryUsage() from >>> getMemoryMaxUsage(). Either way, the value returned is most likely >>> wrong and I'm not a huge fan of it, TBH. >> >> I agree it?s a hack so let?s just make both unsupported. > > Sounds good! > >>>> for the benefit of other reviewers, you should provide links to the cgroupv1 and v2 docs. >>>> >>>> https://www.kernel.org/doc/Documentation/cgroup-v2.txt >>>> >>>>>> Testing: jdk/submit and platform docker tests on Linux x86_64 (with >>>>>> hybrid hierarchy, docker/podman) and on Linux x86_64 with unified >>>>>> hierarchy (podman only). >>>>>> >>>>>> Thoughts? Suggestions? >>>> >>>> Do you think we should check the docker version being used for the tests to make sure it >>>> supports cgroupv2? I assume a fairly recent version is required to work with cgroupv2. >>> >>> I don't think that will be needed. The container engine won't start if >>> cgroups v2 isn't supported. So we can be sure that if docker is >>> running, it's either going to be on cgroups v2 or cgroups v1. In both >>> cases the right set of tests will run. Does that make sense? >> >> I?m just thinking of a situation where a kernel is configured to use cgroupv2 >> and a developer wants to run the jtreg tests. It would be good to skip the >> container tests if docker can?t run on it. We have a check to see if docker can >> run before running docker tests ?using docker ps" but AFAIK, it doesn?t test starting >> a container or verify the version. > > Right. My thinking is that "using docker ps" won't work on cgroups v2 > if docker isn't supporting it in the first place. There is also some > logic to skip the test if building the container fails: > http://hg.openjdk.java.net/jdk/jdk/file/d8b5e32ffa2f/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java#l178 > > Assuming that docker builds pass again gives one reasonable assurance > that cgroups (whatever version) is supported. I'm not a great fan to > have some arbitrary docker version check which would be useless in the > podman case anyway. In all likelihood it would be covered by current > logic anyway. > > More thoughts? It looks like docker still can?t handle cgroups v2 so I take back my suggestion. I thought they?d be further along by now. It looks like Docker and Kubernetes are going to have early access support for cgroupsv2 early next year so we can take a look at doing some validation at that time. https://medium.com/nttlabs/cgroup-v2-596d035be4d7 Bob. > > Thanks, > Severin > >> Bob. >> >> >>> Thanks, >>> Severin >>> >>>> Bob. >>> >>> [1] https://lists.freedesktop.org/archives/systemd-devel/2017-November/039754.html >>>> >>>>> Ping? >>>>> >>>>>> Thanks, >>>>>> Severin >>>>>> >>>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html > From vicente.romero at oracle.com Mon Dec 2 21:07:39 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 2 Dec 2019 16:07:39 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <1824646f-00f5-13c0-0873-6ea6f04137c3@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <04ab170a-72a3-81e0-c38b-79b9a2533cd1@oracle.com> <3805c12d-d476-0f09-3344-a0f7e215c34b@oracle.com> <1824646f-00f5-13c0-0873-6ea6f04137c3@oracle.com> Message-ID: thanks Joe, Vicente On 12/2/19 1:17 AM, Joe Darcy wrote: > Hi Vicente, > > I took the liberty of adding the necessary directory-level jtreg > config files to enable the feature and updated the tests accordingly: > > ??? https://hg.openjdk.java.net/amber/amber/rev/c91826d62310 > > (The feature is enabled by default in for the langtools tests, but > disabled by default elsewhere.) > > HTH, > > -Joe > > On 11/29/2019 3:12 PM, Vicente Romero wrote: >> Hi Joe, >> >> All the tests that have an explicit -source 14 are that way because >> of, I think to remember, a bug in jtreg that doesn't expand the >> ${some.property} macro for those tests. I don't remember the details >> though >> >> Thanks, >> Vicente >> >> On 11/29/19 9:59 AM, Joe Darcy wrote: >>> Hi Vicente, >>> >>> Please change all uses of >>> >>> ??? @compile --enable-preview -source 14 >>> >>> in jtreg tags to to >>> >>> ??? @compile --enable-preview -source ${jdk.version} >>> >>> The former structure will spuriously fail when the JDK 14 -> 15 >>> transition occurs. >>> >>> Also, publishing delta-webrevs between iterations in additional to >>> full webrev would help track the incremental changes. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 11/28/2019 8:05 AM, Vicente Romero wrote: >>>> Hi again, >>>> >>>> Sorry but I realized that I forgot to remove some code on the >>>> compiler side. The code removed is small, before we were issuing an >>>> error if some serialization methods were declared as record >>>> members. That section was removed from the spec. I have prepared >>>> another iteration with this change at [1] >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] >>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ >>>> >>>> On 11/27/19 11:37 PM, Vicente Romero wrote: >>>>> Hi, >>>>> >>>>> Please review the code for the records feature at [1]. This webrev >>>>> includes all: APIs, runtime, compiler, serialization, javadoc, and >>>>> more! Must of the code has been reviewed but there have been some >>>>> changes since reviewers saw it. Also this is the first time an >>>>> integral webrev is sent out for review. Last changes on top of my >>>>> mind since last review iterations: >>>>> >>>>> On the compiler implementation: >>>>> - it has been adapted to the last version of the language spec >>>>> [2], as a reference the JVM spec is at [3]. This implied some >>>>> changes in determining if a user defined constructor is the >>>>> canonical or not. Now if a constructor is override-equivalent to a >>>>> signature derived from the record components, then it is >>>>> considered the canonical constructor. And any canonical >>>>> constructor should satisfy a set of restrictions, see section >>>>> 8.10.4 Record Constructor Declarations of the specification. >>>>> - It was also added a check to make sure that accessors are not >>>>> generic. >>>>> - And that the canonical constructor, if user defined, is not >>>>> explicitly invoking any other constructor. >>>>> - The list of forbidden record component names has also been updated. >>>>> - new error messages have been added >>>>> >>>>> APIs: >>>>> - there have been some API editing in java.lang.Record, >>>>> java.lang.runtime.ObjectMethods and >>>>> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >>>>> javax.lang.model (some visitors were added) >>>>> >>>>> On the JVM implementation: >>>>> - some logging capabilities have been added to classFileParser.cpp >>>>> to provide the reason for which the Record attribute has been ignored >>>>> >>>>> Reflection: >>>>> - there are several new changes to the implementation of >>>>> java.lang.reflect.RecordComponent apart from the spec changes >>>>> mentioned before. >>>>> >>>>> bug fixes in >>>>> - compiler >>>>> - serialization, >>>>> - JVM, etc >>>>> >>>>> As a reference the last iteration of the previous reviews can be >>>>> found at [4] under folders: compiler, hotspot_runtime, javadoc, >>>>> reflection and serialization, >>>>> >>>>> TIA, >>>>> Vicente >>>>> >>>>> [1] >>>>> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >>>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >>>>> [3] >>>>> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >>>>> [4] http://cr.openjdk.java.net/~vromero/records.review/ >>>>> >>>> >> From hannes.wallnoefer at oracle.com Mon Dec 2 21:13:50 2019 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 2 Dec 2019 22:13:50 +0100 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <0BAD6EC6-2DA0-4022-BC64-1673560FB7EA@oracle.com> Hi Vicente, I?ve looked at the Javadoc changes again, everything looks good to me. Hannes > Am 28.11.2019 um 05:37 schrieb Vicente Romero : > > Hi, > > Please review the code for the records feature at [1]. This webrev includes all: APIs, runtime, compiler, serialization, javadoc, and more! Must of the code has been reviewed but there have been some changes since reviewers saw it. Also this is the first time an integral webrev is sent out for review. Last changes on top of my mind since last review iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as a reference the JVM spec is at [3]. This implied some changes in determining if a user defined constructor is the canonical or not. Now if a constructor is override-equivalent to a signature derived from the record components, then it is considered the canonical constructor. And any canonical constructor should satisfy a set of restrictions, see section 8.10.4 Record Constructor Declarations of the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not explicitly invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of java.lang.reflect.RecordComponent apart from the spec changes mentioned before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and serialization, > > TIA, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > [3] http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From lois.foltan at oracle.com Mon Dec 2 21:56:24 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 2 Dec 2019 16:56:24 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <1263a30d-a04a-b821-d110-69ba52f1e1f7@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <1263a30d-a04a-b821-d110-69ba52f1e1f7@oracle.com> Message-ID: <300a8f8e-6db7-f73b-d212-c68f496c782d@oracle.com> I've looked over the hotspot code again as well.? Looks good, you have my review! Lois On 12/2/2019 11:52 AM, coleen.phillimore at oracle.com wrote: > (resending to all the lists) > > Hi, I've looked at the hotspot code again, and it looks good. Nice > work, Harold and Vincente! > > Coleen > > > On 11/27/19 11:37 PM, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> > From raffaello.giulietti at gmail.com Mon Dec 2 21:57:22 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 2 Dec 2019 22:57:22 +0100 Subject: request for sponsor: wavl based alternative to red-black TreeMap Message-ID: Hello, is anybody interested in sponsoring me on exploring a wavl tree implementation of TreeMap [1]? For some reason related to gmail, I'm not able to get messages targeted to the mailing list alone, so please cc: me as well. Greetings Raffaello (Here are some highlights of wavl trees: * worst case height when built without deletions: ~1.4404 lg n * worst case number of rotations for a deletion: 2 As a comparison, the same figures for red-black trees: * worst case height when built without deletions: ~2 lg n * worst case number of rotations for a deletion: 3 Other measures are like those of red-black trees or better.) ---- [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/063737.html From sergei.tsypanov at yandex.ru Mon Dec 2 23:20:47 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Tue, 03 Dec 2019 01:20:47 +0200 Subject: [JDK 8] Class.getName() slows down String concatenation chain Message-ID: <8997161575328847@iva8-3634a30a817d.qloud-c.yandex.net> Hello, recently I've run into an issue regarding String concatenation. This benchmark summarizes it: @OutputTimeUnit(TimeUnit.NANOSECONDS) public class BrokenConcatenationBenchmark { @Benchmark public String slow(Data data) { final Class clazz = data.clazz; return "class " + clazz.getName(); } @Benchmark public String fast(Data data) { final Class clazz = data.clazz; final String clazzName = clazz.getName(); return "class " + clazzName; } @State(Scope.Thread) public static class Data { final Class clazz = getClass(); @Setup public void setup() { //explicitly load name via native method Class.getName0() clazz.getName(); } } } On JDK 1.8.0_222 (OpenJDK 64-Bit Server VM, 25.222-b10) I've got the following results: Benchmark Mode Cnt Score Error Units BrokenConcatenationBenchmark.fast avgt 25 22,253 ? 0,962 ns/op BrokenConcatenationBenchmark.fast:?gc.alloc.rate avgt 25 9824,603 ? 400,088 MB/sec BrokenConcatenationBenchmark.fast:?gc.alloc.rate.norm avgt 25 240,000 ? 0,001 B/op BrokenConcatenationBenchmark.fast:?gc.churn.PS_Eden_Space avgt 25 9824,162 ? 397,745 MB/sec BrokenConcatenationBenchmark.fast:?gc.churn.PS_Eden_Space.norm avgt 25 239,994 ? 0,522 B/op BrokenConcatenationBenchmark.fast:?gc.churn.PS_Survivor_Space avgt 25 0,040 ? 0,011 MB/sec BrokenConcatenationBenchmark.fast:?gc.churn.PS_Survivor_Space.norm avgt 25 0,001 ? 0,001 B/op BrokenConcatenationBenchmark.fast:?gc.count avgt 25 3798,000 counts BrokenConcatenationBenchmark.fast:?gc.time avgt 25 2241,000 ms BrokenConcatenationBenchmark.slow avgt 25 54,316 ? 1,340 ns/op BrokenConcatenationBenchmark.slow:?gc.alloc.rate avgt 25 8435,703 ? 198,587 MB/sec BrokenConcatenationBenchmark.slow:?gc.alloc.rate.norm avgt 25 504,000 ? 0,001 B/op BrokenConcatenationBenchmark.slow:?gc.churn.PS_Eden_Space avgt 25 8434,983 ? 198,966 MB/sec BrokenConcatenationBenchmark.slow:?gc.churn.PS_Eden_Space.norm avgt 25 503,958 ? 1,000 B/op BrokenConcatenationBenchmark.slow:?gc.churn.PS_Survivor_Space avgt 25 0,127 ? 0,011 MB/sec BrokenConcatenationBenchmark.slow:?gc.churn.PS_Survivor_Space.norm avgt 25 0,008 ? 0,001 B/op BrokenConcatenationBenchmark.slow:?gc.count avgt 25 3789,000 counts BrokenConcatenationBenchmark.slow:?gc.time avgt 25 2245,000 ms This looks like an issue similar to JDK-8043677 [1], where an expression having side effect breaks optimization of new StringBuilder.append().append().toString() chain. But the code of Class.getName() itself does seem to have any side effects: ------------------------------------------ private transient String name; public String getName() { String name = this.name; if (name == null) { this.name = name = this.getName0(); } return name; } private native String getName0(); ------------------------------------------ The only suspicious thing here is a call to native method which happens in fact only once and its result is cached in the field of the class. In my benchmark I've explicitly cached it in setup method. I've expected branch predictor to figure out that at each benchmark invocation the actual value of this.name is never null and optimize the whole expression. However, while for the fast() I have this: @ 19 tsypanov.strings.benchmark.concatenation.BrokenConcatenationBenchmark::fast (30 bytes) force inline by CompileCommand @ 6 java.lang.Class::getName (18 bytes) inline (hot) @ 14 java.lang.Class::initClassName (0 bytes) native method @ 14 java.lang.StringBuilder:: (7 bytes) inline (hot) @ 19 java.lang.StringBuilder::append (8 bytes) inline (hot) @ 23 java.lang.StringBuilder::append (8 bytes) inline (hot) @ 26 java.lang.StringBuilder::toString (35 bytes) inline (hot) i.e. compiler is able to inline everything for slow() it is different: @ 19 tsypanov.strings.benchmark.concatenation.BrokenConcatenationBenchmark::slow (28 bytes) force inline by CompilerOracle @ 9 java.lang.StringBuilder:: (7 bytes) inline (hot) @ 3 java.lang.AbstractStringBuilder:: (12 bytes) inline (hot) @ 1 java.lang.Object:: (1 bytes) inline (hot) @ 14 java.lang.StringBuilder::append (8 bytes) inline (hot) @ 2 java.lang.AbstractStringBuilder::append (50 bytes) inline (hot) @ 10 java.lang.String::length (6 bytes) inline (hot) @ 21 java.lang.AbstractStringBuilder::ensureCapacityInternal (27 bytes) inline (hot) @ 17 java.lang.AbstractStringBuilder::newCapacity (39 bytes) inline (hot) @ 20 java.util.Arrays::copyOf (19 bytes) inline (hot) @ 11 java.lang.Math::min (11 bytes) (intrinsic) @ 14 java.lang.System::arraycopy (0 bytes) (intrinsic) @ 35 java.lang.String::getChars (62 bytes) inline (hot) @ 58 java.lang.System::arraycopy (0 bytes) (intrinsic) @ 18 java.lang.Class::getName (21 bytes) inline (hot) @ 11 java.lang.Class::getName0 (0 bytes) native method @ 21 java.lang.StringBuilder::append (8 bytes) inline (hot) @ 2 java.lang.AbstractStringBuilder::append (50 bytes) inline (hot) @ 10 java.lang.String::length (6 bytes) inline (hot) @ 21 java.lang.AbstractStringBuilder::ensureCapacityInternal (27 bytes) inline (hot) @ 17 java.lang.AbstractStringBuilder::newCapacity (39 bytes) inline (hot) @ 20 java.util.Arrays::copyOf (19 bytes) inline (hot) @ 11 java.lang.Math::min (11 bytes) (intrinsic) @ 14 java.lang.System::arraycopy (0 bytes) (intrinsic) @ 35 java.lang.String::getChars (62 bytes) inline (hot) @ 58 java.lang.System::arraycopy (0 bytes) (intrinsic) @ 24 java.lang.StringBuilder::toString (17 bytes) inline (hot) So the question is whether this is appropriate behaviour of the JVM or compiler bug? I'm asking the question because some of the projects are still using Java 8 and if it won't be fixed on any of release updates then it's reasonable to hoist calls to Class.getName() manually from hot spots. [1] https://bugs.openjdk.java.net/browse/JDK-8043677 From david.holmes at oracle.com Tue Dec 3 00:36:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Dec 2019 10:36:35 +1000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Vicente, I have also re-examined all the hotspot related code and everything looks fine - and very neat (kudos to you and Harold!). A couple of nits: src/hotspot/share/classfile/classFileParser.cpp src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp Typo: + // u2 attributs_count; --- src/hotspot/share/classfile/javaClasses.cpp You are using CHECK_0 in RecordComponent::create but that method returns oop. That seems wrong to me, but I see many other oop returning methods also use CHECK_0 so I'll take that up separately. (It's only a cosmetic issue.) --- test/hotspot/jtreg/runtime/records/abstractRecord.jcod 27 // This test is an Record marked as abstract. s/an/a/ --- Thanks, David ----- On 28/11/2019 2:37 pm, Vicente Romero wrote: > Hi, > > Please review the code for the records feature at [1]. This webrev > includes all: APIs, runtime, compiler, serialization, javadoc, and more! > Must of the code has been reviewed but there have been some changes > since reviewers saw it. Also this is the first time an integral webrev > is sent out for review. Last changes on top of my mind since last review > iterations: > > On the compiler implementation: > - it has been adapted to the last version of the language spec [2], as a > reference the JVM spec is at [3]. This implied some changes in > determining if a user defined constructor is the canonical or not. Now > if a constructor is override-equivalent to a signature derived from the > record components, then it is considered the canonical constructor. And > any canonical constructor should satisfy a set of restrictions, see > section 8.10.4 Record Constructor Declarations of the specification. > - It was also added a check to make sure that accessors are not generic. > - And that the canonical constructor, if user defined, is not explicitly > invoking any other constructor. > - The list of forbidden record component names has also been updated. > - new error messages have been added > > APIs: > - there have been some API editing in java.lang.Record, > java.lang.runtime.ObjectMethods and java.lang.reflect.RecordComponent, > java.io.ObjectInputStream, javax.lang.model (some visitors were added) > > On the JVM implementation: > - some logging capabilities have been added to classFileParser.cpp to > provide the reason for which the Record attribute has been ignored > > Reflection: > - there are several new changes to the implementation of > java.lang.reflect.RecordComponent apart from the spec changes mentioned > before. > > bug fixes in > - compiler > - serialization, > - JVM, etc > > As a reference the last iteration of the previous reviews can be found > at [4] under folders: compiler, hotspot_runtime, javadoc, reflection and > serialization, > > TIA, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html > > [3] > http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html > > [4] http://cr.openjdk.java.net/~vromero/records.review/ > From john.r.rose at oracle.com Tue Dec 3 01:08:54 2019 From: john.r.rose at oracle.com (John Rose) Date: Mon, 2 Dec 2019 17:08:54 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: On Dec 2, 2019, at 4:36 PM, David Holmes wrote: > > You are using CHECK_0 in RecordComponent::create but that method returns oop. That seems wrong to me, but I see many other oop returning methods also use CHECK_0 so I'll take that up separately. (It's only a cosmetic issue.) CHECK_NULL is clearly preferable. At some point IIRC it was more than just cosmetics, because we were getting warning noise about `return 0` converting to NULL, from some C++ compiler or other. AFAIK such warnings can still happen. ? John From david.holmes at oracle.com Tue Dec 3 02:12:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Dec 2019 12:12:46 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> Message-ID: <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> Hi Christoph, Can you please post your updated patch for review and I will use it to check the fix for our internal build. Once you have your fix reviewed I will push both fixes together. Thanks, David On 25/11/2019 10:41 pm, David Holmes wrote: > Hi Christoph, > > On 25/11/2019 10:38 pm, Langer, Christoph wrote: >> Hi David, >> >> thanks for your investigation. I'll prepare a fix to move back >> getPrefixed into canonicalize_md.c. However, could you please still >> fix your internal build in terms that it would have 'jdk_util.h' in >> the include path? > > That should be simple enough to do. > > David > >> Thanks >> Christoph >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Montag, 25. November 2019 01:02 >>> To: Langer, Christoph ; Alan Bateman >>> ; gerard ziemski >>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>> between >>> libjava, hotspot and libinstrument >>> >>> >>> >>> On 25/11/2019 8:45 am, David Holmes wrote: >>>> On 25/11/2019 7:49 am, David Holmes wrote: >>>>> On 25/11/2019 7:33 am, David Holmes wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to push this change. However, running it through jdk-submit >>>>>>> shows reproducible errors: >>>>>>> >>>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source >>>>>>> No failed tests >>>>>>> Tasks Summary >>>>>>> ???? NA: 0 >>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>> ???? KILLED: 0 >>>>>>> ???? PASSED: 76 >>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>> ???? FAILED: 0 >>>>>>> ???? HARNESS_ERROR: 0 >>>>>>> Build >>>>>>> 1 Executed with failure >>>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>>>>> return value: 2 >>>>>>> >>>>>>> >>>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source >>>>>>> No failed tests >>>>>>> Tasks Summary >>>>>>> ???? NA: 0 >>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>> ???? KILLED: 0 >>>>>>> ???? PASSED: 76 >>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>> ???? FAILED: 0 >>>>>>> ???? HARNESS_ERROR: 0 >>>>>>> Build >>>>>>> 1 Executed with failure >>>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>>>>> return value: 2 >>>>>>> >>>>>>> >>>>>>> David already had a look and let me know that the following was the >>>>>>> reason: >>>>>>> >>>>>>> >>> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. >>> c(41): >>>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such >>>>>>> file or directory >>>>>>> >>>>>>> This is not explainable to me as I see this running through my local >>>>>>> build and our nightly builds without problems. I also can't explain >>>>>>> jdk_util.h can't be opened at this place - it should be there and >>>>>>> part of the include directories... >>>>>>> >>>>>>> I'd appreciate any help... >>>>>> >>>>>> I just dug a little deeper and this is failing in part of our closed >>>>>> build for the install repo. There is a library there that is using >>>>>> canonicalize_md.c directly - i.e. it adds that file to its source >>>>>> files list. The build instructions don't include that directory on >>>>>> the include directory list - hence the failure. But it will also fail >>>>>> due to the name change you made. >>>>> >>>>> Actually it appears that the other source code doesn't actually refer >>>>> to the canonicalize function at all, so a simple fix may be possible >>>>> at the build level on our side. I'm testing that now. >>>> >>>> It isn't the canonicalize function that is used, it is getPrefixed, >>>> which has now been moved to the io_util_md.c file. So a fix will be a >>>> bit more involved. >>> >>> I tried adding io_util_md.c to the library source list instead of >>> canonicalize_md.c but that just caused a slew of other compilation >>> failures, so I don't see any quick fix for us here. >>> >>> David >>> >>>> >>>> David >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Someone will need to work with you to make the necessary changes to >>>>>> our code. >>>>>> >>>>>> David >>>>>> >>>>>>> Thanks >>>>>>> Christoph >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Langer, Christoph >>>>>>>> Sent: Donnerstag, 21. November 2019 14:19 >>>>>>>> To: Alan Bateman ; core-libs- >>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>>> between >>>>>>>> libjava, hotspot and libinstrument >>>>>>>> >>>>>>>> Hi Alan, >>>>>>>> >>>>>>>> thanks for the review. I'll push it then after running through >>>>>>>> jdk-submit. >>>>>>>> >>>>>>>> /Christoph >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Alan Bateman >>>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>>>>>> To: Langer, Christoph ; core-libs- >>>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>>>> between >>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>> >>>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please review this cleanup change regarding function >>>>>>>>>> "canonicalize" of >>>>>>>>> libjava. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The goal is to cleanup how this function is defined and used. One >>>>>>>>>> thing is, >>>>>>>>> that there was an unnecessary wrapper function "Canonicalize" in >>>>>>>>> jni_util.c. >>>>>>>>> It wrapped the call to "canonicalize". We can get rid of this >>>>>>>>> wrapper. >>>>>>>>> Unfortunately, it is not possible to just export "canonicalize" >>>>>>>>> since this will >>>>>>>>> conflict with a method signature from the math library, at least >>>>>>>>> on modern >>>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and will >>>>>>>>> correctly >>>>>>>>> define it in jdk_util.h which can be included everywhere. >>>>>>>>>> >>>>>>>>> I think this change is okay. My main concern when initially seeing >>>>>>>>> this >>>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the >>>>>>>>> canonical File when it wasn't there previously, this would of >>>>>>>>> course >>>>>>>>> have several implications. But I think you have it right and this >>>>>>>>> is, as >>>>>>>>> you position, just refactoring/cleanup. >>>>>>>>> >>>>>>>>> -Alan From joe.darcy at oracle.com Tue Dec 3 02:50:38 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 2 Dec 2019 18:50:38 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Message-ID: Hi Vicente, It looks like the update to make/data/symbols/symbols removes the jdk.pack module from the history JDKs 9, 10, and 11 when --release is used. If that is the case, it would be incorrect since historically the jdk.pack module was present in those releases. Thanks, -Joe On 11/22/2019 1:30 PM, Vicente Romero wrote: > Hi all, > > On 11/22/19 3:21 AM, Alan Bateman wrote: >> >> >> On 21/11/2019 19:53, Vicente Romero wrote: >>> Hi, >>> >>> I think I have covered all the proposed fixes so far. This is the >>> last iteration of the webrev [1], all the current changes are in >>> this one, the code hasn't been split into different webrevs. I'm >>> also forwarding to build-dev as there are some build related changes >>> too. The CSR for this change is at [2] >> Would it be possible to summarize what will remain in >> test/jdk/tools/pack200 after this removal? The webrev makes it looks >> like badattr.jar is being added but since it already exists then I'm >> not sure whether to believe it. pack200-verifier/data/golden.jar is >> another one as it looks like JAR file that is generated by the tests >> today is being checked in, maybe `hg add` in error? > > I don't know why it is shown as added in the webrev, they have been > removed. I have published another iteration of the webrev at [1] >> >> The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, >> it's not immediately obvious to me which shared code compiled on >> Windows is impacted by this. > > yes probably this change is risky. I did it as the comment suggested > that the only reason the treatment for Windows was different was > because of pack200. But not sure if we can trust that comment. Should > I restore this code to its original state? >> >> -Alan > > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ From david.holmes at oracle.com Tue Dec 3 05:27:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Dec 2019 15:27:36 +1000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <7bfe7b80-caa8-70e4-9d51-03aa39b29a4b@oracle.com> On 3/12/2019 11:08 am, John Rose wrote: > On Dec 2, 2019, at 4:36 PM, David Holmes > wrote: >> >> You are using CHECK_0 in RecordComponent::create but that method >> returns oop. That seems wrong to me, but I see many other oop >> returning methods also use CHECK_0 so I'll take that up separately. >> (It's only a cosmetic issue.) > > CHECK_NULL is clearly preferable. ?At some point IIRC it was more > than just cosmetics, because we were getting warning noise about > `return 0` converting to NULL, from some C++ compiler or other. > AFAIK such warnings can still happen. That was my recollection too (I know we fixed some CHECK_0 -> CHECK_FALSE usages for bool methods). I have filed: https://bugs.openjdk.java.net/browse/JDK-8235225 to fix the existing code. Vicente should make this change to his code before pushing (no need to see new webrev). Thanks, David > ? John From joe.darcy at oracle.com Tue Dec 3 05:36:40 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 2 Dec 2019 21:36:40 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> Message-ID: <7e816aeb-7918-9426-2f6c-5d11d3ee263d@oracle.com> Hi Vicente, These comments are based on http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ I looked over the core-libs and javax.lang.model changes. As a non-essential cleanup, in src/java.base/share/classes/java/io/ObjectOutputStream.java: 1444???????????? final boolean isRecord = isRecord(obj.getClass()) ? true : false; 1445???????????? if (isRecord) { 1446???????????????? writeRecordData(obj,desc); 1447???????????? } else if (desc.isExternalizable() && !desc.isProxy()) { would be clearer as 1445???????????? if (isRecord(obj.getClass())) { 1446???????????????? writeRecordData(obj,desc); 1447???????????? } else if (desc.isExternalizable() && !desc.isProxy()) { Also as a potential refactoring, in java.lang.Class, it would be clearer if the native getRecordComponents0 method returned a RecordComponent[] rather than an Object[] as it is elsewhere documented that only the VM can create RecordComponent objects. In src/java.base/share/classes/sun/reflect/annotation/TypeAnnotation.java, the obsolete way on indicating preview-ness is used. Please fix before pushing: ? 93???????? THROWS, ? 94???????? /** ? 95????????? * @deprecated This target is part of a preview feature and may be removed ? 96????????? * if the preview feature is removed. ? 97????????? */ ? 98???????? @Deprecated(forRemoval=true, since="14") ? 99???????? @SuppressWarnings("removal") ?100???????? RECORD_COMPONENT; No re-review is needed. Thanks, -Joe From vyommani at gmail.com Tue Dec 3 05:40:03 2019 From: vyommani at gmail.com (Vyom Tiwari) Date: Tue, 3 Dec 2019 11:10:03 +0530 Subject: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux In-Reply-To: <5b980e67-f567-d161-5b40-dedfd599bedc@oracle.com> References: <9EDBFD2B-226D-40DC-96E5-BD41F4976747@oracle.com> <5b980e67-f567-d161-5b40-dedfd599bedc@oracle.com> Message-ID: Hi Julia, changes looks good to me. Thanks, Vyom On Mon, Dec 2, 2019 at 4:24 PM Julia Boes wrote: > Hi, > > > > to make it more consistent w/ other tools, I'd move all ifconfig (incl. > one on macOS) to 'net' category, i.e. rename them to net.ifconfig, this > will require also moving all netstat.* on macOS and solaris to 'net' as > well. I don't insist on it, though. > > Good point, I made those changes. > > > > Changes looks OK to me although i have one question, in case of > > Solaris you use explicit path to ifconfig(ifconfig.app=/sbin/ifconfig). > > Does Solaris by default doesn't set the /sbin folder to user's 'PATH' > > environment variable ? > > That's right, /sbin is not on the PATH on the Solaris machines of the > test farm, which can be confirmed under the 'env' section of the > environment information output. > > > Updated webrev: > http://cr.openjdk.java.net/~jboes/webrevs/8234964/webrev.01/ > > > Regards, > > Julia > > > -- Thanks, Vyom From igor.ignatyev at oracle.com Tue Dec 3 06:20:59 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 2 Dec 2019 22:20:59 -0800 Subject: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux In-Reply-To: <5b980e67-f567-d161-5b40-dedfd599bedc@oracle.com> References: <9EDBFD2B-226D-40DC-96E5-BD41F4976747@oracle.com> <5b980e67-f567-d161-5b40-dedfd599bedc@oracle.com> Message-ID: <676D9414-9EFC-449A-AD12-EC02C1CA053E@oracle.com> > On Dec 2, 2019, at 2:54 AM, Julia Boes wrote: > > Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234964/webrev.01/ LGTM -- Igor From arno.zeller at sap.com Tue Dec 3 09:13:46 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Tue, 3 Dec 2019 09:13:46 +0000 Subject: RFR(XS): 8234696: tools/jlink/plugins/VendorInfoPluginsTest.java times out Message-ID: Hi all, could someone please review this small improvement for the test VendorInfoPluginsTest.java? The change avoids writing a core file and might reduce the memory footprint . JBS: https://bugs.openjdk.java.net/browse/JDK-8234696 Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8234696.0/ Best regards, Arno Zeller From christoph.langer at sap.com Tue Dec 3 09:26:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Dec 2019 09:26:46 +0000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> Message-ID: Hi David, thanks for taking care of this. This would be my updated patch that could hopefully be enabled by just adding the include directory where "jdk_util.h" is located. It would be really great if that'd work. I think it would open up a path to automatically include io_util_md.h by including io_util.h. http://cr.openjdk.java.net/~clanger/webrevs/8234185.1/ Cheers Christoph > -----Original Message----- > From: David Holmes > Sent: Dienstag, 3. Dezember 2019 03:13 > To: Langer, Christoph ; Alan Bateman > ; gerard ziemski > Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between > libjava, hotspot and libinstrument > > Hi Christoph, > > Can you please post your updated patch for review and I will use it to > check the fix for our internal build. Once you have your fix reviewed I > will push both fixes together. > > Thanks, > David > > On 25/11/2019 10:41 pm, David Holmes wrote: > > Hi Christoph, > > > > On 25/11/2019 10:38 pm, Langer, Christoph wrote: > >> Hi David, > >> > >> thanks for your investigation. I'll prepare a fix to move back > >> getPrefixed into canonicalize_md.c. However, could you please still > >> fix your internal build in terms that it would have 'jdk_util.h' in > >> the include path? > > > > That should be simple enough to do. > > > > David > > > >> Thanks > >> Christoph > >> > >>> -----Original Message----- > >>> From: David Holmes > >>> Sent: Montag, 25. November 2019 01:02 > >>> To: Langer, Christoph ; Alan Bateman > >>> ; gerard ziemski > > >>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function > >>> between > >>> libjava, hotspot and libinstrument > >>> > >>> > >>> > >>> On 25/11/2019 8:45 am, David Holmes wrote: > >>>> On 25/11/2019 7:49 am, David Holmes wrote: > >>>>> On 25/11/2019 7:33 am, David Holmes wrote: > >>>>>> Hi Christoph, > >>>>>> > >>>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I'd like to push this change. However, running it through jdk-submit > >>>>>>> shows reproducible errors: > >>>>>>> > >>>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 > >>>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source > >>>>>>> No failed tests > >>>>>>> Tasks Summary > >>>>>>> ???? NA: 0 > >>>>>>> ???? NOTHING_TO_RUN: 0 > >>>>>>> ???? KILLED: 0 > >>>>>>> ???? PASSED: 76 > >>>>>>> ???? UNABLE_TO_RUN: 0 > >>>>>>> ???? EXECUTED_WITH_FAILURE: 1 > >>>>>>> ???? FAILED: 0 > >>>>>>> ???? HARNESS_ERROR: 0 > >>>>>>> Build > >>>>>>> 1 Executed with failure > >>>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, > >>>>>>> return value: 2 > >>>>>>> > >>>>>>> > >>>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 > >>>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source > >>>>>>> No failed tests > >>>>>>> Tasks Summary > >>>>>>> ???? NA: 0 > >>>>>>> ???? NOTHING_TO_RUN: 0 > >>>>>>> ???? KILLED: 0 > >>>>>>> ???? PASSED: 76 > >>>>>>> ???? UNABLE_TO_RUN: 0 > >>>>>>> ???? EXECUTED_WITH_FAILURE: 1 > >>>>>>> ???? FAILED: 0 > >>>>>>> ???? HARNESS_ERROR: 0 > >>>>>>> Build > >>>>>>> 1 Executed with failure > >>>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, > >>>>>>> return value: 2 > >>>>>>> > >>>>>>> > >>>>>>> David already had a look and let me know that the following was > the > >>>>>>> reason: > >>>>>>> > >>>>>>> > >>> > t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. > >>> c(41): > >>>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such > >>>>>>> file or directory > >>>>>>> > >>>>>>> This is not explainable to me as I see this running through my local > >>>>>>> build and our nightly builds without problems. I also can't explain > >>>>>>> jdk_util.h can't be opened at this place - it should be there and > >>>>>>> part of the include directories... > >>>>>>> > >>>>>>> I'd appreciate any help... > >>>>>> > >>>>>> I just dug a little deeper and this is failing in part of our closed > >>>>>> build for the install repo. There is a library there that is using > >>>>>> canonicalize_md.c directly - i.e. it adds that file to its source > >>>>>> files list. The build instructions don't include that directory on > >>>>>> the include directory list - hence the failure. But it will also fail > >>>>>> due to the name change you made. > >>>>> > >>>>> Actually it appears that the other source code doesn't actually refer > >>>>> to the canonicalize function at all, so a simple fix may be possible > >>>>> at the build level on our side. I'm testing that now. > >>>> > >>>> It isn't the canonicalize function that is used, it is getPrefixed, > >>>> which has now been moved to the io_util_md.c file. So a fix will be a > >>>> bit more involved. > >>> > >>> I tried adding io_util_md.c to the library source list instead of > >>> canonicalize_md.c but that just caused a slew of other compilation > >>> failures, so I don't see any quick fix for us here. > >>> > >>> David > >>> > >>>> > >>>> David > >>>> > >>>>> > >>>>> David > >>>>> ----- > >>>>> > >>>>>> Someone will need to work with you to make the necessary changes > to > >>>>>> our code. > >>>>>> > >>>>>> David > >>>>>> > >>>>>>> Thanks > >>>>>>> Christoph > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Langer, Christoph > >>>>>>>> Sent: Donnerstag, 21. November 2019 14:19 > >>>>>>>> To: Alan Bateman ; core-libs- > >>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > >>>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function > >>>>>>>> between > >>>>>>>> libjava, hotspot and libinstrument > >>>>>>>> > >>>>>>>> Hi Alan, > >>>>>>>> > >>>>>>>> thanks for the review. I'll push it then after running through > >>>>>>>> jdk-submit. > >>>>>>>> > >>>>>>>> /Christoph > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Alan Bateman > >>>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 > >>>>>>>>> To: Langer, Christoph ; core-libs- > >>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > >>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize > function > >>>>>>>>> between > >>>>>>>>> libjava, hotspot and libinstrument > >>>>>>>>> > >>>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> please review this cleanup change regarding function > >>>>>>>>>> "canonicalize" of > >>>>>>>>> libjava. > >>>>>>>>>> > >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 > >>>>>>>>>> Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> The goal is to cleanup how this function is defined and used. > One > >>>>>>>>>> thing is, > >>>>>>>>> that there was an unnecessary wrapper function "Canonicalize" > in > >>>>>>>>> jni_util.c. > >>>>>>>>> It wrapped the call to "canonicalize". We can get rid of this > >>>>>>>>> wrapper. > >>>>>>>>> Unfortunately, it is not possible to just export "canonicalize" > >>>>>>>>> since this will > >>>>>>>>> conflict with a method signature from the math library, at least > >>>>>>>>> on modern > >>>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and > will > >>>>>>>>> correctly > >>>>>>>>> define it in jdk_util.h which can be included everywhere. > >>>>>>>>>> > >>>>>>>>> I think this change is okay. My main concern when initially seeing > >>>>>>>>> this > >>>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the > >>>>>>>>> canonical File when it wasn't there previously, this would of > >>>>>>>>> course > >>>>>>>>> have several implications. But I think you have it right and this > >>>>>>>>> is, as > >>>>>>>>> you position, just refactoring/cleanup. > >>>>>>>>> > >>>>>>>>> -Alan From behrangsa at gmail.com Tue Dec 3 12:22:53 2019 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Tue, 3 Dec 2019 23:22:53 +1100 Subject: Multi Part publisher for java.net.http.HttpClient Message-ID: Hi all, Are there any plans to implement a "multipart/form-data" BodyPublisher in Java 14 or later? Best regards, { "blog" : "https://blog.behrang.org", "twitter" : "https://twitter.com/behrangsa", "github" : "https://github.com/behrangsa/", "stackoverflow" : "https://stackoverflow.com/users/309683?tab=profile"} From chris.hegarty at oracle.com Tue Dec 3 12:38:05 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Dec 2019 12:38:05 +0000 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <7e816aeb-7918-9426-2f6c-5d11d3ee263d@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> <32b8c703-523f-ae83-291d-4f1b28fa1d91@oracle.com> <5cc9da98-3dae-b6c6-7acb-c9a4c3484a3b@oracle.com> <7e816aeb-7918-9426-2f6c-5d11d3ee263d@oracle.com> Message-ID: <9CABD094-6548-43D5-813E-9A5EB98682AD@oracle.com> Hi Joe, > On 3 Dec 2019, at 05:36, Joe Darcy wrote: > > ... > > As a non-essential cleanup, in src/java.base/share/classes/java/io/ObjectOutputStream.java: > > 1444 final boolean isRecord = isRecord(obj.getClass()) ? true : false; > 1445 if (isRecord) { > 1446 writeRecordData(obj,desc); > 1447 } else if (desc.isExternalizable() && !desc.isProxy()) { > > would be clearer as > > 1445 if (isRecord(obj.getClass())) { > 1446 writeRecordData(obj,desc); > 1447 } else if (desc.isExternalizable() && !desc.isProxy()) { Remi brought up similar on amber-dev ( and the implement has been updated ). https://mail.openjdk.java.net/pipermail/amber-dev/2019-December/005334.html -Chris. From ksrinifmt at gmail.com Tue Dec 3 15:14:14 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Tue, 3 Dec 2019 07:14:14 -0800 Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: Hi, Sorry for chiming in late in the review process, for what it's worth.... 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class and subsequent crash, but it does not address wildcard arguments expansion. What if we have % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java Where jdk.compiler is a java compiler implementation (javac). The user would expect the above compiler module to build all the .java files in that directory, and this fix will not address that. Some background: https://bugs.openjdk.java.net/browse/JDK-7146424 Please see all the related bugs in the above JIRA issue. Paragraph #6 in this interview surmises the wild card behavior on Windows: https://www.princeton.edu/~hos/mike/transcripts/kernighan.htm 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: https://hg.openjdk.java.net/jdk/jdk13/file/0368f3a073a9/test/jdk/tools/launcher/modules/basic Using the modules test framework may make the test simpler. Kumar Srinivasan On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski < Nikola.Grcevski at microsoft.com> wrote: > Hi Alan and Henry, > > Thank you for reviewing my email! Henry's observation matches mine, the > shared common code for all platforms in checkArg > (src/java.base/share/native/libjli/args.c) can potentially leave the > firstAppArgIndex static set to -1, if all passed command line arguments are > prefixed with a dash. Later on the arguments are validated, however we > might crash before then on Windows because of the negative index access. In > this case, the customer command was valid (modules usage) and the program > runs successfully. > > I created a webrev here for the change, including a new test in > Arrrghs.java: > > https://grcevski.github.io/JDK-8234076/webrev/ > > I copied the test validation and assertion style of other code inside the > test class. > > Please let me know if you have any comments or suggestions. > > Thanks again! > > -----Original Message----- > From: Henry Jen > Sent: December 2, 2019 12:26 PM > To: Alan Bateman > Cc: Nikola Grcevski ; > core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > > The fix looks reasonable to me, basically, if the command argument format > is not legal, it?s possible we won?t find the main class when doing > argument file expansion, and the index is -1 which could cause crash on > Windows platform for the wildcard processing. > > I think we should add a test case for this, probably in > test/jdk/tools/launcher/Arrrghs.java. > > As I understand it, the argument validation is done in a later stage after > calling JLI_Launch. > > Cheers, > Henry > > > > On Dec 2, 2019, at 2:12 AM, Alan Bateman > wrote: > > > > On 20/11/2019 19:42, Nikola Grcevski wrote: > >> : > >> > >> Please let me know if this approach is acceptable for the current bug > report and I'll make a webrev and include appropriate launcher tests. I was > thinking the tests should do extra validation on the output from > _JAVA_LAUNCHER_DEBUG on Windows. > >> > > I think you're in the right area but I would have expected the arg index > to 0 here. Henry Jen (cc'ed) might have some comments on this. > > > > -Alan > > From Nikola.Grcevski at microsoft.com Tue Dec 3 16:20:49 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Tue, 3 Dec 2019 16:20:49 +0000 Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate Message-ID: Hi Kumar, Thank you so much for your input! You are absolutely correct, this fix doesn?t fix the argument expansion issue on Windows, it only fixes the crash. I made a similar comment in my original email, fixing the argument expansion would be a bit more substantial change. I?m more than happy to do it, I would just need some guidance on what testing needs to be done to ensure that the argument expansion fix doesn?t break some existing behaviour. I also wanted to clarify that, the command line as specified below, doesn?t expose the issue with negative array index that was reported in JDK- 8234076, however a later check already present in the code prevents argument expansion to run on Windows. I must apologize, I?m new to this project and I really don?t know what?s the appropriate team etiquette in OpenJDK for handling situations like these. I?ve worked on teams where when a specific issue is reported other uncovered problems are fixed too, and also on teams where people tend to fix the reported problem and then file new bug reports for other uncovered problems. I?m happy to do either. Thank you! Nikola From: Kumar Srinivasan Sent: December 3, 2019 10:14 AM To: Nikola Grcevski Cc: Henry Jen ; Alan Bateman ; core-libs-dev at openjdk.java.net Subject: Re: [EXTERNAL] Re: JDK-8234076 bug fix candidate Hi, Sorry for chiming in ?late in the review process, for what it's worth.... 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class ? ? and subsequent crash, ?but it does not address ?wildcard arguments expansion. ? ? What if we have ? ? % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java ? ? Where jdk.compiler is a java compiler implementation (javac). ? ? The user would expect the above compiler module to build all the .java files in that directory,? ? ? and this fix will not address that. Some background: https://bugs.openjdk.java.net/browse/JDK-7146424 Please see all the related bugs in the above JIRA issue. Paragraph #6 in this interview?surmises the wild card behavior on ?Windows: https://www.princeton.edu/~hos/mike/transcripts/kernighan.htm 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: https://hg.openjdk.java.net/jdk/jdk13/file/0368f3a073a9/test/jdk/tools/launcher/modules/basic Using the modules test framework may make the test simpler. Kumar Srinivasan On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: Hi Alan and Henry, Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. I created a webrev here for the change, including a new test in Arrrghs.java: https://grcevski.github.io/JDK-8234076/webrev/ I copied the test validation and assertion style of other code inside the test class. Please let me know if you have any comments or suggestions. Thanks again! -----Original Message----- From: Henry Jen Sent: December 2, 2019 12:26 PM To: Alan Bateman Cc: Nikola Grcevski ; core-libs-dev at openjdk.java.net Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. As I understand it, the argument validation is done in a later stage after calling JLI_Launch. Cheers, Henry > On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > > On 20/11/2019 19:42, Nikola Grcevski wrote: >> : >> >> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >> > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > -Alan From henry.jen at oracle.com Tue Dec 3 16:38:31 2019 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 3 Dec 2019 08:38:31 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: Kumar, Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. Cheers, Henry > On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: > > Hi, > > Sorry for chiming in late in the review process, for what it's worth.... > > 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class > and subsequent crash, but it does not address wildcard arguments expansion. > > What if we have > % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java > Where jdk.compiler is a java compiler implementation (javac). > The user would expect the above compiler module to build all the .java files in that directory, > and this fix will not address that. > > Some background: > https://bugs.openjdk.java.net/browse/JDK-7146424 > Please see all the related bugs in the above JIRA issue. > > Paragraph #6 in this interview surmises the wild card behavior on Windows: > https://www.princeton.edu/~hos/mike/transcripts/kernighan.htm > > 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: > https://hg.openjdk.java.net/jdk/jdk13/file/0368f3a073a9/test/jdk/tools/launcher/modules/basic > Using the modules test framework may make the test simpler. > > Kumar Srinivasan > > > On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: > Hi Alan and Henry, > > Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. > > I created a webrev here for the change, including a new test in Arrrghs.java: > > https://grcevski.github.io/JDK-8234076/webrev/ > > I copied the test validation and assertion style of other code inside the test class. > > Please let me know if you have any comments or suggestions. > > Thanks again! > > -----Original Message----- > From: Henry Jen > Sent: December 2, 2019 12:26 PM > To: Alan Bateman > Cc: Nikola Grcevski ; core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > > The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. > > I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. > > As I understand it, the argument validation is done in a later stage after calling JLI_Launch. > > Cheers, > Henry > > > > On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > > > > On 20/11/2019 19:42, Nikola Grcevski wrote: > >> : > >> > >> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. > >> > > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > > > -Alan > From andy.herrick at oracle.com Tue Dec 3 19:35:03 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 3 Dec 2019 14:35:03 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: Message-ID: Please review the revised cumulative jpackage webrev at [3] /Andy [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11D/ On 11/18/2019 12:01 PM, Andy Herrick wrote: > > On 11/13/2019 7:23 PM, Andy Herrick wrote: >> Please review? changes for [1] which is the implementation bug for >> JEP-343. >> >> The webrev at [2] is the total cumulative webrev of changes for the >> jpackage tool, currently in the JDK-8200758-branch branch of the open >> sandbox repository. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >> >> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >> From andy.herrick at oracle.com Tue Dec 3 20:11:13 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 3 Dec 2019 15:11:13 -0500 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <52a2cb27-2b47-e789-3cca-1ee80b6513bf@oracle.com> References: <35372d0e-910a-d8c1-6bf4-88fcb140daee@oracle.com> <2589963b-b10e-7af9-bf1a-208df190fb2a@oracle.com> <2345349e-6658-5d3c-e191-4bfbd79a13ae@oracle.com> <281621ac-7a32-6eda-8b16-f35efde450db@oracle.com> <03d92b75-3b3b-bd08-694e-b1d0af2da53f@oracle.com> <5DDDD8F9.3060906@oracle.com> <5f88f4a4-4019-db9e-16b1-0efdd9ff0590@oracle.com> <52a2cb27-2b47-e789-3cca-1ee80b6513bf@oracle.com> Message-ID: <165e6d02-ec04-1d57-ecf5-ecc25eb4857c@oracle.com> On 12/2/2019 2:07 PM, Phil Race wrote: > This makes it very difficult to do more than a cursory re-review. > > There is one thing I just spotted. > > I believe these two scripts > http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jdk/tools/jpackage/test_jpackage.sh.html > http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jdk/tools/jpackage/run_tests.sh.html OK - run_tests.sh has been modified to not download jtreg from an external server. /Andy > > Should not be part of what is pushed. > > They should be removed from the webrev. > > -phil. > > On 11/27/19 6:07 AM, Andy Herrick wrote: >> >> yes - The attempted incremental patch is not much use.? The source >> files were moved several times, and despite using "hg addremove -s >> 60", many of the files show as a remove and a new file. >> >> /Andy >> >> >> On 11/26/2019 9:01 PM, Philip Race wrote: >>> > I believe otherwise it is an accurate incremental webrev of the >>> jpackage changes since EA-5. >>> >>> It is also not very incremental. >>> * >>> *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java >>> >>> is definitely not "new" ... >>> >>> -phil. >>> >>> On 11/26/19, 2:17 PM, Andy Herrick wrote: >>>> yes,? this incremental webrev contains the JNLPConverter code, >>>> which it should not. >>>> >>>> I believe otherwise it is an accurate incremental webrev of the >>>> jpackage changes since EA-5. >>>> >>>> /Andy >>>> >>>> On 11/26/2019 4:53 PM, Phil Race wrote: >>>>> Andy, >>>>> >>>>> I am puzzled by what I see here >>>>> > The webrev at [3] shows the changes since EA-06 (Build >>>>> 13-jpackage+1-49 ) up to the current point. >>>>> >>>>> > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>> >>>>> This includes the JNLPConverter which isn't what I expected to see >>>>> and >>>>> (correctly) isn't in the cumulative webrev .... >>>>> >>>>> Since [3] seemed like the most obvious thing to do a review of the >>>>> recent >>>>> changes I'd like to be sure it has the correct content and I am >>>>> not sure it does ... >>>>> >>>>> -phil. >>>>> >>>>> On 11/26/19 1:36 PM, Kevin Rushforth wrote: >>>>>> This all looks good. >>>>>> >>>>>> +1 >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> On 11/26/2019 12:56 PM, Erik Joelsson wrote: >>>>>>> (adding build-dev) >>>>>>> >>>>>>> Build changes look good. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2019-11-20 09:37, Andy Herrick wrote: >>>>>>>> I posted new composite webrev [7], and git patch [8] after >>>>>>>> pushing fix for JDK-8234402 [6]. >>>>>>>> >>>>>>>> [7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/ >>>>>>>> >>>>>>>> [8] >>>>>>>> http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch >>>>>>>> >>>>>>>> /Andy >>>>>>>> >>>>>>>> On 11/19/2019 3:13 PM, Kevin Rushforth wrote: >>>>>>>>> I took the "git diff" patch [5] that you uploaded yesterday, >>>>>>>>> applied it, and verified that it is the same as what is in the >>>>>>>>> JDK-8200758-branch branch of the sandbox. It builds and runs >>>>>>>>> fine for me. >>>>>>>>> >>>>>>>>> I ran jcheck and it found the following three files with >>>>>>>>> whitespace errors that will need to be fixed before you push: >>>>>>>>> >>>>>>>>> src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: >>>>>>>>> Trailing whitespace >>>>>>>>> src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: >>>>>>>>> Trailing whitespace >>>>>>>>> test/jdk/tools/jpackage/share/AddLauncherBase.java:137: >>>>>>>>> Trailing whitespace >>>>>>>>> >>>>>>>>> The second of these will go away with the fix for JDK-8234402 >>>>>>>>> [6], so you don't need to do anything there. Once the fix for >>>>>>>>> JDK-8234402 is pushed to sandbox, I presume you will update >>>>>>>>> the webrev, right? >>>>>>>>> >>>>>>>>> Pending the fix for JDK-8234402 and the needed white-space >>>>>>>>> fixes, this is a +1 from me (although I am not a jdk Project >>>>>>>>> Reviewer, so you will need at least one review from someone >>>>>>>>> who is). >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> [5] >>>>>>>>> http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch >>>>>>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8234402 >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/13/2019 4:23 PM, Andy Herrick wrote: >>>>>>>>>> Please review? changes for [1] which is the implementation >>>>>>>>>> bug for JEP-343. >>>>>>>>>> >>>>>>>>>> The webrev at [2] is the total cumulative webrev of changes >>>>>>>>>> for the jpackage tool, currently in the JDK-8200758-branch >>>>>>>>>> branch of the open sandbox repository. >>>>>>>>>> >>>>>>>>>> The webrev at [3] shows the changes since EA-06 (Build >>>>>>>>>> 13-jpackage+1-49 ) up to the current point. >>>>>>>>>> >>>>>>>>>> The latest EA (Build 14-jpackage+1-49 ) is posted at [4]. >>>>>>>>>> >>>>>>>>>> Please send feedback to core-libs-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>>>>>>>> >>>>>>>>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>>>>>>>> >>>>>>>>>> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/ >>>>>>>>>> >>>>>>>>>> [4] http://jdk.java.net/jpackage/ >>>>>>>>>> >>>>>>>>> >>>>>> >>>>> > From kevin.rushforth at oracle.com Tue Dec 3 20:31:14 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Dec 2019 12:31:14 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: Message-ID: Updated version (with the one change mentioned in reply to Phil) looks good. +1 -- Kevin On 12/3/2019 11:35 AM, Andy Herrick wrote: > Please review the revised cumulative jpackage webrev at [3] > > /Andy > > [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11D/ > > > On 11/18/2019 12:01 PM, Andy Herrick wrote: >> >> On 11/13/2019 7:23 PM, Andy Herrick wrote: >>> Please review? changes for [1] which is the implementation bug for >>> JEP-343. >>> >>> The webrev at [2] is the total cumulative webrev of changes for the >>> jpackage tool, currently in the JDK-8200758-branch branch of the >>> open sandbox repository. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>> From philip.race at oracle.com Tue Dec 3 21:11:07 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 03 Dec 2019 13:11:07 -0800 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: Message-ID: <5DE6CF6B.7030009@oracle.com> +1 (Approved). I think we are now just waiting on the CSR to be approved : https://bugs.openjdk.java.net/browse/JDK-8213087 -phil. On 12/3/19, 12:31 PM, Kevin Rushforth wrote: > Updated version (with the one change mentioned in reply to Phil) looks > good. > > +1 > > -- Kevin > > > On 12/3/2019 11:35 AM, Andy Herrick wrote: >> Please review the revised cumulative jpackage webrev at [3] >> >> /Andy >> >> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11D/ >> >> >> On 11/18/2019 12:01 PM, Andy Herrick wrote: >>> >>> On 11/13/2019 7:23 PM, Andy Herrick wrote: >>>> Please review changes for [1] which is the implementation bug for >>>> JEP-343. >>>> >>>> The webrev at [2] is the total cumulative webrev of changes for the >>>> jpackage tool, currently in the JDK-8200758-branch branch of the >>>> open sandbox repository. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8212780 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/ >>>> > From vicente.romero at oracle.com Tue Dec 3 22:47:23 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 3 Dec 2019 17:47:23 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <1c6520f1-90c2-aeee-706a-b4de9dafdaa0@oracle.com> Hi David, On 12/2/19 7:36 PM, David Holmes wrote: > Hi Vicente, > > I have also re-examined all the hotspot related code and everything > looks fine - and very neat (kudos to you and Harold!). thanks, yep Harold has made most of the work here, I just wrote the initial prototype a while ago, > > A couple of nits: > > src/hotspot/share/classfile/classFileParser.cpp > src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp > > Typo: > > + //??? u2 attributs_count; > > --- > > src/hotspot/share/classfile/javaClasses.cpp > > You are using CHECK_0 in RecordComponent::create but that method > returns oop. That seems wrong to me, but I see many other oop > returning methods also use CHECK_0 so I'll take that up separately. > (It's only a cosmetic issue.) > > --- > > test/hotspot/jtreg/runtime/records/abstractRecord.jcod > > 27 // This test is an Record marked as abstract. > > s/an/a/ > > --- > > Thanks, > David Thanks for the review, Vicente > ----- > > > On 28/11/2019 2:37 pm, Vicente Romero wrote: >> Hi, >> >> Please review the code for the records feature at [1]. This webrev >> includes all: APIs, runtime, compiler, serialization, javadoc, and >> more! Must of the code has been reviewed but there have been some >> changes since reviewers saw it. Also this is the first time an >> integral webrev is sent out for review. Last changes on top of my >> mind since last review iterations: >> >> On the compiler implementation: >> - it has been adapted to the last version of the language spec [2], >> as a reference the JVM spec is at [3]. This implied some changes in >> determining if a user defined constructor is the canonical or not. >> Now if a constructor is override-equivalent to a signature derived >> from the record components, then it is considered the canonical >> constructor. And any canonical constructor should satisfy a set of >> restrictions, see section 8.10.4 Record Constructor Declarations of >> the specification. >> - It was also added a check to make sure that accessors are not generic. >> - And that the canonical constructor, if user defined, is not >> explicitly invoking any other constructor. >> - The list of forbidden record component names has also been updated. >> - new error messages have been added >> >> APIs: >> - there have been some API editing in java.lang.Record, >> java.lang.runtime.ObjectMethods and >> java.lang.reflect.RecordComponent, java.io.ObjectInputStream, >> javax.lang.model (some visitors were added) >> >> On the JVM implementation: >> - some logging capabilities have been added to classFileParser.cpp to >> provide the reason for which the Record attribute has been ignored >> >> Reflection: >> - there are several new changes to the implementation of >> java.lang.reflect.RecordComponent apart from the spec changes >> mentioned before. >> >> bug fixes in >> - compiler >> - serialization, >> - JVM, etc >> >> As a reference the last iteration of the previous reviews can be >> found at [4] under folders: compiler, hotspot_runtime, javadoc, >> reflection and serialization, >> >> TIA, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html >> >> [3] >> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html >> >> [4] http://cr.openjdk.java.net/~vromero/records.review/ >> From david.holmes at oracle.com Tue Dec 3 22:51:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Dec 2019 08:51:51 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> Message-ID: <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> Hi Christoph, On 3/12/2019 7:26 pm, Langer, Christoph wrote: > Hi David, > > thanks for taking care of this. > > This would be my updated patch that could hopefully be enabled by just adding the include directory where "jdk_util.h" is located. It would be really great if that'd work. I think it would open up a path to automatically include io_util_md.h by including io_util.h. > > http://cr.openjdk.java.net/~clanger/webrevs/8234185.1/ I'm afraid I cannot get this to work at our end. I get the following errors: t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): error C2143: syntax error: missing ')' before '*' t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): error C2143: syntax error: missing '{' before '*' t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): warning C4142: 'size_t': benign redefinition of type C:\ade\mesos\work_dir\jib-ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\include\vcruntime.h(184): note: see declaration of 'size_t' t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): error C2370: 'size_t': redefinition; different storage class C:\ade\mesos\work_dir\jib-ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\include\vcruntime.h(184): note: see declaration of 'size_t' t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): error C2146: syntax error: missing ';' before identifier 'info_size' t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): error C2059: syntax error: ')' This pertains to the line: JDK_GetVersionInfo0(jdk_version_info* info, size_t info_size); There is also a second problem in our closed code that will take more effort from someone familiar with that code to resolve. I will file an issue for our install team to pick up. I would ask that this not be pushed for the moment while others figure out how best to handle this. Thanks, David ----- > Cheers > Christoph > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 3. Dezember 2019 03:13 >> To: Langer, Christoph ; Alan Bateman >> ; gerard ziemski >> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between >> libjava, hotspot and libinstrument >> >> Hi Christoph, >> >> Can you please post your updated patch for review and I will use it to >> check the fix for our internal build. Once you have your fix reviewed I >> will push both fixes together. >> >> Thanks, >> David >> >> On 25/11/2019 10:41 pm, David Holmes wrote: >>> Hi Christoph, >>> >>> On 25/11/2019 10:38 pm, Langer, Christoph wrote: >>>> Hi David, >>>> >>>> thanks for your investigation. I'll prepare a fix to move back >>>> getPrefixed into canonicalize_md.c. However, could you please still >>>> fix your internal build in terms that it would have 'jdk_util.h' in >>>> the include path? >>> >>> That should be simple enough to do. >>> >>> David >>> >>>> Thanks >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: Montag, 25. November 2019 01:02 >>>>> To: Langer, Christoph ; Alan Bateman >>>>> ; gerard ziemski >> >>>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>> between >>>>> libjava, hotspot and libinstrument >>>>> >>>>> >>>>> >>>>> On 25/11/2019 8:45 am, David Holmes wrote: >>>>>> On 25/11/2019 7:49 am, David Holmes wrote: >>>>>>> On 25/11/2019 7:33 am, David Holmes wrote: >>>>>>>> Hi Christoph, >>>>>>>> >>>>>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'd like to push this change. However, running it through jdk-submit >>>>>>>>> shows reproducible errors: >>>>>>>>> >>>>>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>>>>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source >>>>>>>>> No failed tests >>>>>>>>> Tasks Summary >>>>>>>>> ???? NA: 0 >>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>> ???? KILLED: 0 >>>>>>>>> ???? PASSED: 76 >>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>> ???? FAILED: 0 >>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>> Build >>>>>>>>> 1 Executed with failure >>>>>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>>>>>>> return value: 2 >>>>>>>>> >>>>>>>>> >>>>>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>>>>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source >>>>>>>>> No failed tests >>>>>>>>> Tasks Summary >>>>>>>>> ???? NA: 0 >>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>> ???? KILLED: 0 >>>>>>>>> ???? PASSED: 76 >>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>> ???? FAILED: 0 >>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>> Build >>>>>>>>> 1 Executed with failure >>>>>>>>> o??? windows-x64-install-windows-x64-build-19 error while building, >>>>>>>>> return value: 2 >>>>>>>>> >>>>>>>>> >>>>>>>>> David already had a look and let me know that the following was >> the >>>>>>>>> reason: >>>>>>>>> >>>>>>>>> >>>>> >> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. >>>>> c(41): >>>>>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such >>>>>>>>> file or directory >>>>>>>>> >>>>>>>>> This is not explainable to me as I see this running through my local >>>>>>>>> build and our nightly builds without problems. I also can't explain >>>>>>>>> jdk_util.h can't be opened at this place - it should be there and >>>>>>>>> part of the include directories... >>>>>>>>> >>>>>>>>> I'd appreciate any help... >>>>>>>> >>>>>>>> I just dug a little deeper and this is failing in part of our closed >>>>>>>> build for the install repo. There is a library there that is using >>>>>>>> canonicalize_md.c directly - i.e. it adds that file to its source >>>>>>>> files list. The build instructions don't include that directory on >>>>>>>> the include directory list - hence the failure. But it will also fail >>>>>>>> due to the name change you made. >>>>>>> >>>>>>> Actually it appears that the other source code doesn't actually refer >>>>>>> to the canonicalize function at all, so a simple fix may be possible >>>>>>> at the build level on our side. I'm testing that now. >>>>>> >>>>>> It isn't the canonicalize function that is used, it is getPrefixed, >>>>>> which has now been moved to the io_util_md.c file. So a fix will be a >>>>>> bit more involved. >>>>> >>>>> I tried adding io_util_md.c to the library source list instead of >>>>> canonicalize_md.c but that just caused a slew of other compilation >>>>> failures, so I don't see any quick fix for us here. >>>>> >>>>> David >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Someone will need to work with you to make the necessary changes >> to >>>>>>>> our code. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Christoph >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Langer, Christoph >>>>>>>>>> Sent: Donnerstag, 21. November 2019 14:19 >>>>>>>>>> To: Alan Bateman ; core-libs- >>>>>>>>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net >>>>>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>>>>> between >>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>> >>>>>>>>>> Hi Alan, >>>>>>>>>> >>>>>>>>>> thanks for the review. I'll push it then after running through >>>>>>>>>> jdk-submit. >>>>>>>>>> >>>>>>>>>> /Christoph >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Alan Bateman >>>>>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>>>>>>>> To: Langer, Christoph ; core-libs- >>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >>>>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize >> function >>>>>>>>>>> between >>>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>>> >>>>>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review this cleanup change regarding function >>>>>>>>>>>> "canonicalize" of >>>>>>>>>>> libjava. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>>>>>>>> Webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The goal is to cleanup how this function is defined and used. >> One >>>>>>>>>>>> thing is, >>>>>>>>>>> that there was an unnecessary wrapper function "Canonicalize" >> in >>>>>>>>>>> jni_util.c. >>>>>>>>>>> It wrapped the call to "canonicalize". We can get rid of this >>>>>>>>>>> wrapper. >>>>>>>>>>> Unfortunately, it is not possible to just export "canonicalize" >>>>>>>>>>> since this will >>>>>>>>>>> conflict with a method signature from the math library, at least >>>>>>>>>>> on modern >>>>>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and >> will >>>>>>>>>>> correctly >>>>>>>>>>> define it in jdk_util.h which can be included everywhere. >>>>>>>>>>>> >>>>>>>>>>> I think this change is okay. My main concern when initially seeing >>>>>>>>>>> this >>>>>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into the >>>>>>>>>>> canonical File when it wasn't there previously, this would of >>>>>>>>>>> course >>>>>>>>>>> have several implications. But I think you have it right and this >>>>>>>>>>> is, as >>>>>>>>>>> you position, just refactoring/cleanup. >>>>>>>>>>> >>>>>>>>>>> -Alan From mandy.chung at oracle.com Tue Dec 3 23:32:11 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Dec 2019 15:32:11 -0800 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: Hi Vicente, I reviewed jvm.h, jvm.cpp, and the changes in java.base but only skimmed on the serialization change from this version: http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ Class::getRecordComponents ?? - JVM_GetRecordComponents creates a new RecordComponent array or a zero-length array if not a record.?? The copying is not needed. I would recommend to include the spec of JVM_GetRecordComponents in jvm.h. Class.c 80 {"getRecordComponents0", "()[" OBJ, (void *)&JVM_GetRecordComponents}, 81 {"isRecord0", "()Z", (void *)&JVM_IsRecord}, Formatting nit: the new lines can be aligned with the existing lines/columns. java/lang/runtime/package-info.java.html I think this package summary should also have @PreviewFeature, shouldn't it? RecordComponent.java 247 * Return the record class which declares this record component. s/Return/Returns/ to be consistent with other methods. I'd expect that the webrev should show the runtime tests are renamed rather than hg add/hg remove (that would make it easier to review). Mandy From mandy.chung at oracle.com Tue Dec 3 23:38:40 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 Dec 2019 15:38:40 -0800 Subject: RFR(XS): 8234696: tools/jlink/plugins/VendorInfoPluginsTest.java times out In-Reply-To: References: Message-ID: <5f66093c-f972-c374-87e4-6467de0cfd34@oracle.com> Hi Arno, On 12/3/19 1:13 AM, Zeller, Arno wrote: > Hi all, > > could someone please review this small improvement for the test VendorInfoPluginsTest.java? The change avoids writing a core file and might reduce the memory footprint . > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234696 > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8234696.0/ > This looks okay. Mandy From Nikola.Grcevski at microsoft.com Wed Dec 4 01:29:03 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Wed, 4 Dec 2019 01:29:03 +0000 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: Hi Henry and Kumar, Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. Please find my updated webrev here for your review: https://grcevski.github.io/JDK-8234076/webrev/ Cheers, Nikola -----Original Message----- From: Henry Jen Sent: December 3, 2019 11:39 AM To: Kumar Srinivasan Cc: Nikola Grcevski ; Alan Bateman ; core-libs-dev at openjdk.java.net Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate Kumar, Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. Cheers, Henry > On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: > > Hi, > > Sorry for chiming in late in the review process, for what it's worth.... > > 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class > and subsequent crash, but it does not address wildcard arguments expansion. > > What if we have > % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java > Where jdk.compiler is a java compiler implementation (javac). > The user would expect the above compiler module to build all the .java files in that directory, > and this fix will not address that. > > Some background: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=9KSksL8%2BCmXSscF8oGGn5piLz2wApQ9paJUyZWbKWCw%3D&reserved=0 > Please see all the related bugs in the above JIRA issue. > > Paragraph #6 in this interview surmises the wild card behavior on Windows: > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=l20J1AN4vBmT19gzBxLOktBsdv260F2rMWRvCLeVb84%3D&reserved=0 > > 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=jsOjS1rgX4tfzJwE8Xif3NARZPRHb39Y64LvSdz1Jic%3D&reserved=0 > Using the modules test framework may make the test simpler. > > Kumar Srinivasan > > > On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: > Hi Alan and Henry, > > Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. > > I created a webrev here for the change, including a new test in Arrrghs.java: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=lx%2FFVo5UOw3uhxgttVm2RKkoFPu8tmQtx0OwMvbTwJs%3D&reserved=0 > > I copied the test validation and assertion style of other code inside the test class. > > Please let me know if you have any comments or suggestions. > > Thanks again! > > -----Original Message----- > From: Henry Jen > Sent: December 2, 2019 12:26 PM > To: Alan Bateman > Cc: Nikola Grcevski ; core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > > The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. > > I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. > > As I understand it, the argument validation is done in a later stage after calling JLI_Launch. > > Cheers, > Henry > > > > On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > > > > On 20/11/2019 19:42, Nikola Grcevski wrote: > >> : > >> > >> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. > >> > > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > > > -Alan > From christoph.langer at sap.com Wed Dec 4 08:06:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Dec 2019 08:06:05 +0000 Subject: native debug symbols support on Windows Message-ID: Hi, I'm currently looking into native debug symbols support for Windows. The OpenJDK build system supports these two configure flags --with-native-debug-symbols= (among a few other options which I don't want to discuss here). So, the name implies that for "internal", debug symbols should be contained in the binaries. And "external" should create separate files that contain the debug symbols. However, to my knowledge, Windows would always make use of external symbol files, named *.pdb. And there is no way to have the debug symbols included in the binaries. Is that correct or am I wrong in this assumption? If it's true, I guess --with-native-debug-symbols=internal would not make sense on Windows and should rather be rejected by configure. Otherwise, if we were to support --with-native-debug-symbols=internal, the build is broken for target "test-image" when it comes to building/copying the gtest image. I'd like to fix either the one way or the other. What do people think? Thanks for your help Christoph From christoph.langer at sap.com Wed Dec 4 12:54:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Dec 2019 12:54:42 +0000 Subject: RFR(XS): 8234696: tools/jlink/plugins/VendorInfoPluginsTest.java times out In-Reply-To: <5f66093c-f972-c374-87e4-6467de0cfd34@oracle.com> References: <5f66093c-f972-c374-87e4-6467de0cfd34@oracle.com> Message-ID: Hi Arno, +1 I'll push it for you. Cheers Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Mandy Chung > Sent: Mittwoch, 4. Dezember 2019 00:39 > To: Zeller, Arno > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR(XS): 8234696: > tools/jlink/plugins/VendorInfoPluginsTest.java times out > > Hi Arno, > > On 12/3/19 1:13 AM, Zeller, Arno wrote: > > Hi all, > > > > could someone please review this small improvement for the test > VendorInfoPluginsTest.java? The change avoids writing a core file and might > reduce the memory footprint . > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234696 > > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8234696.0/ > > > > This looks okay. > > Mandy From vicente.romero at oracle.com Wed Dec 4 14:07:56 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 4 Dec 2019 09:07:56 -0500 Subject: RFR: JEP 359: Records (Preview) (full code) In-Reply-To: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> References: <12069074-7830-8bf6-3818-1df7e2a29f18@oracle.com> Message-ID: <3cc46428-7ab4-a9bc-0c4d-c6a674b8f080@oracle.com> Hi, Thanks a lot to all reviewers. This is the header of the changeset I'm planning to push. There have been a ton of people working on the development and / or the review process and I don't want to forget anyone. Please let me know if I'm missing someone: 8225054: Compiler implementation for records 8225052: javax.lang.model support for records 8225053: Preview APIs support for records 8225055: Javadoc for records 8226314: com.sun.source support for records 8227113: Specification for java.lang.Record 8233526: JVM support for records Summary: implementation of records in the compiler and the JVM, including serialization, reflection and APIs support Reviewed-by: mcimadamore, briangoetz, alanb, darcy, jrose, jlahoda, coleenp, dholmes, lfoltan, mchung, sadayapalam, hannesw Contributed-by: vicente.romero at oracle.com, brian.goetz at oracle.com, maurizio.cimadamore at oracle.com, harold.seigel at oracle.com, joe.darcy at oracle.com, jonathan.gibbons at oracle.com, chris.hegarty at oracle.com, jan.lahoda at oracle.com Thanks to all, Vicente From erik.joelsson at oracle.com Wed Dec 4 14:11:00 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 Dec 2019 06:11:00 -0800 Subject: native debug symbols support on Windows In-Reply-To: References: Message-ID: Correct, with the Microsoft toolchain there is no support for internal. I don't know what happens to the build if you try to configure it that way. Feel free to come up with a reasonable behavior. /Erik On 2019-12-04 00:06, Langer, Christoph wrote: > Hi, > > I'm currently looking into native debug symbols support for Windows. > > The OpenJDK build system supports these two configure flags --with-native-debug-symbols= (among a few other options which I don't want to discuss here). > > So, the name implies that for "internal", debug symbols should be contained in the binaries. And "external" should create separate files that contain the debug symbols. However, to my knowledge, Windows would always make use of external symbol files, named *.pdb. And there is no way to have the debug symbols included in the binaries. Is that correct or am I wrong in this assumption? > > If it's true, I guess --with-native-debug-symbols=internal would not make sense on Windows and should rather be rejected by configure. Otherwise, if we were to support --with-native-debug-symbols=internal, the build is broken for target "test-image" when it comes to building/copying the gtest image. > > I'd like to fix either the one way or the other. What do people think? > > Thanks for your help > Christoph > From bob.vandette at oracle.com Wed Dec 4 14:26:18 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 4 Dec 2019 09:26:18 -0500 Subject: native debug symbols support on Windows In-Reply-To: References: Message-ID: <9F2FEA9C-202F-4413-B281-36C469B25A66@oracle.com> There seems to be an option that will include debug information in generated .obj files. Assuming this option is supported in the versions of Visual Studio we use, it could be used to implement ?internal? native debug symbols. /Z7 The /Z7 option produces object files that also contain full symbolic debugging information for use with the debugger. These object files and the built executable can be substantially larger than files that have no debugging information. The symbolic debugging information includes the names and types of variables, as well as functions and line numbers. No PDB file is produced. Bob. > On Dec 4, 2019, at 9:11 AM, Erik Joelsson wrote: > > Correct, with the Microsoft toolchain there is no support for internal. I don't know what happens to the build if you try to configure it that way. Feel free to come up with a reasonable behavior. > > /Erik > > On 2019-12-04 00:06, Langer, Christoph wrote: >> Hi, >> >> I'm currently looking into native debug symbols support for Windows. >> >> The OpenJDK build system supports these two configure flags --with-native-debug-symbols= (among a few other options which I don't want to discuss here). >> >> So, the name implies that for "internal", debug symbols should be contained in the binaries. And "external" should create separate files that contain the debug symbols. However, to my knowledge, Windows would always make use of external symbol files, named *.pdb. And there is no way to have the debug symbols included in the binaries. Is that correct or am I wrong in this assumption? >> >> If it's true, I guess --with-native-debug-symbols=internal would not make sense on Windows and should rather be rejected by configure. Otherwise, if we were to support --with-native-debug-symbols=internal, the build is broken for target "test-image" when it comes to building/copying the gtest image. >> >> I'd like to fix either the one way or the other. What do people think? >> >> Thanks for your help >> Christoph >> From christoph.langer at sap.com Wed Dec 4 14:39:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Dec 2019 14:39:56 +0000 Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array In-Reply-To: References: Message-ID: Hi Martin, thanks for looking into this and coming up with this patch. The test failures were quite annoying ?? In hotspot, there is coding to define a macro "ATTRIBUTE_ALIGNED(x)". I'd rather like to see that we define such a macro in the JDK code as well and use it. I think it would make the code more readable. Other than that, +1 Cheers Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Doerr, Martin > Sent: Montag, 2. Dezember 2019 16:13 > To: core-libs-dev at openjdk.java.net; security-dev dev at openjdk.java.net> > Cc: Lindenmaier, Goetz > Subject: [CAUTION] RFR(S): 8220348: [ntintel] asserts about copying > unalinged array > > Hi, > > I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u > backport): > https://bugs.openjdk.java.net/browse/JDK-8220348 > > Some jdk native methods use jni_SetLongArrayRegion with a stack allocated > buffer. > jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires > jlongs to be 8 byte aligned (asserted). > However, Windows 32 bit only uses 4 byte alignment for jlong arrays by > default. > I found such issues in the following files: > src/java.prefs/windows/native/libprefs/WindowsPreferences.c > src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > I suggest to use __declspec(align(8)) there. > > Webrev: > http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.0 > 0/ > Please review. > > I think using 8 byte alignment is not a disadvantage for 64 bit. > > I guess there are still people interested in this platform with jdk14. Otherwise > I could contribute it as 11u only fix. > > Is there a better way to force 8 byte alignment for jlongs or jlong arrays on > stack? > Best regards, > Martin From erik.joelsson at oracle.com Wed Dec 4 14:46:10 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 Dec 2019 06:46:10 -0800 Subject: native debug symbols support on Windows In-Reply-To: <9F2FEA9C-202F-4413-B281-36C469B25A66@oracle.com> References: <9F2FEA9C-202F-4413-B281-36C469B25A66@oracle.com> Message-ID: <45a8b20e-1e91-f2da-a431-8f775a216d03@oracle.com> Hello, On 2019-12-04 06:26, Bob Vandette wrote: > There seems to be an option that will include debug information in generated .obj files. Assuming this option is supported in the > versions of Visual Studio we use, it could be used to implement ?internal? native debug symbols. > > /Z7 We already use this when compiling, but we still link to external pdb files. I was not aware of being able to link with the symbol information internal. While this seems like it could be implemented, my question is, does anyone need it? The internal symbols on Linux was something the Linux distros wanted as they like to move it out in a uniform manner later. I can't really see a need for this on Windows, but I certainly wouldn't object if someone else do and wants to implement the support in the OpenJDK build. /Erik > The /Z7 option produces object files that also contain full symbolic debugging information for use with the debugger. These object files and the built executable can be substantially larger than files that have no debugging information. The symbolic debugging information includes the names and types of variables, as well as functions and line numbers. No PDB file is produced. > > Bob. > > >> On Dec 4, 2019, at 9:11 AM, Erik Joelsson wrote: >> >> Correct, with the Microsoft toolchain there is no support for internal. I don't know what happens to the build if you try to configure it that way. Feel free to come up with a reasonable behavior. >> >> /Erik >> >> On 2019-12-04 00:06, Langer, Christoph wrote: >>> Hi, >>> >>> I'm currently looking into native debug symbols support for Windows. >>> >>> The OpenJDK build system supports these two configure flags --with-native-debug-symbols= (among a few other options which I don't want to discuss here). >>> >>> So, the name implies that for "internal", debug symbols should be contained in the binaries. And "external" should create separate files that contain the debug symbols. However, to my knowledge, Windows would always make use of external symbol files, named *.pdb. And there is no way to have the debug symbols included in the binaries. Is that correct or am I wrong in this assumption? >>> >>> If it's true, I guess --with-native-debug-symbols=internal would not make sense on Windows and should rather be rejected by configure. Otherwise, if we were to support --with-native-debug-symbols=internal, the build is broken for target "test-image" when it comes to building/copying the gtest image. >>> >>> I'd like to fix either the one way or the other. What do people think? >>> >>> Thanks for your help >>> Christoph >>> From arno.zeller at sap.com Wed Dec 4 14:59:26 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Wed, 4 Dec 2019 14:59:26 +0000 Subject: RFR(XS): 8234696: tools/jlink/plugins/VendorInfoPluginsTest.java times out In-Reply-To: <5f66093c-f972-c374-87e4-6467de0cfd34@oracle.com> References: <5f66093c-f972-c374-87e4-6467de0cfd34@oracle.com> Message-ID: Hi Mandy, thanks for your review. Best regards, Arno > -----Original Message----- > From: Mandy Chung > Sent: Mittwoch, 4. Dezember 2019 00:39 > To: Zeller, Arno > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR(XS): 8234696: > tools/jlink/plugins/VendorInfoPluginsTest.java times out > > Hi Arno, > > On 12/3/19 1:13 AM, Zeller, Arno wrote: > > Hi all, > > > > could someone please review this small improvement for the test > VendorInfoPluginsTest.java? The change avoids writing a core file and might > reduce the memory footprint . > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234696 > > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8234696.0/ > > > > This looks okay. > > Mandy From arno.zeller at sap.com Wed Dec 4 15:00:51 2019 From: arno.zeller at sap.com (Zeller, Arno) Date: Wed, 4 Dec 2019 15:00:51 +0000 Subject: RFR(XS): 8234696: tools/jlink/plugins/VendorInfoPluginsTest.java times out In-Reply-To: References: <5f66093c-f972-c374-87e4-6467de0cfd34@oracle.com> Message-ID: Hi Christoph, thanks for your review and sponsoring! Best regards, Arno > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 4. Dezember 2019 13:55 > To: Zeller, Arno > Cc: core-libs-dev at openjdk.java.net; Mandy Chung > > Subject: RE: RFR(XS): 8234696: > tools/jlink/plugins/VendorInfoPluginsTest.java times out > > Hi Arno, > > +1 > > I'll push it for you. > > Cheers > Christoph > > > -----Original Message----- > > From: core-libs-dev On Behalf > > Of Mandy Chung > > Sent: Mittwoch, 4. Dezember 2019 00:39 > > To: Zeller, Arno > > Cc: core-libs-dev at openjdk.java.net > > Subject: Re: RFR(XS): 8234696: > > tools/jlink/plugins/VendorInfoPluginsTest.java times out > > > > Hi Arno, > > > > On 12/3/19 1:13 AM, Zeller, Arno wrote: > > > Hi all, > > > > > > could someone please review this small improvement for the test > > VendorInfoPluginsTest.java? The change avoids writing a core file and > might > > reduce the memory footprint . > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234696 > > > Webrev: http://cr.openjdk.java.net/~azeller/webrevs/8234696.0/ > > > > > > > This looks okay. > > > > Mandy From christoph.langer at sap.com Wed Dec 4 15:09:00 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Dec 2019 15:09:00 +0000 Subject: native debug symbols support on Windows In-Reply-To: <45a8b20e-1e91-f2da-a431-8f775a216d03@oracle.com> References: <9F2FEA9C-202F-4413-B281-36C469B25A66@oracle.com> <45a8b20e-1e91-f2da-a431-8f775a216d03@oracle.com> Message-ID: Hi, thanks for your comments. The reason why I want to have (at least basic) internal debugging information is to have helpful callstacks in hs_err files on crashes. So, Bob, I don't think the executables can contain debug information, just the compiled .obj files. When it comes to linking, the linker either generates a pdb file or nothing. That's at least how I read the MSDN documentation (of linker options /debug [0] and /pdb [1]). Maybe an idea to implement "internal" debug symbols for Windows would be to copy the pdb files to the release bundle as well. But actually, it's a strange interpretation of "internal" in that case... Thanks Christoph [0] https://docs.microsoft.com/en-us/cpp/build/reference/debug-generate-debug-info?view=vs-2019 [1] https://docs.microsoft.com/en-us/cpp/build/reference/pdb-use-program-database?view=vs-2019 > -----Original Message----- > From: Erik Joelsson > Sent: Mittwoch, 4. Dezember 2019 15:46 > To: Bob Vandette > Cc: Langer, Christoph ; build- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev > developers > Subject: Re: native debug symbols support on Windows > > Hello, > > On 2019-12-04 06:26, Bob Vandette wrote: > > There seems to be an option that will include debug information in > generated .obj files. Assuming this option is supported in the > > versions of Visual Studio we use, it could be used to implement ?internal? > native debug symbols. > > > > /Z7 > > We already use this when compiling, but we still link to external pdb > files. I was not aware of being able to link with the symbol information > internal. > > While this seems like it could be implemented, my question is, does > anyone need it? The internal symbols on Linux was something the Linux > distros wanted as they like to move it out in a uniform manner later. I > can't really see a need for this on Windows, but I certainly wouldn't > object if someone else do and wants to implement the support in the > OpenJDK build. > > /Erik > > > The /Z7 option produces object files that also contain full symbolic > debugging information for use with the debugger. These object files and the > built executable can be substantially larger than files that have no debugging > information. The symbolic debugging information includes the names and > types of variables, as well as functions and line numbers. No PDB file is > produced. > > > > Bob. > > > > > >> On Dec 4, 2019, at 9:11 AM, Erik Joelsson > wrote: > >> > >> Correct, with the Microsoft toolchain there is no support for internal. I > don't know what happens to the build if you try to configure it that way. Feel > free to come up with a reasonable behavior. > >> > >> /Erik > >> > >> On 2019-12-04 00:06, Langer, Christoph wrote: > >>> Hi, > >>> > >>> I'm currently looking into native debug symbols support for Windows. > >>> > >>> The OpenJDK build system supports these two configure flags --with- > native-debug-symbols= (among a few other options > which I don't want to discuss here). > >>> > >>> So, the name implies that for "internal", debug symbols should be > contained in the binaries. And "external" should create separate files that > contain the debug symbols. However, to my knowledge, Windows would > always make use of external symbol files, named *.pdb. And there is no way > to have the debug symbols included in the binaries. Is that correct or am I > wrong in this assumption? > >>> > >>> If it's true, I guess --with-native-debug-symbols=internal would not > make sense on Windows and should rather be rejected by configure. > Otherwise, if we were to support --with-native-debug-symbols=internal, the > build is broken for target "test-image" when it comes to building/copying the > gtest image. > >>> > >>> I'd like to fix either the one way or the other. What do people think? > >>> > >>> Thanks for your help > >>> Christoph > >>> From bob.vandette at oracle.com Wed Dec 4 15:21:35 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 4 Dec 2019 10:21:35 -0500 Subject: native debug symbols support on Windows In-Reply-To: References: <9F2FEA9C-202F-4413-B281-36C469B25A66@oracle.com> <45a8b20e-1e91-f2da-a431-8f775a216d03@oracle.com> Message-ID: Oh well, this sentence in [0] says it all. "It is not possible to create an .exe or .dll that contains debug information. Debug information is always placed in a .obj or .pdb file.? I guess you need to copy pdb files if you runtime debug information. Bob. > On Dec 4, 2019, at 10:09 AM, Langer, Christoph wrote: > > Hi, > > thanks for your comments. > > The reason why I want to have (at least basic) internal debugging information is to have helpful callstacks in hs_err files on crashes. > > So, Bob, I don't think the executables can contain debug information, just the compiled .obj files. When it comes to linking, the linker either generates a pdb file or nothing. That's at least how I read the MSDN documentation (of linker options /debug [0] and /pdb [1]). > > Maybe an idea to implement "internal" debug symbols for Windows would be to copy the pdb files to the release bundle as well. But actually, it's a strange interpretation of "internal" in that case... > > Thanks > Christoph > > [0] https://docs.microsoft.com/en-us/cpp/build/reference/debug-generate-debug-info?view=vs-2019 > [1] https://docs.microsoft.com/en-us/cpp/build/reference/pdb-use-program-database?view=vs-2019 > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Mittwoch, 4. Dezember 2019 15:46 >> To: Bob Vandette >> Cc: Langer, Christoph ; build- >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev >> developers >> Subject: Re: native debug symbols support on Windows >> >> Hello, >> >> On 2019-12-04 06:26, Bob Vandette wrote: >>> There seems to be an option that will include debug information in >> generated .obj files. Assuming this option is supported in the >>> versions of Visual Studio we use, it could be used to implement ?internal? >> native debug symbols. >>> >>> /Z7 >> >> We already use this when compiling, but we still link to external pdb >> files. I was not aware of being able to link with the symbol information >> internal. >> >> While this seems like it could be implemented, my question is, does >> anyone need it? The internal symbols on Linux was something the Linux >> distros wanted as they like to move it out in a uniform manner later. I >> can't really see a need for this on Windows, but I certainly wouldn't >> object if someone else do and wants to implement the support in the >> OpenJDK build. >> >> /Erik >> >>> The /Z7 option produces object files that also contain full symbolic >> debugging information for use with the debugger. These object files and the >> built executable can be substantially larger than files that have no debugging >> information. The symbolic debugging information includes the names and >> types of variables, as well as functions and line numbers. No PDB file is >> produced. >>> >>> Bob. >>> >>> >>>> On Dec 4, 2019, at 9:11 AM, Erik Joelsson >> wrote: >>>> >>>> Correct, with the Microsoft toolchain there is no support for internal. I >> don't know what happens to the build if you try to configure it that way. Feel >> free to come up with a reasonable behavior. >>>> >>>> /Erik >>>> >>>> On 2019-12-04 00:06, Langer, Christoph wrote: >>>>> Hi, >>>>> >>>>> I'm currently looking into native debug symbols support for Windows. >>>>> >>>>> The OpenJDK build system supports these two configure flags --with- >> native-debug-symbols= (among a few other options >> which I don't want to discuss here). >>>>> >>>>> So, the name implies that for "internal", debug symbols should be >> contained in the binaries. And "external" should create separate files that >> contain the debug symbols. However, to my knowledge, Windows would >> always make use of external symbol files, named *.pdb. And there is no way >> to have the debug symbols included in the binaries. Is that correct or am I >> wrong in this assumption? >>>>> >>>>> If it's true, I guess --with-native-debug-symbols=internal would not >> make sense on Windows and should rather be rejected by configure. >> Otherwise, if we were to support --with-native-debug-symbols=internal, the >> build is broken for target "test-image" when it comes to building/copying the >> gtest image. >>>>> >>>>> I'd like to fix either the one way or the other. What do people think? >>>>> >>>>> Thanks for your help >>>>> Christoph >>>>> From thomas.stuefe at gmail.com Wed Dec 4 16:56:14 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 4 Dec 2019 17:56:14 +0100 Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array In-Reply-To: References: Message-ID: Hi Martin, this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal. +#if defined (_WIN32) && defined (_MSC_VER) Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++? Cheers, Thomas On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin wrote: > Hi, > > I'd like to propose a fix for an old issue on 32 bit Windows (also for an > 11u backport): > https://bugs.openjdk.java.net/browse/JDK-8220348 > > Some jdk native methods use jni_SetLongArrayRegion with a stack allocated > buffer. > jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires > jlongs to be 8 byte aligned (asserted). > However, Windows 32 bit only uses 4 byte alignment for jlong arrays by > default. > I found such issues in the following files: > src/java.prefs/windows/native/libprefs/WindowsPreferences.c > src/java.security.jgss/share/native/libj2gss/GSSLibStub.c > I suggest to use __declspec(align(8)) there. > > Webrev: > http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/ > Please review. > > I think using 8 byte alignment is not a disadvantage for 64 bit. > > I guess there are still people interested in this platform with jdk14. > Otherwise I could contribute it as 11u only fix. > > Is there a better way to force 8 byte alignment for jlongs or jlong arrays > on stack? > Best regards, > Martin > > From huizhe.wang at oracle.com Wed Dec 4 18:12:03 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 4 Dec 2019 10:12:03 -0800 Subject: [14] RFR: 8222756: Plural support in CompactNumberFormat In-Reply-To: <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> Message-ID: <8620cb24-dbd0-fe5e-15ee-bf014c10243d@oracle.com> Hi Naoto, Looks good. I understand you'll update the webrev (with the added statement to readObject) once the CSR is approved. ResourceBundleGenerator.java might have been accidentally touched as there's no change there. I wonder if you need to guard the pluralRules input since you're building a Map with a split. While it normally won't be a problem if the factory methods are used, there's still a chance CompactNumberFormat is constructed directly (e.g. with a custom format). Best, Joe On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote: > I modified CompactNumberFormat.java to simplify the syntax parsing: > > https://cr.openjdk.java.net/~naoto/8222756/webrev.01/ > > Please review this webrev instead. > > Naoto > > On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> CompactNumberFormat has been added since JDK 12 to support compact >> number formatting, such as 10_000 being formatted as "10K." [1] It >> works fine for English, however, not for other languages that take >> plural forms in formatted number prefixes/suffixes. In order to fix >> this, I filed the following CSR to extend the current >> CompactNumberFormat spec: >> >> https://bugs.openjdk.java.net/browse/JDK-8232633 >> >> It basically accommodates the plural prefix/suffix forms into the >> existing compact patterns array, so that the existing compact number >> format works compatibly. The plural rules are solely based on the >> CLDR's plural language rules [2] >> >> Here is the implementation of the CSR: >> >> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/ >> >> Please review the CSR as well as its implementation. >> >> Naoto >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177552 >> [2] >> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules From vicente.romero at oracle.com Wed Dec 4 19:19:54 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 4 Dec 2019 14:19:54 -0500 Subject: RFR: some pack200 tests are failing with records Message-ID: <3e8666f2-50e7-1dd3-7415-cfe46027d80b@oracle.com> Hi, Please review the addition of some pack200 tests to the problem list. They fail as the records patch adds new members to some visitors. But there is less point on fixing them as pack200 will be removed. diff -r 92385cd2429d test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt? Wed Dec 04 14:05:15 2019 -0500 +++ b/test/jdk/ProblemList.txt? Wed Dec 04 14:18:39 2019 -0500 @@ -886,6 +886,13 @@ ?# core_tools ?tools/pack200/CommandLineTests.java 8059906 generic-all +tools/pack200/TestNormal.java 8234542 generic-all??? this test can be delisted as soon as pack200 is removed +tools/pack200/Pack200Test.java 8234542 generic-all??? this test can be delisted as soon as pack200 is removed +tools/pack200/MultiRelease.java 8234542 generic-all??? this test can be delisted as soon as pack200 is removed +tools/pack200/ModuleAttributes.java 8234542 generic-all??? this test can be delisted as soon as pack200 is removed +tools/pack200/InstructionTests.java 8234542 generic-all??? this test can be delisted as soon as pack200 is removed +tools/pack200/AttributeTests.java 8234542 generic-all??? this test can be delisted as soon as pack200 is removed +tools/pack200/typeannos/TestTypeAnnotations.java 8234542 generic-all??? this test can be delisted as soon as pack200 is removed ?tools/jlink/JLinkReproducibleTest.java 8217166 windows-all Thanks, Vicente From joe.darcy at oracle.com Wed Dec 4 19:20:55 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 4 Dec 2019 11:20:55 -0800 Subject: RFR: some pack200 tests are failing with records In-Reply-To: <3e8666f2-50e7-1dd3-7415-cfe46027d80b@oracle.com> References: <3e8666f2-50e7-1dd3-7415-cfe46027d80b@oracle.com> Message-ID: <094729a7-63e3-5640-73e6-ae41fed692e2@oracle.com> Looks fine Vicente; thanks, -Joe On 12/4/2019 11:19 AM, Vicente Romero wrote: > Hi, > > Please review the addition of some pack200 tests to the problem list. > They fail as the records patch adds new members to some visitors. But > there is less point on fixing them as pack200 will be removed. > > diff -r 92385cd2429d test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Wed Dec 04 14:05:15 2019 -0500 > +++ b/test/jdk/ProblemList.txt? Wed Dec 04 14:18:39 2019 -0500 > @@ -886,6 +886,13 @@ > ?# core_tools > > ?tools/pack200/CommandLineTests.java 8059906 generic-all > +tools/pack200/TestNormal.java 8234542 generic-all??? this test can be > delisted as soon as pack200 is removed > +tools/pack200/Pack200Test.java 8234542 generic-all??? this test can > be delisted as soon as pack200 is removed > +tools/pack200/MultiRelease.java 8234542 generic-all??? this test can > be delisted as soon as pack200 is removed > +tools/pack200/ModuleAttributes.java 8234542 generic-all??? this test > can be delisted as soon as pack200 is removed > +tools/pack200/InstructionTests.java 8234542 generic-all??? this test > can be delisted as soon as pack200 is removed > +tools/pack200/AttributeTests.java 8234542 generic-all??? this test > can be delisted as soon as pack200 is removed > +tools/pack200/typeannos/TestTypeAnnotations.java 8234542 > generic-all??? this test can be delisted as soon as pack200 is removed > > ?tools/jlink/JLinkReproducibleTest.java 8217166 windows-all > > Thanks, > Vicente From vicente.romero at oracle.com Wed Dec 4 19:28:23 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 4 Dec 2019 14:28:23 -0500 Subject: RFR: some pack200 tests are failing with records In-Reply-To: <094729a7-63e3-5640-73e6-ae41fed692e2@oracle.com> References: <3e8666f2-50e7-1dd3-7415-cfe46027d80b@oracle.com> <094729a7-63e3-5640-73e6-ae41fed692e2@oracle.com> Message-ID: thanks, Vicente On 12/4/19 2:20 PM, Joe Darcy wrote: > Looks fine Vicente; thanks, > > -Joe > > On 12/4/2019 11:19 AM, Vicente Romero wrote: >> Hi, >> >> Please review the addition of some pack200 tests to the problem list. >> They fail as the records patch adds new members to some visitors. But >> there is less point on fixing them as pack200 will be removed. >> >> diff -r 92385cd2429d test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt? Wed Dec 04 14:05:15 2019 -0500 >> +++ b/test/jdk/ProblemList.txt? Wed Dec 04 14:18:39 2019 -0500 >> @@ -886,6 +886,13 @@ >> ?# core_tools >> >> ?tools/pack200/CommandLineTests.java 8059906 generic-all >> +tools/pack200/TestNormal.java 8234542 generic-all??? this test can >> be delisted as soon as pack200 is removed >> +tools/pack200/Pack200Test.java 8234542 generic-all??? this test can >> be delisted as soon as pack200 is removed >> +tools/pack200/MultiRelease.java 8234542 generic-all??? this test can >> be delisted as soon as pack200 is removed >> +tools/pack200/ModuleAttributes.java 8234542 generic-all??? this test >> can be delisted as soon as pack200 is removed >> +tools/pack200/InstructionTests.java 8234542 generic-all??? this test >> can be delisted as soon as pack200 is removed >> +tools/pack200/AttributeTests.java 8234542 generic-all??? this test >> can be delisted as soon as pack200 is removed >> +tools/pack200/typeannos/TestTypeAnnotations.java 8234542 >> generic-all??? this test can be delisted as soon as pack200 is removed >> >> ?tools/jlink/JLinkReproducibleTest.java 8217166 windows-all >> >> Thanks, >> Vicente From letuyang at amazon.com Wed Dec 4 19:38:40 2019 From: letuyang at amazon.com (Yang, Letu) Date: Wed, 4 Dec 2019 19:38:40 +0000 Subject: Turkish Time Zone name string and translation In-Reply-To: <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com> Message-ID: <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com> Hi Naoto, Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ Letu ?On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" wrote: Looks good. Naoto On 11/22/19 9:55 PM, Yang, Letu wrote: > Hi Naoto, > > Added it in the new webrev > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks! > > Letu > > > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote: > Hi Letu, > > You might want to add lines for "Turkey" zone as well in LocaleData? > > Naoto > > On 11/22/19 4:16 PM, Yang, Letu wrote: >> Hi Naoto, >> >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ >> >> Letu >> >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: >> >> Hi Letu, >> >> The change in the resource bundle file looks good. >> >> As to the regression test, I would avoid adding a separate file, instead >> add some variations for >> open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add >> some lines in "LocaleData" file, which contains the expected resources >> for the COMPAT locale provider. >> >> Naoto >> >> On 11/20/19 9:43 PM, Yang, Letu wrote: >> > Hi Naoto, >> > >> > Thank you for the suggestions! >> > >> > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ >> > >> > Letu >> > >> > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: >> > >> > Hi Letu, >> > >> > Here are my comments to your changes: >> > >> > - You will need a regression test for this fix. Take a look at >> > test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate >> > test cases. >> > >> > - Fix comment should follow the OpenJDK changeset guideline [1] >> > >> > - As to the change itself, I would put "Turkey Summer Time"/"TRST" for >> > the 3rd and 4th array elements. Even though Turkey time do not observe >> > DST, names in those slots should reflect the DST (consistent to other names) >> > >> > - time zone id "Turkey" (line 1050) should also point to TRT array. >> > >> > Naoto >> > >> > [1] http://openjdk.java.net/guide/producingChangeset.html >> > >> > On 11/17/19 8:54 PM, Yang, Letu wrote: >> > > Hi Naoto, >> > > >> > > Thank you for the clarification! >> > > >> > > Xin from my team has filed a JBS and uploaded my webrev: >> > > https://bugs.openjdk.java.net/browse/JDK-8234288 >> > > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ >> > > >> > > Letu >> > > >> > > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: >> > > >> > > Letu, >> > > >> > > Please go ahead and fix the issue in English resource. As to the >> > > translation, Oracle l10n will translate it in appropriate locales. >> > > >> > > Naoto >> > > >> > > On 11/15/19 5:56 PM, Yang, Letu wrote: >> > > > Hi Naoto >> > > > >> > > > Thank you for the quick response! We will file a ticket later today. >> > > > >> > > > Shall we make an effort on fixing and translating the strings, or you >> > > > prefer to take care of it at Oracle? >> > > > >> > > > Letu >> > > > >> > > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: >> > > > Hi Letu, >> > > > >> > > > Please file a JBS issue for this (component: core-libs, subcomponent: >> > > > java.util:i18n). >> > > > >> > > > Naoto >> > > > >> > > > On 11/15/19 3:19 PM, Yang, Letu wrote: >> > > >> Hi, >> > > >> >> > > >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: >> > > >> >> > > >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 >> > > >> >> > > >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS > issue for this, but I >> > > > am not sure whether we should fix this bug, or there is an existing >> > > > procedure for this kind of bug which requires language translation. >> > > >> >> > > >> Letu >> > > >> >> > > >> >> > > >> >> > > >> > > >> > >> > >> >> From hohensee at amazon.com Wed Dec 4 19:39:37 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 4 Dec 2019 19:39:37 +0000 Subject: Turkish Time Zone name string and translation In-Reply-To: <7C49485A-7967-4F56-B00F-A4D3B178C709@amazon.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> <7C49485A-7967-4F56-B00F-A4D3B178C709@amazon.com> Message-ID: This looks good to me, assuming the i18n people are ok with using "Turkey Time" instead of some other designation. Thanks, Paul ?On 11/25/19, 10:44 AM, "core-libs-dev on behalf of Yang, Letu" wrote: Fixed in https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ Thanks! From: Martin Buchholz Date: Monday, November 25, 2019 at 10:27 AM To: "Yang, Letu" Cc: "core-libs-dev at openjdk.java.net" , "i18n-dev at openjdk.java.net" , "naoto.sato at oracle.com" , Leo Jiang , "Liu, Xin" Subject: Re: Turkish Time Zone name string and translation \ No newline at end of file Please fix. From Roger.Riggs at oracle.com Wed Dec 4 20:16:40 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 4 Dec 2019 15:16:40 -0500 Subject: [14] RFR: 8222756: Plural support in CompactNumberFormat In-Reply-To: <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> Message-ID: <5991be86-5c6d-37b6-8885-8a69acf72cf3@oracle.com> Hi Naoto, Looks very good, and a few comments... CompactNumberFormat.java: 144: "each singular and plural patterns" -> "each singular and plural pattern" 148: "Should the pattern include" -> "If the pattern includes" 336:? Add a "." at the end of the sentence 407/417:? If the plural rules is not syntatically correct, how is the error reported?? IllegalArgumentException? 587-588: Can be simplified a bit: ??? The pattern appears multiple times and could be a utility method. ??? private String getPrefix(boolean isNegative, int compactDataIndex, int iPart) { ??????? return (isNegative ? negativePrefixPatterns : positivePrefixPatterns) ??????????????? .get(compactDataIndex).get(iPart); ??? } 1667: Pattern DIGITS; is there a pattern syntax to surround the inf and nan parts to ensure they are treated as literals? Can Pattern.compile throw? The parse(text,pos) method does not declare IllegalArgumentException. It might be clearer to check for inf/nan outside the digits parse pattern. 2378: Using == on doubles seems like a risky choice but may be ok given that the input is integers, not floating point. 2350-2353 Looks ok like a lot of pattern matching on every parse. If performance turns out to be an issue, it should be possible to parse and generate a tree of lambdas with bindings to the literal values. The lambda expressions could be saved and re-used. TestEquality.java: 51: please break the line into reasonable line lengths. Generated PluralRules.java:? Each plural entry has an extra space at the end of the string; CLDRConverter.java: 1215: Please trim strings to avoid looking like they are significant. Regards, Roger ResourceBundleGenerator.java does not have any changes and may not need to be in the webrev. On 11/26/19 4:35 PM, naoto.sato at oracle.com wrote: > I modified CompactNumberFormat.java to simplify the syntax parsing: > > https://cr.openjdk.java.net/~naoto/8222756/webrev.01/ > > Please review this webrev instead. > > Naoto > > On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> CompactNumberFormat has been added since JDK 12 to support compact >> number formatting, such as 10_000 being formatted as "10K." [1] It >> works fine for English, however, not for other languages that take >> plural forms in formatted number prefixes/suffixes. In order to fix >> this, I filed the following CSR to extend the current >> CompactNumberFormat spec: >> >> https://bugs.openjdk.java.net/browse/JDK-8232633 >> >> It basically accommodates the plural prefix/suffix forms into the >> existing compact patterns array, so that the existing compact number >> format works compatibly. The plural rules are solely based on the >> CLDR's plural language rules [2] >> >> Here is the implementation of the CSR: >> >> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/ >> >> Please review the CSR as well as its implementation. >> >> Naoto >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177552 >> [2] >> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules From naoto.sato at oracle.com Wed Dec 4 20:35:10 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 4 Dec 2019 12:35:10 -0800 Subject: Turkish Time Zone name string and translation In-Reply-To: <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com> <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com> Message-ID: <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com> Looks good, assuming the change between 03 and 04 is to fix "no new line..." Naoto On 12/4/19 11:38 AM, Yang, Letu wrote: > Hi Naoto, > > Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ > > Letu > > ?On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" wrote: > > Looks good. > > Naoto > > On 11/22/19 9:55 PM, Yang, Letu wrote: > > Hi Naoto, > > > > Added it in the new webrev > > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks! > > > > Letu > > > > > > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote: > > Hi Letu, > > > > You might want to add lines for "Turkey" zone as well in LocaleData? > > > > Naoto > > > > On 11/22/19 4:16 PM, Yang, Letu wrote: > >> Hi Naoto, > >> > >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ > >> > >> Letu > >> > >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: > >> > >> Hi Letu, > >> > >> The change in the resource bundle file looks good. > >> > >> As to the regression test, I would avoid adding a separate file, instead > >> add some variations for > >> open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add > >> some lines in "LocaleData" file, which contains the expected resources > >> for the COMPAT locale provider. > >> > >> Naoto > >> > >> On 11/20/19 9:43 PM, Yang, Letu wrote: > >> > Hi Naoto, > >> > > >> > Thank you for the suggestions! > >> > > >> > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ > >> > > >> > Letu > >> > > >> > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: > >> > > >> > Hi Letu, > >> > > >> > Here are my comments to your changes: > >> > > >> > - You will need a regression test for this fix. Take a look at > >> > test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate > >> > test cases. > >> > > >> > - Fix comment should follow the OpenJDK changeset guideline [1] > >> > > >> > - As to the change itself, I would put "Turkey Summer Time"/"TRST" for > >> > the 3rd and 4th array elements. Even though Turkey time do not observe > >> > DST, names in those slots should reflect the DST (consistent to other names) > >> > > >> > - time zone id "Turkey" (line 1050) should also point to TRT array. > >> > > >> > Naoto > >> > > >> > [1] http://openjdk.java.net/guide/producingChangeset.html > >> > > >> > On 11/17/19 8:54 PM, Yang, Letu wrote: > >> > > Hi Naoto, > >> > > > >> > > Thank you for the clarification! > >> > > > >> > > Xin from my team has filed a JBS and uploaded my webrev: > >> > > https://bugs.openjdk.java.net/browse/JDK-8234288 > >> > > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ > >> > > > >> > > Letu > >> > > > >> > > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: > >> > > > >> > > Letu, > >> > > > >> > > Please go ahead and fix the issue in English resource. As to the > >> > > translation, Oracle l10n will translate it in appropriate locales. > >> > > > >> > > Naoto > >> > > > >> > > On 11/15/19 5:56 PM, Yang, Letu wrote: > >> > > > Hi Naoto > >> > > > > >> > > > Thank you for the quick response! We will file a ticket later today. > >> > > > > >> > > > Shall we make an effort on fixing and translating the strings, or you > >> > > > prefer to take care of it at Oracle? > >> > > > > >> > > > Letu > >> > > > > >> > > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: > >> > > > Hi Letu, > >> > > > > >> > > > Please file a JBS issue for this (component: core-libs, subcomponent: > >> > > > java.util:i18n). > >> > > > > >> > > > Naoto > >> > > > > >> > > > On 11/15/19 3:19 PM, Yang, Letu wrote: > >> > > >> Hi, > >> > > >> > >> > > >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: > >> > > >> > >> > > >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 > >> > > >> > >> > > >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS > > issue for this, but I > >> > > > am not sure whether we should fix this bug, or there is an existing > >> > > > procedure for this kind of bug which requires language translation. > >> > > >> > >> > > >> Letu > >> > > >> > >> > > >> > >> > > >> > >> > > > >> > > > >> > > >> > > >> > >> > > From ksrinifmt at gmail.com Wed Dec 4 21:15:20 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Wed, 4 Dec 2019 13:15:20 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: Hi Nikola, It looks ok to me, I will leave it to Henry and Alan to bless this. IMHO: I think we should fix it correctly now than later, I don't think it is all that difficult AFAICT all the launcher has to do is identify "--module==", then the next argument is the first index. Kumar On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski < Nikola.Grcevski at microsoft.com> wrote: > Hi Henry and Kumar, > > Thanks again for your comments! I have updated the test to be part of > test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve > the same amount of testing. I added a new test method inside BasicTest.java > and tested on both Windows and Linux. > > Please find my updated webrev here for your review: > https://grcevski.github.io/JDK-8234076/webrev/ > > Cheers, > > Nikola > > -----Original Message----- > From: Henry Jen > Sent: December 3, 2019 11:39 AM > To: Kumar Srinivasan > Cc: Nikola Grcevski ; Alan Bateman < > Alan.Bateman at oracle.com>; core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > Kumar, > > Great to have you look at this, you are correct, this patch doesn?t > address the wildcard expansion issue, but only to address the potential > crash if a main class is not specified as Nikola pointed out. > > We definitely need a follow up to fix wildcard expansion. The pointer to > simplify the test is helpful, it would make the test more obvious. > > Cheers, > Henry > > > On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan > wrote: > > > > Hi, > > > > Sorry for chiming in late in the review process, for what it's worth.... > > > > 1. It is not at all clear to me if this solution is correct, yes it > averts the problem of not finding the main-class > > and subsequent crash, but it does not address wildcard arguments > expansion. > > > > What if we have > > % java --module-path=mods > --module=jdk.compiler/com.sun.tools.javac.Main *.java > > Where jdk.compiler is a java compiler implementation (javac). > > The user would expect the above compiler module to build all the > .java files in that directory, > > and this fix will not address that. > > > > Some background: > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=9KSksL8%2BCmXSscF8oGGn5piLz2wApQ9paJUyZWbKWCw%3D&reserved=0 > > Please see all the related bugs in the above JIRA issue. > > > > Paragraph #6 in this interview surmises the wild card behavior on > Windows: > > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=l20J1AN4vBmT19gzBxLOktBsdv260F2rMWRvCLeVb84%3D&reserved=0 > > > > 2. Though the arguments related tests are in Aaarghs.java the modules > related tests for the launcher are at: > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=jsOjS1rgX4tfzJwE8Xif3NARZPRHb39Y64LvSdz1Jic%3D&reserved=0 > > Using the modules test framework may make the test simpler. > > > > Kumar Srinivasan > > > > > > On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski < > Nikola.Grcevski at microsoft.com> wrote: > > Hi Alan and Henry, > > > > Thank you for reviewing my email! Henry's observation matches mine, the > shared common code for all platforms in checkArg > (src/java.base/share/native/libjli/args.c) can potentially leave the > firstAppArgIndex static set to -1, if all passed command line arguments are > prefixed with a dash. Later on the arguments are validated, however we > might crash before then on Windows because of the negative index access. In > this case, the customer command was valid (modules usage) and the program > runs successfully. > > > > I created a webrev here for the change, including a new test in > Arrrghs.java: > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=lx%2FFVo5UOw3uhxgttVm2RKkoFPu8tmQtx0OwMvbTwJs%3D&reserved=0 > > > > I copied the test validation and assertion style of other code inside > the test class. > > > > Please let me know if you have any comments or suggestions. > > > > Thanks again! > > > > -----Original Message----- > > From: Henry Jen > > Sent: December 2, 2019 12:26 PM > > To: Alan Bateman > > Cc: Nikola Grcevski ; > core-libs-dev at openjdk.java.net > > Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > > > > The fix looks reasonable to me, basically, if the command argument > format is not legal, it?s possible we won?t find the main class when doing > argument file expansion, and the index is -1 which could cause crash on > Windows platform for the wildcard processing. > > > > I think we should add a test case for this, probably in > test/jdk/tools/launcher/Arrrghs.java. > > > > As I understand it, the argument validation is done in a later stage > after calling JLI_Launch. > > > > Cheers, > > Henry > > > > > > > On Dec 2, 2019, at 2:12 AM, Alan Bateman > wrote: > > > > > > On 20/11/2019 19:42, Nikola Grcevski wrote: > > >> : > > >> > > >> Please let me know if this approach is acceptable for the current bug > report and I'll make a webrev and include appropriate launcher tests. I was > thinking the tests should do extra validation on the output from > _JAVA_LAUNCHER_DEBUG on Windows. > > >> > > > I think you're in the right area but I would have expected the arg > index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > > > > > -Alan > > > > From erik.joelsson at oracle.com Wed Dec 4 22:14:21 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 Dec 2019 14:14:21 -0800 Subject: native debug symbols support on Windows In-Reply-To: References: <9F2FEA9C-202F-4413-B281-36C469B25A66@oracle.com> <45a8b20e-1e91-f2da-a431-8f775a216d03@oracle.com> Message-ID: <87a76d15-eabc-913b-bbd2-1ebf594d5f8c@oracle.com> On 2019-12-04 07:09, Langer, Christoph wrote: > Hi, > > thanks for your comments. > > The reason why I want to have (at least basic) internal debugging information is to have helpful callstacks in hs_err files on crashes. We go to rather great length to provide this in our testing. The bundles target creates a symbols bundle that can be overlayed on top of the main bundle. The RunTests.gmk makefile can be supplied with the variable SYMBOLS_IMAGE_DIR (which should point to where the symbols bundle is unzipped if it's separate to the main JDK image) and sets up _NT_SYMBOL_PATH when running tests. /Erik > > So, Bob, I don't think the executables can contain debug information, just the compiled .obj files. When it comes to linking, the linker either generates a pdb file or nothing. That's at least how I read the MSDN documentation (of linker options /debug [0] and /pdb [1]). > > Maybe an idea to implement "internal" debug symbols for Windows would be to copy the pdb files to the release bundle as well. But actually, it's a strange interpretation of "internal" in that case... > > Thanks > Christoph > > [0] https://docs.microsoft.com/en-us/cpp/build/reference/debug-generate-debug-info?view=vs-2019 > [1] https://docs.microsoft.com/en-us/cpp/build/reference/pdb-use-program-database?view=vs-2019 > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Mittwoch, 4. Dezember 2019 15:46 >> To: Bob Vandette >> Cc: Langer, Christoph ; build- >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev >> developers >> Subject: Re: native debug symbols support on Windows >> >> Hello, >> >> On 2019-12-04 06:26, Bob Vandette wrote: >>> There seems to be an option that will include debug information in >> generated .obj files. Assuming this option is supported in the >>> versions of Visual Studio we use, it could be used to implement ?internal? >> native debug symbols. >>> /Z7 >> We already use this when compiling, but we still link to external pdb >> files. I was not aware of being able to link with the symbol information >> internal. >> >> While this seems like it could be implemented, my question is, does >> anyone need it? The internal symbols on Linux was something the Linux >> distros wanted as they like to move it out in a uniform manner later. I >> can't really see a need for this on Windows, but I certainly wouldn't >> object if someone else do and wants to implement the support in the >> OpenJDK build. >> >> /Erik >> >>> The /Z7 option produces object files that also contain full symbolic >> debugging information for use with the debugger. These object files and the >> built executable can be substantially larger than files that have no debugging >> information. The symbolic debugging information includes the names and >> types of variables, as well as functions and line numbers. No PDB file is >> produced. >>> Bob. >>> >>> >>>> On Dec 4, 2019, at 9:11 AM, Erik Joelsson >> wrote: >>>> Correct, with the Microsoft toolchain there is no support for internal. I >> don't know what happens to the build if you try to configure it that way. Feel >> free to come up with a reasonable behavior. >>>> /Erik >>>> >>>> On 2019-12-04 00:06, Langer, Christoph wrote: >>>>> Hi, >>>>> >>>>> I'm currently looking into native debug symbols support for Windows. >>>>> >>>>> The OpenJDK build system supports these two configure flags --with- >> native-debug-symbols= (among a few other options >> which I don't want to discuss here). >>>>> So, the name implies that for "internal", debug symbols should be >> contained in the binaries. And "external" should create separate files that >> contain the debug symbols. However, to my knowledge, Windows would >> always make use of external symbol files, named *.pdb. And there is no way >> to have the debug symbols included in the binaries. Is that correct or am I >> wrong in this assumption? >>>>> If it's true, I guess --with-native-debug-symbols=internal would not >> make sense on Windows and should rather be rejected by configure. >> Otherwise, if we were to support --with-native-debug-symbols=internal, the >> build is broken for target "test-image" when it comes to building/copying the >> gtest image. >>>>> I'd like to fix either the one way or the other. What do people think? >>>>> >>>>> Thanks for your help >>>>> Christoph >>>>> From henry.jen at oracle.com Thu Dec 5 01:26:20 2019 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 4 Dec 2019 17:26:20 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: Message-ID: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> > On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: > > Hi Nikola, > > It looks ok to me, I will leave it to Henry and Alan to bless this. > > IMHO: I think we should fix it correctly now than later, I don't think it is all that > difficult AFAICT all the launcher has to do is identify "--module==", then > the next argument is the first index. > I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. I?ll let Alan to comment about the ?module option usage. The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. [1] https://docs.oracle.com/en/java/javase/13/docs/specs/man/java.html > Kumar > > On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: > Hi Henry and Kumar, > > Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. > > Please find my updated webrev here for your review: https://grcevski.github.io/JDK-8234076/webrev/ > > Cheers, > > Nikola > > -----Original Message----- > From: Henry Jen > Sent: December 3, 2019 11:39 AM > To: Kumar Srinivasan > Cc: Nikola Grcevski ; Alan Bateman ; core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > Kumar, > > Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. > > We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. > > Cheers, > Henry > > > On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: > > > > Hi, > > > > Sorry for chiming in late in the review process, for what it's worth.... > > > > 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class > > and subsequent crash, but it does not address wildcard arguments expansion. > > > > What if we have > > % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java > > Where jdk.compiler is a java compiler implementation (javac). > > The user would expect the above compiler module to build all the .java files in that directory, > > and this fix will not address that. > > > > Some background: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=9KSksL8%2BCmXSscF8oGGn5piLz2wApQ9paJUyZWbKWCw%3D&reserved=0 > > Please see all the related bugs in the above JIRA issue. > > > > Paragraph #6 in this interview surmises the wild card behavior on Windows: > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=l20J1AN4vBmT19gzBxLOktBsdv260F2rMWRvCLeVb84%3D&reserved=0 > > > > 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=jsOjS1rgX4tfzJwE8Xif3NARZPRHb39Y64LvSdz1Jic%3D&reserved=0 > > Using the modules test framework may make the test simpler. > > > > Kumar Srinivasan > > > > > > On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: > > Hi Alan and Henry, > > > > Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. > > > > I created a webrev here for the change, including a new test in Arrrghs.java: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C7b1b46aa46024285881108d7780f452c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637109879293524293&sdata=lx%2FFVo5UOw3uhxgttVm2RKkoFPu8tmQtx0OwMvbTwJs%3D&reserved=0 > > > > I copied the test validation and assertion style of other code inside the test class. > > > > Please let me know if you have any comments or suggestions. > > > > Thanks again! > > > > -----Original Message----- > > From: Henry Jen > > Sent: December 2, 2019 12:26 PM > > To: Alan Bateman > > Cc: Nikola Grcevski ; core-libs-dev at openjdk.java.net > > Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > > > > The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. > > > > I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. > > > > As I understand it, the argument validation is done in a later stage after calling JLI_Launch. > > > > Cheers, > > Henry > > > > > > > On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > > > > > > On 20/11/2019 19:42, Nikola Grcevski wrote: > > >> : > > >> > > >> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. > > >> > > > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > > > > > -Alan > > > From henry.jen at oracle.com Thu Dec 5 08:16:12 2019 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 5 Dec 2019 00:16:12 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Message-ID: Hi, Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. Changes to symbols is reverted, as we expect that only need to be updated in next release by running make/scripts/generate-symbol-data.sh. The jar files are confusing in the webrev, but those files are removed. The whole test/jdk/tools/pack200 is removed. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/jdk14/8234542/0/webrev/ > On Dec 2, 2019, at 6:50 PM, Joe Darcy wrote: > > Hi Vicente, > > It looks like the update to make/data/symbols/symbols removes the jdk.pack module from the history JDKs 9, 10, and 11 when --release is used. > > If that is the case, it would be incorrect since historically the jdk.pack module was present in those releases. > > Thanks, > > -Joe > > On 11/22/2019 1:30 PM, Vicente Romero wrote: >> Hi all, >> >> On 11/22/19 3:21 AM, Alan Bateman wrote: >>> >>> >>> On 21/11/2019 19:53, Vicente Romero wrote: >>>> Hi, >>>> >>>> I think I have covered all the proposed fixes so far. This is the last iteration of the webrev [1], all the current changes are in this one, the code hasn't been split into different webrevs. I'm also forwarding to build-dev as there are some build related changes too. The CSR for this change is at [2] >>> Would it be possible to summarize what will remain in test/jdk/tools/pack200 after this removal? The webrev makes it looks like badattr.jar is being added but since it already exists then I'm not sure whether to believe it. pack200-verifier/data/golden.jar is another one as it looks like JAR file that is generated by the tests today is being checked in, maybe `hg add` in error? >> >> I don't know why it is shown as added in the webrev, they have been removed. I have published another iteration of the webrev at [1] >>> >>> The change to flags-cflag.m4 to add LP64=1 on Windows will need eyes, it's not immediately obvious to me which shared code compiled on Windows is impacted by this. >> >> yes probably this change is risky. I did it as the comment suggested that the only reason the treatment for Windows was different was because of pack200. But not sure if we can trust that comment. Should I restore this code to its original state? >>> >>> -Alan >> >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8234542/webrev.03/ From Alan.Bateman at oracle.com Thu Dec 5 08:41:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Dec 2019 08:41:55 +0000 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> Message-ID: <8f08f1fd-db11-5709-0925-d6ccdcdf3e48@oracle.com> On 05/12/2019 08:16, Henry Jen wrote: > Hi, > > Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. > > Changes to symbols is reverted, as we expect that only need to be updated in next release by running make/scripts/generate-symbol-data.sh. > > The jar files are confusing in the webrev, but those files are removed. The whole test/jdk/tools/pack200 is removed. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/jdk14/8234542/0/webrev/ > The update webrev looks okay to me, except this part of the comment in flags-cflags.m4 "Now that unpack200 has been removed we should consider setting it for windows too. but this could be done as a follow-up effort. It could be that other other clients are relying on the current configuration for windows". I think it would be best to create an infrastructure/build issue and leave most of this? confusing comment out. -Alan. From martin.doerr at sap.com Thu Dec 5 10:59:59 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 5 Dec 2019 10:59:59 +0000 Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array In-Reply-To: References: Message-ID: Hi Thomas and Christoph, thanks for the reviews. Other code in java.security.jgss also uses these #defined checks: src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER) I?d like to have it consistent with that. @Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it? Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned. (AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too: https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html) Best regards, Martin From: Thomas St?fe Sent: Mittwoch, 4. Dezember 2019 17:56 To: Doerr, Martin Cc: core-libs-dev at openjdk.java.net; security-dev ; Lindenmaier, Goetz Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Martin, this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal. +#if defined (_WIN32) && defined (_MSC_VER) Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++? Cheers, Thomas On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin > wrote: Hi, I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport): https://bugs.openjdk.java.net/browse/JDK-8220348 Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer. jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted). However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default. I found such issues in the following files: src/java.prefs/windows/native/libprefs/WindowsPreferences.c src/java.security.jgss/share/native/libj2gss/GSSLibStub.c I suggest to use __declspec(align(8)) there. Webrev: http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/ Please review. I think using 8 byte alignment is not a disadvantage for 64 bit. I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix. Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack? Best regards, Martin From christoph.langer at sap.com Thu Dec 5 11:16:23 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Dec 2019 11:16:23 +0000 Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array In-Reply-To: References: Message-ID: Hi Martin, I can see that both places already include headers from src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. WindowsPreferences.c already includes it. Best regards Christoph From: Doerr, Martin Sent: Donnerstag, 5. Dezember 2019 12:00 To: Thomas St?fe ; Langer, Christoph Cc: core-libs-dev at openjdk.java.net; security-dev ; Lindenmaier, Goetz Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Thomas and Christoph, thanks for the reviews. Other code in java.security.jgss also uses these #defined checks: src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER) I?d like to have it consistent with that. @Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it? Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned. (AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too: https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html) Best regards, Martin From: Thomas St?fe > Sent: Mittwoch, 4. Dezember 2019 17:56 To: Doerr, Martin > Cc: core-libs-dev at openjdk.java.net; security-dev >; Lindenmaier, Goetz > Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Martin, this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal. +#if defined (_WIN32) && defined (_MSC_VER) Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++? Cheers, Thomas On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin > wrote: Hi, I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport): https://bugs.openjdk.java.net/browse/JDK-8220348 Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer. jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted). However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default. I found such issues in the following files: src/java.prefs/windows/native/libprefs/WindowsPreferences.c src/java.security.jgss/share/native/libj2gss/GSSLibStub.c I suggest to use __declspec(align(8)) there. Webrev: http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/ Please review. I think using 8 byte alignment is not a disadvantage for 64 bit. I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix. Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack? Best regards, Martin From christoph.langer at sap.com Thu Dec 5 11:55:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Dec 2019 11:55:19 +0000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> Message-ID: Hi David, thanks again for your efforts. Here is a version that ran successfully through jdk-submit (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172): http://cr.openjdk.java.net/~clanger/webrevs/8234185.2/ I avoid the inclusion of jdk_util.h in src/java.base/windows/native/libjava/canonicalize_md.c. Do you think this is good to go? Somebody in Oracle could then eventually clean up things by decoupling the installer from OpenJDK's canonicalize_md.c. I'd open a bug for this. Thanks Christoph > -----Original Message----- > From: David Holmes > Sent: Dienstag, 3. Dezember 2019 23:52 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net; Alan Bateman ; gerard > ziemski > Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between > libjava, hotspot and libinstrument > > Hi Christoph, > > On 3/12/2019 7:26 pm, Langer, Christoph wrote: > > Hi David, > > > > thanks for taking care of this. > > > > This would be my updated patch that could hopefully be enabled by just > adding the include directory where "jdk_util.h" is located. It would be really > great if that'd work. I think it would open up a path to automatically include > io_util_md.h by including io_util.h. > > > > http://cr.openjdk.java.net/~clanger/webrevs/8234185.1/ > > I'm afraid I cannot get this to work at our end. I get the following errors: > > t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): > error C2143: syntax error: missing ')' before '*' > t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): > error C2143: syntax error: missing '{' before '*' > t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): > warning C4142: 'size_t': benign redefinition of type > C:\ade\mesos\work_dir\jib- > ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ > e\vcruntime.h(184): > note: see declaration of 'size_t' > t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): > error C2370: 'size_t': redefinition; different storage class > C:\ade\mesos\work_dir\jib- > ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ > e\vcruntime.h(184): > note: see declaration of 'size_t' > t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): > error C2146: syntax error: missing ';' before identifier 'info_size' > t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): > error C2059: syntax error: ')' > > This pertains to the line: > > JDK_GetVersionInfo0(jdk_version_info* info, size_t info_size); > > There is also a second problem in our closed code that will take more > effort from someone familiar with that code to resolve. I will file an > issue for our install team to pick up. > > I would ask that this not be pushed for the moment while others figure > out how best to handle this. > > Thanks, > David > ----- > > > > Cheers > > Christoph > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Dienstag, 3. Dezember 2019 03:13 > >> To: Langer, Christoph ; Alan Bateman > >> ; gerard ziemski > > >> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function > between > >> libjava, hotspot and libinstrument > >> > >> Hi Christoph, > >> > >> Can you please post your updated patch for review and I will use it to > >> check the fix for our internal build. Once you have your fix reviewed I > >> will push both fixes together. > >> > >> Thanks, > >> David > >> > >> On 25/11/2019 10:41 pm, David Holmes wrote: > >>> Hi Christoph, > >>> > >>> On 25/11/2019 10:38 pm, Langer, Christoph wrote: > >>>> Hi David, > >>>> > >>>> thanks for your investigation. I'll prepare a fix to move back > >>>> getPrefixed into canonicalize_md.c. However, could you please still > >>>> fix your internal build in terms that it would have 'jdk_util.h' in > >>>> the include path? > >>> > >>> That should be simple enough to do. > >>> > >>> David > >>> > >>>> Thanks > >>>> Christoph > >>>> > >>>>> -----Original Message----- > >>>>> From: David Holmes > >>>>> Sent: Montag, 25. November 2019 01:02 > >>>>> To: Langer, Christoph ; Alan Bateman > >>>>> ; gerard ziemski > >> > >>>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > >>>>> dev at openjdk.java.net > >>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function > >>>>> between > >>>>> libjava, hotspot and libinstrument > >>>>> > >>>>> > >>>>> > >>>>> On 25/11/2019 8:45 am, David Holmes wrote: > >>>>>> On 25/11/2019 7:49 am, David Holmes wrote: > >>>>>>> On 25/11/2019 7:33 am, David Holmes wrote: > >>>>>>>> Hi Christoph, > >>>>>>>> > >>>>>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I'd like to push this change. However, running it through jdk- > submit > >>>>>>>>> shows reproducible errors: > >>>>>>>>> > >>>>>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 > >>>>>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source > >>>>>>>>> No failed tests > >>>>>>>>> Tasks Summary > >>>>>>>>> ???? NA: 0 > >>>>>>>>> ???? NOTHING_TO_RUN: 0 > >>>>>>>>> ???? KILLED: 0 > >>>>>>>>> ???? PASSED: 76 > >>>>>>>>> ???? UNABLE_TO_RUN: 0 > >>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 > >>>>>>>>> ???? FAILED: 0 > >>>>>>>>> ???? HARNESS_ERROR: 0 > >>>>>>>>> Build > >>>>>>>>> 1 Executed with failure > >>>>>>>>> o??? windows-x64-install-windows-x64-build-19 error while > building, > >>>>>>>>> return value: 2 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 > >>>>>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source > >>>>>>>>> No failed tests > >>>>>>>>> Tasks Summary > >>>>>>>>> ???? NA: 0 > >>>>>>>>> ???? NOTHING_TO_RUN: 0 > >>>>>>>>> ???? KILLED: 0 > >>>>>>>>> ???? PASSED: 76 > >>>>>>>>> ???? UNABLE_TO_RUN: 0 > >>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 > >>>>>>>>> ???? FAILED: 0 > >>>>>>>>> ???? HARNESS_ERROR: 0 > >>>>>>>>> Build > >>>>>>>>> 1 Executed with failure > >>>>>>>>> o??? windows-x64-install-windows-x64-build-19 error while > building, > >>>>>>>>> return value: 2 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> David already had a look and let me know that the following was > >> the > >>>>>>>>> reason: > >>>>>>>>> > >>>>>>>>> > >>>>> > >> > t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. > >>>>> c(41): > >>>>>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such > >>>>>>>>> file or directory > >>>>>>>>> > >>>>>>>>> This is not explainable to me as I see this running through my > local > >>>>>>>>> build and our nightly builds without problems. I also can't explain > >>>>>>>>> jdk_util.h can't be opened at this place - it should be there and > >>>>>>>>> part of the include directories... > >>>>>>>>> > >>>>>>>>> I'd appreciate any help... > >>>>>>>> > >>>>>>>> I just dug a little deeper and this is failing in part of our closed > >>>>>>>> build for the install repo. There is a library there that is using > >>>>>>>> canonicalize_md.c directly - i.e. it adds that file to its source > >>>>>>>> files list. The build instructions don't include that directory on > >>>>>>>> the include directory list - hence the failure. But it will also fail > >>>>>>>> due to the name change you made. > >>>>>>> > >>>>>>> Actually it appears that the other source code doesn't actually refer > >>>>>>> to the canonicalize function at all, so a simple fix may be possible > >>>>>>> at the build level on our side. I'm testing that now. > >>>>>> > >>>>>> It isn't the canonicalize function that is used, it is getPrefixed, > >>>>>> which has now been moved to the io_util_md.c file. So a fix will be a > >>>>>> bit more involved. > >>>>> > >>>>> I tried adding io_util_md.c to the library source list instead of > >>>>> canonicalize_md.c but that just caused a slew of other compilation > >>>>> failures, so I don't see any quick fix for us here. > >>>>> > >>>>> David > >>>>> > >>>>>> > >>>>>> David > >>>>>> > >>>>>>> > >>>>>>> David > >>>>>>> ----- > >>>>>>> > >>>>>>>> Someone will need to work with you to make the necessary > changes > >> to > >>>>>>>> our code. > >>>>>>>> > >>>>>>>> David > >>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> Christoph > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Langer, Christoph > >>>>>>>>>> Sent: Donnerstag, 21. November 2019 14:19 > >>>>>>>>>> To: Alan Bateman ; core-libs- > >>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > >>>>>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize > function > >>>>>>>>>> between > >>>>>>>>>> libjava, hotspot and libinstrument > >>>>>>>>>> > >>>>>>>>>> Hi Alan, > >>>>>>>>>> > >>>>>>>>>> thanks for the review. I'll push it then after running through > >>>>>>>>>> jdk-submit. > >>>>>>>>>> > >>>>>>>>>> /Christoph > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Alan Bateman > >>>>>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 > >>>>>>>>>>> To: Langer, Christoph ; core-libs- > >>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize > >> function > >>>>>>>>>>> between > >>>>>>>>>>> libjava, hotspot and libinstrument > >>>>>>>>>>> > >>>>>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: > >>>>>>>>>>>> Hi, > >>>>>>>>>>>> > >>>>>>>>>>>> please review this cleanup change regarding function > >>>>>>>>>>>> "canonicalize" of > >>>>>>>>>>> libjava. > >>>>>>>>>>>> > >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 > >>>>>>>>>>>> Webrev: > >> http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> The goal is to cleanup how this function is defined and used. > >> One > >>>>>>>>>>>> thing is, > >>>>>>>>>>> that there was an unnecessary wrapper function > "Canonicalize" > >> in > >>>>>>>>>>> jni_util.c. > >>>>>>>>>>> It wrapped the call to "canonicalize". We can get rid of this > >>>>>>>>>>> wrapper. > >>>>>>>>>>> Unfortunately, it is not possible to just export "canonicalize" > >>>>>>>>>>> since this will > >>>>>>>>>>> conflict with a method signature from the math library, at > least > >>>>>>>>>>> on modern > >>>>>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and > >> will > >>>>>>>>>>> correctly > >>>>>>>>>>> define it in jdk_util.h which can be included everywhere. > >>>>>>>>>>>> > >>>>>>>>>>> I think this change is okay. My main concern when initially > seeing > >>>>>>>>>>> this > >>>>>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into > the > >>>>>>>>>>> canonical File when it wasn't there previously, this would of > >>>>>>>>>>> course > >>>>>>>>>>> have several implications. But I think you have it right and this > >>>>>>>>>>> is, as > >>>>>>>>>>> you position, just refactoring/cleanup. > >>>>>>>>>>> > >>>>>>>>>>> -Alan From david.holmes at oracle.com Thu Dec 5 13:00:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Dec 2019 23:00:23 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> Message-ID: <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> Hi Christoph, On 5/12/2019 9:55 pm, Langer, Christoph wrote: > Hi David, > > thanks again for your efforts. > > Here is a version that ran successfully through jdk-submit (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172): http://cr.openjdk.java.net/~clanger/webrevs/8234185.2/ > > I avoid the inclusion of jdk_util.h in src/java.base/windows/native/libjava/canonicalize_md.c. Do you think this is good to go? Avoiding the include does seem to be the way to go. That seems so obvious now. src/java.base/windows/native/libjava/canonicalize_md.c +// We can't include jdk_util.h here because the file is used in Oracle in another context +// #include "jdk_util.h" Seems to me clients of JDK_Canonicalize need to include jdk_util.h, not the files that implement it. So there is no reason to include it here and so no need for the comment. Further, does: src/java.base/unix/native/libjava/canonicalize_md.c need to include jdk_util.h? I think not. +/* The appropriate location of getPrefixed() is io_util_md.c, but it is + also used in a non-OpenJDK context within Oracle. There, canonicalize_md.c + is already pulled in and compiled, so to avoid more complicate solutions + we keep this method here. */ I don't like to have comments like this but I guess it is needed here. Please put the */ on a newline. Also s/complicate/complicates/ src/java.base/windows/native/libjava/io_util_md.c should now be unchanged, but you've left in the copyright update. A second review is still needed for the final version of this. Thanks, David > Somebody in Oracle could then eventually clean up things by decoupling the installer from OpenJDK's canonicalize_md.c. I'd open a bug for this. > > Thanks > Christoph > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 3. Dezember 2019 23:52 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net; Alan Bateman ; gerard >> ziemski >> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between >> libjava, hotspot and libinstrument >> >> Hi Christoph, >> >> On 3/12/2019 7:26 pm, Langer, Christoph wrote: >>> Hi David, >>> >>> thanks for taking care of this. >>> >>> This would be my updated patch that could hopefully be enabled by just >> adding the include directory where "jdk_util.h" is located. It would be really >> great if that'd work. I think it would open up a path to automatically include >> io_util_md.h by including io_util.h. >>> >>> http://cr.openjdk.java.net/~clanger/webrevs/8234185.1/ >> >> I'm afraid I cannot get this to work at our end. I get the following errors: >> >> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >> error C2143: syntax error: missing ')' before '*' >> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >> error C2143: syntax error: missing '{' before '*' >> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >> warning C4142: 'size_t': benign redefinition of type >> C:\ade\mesos\work_dir\jib- >> ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ >> e\vcruntime.h(184): >> note: see declaration of 'size_t' >> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >> error C2370: 'size_t': redefinition; different storage class >> C:\ade\mesos\work_dir\jib- >> ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ >> e\vcruntime.h(184): >> note: see declaration of 'size_t' >> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >> error C2146: syntax error: missing ';' before identifier 'info_size' >> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >> error C2059: syntax error: ')' >> >> This pertains to the line: >> >> JDK_GetVersionInfo0(jdk_version_info* info, size_t info_size); >> >> There is also a second problem in our closed code that will take more >> effort from someone familiar with that code to resolve. I will file an >> issue for our install team to pick up. >> >> I would ask that this not be pushed for the moment while others figure >> out how best to handle this. >> >> Thanks, >> David >> ----- >> >> >>> Cheers >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Dienstag, 3. Dezember 2019 03:13 >>>> To: Langer, Christoph ; Alan Bateman >>>> ; gerard ziemski >> >>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >> between >>>> libjava, hotspot and libinstrument >>>> >>>> Hi Christoph, >>>> >>>> Can you please post your updated patch for review and I will use it to >>>> check the fix for our internal build. Once you have your fix reviewed I >>>> will push both fixes together. >>>> >>>> Thanks, >>>> David >>>> >>>> On 25/11/2019 10:41 pm, David Holmes wrote: >>>>> Hi Christoph, >>>>> >>>>> On 25/11/2019 10:38 pm, Langer, Christoph wrote: >>>>>> Hi David, >>>>>> >>>>>> thanks for your investigation. I'll prepare a fix to move back >>>>>> getPrefixed into canonicalize_md.c. However, could you please still >>>>>> fix your internal build in terms that it would have 'jdk_util.h' in >>>>>> the include path? >>>>> >>>>> That should be simple enough to do. >>>>> >>>>> David >>>>> >>>>>> Thanks >>>>>> Christoph >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes >>>>>>> Sent: Montag, 25. November 2019 01:02 >>>>>>> To: Langer, Christoph ; Alan Bateman >>>>>>> ; gerard ziemski >>>> >>>>>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>> between >>>>>>> libjava, hotspot and libinstrument >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 25/11/2019 8:45 am, David Holmes wrote: >>>>>>>> On 25/11/2019 7:49 am, David Holmes wrote: >>>>>>>>> On 25/11/2019 7:33 am, David Holmes wrote: >>>>>>>>>> Hi Christoph, >>>>>>>>>> >>>>>>>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'd like to push this change. However, running it through jdk- >> submit >>>>>>>>>>> shows reproducible errors: >>>>>>>>>>> >>>>>>>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>>>>>>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source >>>>>>>>>>> No failed tests >>>>>>>>>>> Tasks Summary >>>>>>>>>>> ???? NA: 0 >>>>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>>>> ???? KILLED: 0 >>>>>>>>>>> ???? PASSED: 76 >>>>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>>>> ???? FAILED: 0 >>>>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>>>> Build >>>>>>>>>>> 1 Executed with failure >>>>>>>>>>> o??? windows-x64-install-windows-x64-build-19 error while >> building, >>>>>>>>>>> return value: 2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>>>>>>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source >>>>>>>>>>> No failed tests >>>>>>>>>>> Tasks Summary >>>>>>>>>>> ???? NA: 0 >>>>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>>>> ???? KILLED: 0 >>>>>>>>>>> ???? PASSED: 76 >>>>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>>>> ???? FAILED: 0 >>>>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>>>> Build >>>>>>>>>>> 1 Executed with failure >>>>>>>>>>> o??? windows-x64-install-windows-x64-build-19 error while >> building, >>>>>>>>>>> return value: 2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David already had a look and let me know that the following was >>>> the >>>>>>>>>>> reason: >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>> >> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. >>>>>>> c(41): >>>>>>>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': No such >>>>>>>>>>> file or directory >>>>>>>>>>> >>>>>>>>>>> This is not explainable to me as I see this running through my >> local >>>>>>>>>>> build and our nightly builds without problems. I also can't explain >>>>>>>>>>> jdk_util.h can't be opened at this place - it should be there and >>>>>>>>>>> part of the include directories... >>>>>>>>>>> >>>>>>>>>>> I'd appreciate any help... >>>>>>>>>> >>>>>>>>>> I just dug a little deeper and this is failing in part of our closed >>>>>>>>>> build for the install repo. There is a library there that is using >>>>>>>>>> canonicalize_md.c directly - i.e. it adds that file to its source >>>>>>>>>> files list. The build instructions don't include that directory on >>>>>>>>>> the include directory list - hence the failure. But it will also fail >>>>>>>>>> due to the name change you made. >>>>>>>>> >>>>>>>>> Actually it appears that the other source code doesn't actually refer >>>>>>>>> to the canonicalize function at all, so a simple fix may be possible >>>>>>>>> at the build level on our side. I'm testing that now. >>>>>>>> >>>>>>>> It isn't the canonicalize function that is used, it is getPrefixed, >>>>>>>> which has now been moved to the io_util_md.c file. So a fix will be a >>>>>>>> bit more involved. >>>>>>> >>>>>>> I tried adding io_util_md.c to the library source list instead of >>>>>>> canonicalize_md.c but that just caused a slew of other compilation >>>>>>> failures, so I don't see any quick fix for us here. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Someone will need to work with you to make the necessary >> changes >>>> to >>>>>>>>>> our code. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Christoph >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Langer, Christoph >>>>>>>>>>>> Sent: Donnerstag, 21. November 2019 14:19 >>>>>>>>>>>> To: Alan Bateman ; core-libs- >>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >>>>>>>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize >> function >>>>>>>>>>>> between >>>>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>>>> >>>>>>>>>>>> Hi Alan, >>>>>>>>>>>> >>>>>>>>>>>> thanks for the review. I'll push it then after running through >>>>>>>>>>>> jdk-submit. >>>>>>>>>>>> >>>>>>>>>>>> /Christoph >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Alan Bateman >>>>>>>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>>>>>>>>>> To: Langer, Christoph ; core-libs- >>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize >>>> function >>>>>>>>>>>>> between >>>>>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>>>>> >>>>>>>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> please review this cleanup change regarding function >>>>>>>>>>>>>> "canonicalize" of >>>>>>>>>>>>> libjava. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>>>>>>>>>> Webrev: >>>> http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The goal is to cleanup how this function is defined and used. >>>> One >>>>>>>>>>>>>> thing is, >>>>>>>>>>>>> that there was an unnecessary wrapper function >> "Canonicalize" >>>> in >>>>>>>>>>>>> jni_util.c. >>>>>>>>>>>>> It wrapped the call to "canonicalize". We can get rid of this >>>>>>>>>>>>> wrapper. >>>>>>>>>>>>> Unfortunately, it is not possible to just export "canonicalize" >>>>>>>>>>>>> since this will >>>>>>>>>>>>> conflict with a method signature from the math library, at >> least >>>>>>>>>>>>> on modern >>>>>>>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize and >>>> will >>>>>>>>>>>>> correctly >>>>>>>>>>>>> define it in jdk_util.h which can be included everywhere. >>>>>>>>>>>>>> >>>>>>>>>>>>> I think this change is okay. My main concern when initially >> seeing >>>>>>>>>>>>> this >>>>>>>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix into >> the >>>>>>>>>>>>> canonical File when it wasn't there previously, this would of >>>>>>>>>>>>> course >>>>>>>>>>>>> have several implications. But I think you have it right and this >>>>>>>>>>>>> is, as >>>>>>>>>>>>> you position, just refactoring/cleanup. >>>>>>>>>>>>> >>>>>>>>>>>>> -Alan From harold.seigel at oracle.com Thu Dec 5 14:36:29 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 5 Dec 2019 09:36:29 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() Message-ID: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Solaris, Windows, and Mac OS X, by running Mach5 tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on Linux-x64. Thanks, Harold From frederic.parain at oracle.com Thu Dec 5 14:50:17 2019 From: frederic.parain at oracle.com (Frederic Parain) Date: Thu, 5 Dec 2019 09:50:17 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: References: Message-ID: <9BD865A5-7CA4-47C1-8B72-C0801717B476@oracle.com> Looks good to me. Fred > On Dec 5, 2019, at 09:36, Harold Seigel wrote: > > Hi, > > Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Solaris, Windows, and Mac OS X, by running Mach5 tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on Linux-x64. > > Thanks, Harold > From harold.seigel at oracle.com Thu Dec 5 14:50:47 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 5 Dec 2019 09:50:47 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: <9BD865A5-7CA4-47C1-8B72-C0801717B476@oracle.com> References: <9BD865A5-7CA4-47C1-8B72-C0801717B476@oracle.com> Message-ID: <29a00916-4f03-f5bc-e97a-9c0c868c6b8c@oracle.com> Thanks Fred! Harold On 12/5/2019 9:50 AM, Frederic Parain wrote: > Looks good to me. > > Fred > > >> On Dec 5, 2019, at 09:36, Harold Seigel wrote: >> >> Hi, >> >> Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Solaris, Windows, and Mac OS X, by running Mach5 tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on Linux-x64. >> >> Thanks, Harold >> From lois.foltan at oracle.com Thu Dec 5 14:55:22 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 5 Dec 2019 09:55:22 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: References: Message-ID: <7b9fdf97-c23a-6c63-584a-24342f2b6160@oracle.com> Looks good. Lois On 12/5/2019 9:36 AM, Harold Seigel wrote: > Hi, > > Please review this small change to simplify > Class.getRecordComponents() by changing the return type of > getRecordComponents0() to RecordComponent[]. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Solaris, Windows, and Mac OS X, by running Mach5 > tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on Linux-x64. > > Thanks, Harold > From chris.hegarty at oracle.com Thu Dec 5 14:56:46 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 Dec 2019 14:56:46 +0000 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: References: Message-ID: > On 5 Dec 2019, at 14:36, Harold Seigel wrote: > > Hi, > > Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html LGTM. -Chris. P.S. Further changes in this area are being discussed on amber-spec-experts - https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001840.html From harold.seigel at oracle.com Thu Dec 5 15:17:22 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 5 Dec 2019 10:17:22 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: References: Message-ID: <751b8b59-23ae-ae4d-c231-a42d66555411@oracle.com> Thanks Lois and Chris! Harold On 12/5/2019 9:56 AM, Chris Hegarty wrote: > > >> On 5 Dec 2019, at 14:36, Harold Seigel > > wrote: >> >> Hi, >> >> Please review this small change to simplify >> Class.getRecordComponents() by changing the return type of >> getRecordComponents0() to RecordComponent[]. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html > > LGTM. > > -Chris. > > P.S. Further changes in this area are being discussed on > amber-spec-experts - > https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001840.html > From daniel.daugherty at oracle.com Thu Dec 5 16:06:58 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 5 Dec 2019 11:06:58 -0500 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> Message-ID: <958c573a-515f-845f-8096-9ec15419d30b@oracle.com> On 12/5/19 8:00 AM, David Holmes wrote: > Hi Christoph, > > On 5/12/2019 9:55 pm, Langer, Christoph wrote: >> Hi David, >> >> thanks again for your efforts. >> >> Here is a version that ran successfully through jdk-submit >> (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172): >> http://cr.openjdk.java.net/~clanger/webrevs/8234185.2/ >> >> I avoid the inclusion of jdk_util.h in >> src/java.base/windows/native/libjava/canonicalize_md.c. Do you think >> this is good to go? > > Avoiding the include does seem to be the way to go. That seems so > obvious now. > > src/java.base/windows/native/libjava/canonicalize_md.c > > +// We can't include jdk_util.h here because the file is used in > Oracle in another context > +// #include "jdk_util.h" > > Seems to me clients of JDK_Canonicalize need to include jdk_util.h, > not the files that implement it. So there is no reason to include it > here and so no need for the comment. Further, does: > > src/java.base/unix/native/libjava/canonicalize_md.c > > need to include jdk_util.h? I think not. > > +/* The appropriate location of getPrefixed() is io_util_md.c, but it is > +?? also used in a non-OpenJDK context within Oracle. There, > canonicalize_md.c > +?? is already pulled in and compiled, so to avoid more complicate > solutions > +?? we keep this method here. */ > > I don't like to have comments like this but I guess it is needed here. > Please put the */ on a newline. Also s/complicate/complicates/ It should be: s/complicate/complicated/ Dan > > src/java.base/windows/native/libjava/io_util_md.c > > should now be unchanged, but you've left in the copyright update. > > A second review is still needed for the final version of this. > > Thanks, > David > > >> Somebody in Oracle could then eventually clean up things by >> decoupling the installer from OpenJDK's canonicalize_md.c. I'd open a >> bug for this. >> >> Thanks >> Christoph >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Dienstag, 3. Dezember 2019 23:52 >>> To: Langer, Christoph >>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>> dev at openjdk.java.net; Alan Bateman ; gerard >>> ziemski >>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>> between >>> libjava, hotspot and libinstrument >>> >>> Hi Christoph, >>> >>> On 3/12/2019 7:26 pm, Langer, Christoph wrote: >>>> Hi David, >>>> >>>> thanks for taking care of this. >>>> >>>> This would be my updated patch that could hopefully be enabled by just >>> adding the include directory where "jdk_util.h" is located. It would >>> be really >>> great if that'd work. I think it would open up a path to >>> automatically include >>> io_util_md.h by including io_util.h. >>>> >>>> http://cr.openjdk.java.net/~clanger/webrevs/8234185.1/ >>> >>> I'm afraid I cannot get this to work at our end. I get the following >>> errors: >>> >>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>> error C2143: syntax error: missing ')' before '*' >>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>> error C2143: syntax error: missing '{' before '*' >>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>> warning C4142: 'size_t': benign redefinition of type >>> C:\ade\mesos\work_dir\jib- >>> ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ >>> >>> e\vcruntime.h(184): >>> note: see declaration of 'size_t' >>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>> error C2370: 'size_t': redefinition; different storage class >>> C:\ade\mesos\work_dir\jib- >>> ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ >>> >>> e\vcruntime.h(184): >>> note: see declaration of 'size_t' >>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>> error C2146: syntax error: missing ';' before identifier 'info_size' >>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>> error C2059: syntax error: ')' >>> >>> This pertains to the line: >>> >>> JDK_GetVersionInfo0(jdk_version_info* info, size_t info_size); >>> >>> There is also a second problem in our closed code that will take more >>> effort from someone familiar with that code to resolve. I will file an >>> issue for our install team to pick up. >>> >>> I would ask that this not be pushed for the moment while others figure >>> out how best to handle this. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> Cheers >>>> Christoph >>>> >>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: Dienstag, 3. Dezember 2019 03:13 >>>>> To: Langer, Christoph ; Alan Bateman >>>>> ; gerard ziemski >>> >>>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>> between >>>>> libjava, hotspot and libinstrument >>>>> >>>>> Hi Christoph, >>>>> >>>>> Can you please post your updated patch for review and I will use >>>>> it to >>>>> check the fix for our internal build. Once you have your fix >>>>> reviewed I >>>>> will push both fixes together. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 25/11/2019 10:41 pm, David Holmes wrote: >>>>>> Hi Christoph, >>>>>> >>>>>> On 25/11/2019 10:38 pm, Langer, Christoph wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> thanks for your investigation. I'll prepare a fix to move back >>>>>>> getPrefixed into canonicalize_md.c. However, could you please still >>>>>>> fix your internal build in terms that it would have 'jdk_util.h' in >>>>>>> the include path? >>>>>> >>>>>> That should be simple enough to do. >>>>>> >>>>>> David >>>>>> >>>>>>> Thanks >>>>>>> Christoph >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes >>>>>>>> Sent: Montag, 25. November 2019 01:02 >>>>>>>> To: Langer, Christoph ; Alan Bateman >>>>>>>> ; gerard ziemski >>>>> >>>>>>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>>>>>> dev at openjdk.java.net >>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>>> between >>>>>>>> libjava, hotspot and libinstrument >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 25/11/2019 8:45 am, David Holmes wrote: >>>>>>>>> On 25/11/2019 7:49 am, David Holmes wrote: >>>>>>>>>> On 25/11/2019 7:33 am, David Holmes wrote: >>>>>>>>>>> Hi Christoph, >>>>>>>>>>> >>>>>>>>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I'd like to push this change. However, running it through jdk- >>> submit >>>>>>>>>>>> shows reproducible errors: >>>>>>>>>>>> >>>>>>>>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>>>>>>>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source >>>>>>>>>>>> No failed tests >>>>>>>>>>>> Tasks Summary >>>>>>>>>>>> ???? NA: 0 >>>>>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>>>>> ???? KILLED: 0 >>>>>>>>>>>> ???? PASSED: 76 >>>>>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>>>>> ???? FAILED: 0 >>>>>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>>>>> Build >>>>>>>>>>>> 1 Executed with failure >>>>>>>>>>>> o windows-x64-install-windows-x64-build-19 error while >>> building, >>>>>>>>>>>> return value: 2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>>>>>>>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source >>>>>>>>>>>> No failed tests >>>>>>>>>>>> Tasks Summary >>>>>>>>>>>> ???? NA: 0 >>>>>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>>>>> ???? KILLED: 0 >>>>>>>>>>>> ???? PASSED: 76 >>>>>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>>>>> ???? FAILED: 0 >>>>>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>>>>> Build >>>>>>>>>>>> 1 Executed with failure >>>>>>>>>>>> o windows-x64-install-windows-x64-build-19 error while >>> building, >>>>>>>>>>>> return value: 2 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David already had a look and let me know that the following >>>>>>>>>>>> was >>>>> the >>>>>>>>>>>> reason: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>> >>> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. >>>>>>>> c(41): >>>>>>>>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': >>>>>>>>>>>> No such >>>>>>>>>>>> file or directory >>>>>>>>>>>> >>>>>>>>>>>> This is not explainable to me as I see this running through my >>> local >>>>>>>>>>>> build and our nightly builds without problems. I also can't >>>>>>>>>>>> explain >>>>>>>>>>>> jdk_util.h can't be opened at this place - it should be >>>>>>>>>>>> there and >>>>>>>>>>>> part of the include directories... >>>>>>>>>>>> >>>>>>>>>>>> I'd appreciate any help... >>>>>>>>>>> >>>>>>>>>>> I just dug a little deeper and this is failing in part of >>>>>>>>>>> our closed >>>>>>>>>>> build for the install repo. There is a library there that is >>>>>>>>>>> using >>>>>>>>>>> canonicalize_md.c directly - i.e. it adds that file to its >>>>>>>>>>> source >>>>>>>>>>> files list. The build instructions don't include that >>>>>>>>>>> directory on >>>>>>>>>>> the include directory list - hence the failure. But it will >>>>>>>>>>> also fail >>>>>>>>>>> due to the name change you made. >>>>>>>>>> >>>>>>>>>> Actually it appears that the other source code doesn't >>>>>>>>>> actually refer >>>>>>>>>> to the canonicalize function at all, so a simple fix may be >>>>>>>>>> possible >>>>>>>>>> at the build level on our side. I'm testing that now. >>>>>>>>> >>>>>>>>> It isn't the canonicalize function that is used, it is >>>>>>>>> getPrefixed, >>>>>>>>> which has now been moved to the io_util_md.c file. So a fix >>>>>>>>> will be a >>>>>>>>> bit more involved. >>>>>>>> >>>>>>>> I tried adding io_util_md.c to the library source list instead of >>>>>>>> canonicalize_md.c but that just caused a slew of other compilation >>>>>>>> failures, so I don't see any quick fix for us here. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Someone will need to work with you to make the necessary >>> changes >>>>> to >>>>>>>>>>> our code. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Christoph >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Langer, Christoph >>>>>>>>>>>>> Sent: Donnerstag, 21. November 2019 14:19 >>>>>>>>>>>>> To: Alan Bateman ; core-libs- >>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>> dev at openjdk.java.net >>>>>>>>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize >>> function >>>>>>>>>>>>> between >>>>>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for the review. I'll push it then after running >>>>>>>>>>>>> through >>>>>>>>>>>>> jdk-submit. >>>>>>>>>>>>> >>>>>>>>>>>>> /Christoph >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Alan Bateman >>>>>>>>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>>>>>>>>>>> To: Langer, Christoph ; core-libs- >>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize >>>>> function >>>>>>>>>>>>>> between >>>>>>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> please review this cleanup change regarding function >>>>>>>>>>>>>>> "canonicalize" of >>>>>>>>>>>>>> libjava. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>>>>>>>>>>> Webrev: >>>>> http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The goal is to cleanup how this function is defined and >>>>>>>>>>>>>>> used. >>>>> One >>>>>>>>>>>>>>> thing is, >>>>>>>>>>>>>> that there was an unnecessary wrapper function >>> "Canonicalize" >>>>> in >>>>>>>>>>>>>> jni_util.c. >>>>>>>>>>>>>> It wrapped the call to "canonicalize". We can get rid of >>>>>>>>>>>>>> this >>>>>>>>>>>>>> wrapper. >>>>>>>>>>>>>> Unfortunately, it is not possible to just export >>>>>>>>>>>>>> "canonicalize" >>>>>>>>>>>>>> since this will >>>>>>>>>>>>>> conflict with a method signature from the math library, at >>> least >>>>>>>>>>>>>> on modern >>>>>>>>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize >>>>>>>>>>>>>> and >>>>> will >>>>>>>>>>>>>> correctly >>>>>>>>>>>>>> define it in jdk_util.h which can be included everywhere. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I think this change is okay. My main concern when initially >>> seeing >>>>>>>>>>>>>> this >>>>>>>>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix >>>>>>>>>>>>>> into >>> the >>>>>>>>>>>>>> canonical File when it wasn't there previously, this >>>>>>>>>>>>>> would of >>>>>>>>>>>>>> course >>>>>>>>>>>>>> have several implications. But I think you have it right >>>>>>>>>>>>>> and this >>>>>>>>>>>>>> is, as >>>>>>>>>>>>>> you position, just refactoring/cleanup. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Alan From christoph.langer at sap.com Thu Dec 5 16:12:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Dec 2019 16:12:06 +0000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> Message-ID: Hi David, I prepared an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.3/ > src/java.base/windows/native/libjava/canonicalize_md.c > > +// We can't include jdk_util.h here because the file is used in Oracle > in another context > +// #include "jdk_util.h" > > Seems to me clients of JDK_Canonicalize need to include jdk_util.h, not > the files that implement it. So there is no reason to include it here > and so no need for the comment. Well, it's actually not needed but I think it's good practice that the declaring header is included in the implementation file. > Further, does: > > src/java.base/unix/native/libjava/canonicalize_md.c > > need to include jdk_util.h? I think not. Same as for the windows file - not necessary but good style. > +/* The appropriate location of getPrefixed() is io_util_md.c, but it is > + also used in a non-OpenJDK context within Oracle. There, > canonicalize_md.c > + is already pulled in and compiled, so to avoid more complicate solutions > + we keep this method here. */ > > I don't like to have comments like this but I guess it is needed here. > Please put the */ on a newline. Also s/complicate/complicates/ I did as Dan pointed out. > src/java.base/windows/native/libjava/io_util_md.c > > should now be unchanged, but you've left in the copyright update. > Right, thanks for the catch. > A second review is still needed for the final version of this. Dan, can I add you as reviewer then? Best regards Christoph From vicente.romero at oracle.com Thu Dec 5 16:44:04 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Dec 2019 11:44:04 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: References: Message-ID: <2591d786-198a-9dc7-3317-45e60a2476d1@oracle.com> looks good, Vicente On 12/5/19 9:36 AM, Harold Seigel wrote: > Hi, > > Please review this small change to simplify > Class.getRecordComponents() by changing the return type of > getRecordComponents0() to RecordComponent[]. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Solaris, Windows, and Mac OS X, by running Mach5 > tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on Linux-x64. > > Thanks, Harold > From joe.darcy at oracle.com Thu Dec 5 18:08:13 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 5 Dec 2019 10:08:13 -0800 Subject: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records" Message-ID: Hello, Please review this small cleanup to records support in java.lang.Class: ??? JDK-8235369: "Class.toGenericString need to be updated for records" ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235428 ??? webrev: http://cr.openjdk.java.net/~darcy/8235369.0/ Patch below; thanks, -Joe diff -r 666fa504b60c src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java??? Wed Dec 04 14:55:15 2019 -0800 +++ b/src/java.base/share/classes/java/lang/Class.java??? Thu Dec 05 10:04:26 2019 -0800 @@ -207,8 +207,8 @@ ????? * ????? * The string is formatted as a list of type modifiers, if any, ????? * followed by the kind of type (empty string for primitive types -???? * and {@code class}, {@code enum}, {@code interface}, or -???? * @{@code interface}, as appropriate), followed +???? * and {@code class}, {@code enum}, {@code interface}, +???? * @{@code interface}, or {@code record} as appropriate), followed ????? * by the type's name, followed by an angle-bracketed ????? * comma-separated list of the type's type parameters, if any, ????? * including informative bounds on the type parameters, if any. @@ -234,6 +234,7 @@ ????? * ????? * @since 1.8 ????? */ +??? @SuppressWarnings("preview") ???? public String toGenericString() { ???????? if (isPrimitive()) { ???????????? return toString(); @@ -264,6 +265,8 @@ ???????????????? } else { ???????????????????? if (isEnum()) ???????????????????????? sb.append("enum"); +??????????????????? else if (isRecord()) +??????????????????????? sb.append("record"); ???????????????????? else ???????????????????????? sb.append("class"); ???????????????? } diff -r 666fa504b60c test/jdk/java/lang/reflect/records/RecordReflectionTest.java --- a/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Wed Dec 04 14:55:15 2019 -0800 +++ b/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Thu Dec 05 10:05:01 2019 -0800 @@ -23,6 +23,7 @@ ?/* ? * @test + * @bug 8235369 ? * @summary reflection test for records ? * @compile --enable-preview -source ${jdk.version} RecordReflectionTest.java ? * @run testng/othervm --enable-preview RecordReflectionTest @@ -51,8 +52,11 @@ ???? public void testIsRecord() { ???????? assertFalse(NoRecord.class.isRecord()); -??????? for (Class c : List.of(R1.class, R2.class, R3.class)) -??????????? assertTrue(c.isRecord()); +??????? for (Class c : List.of(R1.class, R2.class, R3.class)) { +??????????? String message = c.toGenericString(); +??????????? assertTrue(c.isRecord(), message); +??????????? assertTrue(message.contains("record") , message); +??????? } ???? } ???? public void testGetComponentsNoRecord() { From harold.seigel at oracle.com Thu Dec 5 18:35:54 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 5 Dec 2019 13:35:54 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: <2591d786-198a-9dc7-3317-45e60a2476d1@oracle.com> References: <2591d786-198a-9dc7-3317-45e60a2476d1@oracle.com> Message-ID: <2222813a-f0da-e740-55ba-b1a1f20bcc7f@oracle.com> Thanks Vicente! Harold On 12/5/2019 11:44 AM, Vicente Romero wrote: > looks good, > Vicente > > On 12/5/19 9:36 AM, Harold Seigel wrote: >> Hi, >> >> Please review this small change to simplify >> Class.getRecordComponents() by changing the return type of >> getRecordComponents0() to RecordComponent[]. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests >> and builds on Linux-x64, Solaris, Windows, and Mac OS X, by running >> Mach5 tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on >> Linux-x64. >> >> Thanks, Harold >> > From naoto.sato at oracle.com Thu Dec 5 18:49:26 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 5 Dec 2019 10:49:26 -0800 Subject: [14] RFR: 8222756: Plural support in CompactNumberFormat In-Reply-To: <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> Message-ID: Thanks, Joe and Roger, for the reviews. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8222756/webrev.02/ These are the changes since v.01: CompactNumberFormat.java: - Reflected the CSR changes (thank you, JoeD, for the quick turnaround!), and misc typos in the spec. - Added length limitation to the "pluralRules" argument in the new constructor. Throws IllegalArgumentException if the input is too long (>2,048 chars). - Added validation to plural rules, and throws IllegalArgumentException if the given rules' syntax is incorrect. - Consolidated the same pattern to get the affixes into a utility method (getAffix()) - Directly find NaN and Infinity in the number string, parse the number with regex otherwise. TestEquality.java: Tidied the test array up. CLDRConverter.java: Added String::trim so that the generated PluralRules.java will not have extra spaces. TestPlurals.java: Added test cases for invalid cases, i.e., invalid syntax and length limit exceeding rules in the constructor. Not addressed: - ResourceBundleGenerator.java exists in the webrev as it does have a modification (only seen in "patch" link, as the mod is only the indentation) - Using "==" for double values: As Roger mentioned, it is in fact comparing integers (the only reason to use double is to deal with NaN and Infinity) - Possible performance improvement: Could be addressed later if it is regarded as an issue. But since the effective plural rules are simple/short enough, I would not expect it as a problem. Naoto On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote: > I modified CompactNumberFormat.java to simplify the syntax parsing: > > https://cr.openjdk.java.net/~naoto/8222756/webrev.01/ > > Please review this webrev instead. > > Naoto > > On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> CompactNumberFormat has been added since JDK 12 to support compact >> number formatting, such as 10_000 being formatted as "10K." [1] It >> works fine for English, however, not for other languages that take >> plural forms in formatted number prefixes/suffixes. In order to fix >> this, I filed the following CSR to extend the current >> CompactNumberFormat spec: >> >> https://bugs.openjdk.java.net/browse/JDK-8232633 >> >> It basically accommodates the plural prefix/suffix forms into the >> existing compact patterns array, so that the existing compact number >> format works compatibly. The plural rules are solely based on the >> CLDR's plural language rules [2] >> >> Here is the implementation of the CSR: >> >> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/ >> >> Please review the CSR as well as its implementation. >> >> Naoto >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177552 >> [2] >> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules From mandy.chung at oracle.com Thu Dec 5 18:59:17 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Dec 2019 10:59:17 -0800 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: References: Message-ID: <1505448b-aafd-714c-678c-45066d6fdc98@oracle.com> Looks good. Mandy On 12/5/19 6:36 AM, Harold Seigel wrote: > Hi, > > Please review this small change to simplify > Class.getRecordComponents() by changing the return type of > getRecordComponents0() to RecordComponent[]. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Solaris, Windows, and Mac OS X, by running Mach5 > tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on Linux-x64. > > Thanks, Harold > From harold.seigel at oracle.com Thu Dec 5 19:03:44 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 5 Dec 2019 14:03:44 -0500 Subject: RFR 8235359: Simplify method Class.getRecordComponents() In-Reply-To: <1505448b-aafd-714c-678c-45066d6fdc98@oracle.com> References: <1505448b-aafd-714c-678c-45066d6fdc98@oracle.com> Message-ID: <0af0ecf8-713b-d06f-4fe0-fe31964f55b4@oracle.com> Thanks Mandy! Harold On 12/5/2019 1:59 PM, Mandy Chung wrote: > Looks good. > > Mandy > > On 12/5/19 6:36 AM, Harold Seigel wrote: >> Hi, >> >> Please review this small change to simplify >> Class.getRecordComponents() by changing the return type of >> getRecordComponents0() to RecordComponent[]. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests >> and builds on Linux-x64, Solaris, Windows, and Mac OS X, by running >> Mach5 tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on >> Linux-x64. >> >> Thanks, Harold >> > From Roger.Riggs at oracle.com Thu Dec 5 20:13:57 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 5 Dec 2019 15:13:57 -0500 Subject: [14] RFR: 8222756: Plural support in CompactNumberFormat In-Reply-To: References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> Message-ID: <8902cbf4-6abf-493f-cf4f-f50fe622c520@oracle.com> Hi Naoto, Thanks for the updates. Looks fine. Roger On 12/5/19 1:49 PM, naoto.sato at oracle.com wrote: > Thanks, Joe and Roger, for the reviews. Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8222756/webrev.02/ > > These are the changes since v.01: > > CompactNumberFormat.java: > > - Reflected the CSR changes (thank you, JoeD, for the quick > turnaround!), and misc typos in the spec. > > - Added length limitation to the "pluralRules" argument in the new > constructor. Throws IllegalArgumentException if the input is too long > (>2,048 chars). > > - Added validation to plural rules, and throws > IllegalArgumentException if the given rules' syntax is incorrect. > > - Consolidated the same pattern to get the affixes into a utility > method (getAffix()) > > - Directly find NaN and Infinity in the number string, parse the > number with regex otherwise. > > TestEquality.java: Tidied the test array up. > > CLDRConverter.java: Added String::trim so that the generated > PluralRules.java will not have extra spaces. > > TestPlurals.java: Added test cases for invalid cases, i.e., invalid > syntax and length limit exceeding rules in the constructor. > > Not addressed: > > - ResourceBundleGenerator.java exists in the webrev as it does have a > modification (only seen in "patch" link, as the mod is only the > indentation) > > - Using "==" for double values: As Roger mentioned, it is in fact > comparing integers (the only reason to use double is to deal with NaN > and Infinity) > > - Possible performance improvement: Could be addressed later if it is > regarded as an issue. But since the effective plural rules are > simple/short enough, I would not expect it as a problem. > > Naoto > > > > On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote: >> I modified CompactNumberFormat.java to simplify the syntax parsing: >> >> https://cr.openjdk.java.net/~naoto/8222756/webrev.01/ >> >> Please review this webrev instead. >> >> Naoto >> >> On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> CompactNumberFormat has been added since JDK 12 to support compact >>> number formatting, such as 10_000 being formatted as "10K." [1] It >>> works fine for English, however, not for other languages that take >>> plural forms in formatted number prefixes/suffixes. In order to fix >>> this, I filed the following CSR to extend the current >>> CompactNumberFormat spec: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8232633 >>> >>> It basically accommodates the plural prefix/suffix forms into the >>> existing compact patterns array, so that the existing compact number >>> format works compatibly. The plural rules are solely based on the >>> CLDR's plural language rules [2] >>> >>> Here is the implementation of the CSR: >>> >>> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/ >>> >>> Please review the CSR as well as its implementation. >>> >>> Naoto >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8177552 >>> [2] >>> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules >>> From mandy.chung at oracle.com Thu Dec 5 20:21:55 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Dec 2019 12:21:55 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <8f08f1fd-db11-5709-0925-d6ccdcdf3e48@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> <8f08f1fd-db11-5709-0925-d6ccdcdf3e48@oracle.com> Message-ID: <21cdc073-f1c1-195c-e825-a0273d67d456@oracle.com> On 12/5/19 12:41 AM, Alan Bateman wrote: > On 05/12/2019 08:16, Henry Jen wrote: >> Hi, >> >> Updated webrev[1] reflect comments since last webrev. Vicente had >> done all the heavy-lifting and hand over to me to finish up. >> >> Changes to symbols is reverted, as we expect that only need to be >> updated in next release by running make/scripts/generate-symbol-data.sh. >> >> The jar files are confusing in the webrev, but those files are >> removed. The whole test/jdk/tools/pack200 is removed. >> >> Cheers, >> Henry >> >> [1] http://cr.openjdk.java.net/~henryjen/jdk14/8234542/0/webrev/ >> > The update webrev looks okay to me, except this part of the comment in > flags-cflags.m4 > > "Now that unpack200 has been removed we should consider setting it for > windows too. but this could be done as a follow-up effort. It could be > that other other clients are relying on the current configuration for > windows". > > I think it would be best to create an infrastructure/build issue and > leave most of this? confusing comment out. > I also think keeping flags-cflags.m4 as is and file a new build issue as a follow-up would be better. Otherwise, this updated webrev looks okay to me. Mandy From vicente.romero at oracle.com Thu Dec 5 20:41:25 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Dec 2019 15:41:25 -0500 Subject: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records" In-Reply-To: References: Message-ID: looks good, Vicente On 12/5/19 1:08 PM, Joe Darcy wrote: > Hello, > > Please review this small cleanup to records support in java.lang.Class: > > ??? JDK-8235369: "Class.toGenericString need to be updated for records" > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235428 > ??? webrev: http://cr.openjdk.java.net/~darcy/8235369.0/ > > Patch below; thanks, > > -Joe > > diff -r 666fa504b60c src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java??? Wed Dec 04 > 14:55:15 2019 -0800 > +++ b/src/java.base/share/classes/java/lang/Class.java??? Thu Dec 05 > 10:04:26 2019 -0800 > @@ -207,8 +207,8 @@ > ????? * > ????? * The string is formatted as a list of type modifiers, if any, > ????? * followed by the kind of type (empty string for primitive types > -???? * and {@code class}, {@code enum}, {@code interface}, or > -???? * @{@code interface}, as appropriate), followed > +???? * and {@code class}, {@code enum}, {@code interface}, > +???? * @{@code interface}, or {@code record} as > appropriate), followed > ????? * by the type's name, followed by an angle-bracketed > ????? * comma-separated list of the type's type parameters, if any, > ????? * including informative bounds on the type parameters, if any. > @@ -234,6 +234,7 @@ > ????? * > ????? * @since 1.8 > ????? */ > +??? @SuppressWarnings("preview") > ???? public String toGenericString() { > ???????? if (isPrimitive()) { > ???????????? return toString(); > @@ -264,6 +265,8 @@ > ???????????????? } else { > ???????????????????? if (isEnum()) > ???????????????????????? sb.append("enum"); > +??????????????????? else if (isRecord()) > +??????????????????????? sb.append("record"); > ???????????????????? else > ???????????????????????? sb.append("class"); > ???????????????? } > > diff -r 666fa504b60c > test/jdk/java/lang/reflect/records/RecordReflectionTest.java > --- a/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Wed > Dec 04 14:55:15 2019 -0800 > +++ b/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Thu > Dec 05 10:05:01 2019 -0800 > @@ -23,6 +23,7 @@ > > ?/* > ? * @test > + * @bug 8235369 > ? * @summary reflection test for records > ? * @compile --enable-preview -source ${jdk.version} > RecordReflectionTest.java > ? * @run testng/othervm --enable-preview RecordReflectionTest > @@ -51,8 +52,11 @@ > ???? public void testIsRecord() { > ???????? assertFalse(NoRecord.class.isRecord()); > > -??????? for (Class c : List.of(R1.class, R2.class, R3.class)) > -??????????? assertTrue(c.isRecord()); > +??????? for (Class c : List.of(R1.class, R2.class, R3.class)) { > +??????????? String message = c.toGenericString(); > +??????????? assertTrue(c.isRecord(), message); > +??????????? assertTrue(message.contains("record") , message); > +??????? } > ???? } > > ???? public void testGetComponentsNoRecord() { > > From mandy.chung at oracle.com Thu Dec 5 20:50:53 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Dec 2019 12:50:53 -0800 Subject: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records" In-Reply-To: References: Message-ID: +1 Mandy On 12/5/19 10:08 AM, Joe Darcy wrote: > Hello, > > Please review this small cleanup to records support in java.lang.Class: > > ??? JDK-8235369: "Class.toGenericString need to be updated for records" > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235428 > ??? webrev: http://cr.openjdk.java.net/~darcy/8235369.0/ > > Patch below; thanks, > > -Joe > > diff -r 666fa504b60c src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java??? Wed Dec 04 > 14:55:15 2019 -0800 > +++ b/src/java.base/share/classes/java/lang/Class.java??? Thu Dec 05 > 10:04:26 2019 -0800 > @@ -207,8 +207,8 @@ > ????? * > ????? * The string is formatted as a list of type modifiers, if any, > ????? * followed by the kind of type (empty string for primitive types > -???? * and {@code class}, {@code enum}, {@code interface}, or > -???? * @{@code interface}, as appropriate), followed > +???? * and {@code class}, {@code enum}, {@code interface}, > +???? * @{@code interface}, or {@code record} as > appropriate), followed > ????? * by the type's name, followed by an angle-bracketed > ????? * comma-separated list of the type's type parameters, if any, > ????? * including informative bounds on the type parameters, if any. > @@ -234,6 +234,7 @@ > ????? * > ????? * @since 1.8 > ????? */ > +??? @SuppressWarnings("preview") > ???? public String toGenericString() { > ???????? if (isPrimitive()) { > ???????????? return toString(); > @@ -264,6 +265,8 @@ > ???????????????? } else { > ???????????????????? if (isEnum()) > ???????????????????????? sb.append("enum"); > +??????????????????? else if (isRecord()) > +??????????????????????? sb.append("record"); > ???????????????????? else > ???????????????????????? sb.append("class"); > ???????????????? } > > diff -r 666fa504b60c > test/jdk/java/lang/reflect/records/RecordReflectionTest.java > --- a/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Wed > Dec 04 14:55:15 2019 -0800 > +++ b/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Thu > Dec 05 10:05:01 2019 -0800 > @@ -23,6 +23,7 @@ > > ?/* > ? * @test > + * @bug 8235369 > ? * @summary reflection test for records > ? * @compile --enable-preview -source ${jdk.version} > RecordReflectionTest.java > ? * @run testng/othervm --enable-preview RecordReflectionTest > @@ -51,8 +52,11 @@ > ???? public void testIsRecord() { > ???????? assertFalse(NoRecord.class.isRecord()); > > -??????? for (Class c : List.of(R1.class, R2.class, R3.class)) > -??????????? assertTrue(c.isRecord()); > +??????? for (Class c : List.of(R1.class, R2.class, R3.class)) { > +??????????? String message = c.toGenericString(); > +??????????? assertTrue(c.isRecord(), message); > +??????????? assertTrue(message.contains("record") , message); > +??????? } > ???? } > > ???? public void testGetComponentsNoRecord() { > > From huizhe.wang at oracle.com Thu Dec 5 21:02:39 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 5 Dec 2019 13:02:39 -0800 Subject: [14] RFR: 8222756: Plural support in CompactNumberFormat In-Reply-To: <8902cbf4-6abf-493f-cf4f-f50fe622c520@oracle.com> References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com> <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com> <8902cbf4-6abf-493f-cf4f-f50fe622c520@oracle.com> Message-ID: +1, looks good! Best regards, Joe On 12/5/19 12:13 PM, Roger Riggs wrote: > Hi Naoto, > > Thanks for the updates. > > Looks fine. > > Roger > > > On 12/5/19 1:49 PM, naoto.sato at oracle.com wrote: >> Thanks, Joe and Roger, for the reviews. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8222756/webrev.02/ >> >> These are the changes since v.01: >> >> CompactNumberFormat.java: >> >> - Reflected the CSR changes (thank you, JoeD, for the quick >> turnaround!), and misc typos in the spec. >> >> - Added length limitation to the "pluralRules" argument in the new >> constructor. Throws IllegalArgumentException if the input is too long >> (>2,048 chars). >> >> - Added validation to plural rules, and throws >> IllegalArgumentException if the given rules' syntax is incorrect. >> >> - Consolidated the same pattern to get the affixes into a utility >> method (getAffix()) >> >> - Directly find NaN and Infinity in the number string, parse the >> number with regex otherwise. >> >> TestEquality.java: Tidied the test array up. >> >> CLDRConverter.java: Added String::trim so that the generated >> PluralRules.java will not have extra spaces. >> >> TestPlurals.java: Added test cases for invalid cases, i.e., invalid >> syntax and length limit exceeding rules in the constructor. >> >> Not addressed: >> >> - ResourceBundleGenerator.java exists in the webrev as it does have a >> modification (only seen in "patch" link, as the mod is only the >> indentation) >> >> - Using "==" for double values: As Roger mentioned, it is in fact >> comparing integers (the only reason to use double is to deal with NaN >> and Infinity) >> >> - Possible performance improvement: Could be addressed later if it is >> regarded as an issue. But since the effective plural rules are >> simple/short enough, I would not expect it as a problem. >> >> Naoto >> >> >> >> On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote: >>> I modified CompactNumberFormat.java to simplify the syntax parsing: >>> >>> https://cr.openjdk.java.net/~naoto/8222756/webrev.01/ >>> >>> Please review this webrev instead. >>> >>> Naoto >>> >>> On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> CompactNumberFormat has been added since JDK 12 to support compact >>>> number formatting, such as 10_000 being formatted as "10K." [1] It >>>> works fine for English, however, not for other languages that take >>>> plural forms in formatted number prefixes/suffixes. In order to fix >>>> this, I filed the following CSR to extend the current >>>> CompactNumberFormat spec: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8232633 >>>> >>>> It basically accommodates the plural prefix/suffix forms into the >>>> existing compact patterns array, so that the existing compact >>>> number format works compatibly. The plural rules are solely based >>>> on the CLDR's plural language rules [2] >>>> >>>> Here is the implementation of the CSR: >>>> >>>> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/ >>>> >>>> Please review the CSR as well as its implementation. >>>> >>>> Naoto >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8177552 >>>> [2] >>>> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules >>>> > From maurizio.cimadamore at oracle.com Thu Dec 5 21:04:55 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Dec 2019 21:04:55 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) Message-ID: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Hi, as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code review for the corresponding core-libs and hotspot changes: http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ A javadoc for the memory access API is also available here: http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html Note: the patch passes tier1, tier2 and tier3 testing (**) Here is a brief summary of the changes in java.base and hotspot (the remaining new files are implementation classes and tests for the new API): * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) * Modules.gmk - these changes are needed to require that the incubating module is loaded by the boot loader (otherwise the above changes are useless) * library_call.cpp - this one is a JIT compiler change to treat Thread.currentThread() as a well-known constant - which helps a lot in the confinement checks (thanks Vlad!) * various Buffer-related changes; these changes are needed because the memory access API allows a memory segment to be projected into a byte buffer, for interop reasons. As such, we need to insert a liveness check in the various get/put methods. Previously we had an implementation strategy where a BB was 'decorated' by a subclass called ScopedBuffer - but doing so required some changes to the BB API (e.g. making certain methods non-final, so that we could decorate them). Here I use an approach (which I have discussed with Alan) which doesn't require any public API? changes, but needs to add a 'segment' field in Buffer - and then have constructors which keep track of this extra parameter. * FileChannel changes - these changes are required so that we can reuse the Unmapper class from the MemorySegment implementation, to deterministically deallocate a mapped memory segment. This should be a 'straight' refactoring, no change in behavior should occur here. Please double check. * VarHandles - this class now provides a factory to create memory access VarHandle - this is a bit tricky, since VarHandle cannot really be implemented outside java.base (e.g. VarForm is not public). So we do the usual trick where we define a bunch of proxy interfaces (see jdk/internal/access/foreign) have the classes in java.base refer to these - and then have the implementation classes of the memory access API implement these interfaces. * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to provide access to otherwise hidden functionalities - e.g. creating a new scoped buffer, or retrieving the properties of a memory access handle (e.g. offset, stride etc.), so that we can implement the memory access API in its own separate module * GensrcVarHandles.gmk - these changes are needed to enable the generation of the new memory address var handle implementations; there's an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access var handle is needed, we dynamically spin a new VH implementation which makes use of the right carrier. We need to spin because the VH can have a variable number of access coordinates (e.g. depending on the dimensions of the array to be accessed). But, under the hood, all the generated implementation will be using the same helper class. * tests - we've tried to add fairly robust tests, often checking all possible permutations of carriers/dimensions etc. Because of that, the tests might not be the easiest to look at, but they have proven to be pretty effective at shaking out issues. I think that covers the main aspects of the implementation and where it differs from vanilla JDK. P.S. In the CSR review [2], Joe raised a fair point - which is MemoryAddress has both: offset(long) --> move address of given offset offset() --> return the offset of this address in its owning segment And this was considered suboptimal, given both methods use the same name but do something quite different (one is an accessor, another is a 'wither'). one obvious option is to rename the first to 'withOffset'. But I think that would lead to verbose code (since that is a very common operation). Other options are to: * rename offset(long) to move(long), advance(long), or something else * drop offset() - but then add an overload of MemorySegment::asSlice which takes an address instead of a plain long offset I'll leave the choice to the reviewers :-) Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, Roger, Joe and the Panama team for the feedback provided so far, which helped to get the API in the shape it is today. Cheers Maurizio (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - but that is unrelated to this patch, and it's a known failing test. [1] - https://openjdk.java.net/jeps/370 [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 From chris.hegarty at oracle.com Thu Dec 5 21:55:01 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 Dec 2019 21:55:01 +0000 Subject: JDK 14 RFR of JDK-8235369: "Class.toGenericString need to be updated for records" In-Reply-To: References: Message-ID: LGTM. -Chris > On 5 Dec 2019, at 18:08, Joe Darcy wrote: > > ?Hello, > > Please review this small cleanup to records support in java.lang.Class: > > JDK-8235369: "Class.toGenericString need to be updated for records" > CSR: https://bugs.openjdk.java.net/browse/JDK-8235428 > webrev: http://cr.openjdk.java.net/~darcy/8235369.0/ > > Patch below; thanks, > > -Joe > > diff -r 666fa504b60c src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java Wed Dec 04 14:55:15 2019 -0800 > +++ b/src/java.base/share/classes/java/lang/Class.java Thu Dec 05 10:04:26 2019 -0800 > @@ -207,8 +207,8 @@ > * > * The string is formatted as a list of type modifiers, if any, > * followed by the kind of type (empty string for primitive types > - * and {@code class}, {@code enum}, {@code interface}, or > - * @{@code interface}, as appropriate), followed > + * and {@code class}, {@code enum}, {@code interface}, > + * @{@code interface}, or {@code record} as appropriate), followed > * by the type's name, followed by an angle-bracketed > * comma-separated list of the type's type parameters, if any, > * including informative bounds on the type parameters, if any. > @@ -234,6 +234,7 @@ > * > * @since 1.8 > */ > + @SuppressWarnings("preview") > public String toGenericString() { > if (isPrimitive()) { > return toString(); > @@ -264,6 +265,8 @@ > } else { > if (isEnum()) > sb.append("enum"); > + else if (isRecord()) > + sb.append("record"); > else > sb.append("class"); > } > > diff -r 666fa504b60c test/jdk/java/lang/reflect/records/RecordReflectionTest.java > --- a/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Wed Dec 04 14:55:15 2019 -0800 > +++ b/test/jdk/java/lang/reflect/records/RecordReflectionTest.java Thu Dec 05 10:05:01 2019 -0800 > @@ -23,6 +23,7 @@ > > /* > * @test > + * @bug 8235369 > * @summary reflection test for records > * @compile --enable-preview -source ${jdk.version} RecordReflectionTest.java > * @run testng/othervm --enable-preview RecordReflectionTest > @@ -51,8 +52,11 @@ > public void testIsRecord() { > assertFalse(NoRecord.class.isRecord()); > > - for (Class c : List.of(R1.class, R2.class, R3.class)) > - assertTrue(c.isRecord()); > + for (Class c : List.of(R1.class, R2.class, R3.class)) { > + String message = c.toGenericString(); > + assertTrue(c.isRecord(), message); > + assertTrue(message.contains("record") , message); > + } > } > > public void testGetComponentsNoRecord() { > > From vladimir.x.ivanov at oracle.com Thu Dec 5 22:39:49 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 Dec 2019 01:39:49 +0300 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> Awesome work, Maurizio! Regarding hotspot changes: > * ciField.cpp - this one is to trust final fields in the foreign memory > access implementation (otherwise VM doesn't trust memory segment bounds) New packages aren't part of java.base. Considering the implementation resides in an incubator module, is it enough to consider them as trusted and well-known to the JVM? > * library_call.cpp - this one is a JIT compiler change to treat > Thread.currentThread() as a well-known constant - which helps a lot in > the confinement checks (thanks Vlad!) FTR it is tracked by JDK-8235143 [1] and the patch is under review [2]. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8235143 [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036295.html > * various Buffer-related changes; these changes are needed because the > memory access API allows a memory segment to be projected into a byte > buffer, for interop reasons. As such, we need to insert a liveness check > in the various get/put methods. Previously we had an implementation > strategy where a BB was 'decorated' by a subclass called ScopedBuffer - > but doing so required some changes to the BB API (e.g. making certain > methods non-final, so that we could decorate them). Here I use an > approach (which I have discussed with Alan) which doesn't require any > public API? changes, but needs to add a 'segment' field in Buffer - and > then have constructors which keep track of this extra parameter. > > * FileChannel changes - these changes are required so that we can reuse > the Unmapper class from the MemorySegment implementation, to > deterministically deallocate a mapped memory segment. This should be a > 'straight' refactoring, no change in behavior should occur here. Please > double check. > > * VarHandles - this class now provides a factory to create memory access > VarHandle - this is a bit tricky, since VarHandle cannot really be > implemented outside java.base (e.g. VarForm is not public). So we do the > usual trick where we define a bunch of proxy interfaces (see > jdk/internal/access/foreign) have the classes in java.base refer to > these - and then have the implementation classes of the memory access > API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to > provide access to otherwise hidden functionalities - e.g. creating a new > scoped buffer, or retrieving the properties of a memory access handle > (e.g. offset, stride etc.), so that we can implement the memory access > API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the > generation of the new memory address var handle implementations; there's > an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). > At runtime, when a memory access var handle is needed, we dynamically > spin a new VH implementation which makes use of the right carrier. We > need to spin because the VH can have a variable number of access > coordinates (e.g. depending on the dimensions of the array to be > accessed). But, under the hood, all the generated implementation will be > using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all > possible permutations of carriers/dimensions etc. Because of that, the > tests might not be the easiest to look at, but they have proven to be > pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where it > differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is MemoryAddress > has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same name > but do something quite different (one is an accessor, another is a > 'wither'). one obvious option is to rename the first to 'withOffset'. > But I think that would lead to verbose code (since that is a very common > operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers :-) > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, > Roger, Joe and the Panama team for the feedback provided so far, which > helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - > but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 > From alexey.semenyuk at oracle.com Thu Dec 5 22:47:56 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 5 Dec 2019 17:47:56 -0500 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: References: Message-ID: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> Please review? fixes for [1] and [2]. Both target jpackage tool. The webrev is at [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8233270 [2] https://bugs.openjdk.java.net/browse/JDK-8230933 [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ From david.holmes at oracle.com Thu Dec 5 23:02:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Dec 2019 09:02:06 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <958c573a-515f-845f-8096-9ec15419d30b@oracle.com> References: <6209301e-ae85-2a91-7d9e-c9096581365d@oracle.com> <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> <958c573a-515f-845f-8096-9ec15419d30b@oracle.com> Message-ID: On 6/12/2019 2:06 am, Daniel D. Daugherty wrote: > On 12/5/19 8:00 AM, David Holmes wrote: >> Hi Christoph, >> >> On 5/12/2019 9:55 pm, Langer, Christoph wrote: >>> Hi David, >>> >>> thanks again for your efforts. >>> >>> Here is a version that ran successfully through jdk-submit >>> (mach5-one-clanger-JDK-8234185-3-20191205-1051-7247172): >>> http://cr.openjdk.java.net/~clanger/webrevs/8234185.2/ >>> >>> I avoid the inclusion of jdk_util.h in >>> src/java.base/windows/native/libjava/canonicalize_md.c. Do you think >>> this is good to go? >> >> Avoiding the include does seem to be the way to go. That seems so >> obvious now. >> >> src/java.base/windows/native/libjava/canonicalize_md.c >> >> +// We can't include jdk_util.h here because the file is used in >> Oracle in another context >> +// #include "jdk_util.h" >> >> Seems to me clients of JDK_Canonicalize need to include jdk_util.h, >> not the files that implement it. So there is no reason to include it >> here and so no need for the comment. Further, does: >> >> src/java.base/unix/native/libjava/canonicalize_md.c >> >> need to include jdk_util.h? I think not. >> >> +/* The appropriate location of getPrefixed() is io_util_md.c, but it is >> +?? also used in a non-OpenJDK context within Oracle. There, >> canonicalize_md.c >> +?? is already pulled in and compiled, so to avoid more complicate >> solutions >> +?? we keep this method here. */ >> >> I don't like to have comments like this but I guess it is needed here. >> Please put the */ on a newline. Also s/complicate/complicates/ > > It should be: > > s/complicate/complicated/ Thanks Dan - fat fingers :) I need a keyboard with bigger spaces between keys David > > Dan > >> >> src/java.base/windows/native/libjava/io_util_md.c >> >> should now be unchanged, but you've left in the copyright update. >> >> A second review is still needed for the final version of this. >> >> Thanks, >> David >> >> >>> Somebody in Oracle could then eventually clean up things by >>> decoupling the installer from OpenJDK's canonicalize_md.c. I'd open a >>> bug for this. >>> >>> Thanks >>> Christoph >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Dienstag, 3. Dezember 2019 23:52 >>>> To: Langer, Christoph >>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net; Alan Bateman ; gerard >>>> ziemski >>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>> between >>>> libjava, hotspot and libinstrument >>>> >>>> Hi Christoph, >>>> >>>> On 3/12/2019 7:26 pm, Langer, Christoph wrote: >>>>> Hi David, >>>>> >>>>> thanks for taking care of this. >>>>> >>>>> This would be my updated patch that could hopefully be enabled by just >>>> adding the include directory where "jdk_util.h" is located. It would >>>> be really >>>> great if that'd work. I think it would open up a path to >>>> automatically include >>>> io_util_md.h by including io_util.h. >>>>> >>>>> http://cr.openjdk.java.net/~clanger/webrevs/8234185.1/ >>>> >>>> I'm afraid I cannot get this to work at our end. I get the following >>>> errors: >>>> >>>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>>> error C2143: syntax error: missing ')' before '*' >>>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>>> error C2143: syntax error: missing '{' before '*' >>>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>>> warning C4142: 'size_t': benign redefinition of type >>>> C:\ade\mesos\work_dir\jib- >>>> ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ >>>> >>>> e\vcruntime.h(184): >>>> note: see declaration of 'size_t' >>>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>>> error C2370: 'size_t': redefinition; different storage class >>>> C:\ade\mesos\work_dir\jib- >>>> ma~1\install\jpg\infra\buildd~1\devkit~1\vs2017~3.0\devkit~1.gz\VC\includ >>>> >>>> e\vcruntime.h(184): >>>> note: see declaration of 'size_t' >>>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>>> error C2146: syntax error: missing ';' before identifier 'info_size' >>>> t:\workspace\open\src\java.base\share\native\libjava\jdk_util.h(46): >>>> error C2059: syntax error: ')' >>>> >>>> This pertains to the line: >>>> >>>> JDK_GetVersionInfo0(jdk_version_info* info, size_t info_size); >>>> >>>> There is also a second problem in our closed code that will take more >>>> effort from someone familiar with that code to resolve. I will file an >>>> issue for our install team to pick up. >>>> >>>> I would ask that this not be pushed for the moment while others figure >>>> out how best to handle this. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>>> Cheers >>>>> Christoph >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Dienstag, 3. Dezember 2019 03:13 >>>>>> To: Langer, Christoph ; Alan Bateman >>>>>> ; gerard ziemski >>>> >>>>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>> between >>>>>> libjava, hotspot and libinstrument >>>>>> >>>>>> Hi Christoph, >>>>>> >>>>>> Can you please post your updated patch for review and I will use >>>>>> it to >>>>>> check the fix for our internal build. Once you have your fix >>>>>> reviewed I >>>>>> will push both fixes together. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 25/11/2019 10:41 pm, David Holmes wrote: >>>>>>> Hi Christoph, >>>>>>> >>>>>>> On 25/11/2019 10:38 pm, Langer, Christoph wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> thanks for your investigation. I'll prepare a fix to move back >>>>>>>> getPrefixed into canonicalize_md.c. However, could you please still >>>>>>>> fix your internal build in terms that it would have 'jdk_util.h' in >>>>>>>> the include path? >>>>>>> >>>>>>> That should be simple enough to do. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Thanks >>>>>>>> Christoph >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes >>>>>>>>> Sent: Montag, 25. November 2019 01:02 >>>>>>>>> To: Langer, Christoph ; Alan Bateman >>>>>>>>> ; gerard ziemski >>>>>> >>>>>>>>> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function >>>>>>>>> between >>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 25/11/2019 8:45 am, David Holmes wrote: >>>>>>>>>> On 25/11/2019 7:49 am, David Holmes wrote: >>>>>>>>>>> On 25/11/2019 7:33 am, David Holmes wrote: >>>>>>>>>>>> Hi Christoph, >>>>>>>>>>>> >>>>>>>>>>>> On 23/11/2019 12:04 am, Langer, Christoph wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I'd like to push this change. However, running it through jdk- >>>> submit >>>>>>>>>>>>> shows reproducible errors: >>>>>>>>>>>>> >>>>>>>>>>>>> Job: mach5-one-clanger-JDK-8234185-1-20191122-0927-6913189 >>>>>>>>>>>>> BuildId: 2019-11-22-0926373.christoph.langer.source >>>>>>>>>>>>> No failed tests >>>>>>>>>>>>> Tasks Summary >>>>>>>>>>>>> ???? NA: 0 >>>>>>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>>>>>> ???? KILLED: 0 >>>>>>>>>>>>> ???? PASSED: 76 >>>>>>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>>>>>> ???? FAILED: 0 >>>>>>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>>>>>> Build >>>>>>>>>>>>> 1 Executed with failure >>>>>>>>>>>>> o windows-x64-install-windows-x64-build-19 error while >>>> building, >>>>>>>>>>>>> return value: 2 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Job: mach5-one-clanger-JDK-8234185-20191121-2313-6898791 >>>>>>>>>>>>> BuildId: 2019-11-21-2311357.christoph.langer.source >>>>>>>>>>>>> No failed tests >>>>>>>>>>>>> Tasks Summary >>>>>>>>>>>>> ???? NA: 0 >>>>>>>>>>>>> ???? NOTHING_TO_RUN: 0 >>>>>>>>>>>>> ???? KILLED: 0 >>>>>>>>>>>>> ???? PASSED: 76 >>>>>>>>>>>>> ???? UNABLE_TO_RUN: 0 >>>>>>>>>>>>> ???? EXECUTED_WITH_FAILURE: 1 >>>>>>>>>>>>> ???? FAILED: 0 >>>>>>>>>>>>> ???? HARNESS_ERROR: 0 >>>>>>>>>>>>> Build >>>>>>>>>>>>> 1 Executed with failure >>>>>>>>>>>>> o windows-x64-install-windows-x64-build-19 error while >>>> building, >>>>>>>>>>>>> return value: 2 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David already had a look and let me know that the following >>>>>>>>>>>>> was >>>>>> the >>>>>>>>>>>>> reason: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>> >>>> t:/workspace/open/src/java.base/windows/native/libjava/canonicalize_md. >>>>>>>>> c(41): >>>>>>>>>>>>> fatal error C1083: Cannot open include file: 'jdk_util.h': >>>>>>>>>>>>> No such >>>>>>>>>>>>> file or directory >>>>>>>>>>>>> >>>>>>>>>>>>> This is not explainable to me as I see this running through my >>>> local >>>>>>>>>>>>> build and our nightly builds without problems. I also can't >>>>>>>>>>>>> explain >>>>>>>>>>>>> jdk_util.h can't be opened at this place - it should be >>>>>>>>>>>>> there and >>>>>>>>>>>>> part of the include directories... >>>>>>>>>>>>> >>>>>>>>>>>>> I'd appreciate any help... >>>>>>>>>>>> >>>>>>>>>>>> I just dug a little deeper and this is failing in part of >>>>>>>>>>>> our closed >>>>>>>>>>>> build for the install repo. There is a library there that is >>>>>>>>>>>> using >>>>>>>>>>>> canonicalize_md.c directly - i.e. it adds that file to its >>>>>>>>>>>> source >>>>>>>>>>>> files list. The build instructions don't include that >>>>>>>>>>>> directory on >>>>>>>>>>>> the include directory list - hence the failure. But it will >>>>>>>>>>>> also fail >>>>>>>>>>>> due to the name change you made. >>>>>>>>>>> >>>>>>>>>>> Actually it appears that the other source code doesn't >>>>>>>>>>> actually refer >>>>>>>>>>> to the canonicalize function at all, so a simple fix may be >>>>>>>>>>> possible >>>>>>>>>>> at the build level on our side. I'm testing that now. >>>>>>>>>> >>>>>>>>>> It isn't the canonicalize function that is used, it is >>>>>>>>>> getPrefixed, >>>>>>>>>> which has now been moved to the io_util_md.c file. So a fix >>>>>>>>>> will be a >>>>>>>>>> bit more involved. >>>>>>>>> >>>>>>>>> I tried adding io_util_md.c to the library source list instead of >>>>>>>>> canonicalize_md.c but that just caused a slew of other compilation >>>>>>>>> failures, so I don't see any quick fix for us here. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> Someone will need to work with you to make the necessary >>>> changes >>>>>> to >>>>>>>>>>>> our code. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Christoph >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Langer, Christoph >>>>>>>>>>>>>> Sent: Donnerstag, 21. November 2019 14:19 >>>>>>>>>>>>>> To: Alan Bateman ; core-libs- >>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>>>>>>>>>>>> Subject: RE: RFR: 8234185: Cleanup usage of canonicalize >>>> function >>>>>>>>>>>>>> between >>>>>>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Alan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks for the review. I'll push it then after running >>>>>>>>>>>>>> through >>>>>>>>>>>>>> jdk-submit. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Christoph >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Alan Bateman >>>>>>>>>>>>>>> Sent: Donnerstag, 21. November 2019 09:51 >>>>>>>>>>>>>>> To: Langer, Christoph ; core-libs- >>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize >>>>>> function >>>>>>>>>>>>>>> between >>>>>>>>>>>>>>> libjava, hotspot and libinstrument >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 14/11/2019 15:37, Langer, Christoph wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> please review this cleanup change regarding function >>>>>>>>>>>>>>>> "canonicalize" of >>>>>>>>>>>>>>> libjava. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 >>>>>>>>>>>>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The goal is to cleanup how this function is defined and >>>>>>>>>>>>>>>> used. >>>>>> One >>>>>>>>>>>>>>>> thing is, >>>>>>>>>>>>>>> that there was an unnecessary wrapper function >>>> "Canonicalize" >>>>>> in >>>>>>>>>>>>>>> jni_util.c. >>>>>>>>>>>>>>> It wrapped the call to "canonicalize". We can get rid of >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> wrapper. >>>>>>>>>>>>>>> Unfortunately, it is not possible to just export >>>>>>>>>>>>>>> "canonicalize" >>>>>>>>>>>>>>> since this will >>>>>>>>>>>>>>> conflict with a method signature from the math library, at >>>> least >>>>>>>>>>>>>>> on modern >>>>>>>>>>>>>>> Linuxes. So I decided to call the method JDK_Canonicalize >>>>>>>>>>>>>>> and >>>>>> will >>>>>>>>>>>>>>> correctly >>>>>>>>>>>>>>> define it in jdk_util.h which can be included everywhere. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think this change is okay. My main concern when initially >>>> seeing >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> go by was that it would leak the \\?\ or \\?\UNC\ prefix >>>>>>>>>>>>>>> into >>>> the >>>>>>>>>>>>>>> canonical File when it wasn't there previously, this >>>>>>>>>>>>>>> would of >>>>>>>>>>>>>>> course >>>>>>>>>>>>>>> have several implications. But I think you have it right >>>>>>>>>>>>>>> and this >>>>>>>>>>>>>>> is, as >>>>>>>>>>>>>>> you position, just refactoring/cleanup. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Alan > From maurizio.cimadamore at oracle.com Thu Dec 5 23:27:18 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Dec 2019 23:27:18 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> Message-ID: <0dc305b6-c727-7591-469e-fedd0f16d0a0@oracle.com> On 05/12/2019 22:39, Vladimir Ivanov wrote: > Awesome work, Maurizio! > > Regarding hotspot changes: > >> * ciField.cpp - this one is to trust final fields in the foreign >> memory access implementation (otherwise VM doesn't trust memory >> segment bounds) > > New packages aren't part of java.base. Considering the implementation > resides in an incubator module, is it enough to consider them as > trusted and well-known to the JVM? This gives same performance as with -XX:+TrustFinalNonStaticFields - if we remove these changes, then memory segment bounds are never inlined. I'm happy to change this if you have other suggestions on how to get there, of course (I can run some benchmarks w/ and w/o and post some numbers if that helps). > >> * library_call.cpp - this one is a JIT compiler change to treat >> Thread.currentThread() as a well-known constant - which helps a lot >> in the confinement checks (thanks Vlad!) > > FTR it is tracked by JDK-8235143 [1] and the patch is under review [2]. Should I remove this from the patch then? Thanks Maurizio > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8235143 > > [2] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036295.html > >> * various Buffer-related changes; these changes are needed because >> the memory access API allows a memory segment to be projected into a >> byte buffer, for interop reasons. As such, we need to insert a >> liveness check in the various get/put methods. Previously we had an >> implementation strategy where a BB was 'decorated' by a subclass >> called ScopedBuffer - but doing so required some changes to the BB >> API (e.g. making certain methods non-final, so that we could decorate >> them). Here I use an approach (which I have discussed with Alan) >> which doesn't require any public API? changes, but needs to add a >> 'segment' field in Buffer - and then have constructors which keep >> track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can >> reuse the Unmapper class from the MemorySegment implementation, to >> deterministically deallocate a mapped memory segment. This should be >> a 'straight' refactoring, no change in behavior should occur here. >> Please double check. >> >> * VarHandles - this class now provides a factory to create memory >> access VarHandle - this is a bit tricky, since VarHandle cannot >> really be implemented outside java.base (e.g. VarForm is not public). >> So we do the usual trick where we define a bunch of proxy interfaces >> (see jdk/internal/access/foreign) have the classes in java.base refer >> to these - and then have the implementation classes of the memory >> access API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >> to provide access to otherwise hidden functionalities - e.g. creating >> a new scoped buffer, or retrieving the properties of a memory access >> handle (e.g. offset, stride etc.), so that we can implement the >> memory access API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the >> generation of the new memory address var handle implementations; >> there's an helper class per carrier (e.g. >> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >> var handle is needed, we dynamically spin a new VH implementation >> which makes use of the right carrier. We need to spin because the VH >> can have a variable number of access coordinates (e.g. depending on >> the dimensions of the array to be accessed). But, under the hood, all >> the generated implementation will be using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all >> possible permutations of carriers/dimensions etc. Because of that, >> the tests might not be the easiest to look at, but they have proven >> to be pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where >> it differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is >> MemoryAddress has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same >> name but do something quite different (one is an accessor, another is >> a 'wither'). one obvious option is to rename the first to >> 'withOffset'. But I think that would lead to verbose code (since that >> is a very common operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice >> which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >> Stuart, Roger, Joe and the Panama team for the feedback provided so >> far, which helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >> but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >> From forax at univ-mlv.fr Fri Dec 6 00:13:14 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 6 Dec 2019 01:13:14 +0100 (CET) Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: <105628217.1955942.1575591194730.JavaMail.zimbra@u-pem.fr> Hi Maurizio, that's a huge work :) So as a guy discovering the API, i've not taken a deep look to the implementation because i've noob questions. The first sentence of the overview of GroupLayout should say that there are two types of GroupLayout struct and union instead of talking about members layouts in italic. Still in GroupLayout, there is a static method "optSize" with no documentation and you don"t use the prefix "opt" anywhere else so i think it should be dropped. hasNaturalAlignment() is protected, but you don"t allow user to implement their own GroupLayout, so it's like the method was package private but visible in the javadoc. MemoryLayout and MemoryLayout.PathElement static methods have names that are ok to use in static imports, but it's not explicit written in the javadoc. People will say that Java is verbose :) I don't see the point of having MemoryLayouts separated from MemoryLayout. MemoryAddress should have a method that does raw bytes comparison like there is MemoryAddress.copy() so simulate struct comparison. I don't understand how MemorySegment.acquire() solve the fact that you have two threads that can access to the same underlying memory area with unprotected access. When you own a memory segment, an other thread can acquire a new memory segment and then both thread can mutate the same memory location ? MemorySegment.isAccessible() is a very overloaded term, isOwnByCurrentThread() is maybe better ? In the implementation of MemoryScope, please don't use i++ or i-- to change the lambda parameter, what you want is i - 1 or i + 1. And i wander if it's not more efficient to use getAndIncrement and if it's negative (overflow), to do a supplementary volatile write to Integer.MIN_VALUE before raising the IllegalStateException. In AddressVarHandleGenerator.iConstInsn(), ICONST_M1, ICONST_0, etc are subsequent bytecodes so you can group all the case to: mv.visitInsn(ICONST_0 + i); regards, R?mi ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "core-libs-dev" , "hotspot-dev" > Envoy?: Jeudi 5 D?cembre 2019 22:04:55 > Objet: RFR JDK-8234049: Implementation of Memory Access API (Incubator) > Hi, > as part of the effort to upstream the changes related to JEP 370 > (foreign memory access API) [1], I'd like to ask for a code review for > the corresponding core-libs and hotspot changes: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > A javadoc for the memory access API is also available here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > Here is a brief summary of the changes in java.base and hotspot (the > remaining new files are implementation classes and tests for the new API): > > * ciField.cpp - this one is to trust final fields in the foreign memory > access implementation (otherwise VM doesn't trust memory segment bounds) > > * Modules.gmk - these changes are needed to require that the incubating > module is loaded by the boot loader (otherwise the above changes are > useless) > > * library_call.cpp - this one is a JIT compiler change to treat > Thread.currentThread() as a well-known constant - which helps a lot in > the confinement checks (thanks Vlad!) > > * various Buffer-related changes; these changes are needed because the > memory access API allows a memory segment to be projected into a byte > buffer, for interop reasons. As such, we need to insert a liveness check > in the various get/put methods. Previously we had an implementation > strategy where a BB was 'decorated' by a subclass called ScopedBuffer - > but doing so required some changes to the BB API (e.g. making certain > methods non-final, so that we could decorate them). Here I use an > approach (which I have discussed with Alan) which doesn't require any > public API? changes, but needs to add a 'segment' field in Buffer - and > then have constructors which keep track of this extra parameter. > > * FileChannel changes - these changes are required so that we can reuse > the Unmapper class from the MemorySegment implementation, to > deterministically deallocate a mapped memory segment. This should be a > 'straight' refactoring, no change in behavior should occur here. Please > double check. > > * VarHandles - this class now provides a factory to create memory access > VarHandle - this is a bit tricky, since VarHandle cannot really be > implemented outside java.base (e.g. VarForm is not public). So we do the > usual trick where we define a bunch of proxy interfaces (see > jdk/internal/access/foreign) have the classes in java.base refer to > these - and then have the implementation classes of the memory access > API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to > provide access to otherwise hidden functionalities - e.g. creating a new > scoped buffer, or retrieving the properties of a memory access handle > (e.g. offset, stride etc.), so that we can implement the memory access > API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the > generation of the new memory address var handle implementations; there's > an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). > At runtime, when a memory access var handle is needed, we dynamically > spin a new VH implementation which makes use of the right carrier. We > need to spin because the VH can have a variable number of access > coordinates (e.g. depending on the dimensions of the array to be > accessed). But, under the hood, all the generated implementation will be > using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all > possible permutations of carriers/dimensions etc. Because of that, the > tests might not be the easiest to look at, but they have proven to be > pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where it > differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is MemoryAddress > has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same name > but do something quite different (one is an accessor, another is a > 'wither'). one obvious option is to rename the first to 'withOffset'. > But I think that would lead to verbose code (since that is a very common > operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers :-) > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, > Roger, Joe and the Panama team for the feedback provided so far, which > helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - > but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 From maurizio.cimadamore at oracle.com Fri Dec 6 01:07:33 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 01:07:33 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <105628217.1955942.1575591194730.JavaMail.zimbra@u-pem.fr> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <105628217.1955942.1575591194730.JavaMail.zimbra@u-pem.fr> Message-ID: <6fbd62eb-e434-c546-37af-fcc9b0744fc8@oracle.com> On 06/12/2019 00:13, Remi Forax wrote: > Hi Maurizio, > that's a huge work :) > > So as a guy discovering the API, > i've not taken a deep look to the implementation because i've noob questions. > > The first sentence of the overview of GroupLayout should say that there are two types of GroupLayout struct and union instead of talking about members layouts in italic. > Still in GroupLayout, there is a static method "optSize" with no documentation and you don"t use the prefix "opt" anywhere else so i think it should be dropped. > hasNaturalAlignment() is protected, but you don"t allow user to implement their own GroupLayout, so it's like the method was package private but visible in the javadoc. Good catch - these two methods were never meant to be exposed - they are morally package private members of a shared implementation class - I will fix that > > MemoryLayout and MemoryLayout.PathElement static methods have names that are ok to use in static imports, but it's not explicit written in the javadoc. > People will say that Java is verbose :) To give some context here - we had an earlier variant of the API which was much more concise - e.g. layout.varHandle(p -> p.groupElement("foo").sequenceElement()) This uses a builder-style idiom. The problem with this approach is that is less constant-folding friendly - which is the main reason as to why we went the current path. > > I don't see the point of having MemoryLayouts separated from MemoryLayout. Possibly - I found myself thinking that too - although, with the subsequent Panama step (ABI support) we'll be adding a ton of ABI-dependent layouts in here... (but we could address that in other ways also). If there's enough consensus one way or another I'm happy to consolidate the two classes. > > MemoryAddress should have a method that does raw bytes comparison like there is MemoryAddress.copy() so simulate struct comparison. Uhm - it's not a bad idea - but I don't immediately see why it *has* to be in the API - it will be a loop - we can't do much more than that, in terms of making it fast. > > I don't understand how MemorySegment.acquire() solve the fact that you have two threads that can access to the same underlying memory area with unprotected access. > When you own a memory segment, an other thread can acquire a new memory segment and then both thread can mutate the same memory location ? With concurrent access you have two kinds of races: - access vs. access (e.g. thread A reads while threads B write) - access vs. close (e.g. thread A reads while thread B close the segment) The first race is *not* what we want to protect you against here. The VarHandle API has plenty of primitives which allow clients to roll in their own synchronization. The really nasty issue is with the latter race - if you access a segment that has been closed, you don't just read a stale value, you can crash the VM. When you acquire a segment you obtain a new view of the same memory block which is temporally bounded by the original segment. The original segment cannot be closed until all the acquired views have been closed. This guarantees that the memory will never go away behind your back. > > MemorySegment.isAccessible() is a very overloaded term, isOwnByCurrentThread() is maybe better ? Open to suggestion - I don't particularly like yours though :-) > > In the implementation of MemoryScope, please don't use i++ or i-- to change the lambda parameter, what you want is i - 1 or i + 1. > And i wander if it's not more efficient to use getAndIncrement and if it's negative (overflow), to do a supplementary volatile write to Integer.MIN_VALUE before raising the IllegalStateException. Goo points - note that, in these cases, we don't really care about performance much - because acquiring a segment is not on the hot path (which is memory access). > > In AddressVarHandleGenerator.iConstInsn(), > ICONST_M1, ICONST_0, etc are subsequent bytecodes so you can group all the case to: mv.visitInsn(ICONST_0 + i); will do thanks! Maurizio > > regards, > R?mi > > ----- Mail original ----- >> De: "Maurizio Cimadamore" >> ?: "core-libs-dev" , "hotspot-dev" >> Envoy?: Jeudi 5 D?cembre 2019 22:04:55 >> Objet: RFR JDK-8234049: Implementation of Memory Access API (Incubator) >> Hi, >> as part of the effort to upstream the changes related to JEP 370 >> (foreign memory access API) [1], I'd like to ask for a code review for >> the corresponding core-libs and hotspot changes: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >> >> A javadoc for the memory access API is also available here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> Note: the patch passes tier1, tier2 and tier3 testing (**) >> >> >> Here is a brief summary of the changes in java.base and hotspot (the >> remaining new files are implementation classes and tests for the new API): >> >> * ciField.cpp - this one is to trust final fields in the foreign memory >> access implementation (otherwise VM doesn't trust memory segment bounds) >> >> * Modules.gmk - these changes are needed to require that the incubating >> module is loaded by the boot loader (otherwise the above changes are >> useless) >> >> * library_call.cpp - this one is a JIT compiler change to treat >> Thread.currentThread() as a well-known constant - which helps a lot in >> the confinement checks (thanks Vlad!) >> >> * various Buffer-related changes; these changes are needed because the >> memory access API allows a memory segment to be projected into a byte >> buffer, for interop reasons. As such, we need to insert a liveness check >> in the various get/put methods. Previously we had an implementation >> strategy where a BB was 'decorated' by a subclass called ScopedBuffer - >> but doing so required some changes to the BB API (e.g. making certain >> methods non-final, so that we could decorate them). Here I use an >> approach (which I have discussed with Alan) which doesn't require any >> public API? changes, but needs to add a 'segment' field in Buffer - and >> then have constructors which keep track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can reuse >> the Unmapper class from the MemorySegment implementation, to >> deterministically deallocate a mapped memory segment. This should be a >> 'straight' refactoring, no change in behavior should occur here. Please >> double check. >> >> * VarHandles - this class now provides a factory to create memory access >> VarHandle - this is a bit tricky, since VarHandle cannot really be >> implemented outside java.base (e.g. VarForm is not public). So we do the >> usual trick where we define a bunch of proxy interfaces (see >> jdk/internal/access/foreign) have the classes in java.base refer to >> these - and then have the implementation classes of the memory access >> API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to >> provide access to otherwise hidden functionalities - e.g. creating a new >> scoped buffer, or retrieving the properties of a memory access handle >> (e.g. offset, stride etc.), so that we can implement the memory access >> API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the >> generation of the new memory address var handle implementations; there's >> an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). >> At runtime, when a memory access var handle is needed, we dynamically >> spin a new VH implementation which makes use of the right carrier. We >> need to spin because the VH can have a variable number of access >> coordinates (e.g. depending on the dimensions of the array to be >> accessed). But, under the hood, all the generated implementation will be >> using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all >> possible permutations of carriers/dimensions etc. Because of that, the >> tests might not be the easiest to look at, but they have proven to be >> pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where it >> differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is MemoryAddress >> has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same name >> but do something quite different (one is an accessor, another is a >> 'wither'). one obvious option is to rename the first to 'withOffset'. >> But I think that would lead to verbose code (since that is a very common >> operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice >> which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, >> Roger, Joe and the Panama team for the feedback provided so far, which >> helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >> but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 From philip.race at oracle.com Fri Dec 6 01:33:10 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 05 Dec 2019 17:33:10 -0800 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> References: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> Message-ID: <5DE9AFD6.5070501@oracle.com> I don't understand the relationship between these two bugs. -phil On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: > Please review fixes for [1] and [2]. Both target jpackage tool. > > The webrev is at [3]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8233270 > > [2] https://bugs.openjdk.java.net/browse/JDK-8230933 > > [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ > From alexander.matveev at oracle.com Fri Dec 6 01:44:00 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 5 Dec 2019 17:44:00 -0800 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: <5DE9AFD6.5070501@oracle.com> References: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> <5DE9AFD6.5070501@oracle.com> Message-ID: <3f557b9a-a5bc-221f-1a45-486d0bf36e6e@oracle.com> Hi Alexey, 1) Remove this file: test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.rej 2) Agree with Phil, they probably should be pushed as two separate bugs. 3) Do you know how to run installer tests with new changes? It is not clear from code. Changes itself looks fine. Thanks, Alexander On 12/5/2019 5:33 PM, Philip Race wrote: > I don't understand the relationship between these two bugs. > > -phil > > On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: >> Please review? fixes for [1] and [2]. Both target jpackage tool. >> >> The webrev is at [3]. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8233270 >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8230933 >> >> [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ >> From Nikola.Grcevski at microsoft.com Fri Dec 6 01:57:05 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Fri, 6 Dec 2019 01:57:05 +0000 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> Message-ID: Hello all again! Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: --- a/src/java.base/share/native/libjli/args.c +++ b/src/java.base/share/native/libjli/args.c @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { } } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { stopExpansion = JNI_TRUE; + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { + idx = argsCount; } } else { if (!expectingNoDashArg) { The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). I ran all the launcher tests on both Windows and Linux and all tests pass. Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. Thank you, Nikola -----Original Message----- From: Henry Jen Sent: December 4, 2019 8:26 PM To: Kumar Srinivasan ; Alan Bateman ; Nikola Grcevski Cc: core-libs-dev at openjdk.java.net Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: > > Hi Nikola, > > It looks ok to me, I will leave it to Henry and Alan to bless this. > > IMHO: I think we should fix it correctly now than later, I don't think > it is all that difficult AFAICT all the launcher has to do is > identify "--module==", then the next argument is the first index. > I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. I?ll let Alan to comment about the ?module option usage. The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F13%2Fdocs%2Fspecs%2Fman%2Fjava.html&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=uO2tgi1QNvXgI0wT%2FxOxB%2Bh10YpCbq37uzkKKlByUYg%3D&reserved=0 > Kumar > > On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: > Hi Henry and Kumar, > > Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. > > Please find my updated webrev here for your review: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrce > vski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grc > evski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f > 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ% > 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > > Cheers, > > Nikola > > -----Original Message----- > From: Henry Jen > Sent: December 3, 2019 11:39 AM > To: Kumar Srinivasan > Cc: Nikola Grcevski ; Alan Bateman > ; core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > Kumar, > > Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. > > We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. > > Cheers, > Henry > > > On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: > > > > Hi, > > > > Sorry for chiming in late in the review process, for what it's worth.... > > > > 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class > > and subsequent crash, but it does not address wildcard arguments expansion. > > > > What if we have > > % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java > > Where jdk.compiler is a java compiler implementation (javac). > > The user would expect the above compiler module to build all the .java files in that directory, > > and this fix will not address that. > > > > Some background: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > > gs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola > > .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 > > 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b > > 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 > > Please see all the related bugs in the above JIRA issue. > > > > Paragraph #6 in this interview surmises the wild card behavior on Windows: > > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. > > princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=0 > > 2%7C01%7CNikola.Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d77 > > 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 > > 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& > > ;reserved=0 > > > > 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg > > .openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2 > > Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs > > ki%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f1 > > 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE > > WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 > > Using the modules test framework may make the test simpler. > > > > Kumar Srinivasan > > > > > > On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: > > Hi Alan and Henry, > > > > Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. > > > > I created a webrev here for the change, including a new test in Arrrghs.java: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr > > cevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola > > .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 > > 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e > > e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > > > > I copied the test validation and assertion style of other code inside the test class. > > > > Please let me know if you have any comments or suggestions. > > > > Thanks again! > > > > -----Original Message----- > > From: Henry Jen > > Sent: December 2, 2019 12:26 PM > > To: Alan Bateman > > Cc: Nikola Grcevski ; > > core-libs-dev at openjdk.java.net > > Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > > > > The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. > > > > I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. > > > > As I understand it, the argument validation is done in a later stage after calling JLI_Launch. > > > > Cheers, > > Henry > > > > > > > On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > > > > > > On 20/11/2019 19:42, Nikola Grcevski wrote: > > >> : > > >> > > >> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. > > >> > > > I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > > > > > > -Alan > > > From mandy.chung at oracle.com Fri Dec 6 03:17:37 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 Dec 2019 19:17:37 -0800 Subject: RFR JDK-8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag Message-ID: <5edc03d8-4644-18a3-80d7-f6895f1f4fc3@oracle.com> When unreflecting on a Method for caller-sensitive method, the produced MethodHandle should bind with the original caller lookup independent of the accessible flag. Webrev: ? http://cr.openjdk.java.net/~mchung/jdk14/8235351/webrev.00/ thanks Mandy From henry.jen at oracle.com Fri Dec 6 04:18:34 2019 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 5 Dec 2019 20:18:34 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: <21cdc073-f1c1-195c-e825-a0273d67d456@oracle.com> References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> <8f08f1fd-db11-5709-0925-d6ccdcdf3e48@oracle.com> <21cdc073-f1c1-195c-e825-a0273d67d456@oracle.com> Message-ID: OK, so I created an issue[1] for follow up for Windows build and reverted the change in flags-cflags.m4, if nothing else, I?ll push without another webrev pinging that I get an +1 from someone in build-de, Erik? [1] https://bugs.openjdk.java.net/browse/JDK-8235461 Cheers, Henry > On Dec 5, 2019, at 12:21 PM, Mandy Chung wrote: > > > > On 12/5/19 12:41 AM, Alan Bateman wrote: >> On 05/12/2019 08:16, Henry Jen wrote: >>> Hi, >>> >>> Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. >>> >>> Changes to symbols is reverted, as we expect that only need to be updated in next release by running make/scripts/generate-symbol-data.sh. >>> >>> The jar files are confusing in the webrev, but those files are removed. The whole test/jdk/tools/pack200 is removed. >>> >>> Cheers, >>> Henry >>> >>> [1] http://cr.openjdk.java.net/~henryjen/jdk14/8234542/0/webrev/ >>> >> The update webrev looks okay to me, except this part of the comment in flags-cflags.m4 >> >> "Now that unpack200 has been removed we should consider setting it for windows too. but this could be done as a follow-up effort. It could be that other other clients are relying on the current configuration for windows". >> >> I think it would be best to create an infrastructure/build issue and leave most of this confusing comment out. >> > > I also think keeping flags-cflags.m4 as is and file a new build issue as a follow-up would be better. > > Otherwise, this updated webrev looks okay to me. > > Mandy From henry.jen at oracle.com Fri Dec 6 05:03:03 2019 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 5 Dec 2019 21:03:03 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> Message-ID: <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> > On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: > > Hello all again! > > Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: > > --- a/src/java.base/share/native/libjli/args.c > +++ b/src/java.base/share/native/libjli/args.c > @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. BTW, we need the patch to be hosted on cr.openjdk.java.net or you can attach the patch to the review thread if you are not yet an author. Cheers, Henry > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > > The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. > > I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. > > I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). > > I ran all the launcher tests on both Windows and Linux and all tests pass. > > Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. > > Thank you, > Nikola > > -----Original Message----- > From: Henry Jen > Sent: December 4, 2019 8:26 PM > To: Kumar Srinivasan ; Alan Bateman ; Nikola Grcevski > Cc: core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >> >> Hi Nikola, >> >> It looks ok to me, I will leave it to Henry and Alan to bless this. >> >> IMHO: I think we should fix it correctly now than later, I don't think >> it is all that difficult AFAICT all the launcher has to do is >> identify "--module==", then the next argument is the first index. >> > > I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. > > If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. > > FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. > > I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. > > I?ll let Alan to comment about the ?module option usage. > > The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fjava%2Fjavase%2F13%2Fdocs%2Fspecs%2Fman%2Fjava.html&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=uO2tgi1QNvXgI0wT%2FxOxB%2Bh10YpCbq37uzkKKlByUYg%3D&reserved=0 > >> Kumar >> >> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >> Hi Henry and Kumar, >> >> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >> >> Please find my updated webrev here for your review: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrce >> vski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grc >> evski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f >> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ% >> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >> >> Cheers, >> >> Nikola >> >> -----Original Message----- >> From: Henry Jen >> Sent: December 3, 2019 11:39 AM >> To: Kumar Srinivasan >> Cc: Nikola Grcevski ; Alan Bateman >> ; core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> Kumar, >> >> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >> >> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >> >> Cheers, >> Henry >> >>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>> >>> Hi, >>> >>> Sorry for chiming in late in the review process, for what it's worth.... >>> >>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>> and subsequent crash, but it does not address wildcard arguments expansion. >>> >>> What if we have >>> % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>> Where jdk.compiler is a java compiler implementation (javac). >>> The user would expect the above compiler module to build all the .java files in that directory, >>> and this fix will not address that. >>> >>> Some background: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>> gs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola >>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>> Please see all the related bugs in the above JIRA issue. >>> >>> Paragraph #6 in this interview surmises the wild card behavior on Windows: >>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>> princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=0 >>> 2%7C01%7CNikola.Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d77 >>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>> ;reserved=0 >>> >>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>> .openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2 >>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>> ki%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f1 >>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>> Using the modules test framework may make the test simpler. >>> >>> Kumar Srinivasan >>> >>> >>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>> Hi Alan and Henry, >>> >>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>> >>> I created a webrev here for the change, including a new test in Arrrghs.java: >>> >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>> cevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola >>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>> >>> I copied the test validation and assertion style of other code inside the test class. >>> >>> Please let me know if you have any comments or suggestions. >>> >>> Thanks again! >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 2, 2019 12:26 PM >>> To: Alan Bateman >>> Cc: Nikola Grcevski ; >>> core-libs-dev at openjdk.java.net >>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>> >>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>> >>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>> >>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>> >>> Cheers, >>> Henry >>> >>> >>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>> >>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>> : >>>>> >>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>> >>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>> >>>> -Alan From david.holmes at oracle.com Fri Dec 6 07:01:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Dec 2019 17:01:51 +1000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> Message-ID: Hi Christoph, On 6/12/2019 2:12 am, Langer, Christoph wrote: > Hi David, > > I prepared an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.3/ > >> src/java.base/windows/native/libjava/canonicalize_md.c >> >> +// We can't include jdk_util.h here because the file is used in Oracle >> in another context >> +// #include "jdk_util.h" >> >> Seems to me clients of JDK_Canonicalize need to include jdk_util.h, not >> the files that implement it. So there is no reason to include it here >> and so no need for the comment. > > Well, it's actually not needed but I think it's good practice that the declaring header is included in the implementation file. Yes I was forgetting the importance of ensuring the declaration in the header matches the definition. There is a typo in the comment "possibile". >> Further, does: >> >> src/java.base/unix/native/libjava/canonicalize_md.c >> >> need to include jdk_util.h? I think not. > > Same as for the windows file - not necessary but good style. > >> +/* The appropriate location of getPrefixed() is io_util_md.c, but it is >> + also used in a non-OpenJDK context within Oracle. There, >> canonicalize_md.c >> + is already pulled in and compiled, so to avoid more complicate solutions >> + we keep this method here. */ >> >> I don't like to have comments like this but I guess it is needed here. >> Please put the */ on a newline. Also s/complicate/complicates/ > > I did as Dan pointed out. :) Yes sorry about that slip. Otherwise all looks good. No need for new webrev for the typo. Thanks, David >> src/java.base/windows/native/libjava/io_util_md.c >> >> should now be unchanged, but you've left in the copyright update. >> > > Right, thanks for the catch. > >> A second review is still needed for the final version of this. > > Dan, can I add you as reviewer then? > > Best regards > Christoph > From christoph.langer at sap.com Fri Dec 6 08:04:54 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Dec 2019 08:04:54 +0000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> Message-ID: Thanks, David. I'll run the final change once again through jdk-submit befor pushing. Alan, Dan, may I consider this reviewed by either of you? Thanks Christoph > -----Original Message----- > From: David Holmes > Sent: Freitag, 6. Dezember 2019 08:02 > To: Langer, Christoph ; > daniel.daugherty at oracle.com > Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net; Alan Bateman ; gerard > ziemski > Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between > libjava, hotspot and libinstrument > > Hi Christoph, > > On 6/12/2019 2:12 am, Langer, Christoph wrote: > > Hi David, > > > > I prepared an updated webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8234185.3/ > > > >> src/java.base/windows/native/libjava/canonicalize_md.c > >> > >> +// We can't include jdk_util.h here because the file is used in Oracle > >> in another context > >> +// #include "jdk_util.h" > >> > >> Seems to me clients of JDK_Canonicalize need to include jdk_util.h, not > >> the files that implement it. So there is no reason to include it here > >> and so no need for the comment. > > > > Well, it's actually not needed but I think it's good practice that the declaring > header is included in the implementation file. > > Yes I was forgetting the importance of ensuring the declaration in the > header matches the definition. There is a typo in the comment "possibile". > > >> Further, does: > >> > >> src/java.base/unix/native/libjava/canonicalize_md.c > >> > >> need to include jdk_util.h? I think not. > > > > Same as for the windows file - not necessary but good style. > > > >> +/* The appropriate location of getPrefixed() is io_util_md.c, but it is > >> + also used in a non-OpenJDK context within Oracle. There, > >> canonicalize_md.c > >> + is already pulled in and compiled, so to avoid more complicate solutions > >> + we keep this method here. */ > >> > >> I don't like to have comments like this but I guess it is needed here. > >> Please put the */ on a newline. Also s/complicate/complicates/ > > > > I did as Dan pointed out. > > :) Yes sorry about that slip. > > Otherwise all looks good. No need for new webrev for the typo. > > Thanks, > David > > >> src/java.base/windows/native/libjava/io_util_md.c > >> > >> should now be unchanged, but you've left in the copyright update. > >> > > > > Right, thanks for the catch. > > > >> A second review is still needed for the final version of this. > > > > Dan, can I add you as reviewer then? > > > > Best regards > > Christoph > > From maurizio.cimadamore at oracle.com Fri Dec 6 08:32:12 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 08:32:12 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <105628217.1955942.1575591194730.JavaMail.zimbra@u-pem.fr> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <105628217.1955942.1575591194730.JavaMail.zimbra@u-pem.fr> Message-ID: <39931722-731d-6cdd-fa9b-c0173a8e565c@oracle.com> Couple of naming ideas: > MemorySegment.isAccessible() is a very overloaded term, isOwnByCurrentThread() is maybe better ? One solution here would be to, instead, have an accessor called ownerThread() - then clients can test doing ownerThread() != Thread.currentThread (or some other thread). After all a segment is specified to have an owner, so it kind of makes sense to have an accessor for it? > I don't understand how MemorySegment.acquire() solve the fact that you have two threads that can access to the same underlying memory area with unprotected access. > When you own a memory segment, an other thread can acquire a new memory segment and then both thread can mutate the same memory location ? I believe the name "acquire" might not describe accurately what is going on - I believe "fork" is much closer to what the method is actually doing. You can imagine segments forming a tree - if you keep forking from same segment, you create a lot of sub-segments - and so on and so forth. A segment cannot be closed if it has a non-zero number of forks. Maurizio From maurizio.cimadamore at oracle.com Fri Dec 6 08:48:49 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 08:48:49 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <0dc305b6-c727-7591-469e-fedd0f16d0a0@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> <0dc305b6-c727-7591-469e-fedd0f16d0a0@oracle.com> Message-ID: On 05/12/2019 23:27, Maurizio Cimadamore wrote: > This gives same performance as with -XX:+TrustFinalNonStaticFields - > if we remove these changes, then memory segment bounds are never > inlined. I'm happy to change this if you have other suggestions on how > to get there, of course (I can run some benchmarks w/ and w/o and post > some numbers if that helps). Here are some numbers for a straight VH get using a constant address; with the patch I get this (throughput - higher the better): GetSetConstantBenchmark.testMemoryHandleGet? --> 299325598.056 ? 160635.595? ops/s Without the patch I get this: GetSetConstantBenchmark.testMemoryHandleGet? -->? 163721200.469 ? 2344351.046? ops/s So, the difference is quiet big. Graal (using JVMCI) seems less sensitive to this particular issue, and I detected no differences there. That said, if we have plans to fix this another way, I'm happy to remove this workaround. Cheers Maurizio From maurizio.cimadamore at oracle.com Fri Dec 6 10:43:22 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 10:43:22 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> Hi, here's an updated version of the patch: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ And a delta of the changes since last version here: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ The javadoc has been updated inline here: http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html Summary of changes: * fixed spurious protected methods in AbstractLayout and subclasses which leaked into API * removed library_call.cpp changes, as these are being tracked separately by Vlad * compacted ILOAD code in AddressVarHandleGenerator * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope I have made no changes to the *name* of the methods in the API. In fact, I suggest we keep a list of the names we'd like to revisit, and we address them all at once at the end of the review (once we're happy with the contents). Here's a list of the current open naming issues: * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much distance between these two semantically different operations * MemorySegment::isAccessible() -- as the A* word is overloaded, some other name should be found? * MemorySegment::acquire() -- replace with MemorySegment::fork? Cheers Maurizio On 05/12/2019 21:04, Maurizio Cimadamore wrote: > Hi, > as part of the effort to upstream the changes related to JEP 370 > (foreign memory access API) [1], I'd like to ask for a code review for > the corresponding core-libs and hotspot changes: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > A javadoc for the memory access API is also available here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > Here is a brief summary of the changes in java.base and hotspot (the > remaining new files are implementation classes and tests for the new > API): > > * ciField.cpp - this one is to trust final fields in the foreign > memory access implementation (otherwise VM doesn't trust memory > segment bounds) > > * Modules.gmk - these changes are needed to require that the > incubating module is loaded by the boot loader (otherwise the above > changes are useless) > > * library_call.cpp - this one is a JIT compiler change to treat > Thread.currentThread() as a well-known constant - which helps a lot in > the confinement checks (thanks Vlad!) > > * various Buffer-related changes; these changes are needed because the > memory access API allows a memory segment to be projected into a byte > buffer, for interop reasons. As such, we need to insert a liveness > check in the various get/put methods. Previously we had an > implementation strategy where a BB was 'decorated' by a subclass > called ScopedBuffer - but doing so required some changes to the BB API > (e.g. making certain methods non-final, so that we could decorate > them). Here I use an approach (which I have discussed with Alan) which > doesn't require any public API changes, but needs to add a 'segment' > field in Buffer - and then have constructors which keep track of this > extra parameter. > > * FileChannel changes - these changes are required so that we can > reuse the Unmapper class from the MemorySegment implementation, to > deterministically deallocate a mapped memory segment. This should be a > 'straight' refactoring, no change in behavior should occur here. > Please double check. > > * VarHandles - this class now provides a factory to create memory > access VarHandle - this is a bit tricky, since VarHandle cannot really > be implemented outside java.base (e.g. VarForm is not public). So we > do the usual trick where we define a bunch of proxy interfaces (see > jdk/internal/access/foreign) have the classes in java.base refer to > these - and then have the implementation classes of the memory access > API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need > to provide access to otherwise hidden functionalities - e.g. creating > a new scoped buffer, or retrieving the properties of a memory access > handle (e.g. offset, stride etc.), so that we can implement the memory > access API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the > generation of the new memory address var handle implementations; > there's an helper class per carrier (e.g. > VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access > var handle is needed, we dynamically spin a new VH implementation > which makes use of the right carrier. We need to spin because the VH > can have a variable number of access coordinates (e.g. depending on > the dimensions of the array to be accessed). But, under the hood, all > the generated implementation will be using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all > possible permutations of carriers/dimensions etc. Because of that, the > tests might not be the easiest to look at, but they have proven to be > pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where > it differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is > MemoryAddress has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same > name but do something quite different (one is an accessor, another is > a 'wither'). one obvious option is to rename the first to > 'withOffset'. But I think that would lead to verbose code (since that > is a very common operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers :-) > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, > Stuart, Roger, Joe and the Panama team for the feedback provided so > far, which helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - > but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 > From martin.doerr at sap.com Fri Dec 6 11:21:39 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 6 Dec 2019 11:21:39 +0000 Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array In-Reply-To: References: Message-ID: Hi Christoph, that would work, but I don?t want to pollute this file with compiler specific defines. In addition, I don?t like introducing a macro which works on some platforms and does nothing on other ones (which is the case for hotspot?s ATTRIBUTE_ALIGNED). Because Windows 32 bit is the only affected platform, I prefer not to touch other ones. Are you ok with webrev.00 as it is? Best regards, Martin From: Langer, Christoph Sent: Donnerstag, 5. Dezember 2019 12:16 To: Doerr, Martin Cc: core-libs-dev at openjdk.java.net; security-dev ; Lindenmaier, Goetz ; Thomas St?fe Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Martin, I can see that both places already include headers from src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. WindowsPreferences.c already includes it. Best regards Christoph From: Doerr, Martin > Sent: Donnerstag, 5. Dezember 2019 12:00 To: Thomas St?fe >; Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; security-dev >; Lindenmaier, Goetz > Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Thomas and Christoph, thanks for the reviews. Other code in java.security.jgss also uses these #defined checks: src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER) I?d like to have it consistent with that. @Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it? Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned. (AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too: https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html) Best regards, Martin From: Thomas St?fe > Sent: Mittwoch, 4. Dezember 2019 17:56 To: Doerr, Martin > Cc: core-libs-dev at openjdk.java.net; security-dev >; Lindenmaier, Goetz > Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Martin, this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal. +#if defined (_WIN32) && defined (_MSC_VER) Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++? Cheers, Thomas On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin > wrote: Hi, I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport): https://bugs.openjdk.java.net/browse/JDK-8220348 Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer. jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted). However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default. I found such issues in the following files: src/java.prefs/windows/native/libprefs/WindowsPreferences.c src/java.security.jgss/share/native/libj2gss/GSSLibStub.c I suggest to use __declspec(align(8)) there. Webrev: http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/ Please review. I think using 8 byte alignment is not a disadvantage for 64 bit. I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix. Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack? Best regards, Martin From Alan.Bateman at oracle.com Fri Dec 6 11:32:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Dec 2019 11:32:04 +0000 Subject: RFR JDK-8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag In-Reply-To: <5edc03d8-4644-18a3-80d7-f6895f1f4fc3@oracle.com> References: <5edc03d8-4644-18a3-80d7-f6895f1f4fc3@oracle.com> Message-ID: <24072e20-02a7-e36f-302e-7648cd09063d@oracle.com> On 06/12/2019 03:17, Mandy Chung wrote: > When unreflecting on a Method for caller-sensitive method, the produced > MethodHandle should bind with the original caller lookup independent > of the accessible flag. > > Webrev: > ? http://cr.openjdk.java.net/~mchung/jdk14/8235351/webrev.00/ This looks good to me, the expanded test coverage is good too (probably should add 8235351 to the @bug tag). -Alan From jorn.vernee at oracle.com Fri Dec 6 11:53:18 2019 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 6 Dec 2019 12:53:18 +0100 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> Message-ID: <83d4f431-85f7-4434-2088-d79288223686@oracle.com> > * drop offset() - but then add an overload of MemorySegment::asSlice which takes an address instead of a plain long offset This sounds good to me, since it fits with what we're doing with makeUncheckedSegment(MemoryAddress, length), and we added the offset() accessor to support slicing. I don't like changing the name of offset(long) to advance(long) since the offset can be negative as well (and 'advance' implies only positive). >> I don't see the point of having MemoryLayouts separated from MemoryLayout. > Possibly - I found myself thinking that too - although, with the subsequent Panama step (ABI support) we'll be adding a ton of ABI-dependent layouts in here... (but we could address that in other ways also). We had some ideas to move the ABI constants to separate classes I remember. I.e. provide separate classes for different platform ABIs (implementing SystemABI), and stick the constants in there. Together with the idea to make JAVA_INT into Integer::LAYOUT later, I think the remaining constants fit into MemoryLayout pretty naturally, and we can remove MemoryLayouts. Jorn On 06/12/2019 11:43, Maurizio Cimadamore wrote: > Hi, > here's an updated version of the patch: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ > > And a delta of the changes since last version here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ > > The javadoc has been updated inline here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Summary of changes: > > * fixed spurious protected methods in AbstractLayout and subclasses > which leaked into API > * removed library_call.cpp changes, as these are being tracked > separately by Vlad > * compacted ILOAD code in AddressVarHandleGenerator > * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope > > I have made no changes to the *name* of the methods in the API. In > fact, I suggest we keep a list of the names we'd like to revisit, and > we address them all at once at the end of the review (once we're happy > with the contents). Here's a list of the current open naming issues: > > * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much > distance between these two semantically different operations > * MemorySegment::isAccessible() -- as the A* word is overloaded, some > other name should be found? > * MemorySegment::acquire() -- replace with MemorySegment::fork? > > Cheers > Maurizio > > > On 05/12/2019 21:04, Maurizio Cimadamore wrote: >> Hi, >> as part of the effort to upstream the changes related to JEP 370 >> (foreign memory access API) [1], I'd like to ask for a code review >> for the corresponding core-libs and hotspot changes: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >> >> A javadoc for the memory access API is also available here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Note: the patch passes tier1, tier2 and tier3 testing (**) >> >> >> Here is a brief summary of the changes in java.base and hotspot (the >> remaining new files are implementation classes and tests for the new >> API): >> >> * ciField.cpp - this one is to trust final fields in the foreign >> memory access implementation (otherwise VM doesn't trust memory >> segment bounds) >> >> * Modules.gmk - these changes are needed to require that the >> incubating module is loaded by the boot loader (otherwise the above >> changes are useless) >> >> * library_call.cpp - this one is a JIT compiler change to treat >> Thread.currentThread() as a well-known constant - which helps a lot >> in the confinement checks (thanks Vlad!) >> >> * various Buffer-related changes; these changes are needed because >> the memory access API allows a memory segment to be projected into a >> byte buffer, for interop reasons. As such, we need to insert a >> liveness check in the various get/put methods. Previously we had an >> implementation strategy where a BB was 'decorated' by a subclass >> called ScopedBuffer - but doing so required some changes to the BB >> API (e.g. making certain methods non-final, so that we could decorate >> them). Here I use an approach (which I have discussed with Alan) >> which doesn't require any public API changes, but needs to add a >> 'segment' field in Buffer - and then have constructors which keep >> track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can >> reuse the Unmapper class from the MemorySegment implementation, to >> deterministically deallocate a mapped memory segment. This should be >> a 'straight' refactoring, no change in behavior should occur here. >> Please double check. >> >> * VarHandles - this class now provides a factory to create memory >> access VarHandle - this is a bit tricky, since VarHandle cannot >> really be implemented outside java.base (e.g. VarForm is not public). >> So we do the usual trick where we define a bunch of proxy interfaces >> (see jdk/internal/access/foreign) have the classes in java.base refer >> to these - and then have the implementation classes of the memory >> access API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >> to provide access to otherwise hidden functionalities - e.g. creating >> a new scoped buffer, or retrieving the properties of a memory access >> handle (e.g. offset, stride etc.), so that we can implement the >> memory access API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the >> generation of the new memory address var handle implementations; >> there's an helper class per carrier (e.g. >> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >> var handle is needed, we dynamically spin a new VH implementation >> which makes use of the right carrier. We need to spin because the VH >> can have a variable number of access coordinates (e.g. depending on >> the dimensions of the array to be accessed). But, under the hood, all >> the generated implementation will be using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all >> possible permutations of carriers/dimensions etc. Because of that, >> the tests might not be the easiest to look at, but they have proven >> to be pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where >> it differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is >> MemoryAddress has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same >> name but do something quite different (one is an accessor, another is >> a 'wither'). one obvious option is to rename the first to >> 'withOffset'. But I think that would lead to verbose code (since that >> is a very common operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice >> which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >> Stuart, Roger, Joe and the Panama team for the feedback provided so >> far, which helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >> but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >> From maurizio.cimadamore at oracle.com Fri Dec 6 12:06:00 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 12:06:00 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <83d4f431-85f7-4434-2088-d79288223686@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <83d4f431-85f7-4434-2088-d79288223686@oracle.com> Message-ID: <96811c65-c48a-3f41-12e8-a8b855cf3894@oracle.com> On 06/12/2019 11:53, Jorn Vernee wrote: > > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > This sounds good to me, since it fits with what we're doing with > makeUncheckedSegment(MemoryAddress, length), and we added the offset() > accessor to support slicing. I don't like changing the name of > offset(long) to advance(long) since the offset can be negative as well > (and 'advance' implies only positive). Right - I'd say if we go down this path we need at least two overload: * MemorySegment::asSlice(MemoryAddress, long) * MemoryAddress::offset(MemoryAddress) And then we could be offset() free :-) > > >> I don't see the point of having MemoryLayouts separated from > MemoryLayout. > > Possibly - I found myself thinking that too - although, with the > subsequent Panama step (ABI support) we'll be adding a ton of > ABI-dependent layouts in here... (but we could address that in other > ways also). > > We had some ideas to move the ABI constants to separate classes I > remember. I.e. provide separate classes for different platform ABIs > (implementing SystemABI), and stick the constants in there. Together > with the idea to make JAVA_INT into Integer::LAYOUT later, I think the > remaining constants fit into MemoryLayout pretty naturally, and we can > remove MemoryLayouts. Yeah - that's what I was referring to when I said " (but we could address that in other ways also). " :-) Maurizio > > Jorn > > On 06/12/2019 11:43, Maurizio Cimadamore wrote: >> Hi, >> here's an updated version of the patch: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ >> >> And a delta of the changes since last version here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ >> >> The javadoc has been updated inline here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Summary of changes: >> >> * fixed spurious protected methods in AbstractLayout and subclasses >> which leaked into API >> * removed library_call.cpp changes, as these are being tracked >> separately by Vlad >> * compacted ILOAD code in AddressVarHandleGenerator >> * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope >> >> I have made no changes to the *name* of the methods in the API. In >> fact, I suggest we keep a list of the names we'd like to revisit, and >> we address them all at once at the end of the review (once we're >> happy with the contents). Here's a list of the current open naming >> issues: >> >> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much >> distance between these two semantically different operations >> * MemorySegment::isAccessible() -- as the A* word is overloaded, some >> other name should be found? >> * MemorySegment::acquire() -- replace with MemorySegment::fork? >> >> Cheers >> Maurizio >> >> >> On 05/12/2019 21:04, Maurizio Cimadamore wrote: >>> Hi, >>> as part of the effort to upstream the changes related to JEP 370 >>> (foreign memory access API) [1], I'd like to ask for a code review >>> for the corresponding core-libs and hotspot changes: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>> >>> A javadoc for the memory access API is also available here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>> >>> >>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>> >>> >>> Here is a brief summary of the changes in java.base and hotspot (the >>> remaining new files are implementation classes and tests for the new >>> API): >>> >>> * ciField.cpp - this one is to trust final fields in the foreign >>> memory access implementation (otherwise VM doesn't trust memory >>> segment bounds) >>> >>> * Modules.gmk - these changes are needed to require that the >>> incubating module is loaded by the boot loader (otherwise the above >>> changes are useless) >>> >>> * library_call.cpp - this one is a JIT compiler change to treat >>> Thread.currentThread() as a well-known constant - which helps a lot >>> in the confinement checks (thanks Vlad!) >>> >>> * various Buffer-related changes; these changes are needed because >>> the memory access API allows a memory segment to be projected into a >>> byte buffer, for interop reasons. As such, we need to insert a >>> liveness check in the various get/put methods. Previously we had an >>> implementation strategy where a BB was 'decorated' by a subclass >>> called ScopedBuffer - but doing so required some changes to the BB >>> API (e.g. making certain methods non-final, so that we could >>> decorate them). Here I use an approach (which I have discussed with >>> Alan) which doesn't require any public API changes, but needs to add >>> a 'segment' field in Buffer - and then have constructors which keep >>> track of this extra parameter. >>> >>> * FileChannel changes - these changes are required so that we can >>> reuse the Unmapper class from the MemorySegment implementation, to >>> deterministically deallocate a mapped memory segment. This should be >>> a 'straight' refactoring, no change in behavior should occur here. >>> Please double check. >>> >>> * VarHandles - this class now provides a factory to create memory >>> access VarHandle - this is a bit tricky, since VarHandle cannot >>> really be implemented outside java.base (e.g. VarForm is not >>> public). So we do the usual trick where we define a bunch of proxy >>> interfaces (see jdk/internal/access/foreign) have the classes in >>> java.base refer to these - and then have the implementation classes >>> of the memory access API implement these interfaces. >>> >>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we >>> need to provide access to otherwise hidden functionalities - e.g. >>> creating a new scoped buffer, or retrieving the properties of a >>> memory access handle (e.g. offset, stride etc.), so that we can >>> implement the memory access API in its own separate module >>> >>> * GensrcVarHandles.gmk - these changes are needed to enable the >>> generation of the new memory address var handle implementations; >>> there's an helper class per carrier (e.g. >>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory >>> access var handle is needed, we dynamically spin a new VH >>> implementation which makes use of the right carrier. We need to spin >>> because the VH can have a variable number of access coordinates >>> (e.g. depending on the dimensions of the array to be accessed). But, >>> under the hood, all the generated implementation will be using the >>> same helper class. >>> >>> * tests - we've tried to add fairly robust tests, often checking all >>> possible permutations of carriers/dimensions etc. Because of that, >>> the tests might not be the easiest to look at, but they have proven >>> to be pretty effective at shaking out issues. >>> >>> I think that covers the main aspects of the implementation and where >>> it differs from vanilla JDK. >>> >>> P.S. >>> >>> In the CSR review [2], Joe raised a fair point - which is >>> MemoryAddress has both: >>> >>> offset(long) --> move address of given offset >>> offset() --> return the offset of this address in its owning segment >>> >>> And this was considered suboptimal, given both methods use the same >>> name but do something quite different (one is an accessor, another >>> is a 'wither'). one obvious option is to rename the first to >>> 'withOffset'. But I think that would lead to verbose code (since >>> that is a very common operation). Other options are to: >>> >>> * rename offset(long) to move(long), advance(long), or something else >>> * drop offset() - but then add an overload of MemorySegment::asSlice >>> which takes an address instead of a plain long offset >>> >>> I'll leave the choice to the reviewers :-) >>> >>> >>> >>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>> Stuart, Roger, Joe and the Panama team for the feedback provided so >>> far, which helped to get the API in the shape it is today. >>> >>> Cheers >>> Maurizio >>> >>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" >>> - but that is unrelated to this patch, and it's a known failing test. >>> >>> [1] - https://openjdk.java.net/jeps/370 >>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>> From Alan.Bateman at oracle.com Fri Dec 6 12:17:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Dec 2019 12:17:03 +0000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> Message-ID: <78889f5e-deae-6d83-31a2-0616d9521812@oracle.com> On 06/12/2019 08:04, Langer, Christoph wrote: > Thanks, David. > > I'll run the final change once again through jdk-submit befor pushing. > > Alan, Dan, may I consider this reviewed by either of you? > Yes, I think this looks okay. -Alan From vladimir.x.ivanov at oracle.com Fri Dec 6 12:28:45 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 6 Dec 2019 15:28:45 +0300 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <0dc305b6-c727-7591-469e-fedd0f16d0a0@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> <0dc305b6-c727-7591-469e-fedd0f16d0a0@oracle.com> Message-ID: >>> * ciField.cpp - this one is to trust final fields in the foreign >>> memory access implementation (otherwise VM doesn't trust memory >>> segment bounds) >> >> New packages aren't part of java.base. Considering the implementation >> resides in an incubator module, is it enough to consider them as >> trusted and well-known to the JVM? > This gives same performance as with -XX:+TrustFinalNonStaticFields - if > we remove these changes, then memory segment bounds are never inlined. > I'm happy to change this if you have other suggestions on how to get > there, of course (I can run some benchmarks w/ and w/o and post some > numbers if that helps). I'm not questioning whether these changes are needed for the implementation or not. I wanted to attract attention that it's not just a mechanical expansion of the list we have done in the past, but a new case (java.base vs incubator) and hear from others are they fine with leaving it as is? All the options I see (either new JVM annotation or trust final fields by default) require significant engineering effort. So, I'd like to clarify first whether the effort to rewrite current solution is required or not. >>> * library_call.cpp - this one is a JIT compiler change to treat >>> Thread.currentThread() as a well-known constant - which helps a lot >>> in the confinement checks (thanks Vlad!) >> >> FTR it is tracked by JDK-8235143 [1] and the patch is under review [2]. > > Should I remove this from the patch then? Yes, please. Best regards, Vladimir Ivanov >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235143 >> >> [2] >> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036295.html >> >> >>> * various Buffer-related changes; these changes are needed because >>> the memory access API allows a memory segment to be projected into a >>> byte buffer, for interop reasons. As such, we need to insert a >>> liveness check in the various get/put methods. Previously we had an >>> implementation strategy where a BB was 'decorated' by a subclass >>> called ScopedBuffer - but doing so required some changes to the BB >>> API (e.g. making certain methods non-final, so that we could decorate >>> them). Here I use an approach (which I have discussed with Alan) >>> which doesn't require any public API? changes, but needs to add a >>> 'segment' field in Buffer - and then have constructors which keep >>> track of this extra parameter. >>> >>> * FileChannel changes - these changes are required so that we can >>> reuse the Unmapper class from the MemorySegment implementation, to >>> deterministically deallocate a mapped memory segment. This should be >>> a 'straight' refactoring, no change in behavior should occur here. >>> Please double check. >>> >>> * VarHandles - this class now provides a factory to create memory >>> access VarHandle - this is a bit tricky, since VarHandle cannot >>> really be implemented outside java.base (e.g. VarForm is not public). >>> So we do the usual trick where we define a bunch of proxy interfaces >>> (see jdk/internal/access/foreign) have the classes in java.base refer >>> to these - and then have the implementation classes of the memory >>> access API implement these interfaces. >>> >>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >>> to provide access to otherwise hidden functionalities - e.g. creating >>> a new scoped buffer, or retrieving the properties of a memory access >>> handle (e.g. offset, stride etc.), so that we can implement the >>> memory access API in its own separate module >>> >>> * GensrcVarHandles.gmk - these changes are needed to enable the >>> generation of the new memory address var handle implementations; >>> there's an helper class per carrier (e.g. >>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >>> var handle is needed, we dynamically spin a new VH implementation >>> which makes use of the right carrier. We need to spin because the VH >>> can have a variable number of access coordinates (e.g. depending on >>> the dimensions of the array to be accessed). But, under the hood, all >>> the generated implementation will be using the same helper class. >>> >>> * tests - we've tried to add fairly robust tests, often checking all >>> possible permutations of carriers/dimensions etc. Because of that, >>> the tests might not be the easiest to look at, but they have proven >>> to be pretty effective at shaking out issues. >>> >>> I think that covers the main aspects of the implementation and where >>> it differs from vanilla JDK. >>> >>> P.S. >>> >>> In the CSR review [2], Joe raised a fair point - which is >>> MemoryAddress has both: >>> >>> offset(long) --> move address of given offset >>> offset() --> return the offset of this address in its owning segment >>> >>> And this was considered suboptimal, given both methods use the same >>> name but do something quite different (one is an accessor, another is >>> a 'wither'). one obvious option is to rename the first to >>> 'withOffset'. But I think that would lead to verbose code (since that >>> is a very common operation). Other options are to: >>> >>> * rename offset(long) to move(long), advance(long), or something else >>> * drop offset() - but then add an overload of MemorySegment::asSlice >>> which takes an address instead of a plain long offset >>> >>> I'll leave the choice to the reviewers :-) >>> >>> >>> >>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>> Stuart, Roger, Joe and the Panama team for the feedback provided so >>> far, which helped to get the API in the shape it is today. >>> >>> Cheers >>> Maurizio >>> >>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >>> but that is unrelated to this patch, and it's a known failing test. >>> >>> [1] - https://openjdk.java.net/jeps/370 >>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>> From fujie at loongson.cn Fri Dec 6 12:51:23 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 6 Dec 2019 20:51:23 +0800 Subject: RFR: 8235482: [TESTBUG] PackageType LINUX_RPM should be excluded for jpackage tests on debian systems Message-ID: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> Hi all, May I get reviews for the small fix? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235482 Webrev: http://cr.openjdk.java.net/~jiefu/8235482/webrev.00/ Thanks a lot. Best regards, Jie From christoph.langer at sap.com Fri Dec 6 13:06:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Dec 2019 13:06:56 +0000 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: <78889f5e-deae-6d83-31a2-0616d9521812@oracle.com> References: <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> <78889f5e-deae-6d83-31a2-0616d9521812@oracle.com> Message-ID: Thanks, Alan. Then I'll push it now. A final jdk-submit run succeeded (mach5-one-clanger-JDK-8234185-4-20191206-0819-7283662). > -----Original Message----- > From: Alan Bateman > Sent: Freitag, 6. Dezember 2019 13:17 > To: Langer, Christoph ; David Holmes > ; daniel.daugherty at oracle.com > Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net; gerard ziemski > Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between > libjava, hotspot and libinstrument > > On 06/12/2019 08:04, Langer, Christoph wrote: > > Thanks, David. > > > > I'll run the final change once again through jdk-submit befor pushing. > > > > Alan, Dan, may I consider this reviewed by either of you? > > > Yes, I think this looks okay. > > -Alan From christoph.langer at sap.com Fri Dec 6 13:24:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Dec 2019 13:24:17 +0000 Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array In-Reply-To: References: Message-ID: Hi Martin, ok, you are the author ? so I won?t insist. ?? Best regards Christoph From: Doerr, Martin Sent: Freitag, 6. Dezember 2019 12:22 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net; security-dev ; Lindenmaier, Goetz ; Thomas St?fe Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Christoph, that would work, but I don?t want to pollute this file with compiler specific defines. In addition, I don?t like introducing a macro which works on some platforms and does nothing on other ones (which is the case for hotspot?s ATTRIBUTE_ALIGNED). Because Windows 32 bit is the only affected platform, I prefer not to touch other ones. Are you ok with webrev.00 as it is? Best regards, Martin From: Langer, Christoph > Sent: Donnerstag, 5. Dezember 2019 12:16 To: Doerr, Martin > Cc: core-libs-dev at openjdk.java.net; security-dev >; Lindenmaier, Goetz >; Thomas St?fe > Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Martin, I can see that both places already include headers from src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. WindowsPreferences.c already includes it. Best regards Christoph From: Doerr, Martin > Sent: Donnerstag, 5. Dezember 2019 12:00 To: Thomas St?fe >; Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; security-dev >; Lindenmaier, Goetz > Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Thomas and Christoph, thanks for the reviews. Other code in java.security.jgss also uses these #defined checks: src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER) I?d like to have it consistent with that. @Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it? Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned. (AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too: https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html) Best regards, Martin From: Thomas St?fe > Sent: Mittwoch, 4. Dezember 2019 17:56 To: Doerr, Martin > Cc: core-libs-dev at openjdk.java.net; security-dev >; Lindenmaier, Goetz > Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array Hi Martin, this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal. +#if defined (_WIN32) && defined (_MSC_VER) Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++? Cheers, Thomas On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin > wrote: Hi, I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport): https://bugs.openjdk.java.net/browse/JDK-8220348 Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer. jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted). However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default. I found such issues in the following files: src/java.prefs/windows/native/libprefs/WindowsPreferences.c src/java.security.jgss/share/native/libj2gss/GSSLibStub.c I suggest to use __declspec(align(8)) there. Webrev: http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/ Please review. I think using 8 byte alignment is not a disadvantage for 64 bit. I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix. Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack? Best regards, Martin From maurizio.cimadamore at oracle.com Fri Dec 6 13:36:22 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 13:36:22 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> <0dc305b6-c727-7591-469e-fedd0f16d0a0@oracle.com> Message-ID: On 06/12/2019 12:28, Vladimir Ivanov wrote: > >>>> * ciField.cpp - this one is to trust final fields in the foreign >>>> memory access implementation (otherwise VM doesn't trust memory >>>> segment bounds) >>> >>> New packages aren't part of java.base. Considering the >>> implementation resides in an incubator module, is it enough to >>> consider them as trusted and well-known to the JVM? >> This gives same performance as with -XX:+TrustFinalNonStaticFields - >> if we remove these changes, then memory segment bounds are never >> inlined. I'm happy to change this if you have other suggestions on >> how to get there, of course (I can run some benchmarks w/ and w/o and >> post some numbers if that helps). > > I'm not questioning whether these changes are needed for the > implementation or not. I wanted to attract attention that it's not > just a mechanical expansion of the list we have done in the past, but > a new case (java.base vs incubator) and hear from others are they fine > with leaving it as is? > > All the options I see (either new JVM annotation or trust final fields > by default) require significant engineering effort. So, I'd like to > clarify first whether the effort to rewrite current solution is > required or not. Thanks for the clarification - I agree it's a bit unorthodox, but I'll leave to others (more qualified than me) to respond on that point. > >>>> * library_call.cpp - this one is a JIT compiler change to treat >>>> Thread.currentThread() as a well-known constant - which helps a lot >>>> in the confinement checks (thanks Vlad!) >>> >>> FTR it is tracked by JDK-8235143 [1] and the patch is under review [2]. >> >> Should I remove this from the patch then? > > Yes, please. Done in the recently submitted v2 Thanks Maurizio > > Best regards, > Vladimir Ivanov > >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235143 >>> >>> [2] >>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-December/036295.html >>> >>> >>>> * various Buffer-related changes; these changes are needed because >>>> the memory access API allows a memory segment to be projected into >>>> a byte buffer, for interop reasons. As such, we need to insert a >>>> liveness check in the various get/put methods. Previously we had an >>>> implementation strategy where a BB was 'decorated' by a subclass >>>> called ScopedBuffer - but doing so required some changes to the BB >>>> API (e.g. making certain methods non-final, so that we could >>>> decorate them). Here I use an approach (which I have discussed with >>>> Alan) which doesn't require any public API? changes, but needs to >>>> add a 'segment' field in Buffer - and then have constructors which >>>> keep track of this extra parameter. >>>> >>>> * FileChannel changes - these changes are required so that we can >>>> reuse the Unmapper class from the MemorySegment implementation, to >>>> deterministically deallocate a mapped memory segment. This should >>>> be a 'straight' refactoring, no change in behavior should occur >>>> here. Please double check. >>>> >>>> * VarHandles - this class now provides a factory to create memory >>>> access VarHandle - this is a bit tricky, since VarHandle cannot >>>> really be implemented outside java.base (e.g. VarForm is not >>>> public). So we do the usual trick where we define a bunch of proxy >>>> interfaces (see jdk/internal/access/foreign) have the classes in >>>> java.base refer to these - and then have the implementation classes >>>> of the memory access API implement these interfaces. >>>> >>>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we >>>> need to provide access to otherwise hidden functionalities - e.g. >>>> creating a new scoped buffer, or retrieving the properties of a >>>> memory access handle (e.g. offset, stride etc.), so that we can >>>> implement the memory access API in its own separate module >>>> >>>> * GensrcVarHandles.gmk - these changes are needed to enable the >>>> generation of the new memory address var handle implementations; >>>> there's an helper class per carrier (e.g. >>>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory >>>> access var handle is needed, we dynamically spin a new VH >>>> implementation which makes use of the right carrier. We need to >>>> spin because the VH can have a variable number of access >>>> coordinates (e.g. depending on the dimensions of the array to be >>>> accessed). But, under the hood, all the generated implementation >>>> will be using the same helper class. >>>> >>>> * tests - we've tried to add fairly robust tests, often checking >>>> all possible permutations of carriers/dimensions etc. Because of >>>> that, the tests might not be the easiest to look at, but they have >>>> proven to be pretty effective at shaking out issues. >>>> >>>> I think that covers the main aspects of the implementation and >>>> where it differs from vanilla JDK. >>>> >>>> P.S. >>>> >>>> In the CSR review [2], Joe raised a fair point - which is >>>> MemoryAddress has both: >>>> >>>> offset(long) --> move address of given offset >>>> offset() --> return the offset of this address in its owning segment >>>> >>>> And this was considered suboptimal, given both methods use the same >>>> name but do something quite different (one is an accessor, another >>>> is a 'wither'). one obvious option is to rename the first to >>>> 'withOffset'. But I think that would lead to verbose code (since >>>> that is a very common operation). Other options are to: >>>> >>>> * rename offset(long) to move(long), advance(long), or something else >>>> * drop offset() - but then add an overload of >>>> MemorySegment::asSlice which takes an address instead of a plain >>>> long offset >>>> >>>> I'll leave the choice to the reviewers :-) >>>> >>>> >>>> >>>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>>> Stuart, Roger, Joe and the Panama team for the feedback provided so >>>> far, which helped to get the API in the shape it is today. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" >>>> - but that is unrelated to this patch, and it's a known failing test. >>>> >>>> [1] - https://openjdk.java.net/jeps/370 >>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>>> From daniel.daugherty at oracle.com Fri Dec 6 14:03:24 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 6 Dec 2019 09:03:24 -0500 Subject: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument In-Reply-To: References: <21f83181-eea8-7b7f-9f5f-5f1a26413154@oracle.com> <5b46607d-c84b-086d-6241-cf2eee95d0a6@oracle.com> <1d4ed7c6-d626-053a-e077-da284a078082@oracle.com> <1657461f-ea1f-cd0d-f842-e5a5404afb96@oracle.com> <566d4f4f-e179-48bd-23fd-e3580c8c3708@oracle.com> <21c5b580-af70-dbca-1714-9b0e17894eae@oracle.com> <59a6a918-5388-3574-4675-527b2ad09d20@oracle.com> Message-ID: <5cd49296-8718-c0b4-7a37-5956fe576c1c@oracle.com> On 12/6/19 3:04 AM, Langer, Christoph wrote: > Thanks, David. > > I'll run the final change once again through jdk-submit befor pushing. > > Alan, Dan, may I consider this reviewed by either of you? Sorry I haven't done a full review on this change. I just happened to see the typo fly by... Dan > > Thanks > Christoph > >> -----Original Message----- >> From: David Holmes >> Sent: Freitag, 6. Dezember 2019 08:02 >> To: Langer, Christoph ; >> daniel.daugherty at oracle.com >> Cc: core-libs-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net; Alan Bateman ; gerard >> ziemski >> Subject: Re: RFR: 8234185: Cleanup usage of canonicalize function between >> libjava, hotspot and libinstrument >> >> Hi Christoph, >> >> On 6/12/2019 2:12 am, Langer, Christoph wrote: >>> Hi David, >>> >>> I prepared an updated webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/8234185.3/ >>>> src/java.base/windows/native/libjava/canonicalize_md.c >>>> >>>> +// We can't include jdk_util.h here because the file is used in Oracle >>>> in another context >>>> +// #include "jdk_util.h" >>>> >>>> Seems to me clients of JDK_Canonicalize need to include jdk_util.h, not >>>> the files that implement it. So there is no reason to include it here >>>> and so no need for the comment. >>> Well, it's actually not needed but I think it's good practice that the declaring >> header is included in the implementation file. >> >> Yes I was forgetting the importance of ensuring the declaration in the >> header matches the definition. There is a typo in the comment "possibile". >> >>>> Further, does: >>>> >>>> src/java.base/unix/native/libjava/canonicalize_md.c >>>> >>>> need to include jdk_util.h? I think not. >>> Same as for the windows file - not necessary but good style. >>> >>>> +/* The appropriate location of getPrefixed() is io_util_md.c, but it is >>>> + also used in a non-OpenJDK context within Oracle. There, >>>> canonicalize_md.c >>>> + is already pulled in and compiled, so to avoid more complicate solutions >>>> + we keep this method here. */ >>>> >>>> I don't like to have comments like this but I guess it is needed here. >>>> Please put the */ on a newline. Also s/complicate/complicates/ >>> I did as Dan pointed out. >> :) Yes sorry about that slip. >> >> Otherwise all looks good. No need for new webrev for the typo. >> >> Thanks, >> David >> >>>> src/java.base/windows/native/libjava/io_util_md.c >>>> >>>> should now be unchanged, but you've left in the copyright update. >>>> >>> Right, thanks for the catch. >>> >>>> A second review is still needed for the final version of this. >>> Dan, can I add you as reviewer then? >>> >>> Best regards >>> Christoph >>> From erik.joelsson at oracle.com Fri Dec 6 16:05:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 6 Dec 2019 08:05:49 -0800 Subject: RFR: JEP 367: Remove the Pack200 Tools and API In-Reply-To: References: <09dc53f1-9208-3b1f-3ee6-e0e22210afc5@oracle.com> <96643033-bcac-20f3-32d6-3152a6926459@oracle.com> <8eccfd0c-04da-dc09-2e1f-a76b61fef519@oracle.com> <1e68fb03-814b-b671-346e-faa55b068a77@oracle.com> <8fe0abd5-f154-292b-25fc-0bc907633037@oracle.com> <8f08f1fd-db11-5709-0925-d6ccdcdf3e48@oracle.com> <21cdc073-f1c1-195c-e825-a0273d67d456@oracle.com> Message-ID: <9e734797-d1dd-2f98-6d81-3120d1ddb806@oracle.com> Sounds good and looks good. /Erik On 2019-12-05 20:18, Henry Jen wrote: > OK, so I created an issue[1] for follow up for Windows build and reverted the change in flags-cflags.m4, if nothing else, I?ll push without another webrev pinging that I get an +1 from someone in build-de, Erik? > > [1] https://bugs.openjdk.java.net/browse/JDK-8235461 > > Cheers, > Henry > >> On Dec 5, 2019, at 12:21 PM, Mandy Chung wrote: >> >> >> >> On 12/5/19 12:41 AM, Alan Bateman wrote: >>> On 05/12/2019 08:16, Henry Jen wrote: >>>> Hi, >>>> >>>> Updated webrev[1] reflect comments since last webrev. Vicente had done all the heavy-lifting and hand over to me to finish up. >>>> >>>> Changes to symbols is reverted, as we expect that only need to be updated in next release by running make/scripts/generate-symbol-data.sh. >>>> >>>> The jar files are confusing in the webrev, but those files are removed. The whole test/jdk/tools/pack200 is removed. >>>> >>>> Cheers, >>>> Henry >>>> >>>> [1] http://cr.openjdk.java.net/~henryjen/jdk14/8234542/0/webrev/ >>>> >>> The update webrev looks okay to me, except this part of the comment in flags-cflags.m4 >>> >>> "Now that unpack200 has been removed we should consider setting it for windows too. but this could be done as a follow-up effort. It could be that other other clients are relying on the current configuration for windows". >>> >>> I think it would be best to create an infrastructure/build issue and leave most of this confusing comment out. >>> >> I also think keeping flags-cflags.m4 as is and file a new build issue as a follow-up would be better. >> >> Otherwise, this updated webrev looks okay to me. >> >> Mandy From andy.herrick at oracle.com Fri Dec 6 16:47:28 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 6 Dec 2019 11:47:28 -0500 Subject: RFR: 8235482: [TESTBUG] PackageType LINUX_RPM should be excluded for jpackage tests on debian systems In-Reply-To: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> References: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> Message-ID: looks good to me. /Andy On 12/6/2019 7:51 AM, Jie Fu wrote: > Hi all, > > May I get reviews for the small fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235482 > Webrev: http://cr.openjdk.java.net/~jiefu/8235482/webrev.00/ > > Thanks a lot. > Best regards, > Jie > From alexey.semenyuk at oracle.com Fri Dec 6 17:26:10 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 6 Dec 2019 12:26:10 -0500 Subject: RFR: 8235482: [TESTBUG] PackageType LINUX_RPM should be excluded for jpackage tests on debian systems In-Reply-To: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> References: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> Message-ID: <716346c8-ced9-862b-b6d3-240b438ea3a0@oracle.com> This fix will disable running rpm tests on Debian systems that support it. This is not a good idea. If you need to exclude some packaging from jpackage tests, just run jtreg with "jpackage.test.disabledPackagers" system property set to the list of corresponding package types. E.g.: -Djpackage.test.disabledPackagers=rpm will disable rpm packaging. - Alexey On 12/6/2019 7:51 AM, Jie Fu wrote: > Hi all, > > May I get reviews for the small fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235482 > Webrev: http://cr.openjdk.java.net/~jiefu/8235482/webrev.00/ > > Thanks a lot. > Best regards, > Jie > From aleksej.efimov at oracle.com Fri Dec 6 17:33:33 2019 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 6 Dec 2019 17:33:33 +0000 Subject: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed Message-ID: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> Hi, InvalidLdapFilters test has been seen failing intermittently with timeouts. The cause of the observed failures could be the binding of test server to the wildcard address. Proposed fix binds the test server to the loopback address and uses the test library to construct LDAP provider URL. The modified test has been executed ~100 times alongside to other networking and JNDI tests: No failures have been observed. Webrev: http://cr.openjdk.java.net/~aefimov/8141685/00 JBS: https://bugs.openjdk.java.net/browse/JDK-8141685 With Best Regards, Aleksei From alexey.semenyuk at oracle.com Fri Dec 6 17:55:47 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 6 Dec 2019 12:55:47 -0500 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: <5DE9AFD6.5070501@oracle.com> References: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> <5DE9AFD6.5070501@oracle.com> Message-ID: <86014195-f10d-3e8a-b0b0-e2b2aa0ccf50@oracle.com> Initially the work was focused on [2] issue to fix icons assignment for launchers created by jpackage. In the process of working on the fix for [2] it turned out jpackage test framework was lacking functionality to cover the fix in an environment where installation of packages produced by jpackage is not possible. This gap was filled with the patch for [1]. The amount of work to fix [1] outweighed [2], so [1] became primary fix in this bundle. Fixes can be decoupled and pushed as an independent patches. This will require extra effort though. Would this be a better option? - Alexey On 12/5/2019 8:33 PM, Philip Race wrote: > I don't understand the relationship between these two bugs. > > -phil > > On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: >> Please review? fixes for [1] and [2]. Both target jpackage tool. >> >> The webrev is at [3]. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8233270 >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8230933 >> >> [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ >> From daniel.fuchs at oracle.com Fri Dec 6 18:11:24 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 6 Dec 2019 18:11:24 +0000 Subject: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed In-Reply-To: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> References: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> Message-ID: <0a09885f-dd8b-13e7-f042-752ce77b4cc7@oracle.com> Looks good to me Aleksei! best regards, -- daniel On 06/12/2019 17:33, Aleks Efimov wrote: > Hi, > > InvalidLdapFilters test has been seen failing intermittently with > timeouts. The cause of the observed failures could be the binding of > test server to the wildcard address. > Proposed fix binds the test server to the loopback address and uses the > test library to construct LDAP provider URL. > The modified test has been executed ~100 times alongside to other > networking and JNDI tests: No failures have been observed. > > Webrev: http://cr.openjdk.java.net/~aefimov/8141685/00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8141685 > > With Best Regards, > Aleksei > From raffaello.giulietti at gmail.com Fri Dec 6 18:29:54 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 6 Dec 2019 19:29:54 +0100 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) Message-ID: Hello, great job! I think that the doc of MemoryAddress.copy() should be explicit about the direction of the copying, so it should either: * explicitly specify a direction, e.g., lower-to-higher addresses * or specify that in the case of an overlap the copying is smart enough to not destroy the src bytes before they have landed in dst * or accept a negative third argument to encode a higher-to-lower addresses copying direction. Greetings Raffaello > Hi, > as part of the effort to upstream the changes related to JEP 370 > (foreign memory access API) [1], I'd like to ask for a code review for > the corresponding core-libs and hotspot changes: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > A javadoc for the memory access API is also available here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > Here is a brief summary of the changes in java.base and hotspot (the > remaining new files are implementation classes and tests for the new API): > > * ciField.cpp - this one is to trust final fields in the foreign memory > access implementation (otherwise VM doesn't trust memory segment bounds) > > * Modules.gmk - these changes are needed to require that the incubating > module is loaded by the boot loader (otherwise the above changes are > useless) > > * library_call.cpp - this one is a JIT compiler change to treat > Thread.currentThread() as a well-known constant - which helps a lot in > the confinement checks (thanks Vlad!) > > * various Buffer-related changes; these changes are needed because the > memory access API allows a memory segment to be projected into a byte > buffer, for interop reasons. As such, we need to insert a liveness check > in the various get/put methods. Previously we had an implementation > strategy where a BB was 'decorated' by a subclass called ScopedBuffer - > but doing so required some changes to the BB API (e.g. making certain > methods non-final, so that we could decorate them). Here I use an > approach (which I have discussed with Alan) which doesn't require any > public API changes, but needs to add a 'segment' field in Buffer - and > then have constructors which keep track of this extra parameter. > > * FileChannel changes - these changes are required so that we can reuse > the Unmapper class from the MemorySegment implementation, to > deterministically deallocate a mapped memory segment. This should be a > 'straight' refactoring, no change in behavior should occur here. Please > double check. > > * VarHandles - this class now provides a factory to create memory access > VarHandle - this is a bit tricky, since VarHandle cannot really be > implemented outside java.base (e.g. VarForm is not public). So we do the > usual trick where we define a bunch of proxy interfaces (see > jdk/internal/access/foreign) have the classes in java.base refer to > these - and then have the implementation classes of the memory access > API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to > provide access to otherwise hidden functionalities - e.g. creating a new > scoped buffer, or retrieving the properties of a memory access handle > (e.g. offset, stride etc.), so that we can implement the memory access > API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the > generation of the new memory address var handle implementations; there's > an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). > At runtime, when a memory access var handle is needed, we dynamically > spin a new VH implementation which makes use of the right carrier. We > need to spin because the VH can have a variable number of access > coordinates (e.g. depending on the dimensions of the array to be > accessed). But, under the hood, all the generated implementation will be > using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all > possible permutations of carriers/dimensions etc. Because of that, the > tests might not be the easiest to look at, but they have proven to be > pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where it > differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is MemoryAddress > has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same name > but do something quite different (one is an accessor, another is a > 'wither'). one obvious option is to rename the first to 'withOffset'. > But I think that would lead to verbose code (since that is a very common > operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers :-) > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, > Roger, Joe and the Panama team for the feedback provided so far, which > helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - > but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 From andy.herrick at oracle.com Fri Dec 6 18:33:54 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 6 Dec 2019 13:33:54 -0500 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" Message-ID: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> Please review this jpackager test fix for bug [1] at [2]. the fix adds "@requires (os.family == "linux") | (os.family == "mac") | (os.family == "windows")" to all jpackage tests that were not already filtered with "@requires (os.family == "XXX")" [1] https://bugs.openjdk.java.net/browse/JDK-8235453 [2] http://cr.openjdk.java.net/~herrick/8235453/ /Andy From alexey.semenyuk at oracle.com Fri Dec 6 18:35:49 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 6 Dec 2019 13:35:49 -0500 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> Message-ID: Looks good. - Alexey On 12/6/2019 1:33 PM, Andy Herrick wrote: > Please review this jpackager test fix for bug [1] at [2]. > > the fix adds "@requires (os.family == "linux") | (os.family == "mac") > | (os.family == "windows")" to all jpackage tests that were not > already filtered with "@requires (os.family == "XXX")" > > [1] https://bugs.openjdk.java.net/browse/JDK-8235453 > > [2] http://cr.openjdk.java.net/~herrick/8235453/ > > /Andy > From raffaello.giulietti at gmail.com Fri Dec 6 18:45:02 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 6 Dec 2019 19:45:02 +0100 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) Message-ID: <86828be9-dfe5-2594-9c22-3cc7a67ad860@gmail.com> Hi, MemoryLayouts exposes BITS_8_BE and BITS_8_LE. Is there a reason to have both or is just love for symmetries (which I share)? Greetings Raffaello > Hi, > as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code review for the corresponding core-libs and hotspot changes: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > A javadoc for the memory access API is also available here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > Here is a brief summary of the changes in java.base and hotspot (the remaining new files are implementation classes and tests for the new API): > > * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) > > * Modules.gmk - these changes are needed to require that the incubating module is loaded by the boot loader (otherwise the above changes are useless) > > * library_call.cpp - this one is a JIT compiler change to treat Thread.currentThread() as a well-known constant - which helps a lot in the confinement checks (thanks Vlad!) > > * various Buffer-related changes; these changes are needed because the memory access API allows a memory segment to be projected into a byte buffer, for interop reasons. As such, we need to insert a liveness check in the various get/put methods. Previously we had an implementation strategy where a BB was 'decorated' by a subclass called ScopedBuffer - but doing so required some changes to the BB API (e.g. making certain methods non-final, so that we could decorate them). Here I use an approach (which I have discussed with Alan) which doesn't require any public API changes, but needs to add a 'segment' field in Buffer - and then have constructors which keep track of this extra parameter. > > * FileChannel changes - these changes are required so that we can reuse the Unmapper class from the MemorySegment implementation, to deterministically deallocate a mapped memory segment. This should be a 'straight' refactoring, no change in behavior should occur here. Please double check. > > * VarHandles - this class now provides a factory to create memory access VarHandle - this is a bit tricky, since VarHandle cannot really be implemented outside java.base (e.g. VarForm is not public). So we do the usual trick where we define a bunch of proxy interfaces (see jdk/internal/access/foreign) have the classes in java.base refer to these - and then have the implementation classes of the memory access API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to provide access to otherwise hidden functionalities - e.g. creating a new scoped buffer, or retrieving the properties of a memory access handle (e.g. offset, stride etc.), so that we can implement the memory access API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the generation of the new memory address var handle implementations; there's an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access var handle is needed, we dynamically spin a new VH implementation which makes use of the right carrier. We need to spin because the VH can have a variable number of access coordinates (e.g. depending on the dimensions of the array to be accessed). But, under the hood, all the generated implementation will be using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all possible permutations of carriers/dimensions etc. Because of that, the tests might not be the easiest to look at, but they have proven to be pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where it differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is MemoryAddress has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same name but do something quite different (one is an accessor, another is a 'wither'). one obvious option is to rename the first to 'withOffset'. But I think that would lead to verbose code (since that is a very common operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, Roger, Joe and the Panama team for the feedback provided so far, which helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 From andy.herrick at oracle.com Fri Dec 6 18:55:56 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 6 Dec 2019 13:55:56 -0500 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: <86014195-f10d-3e8a-b0b0-e2b2aa0ccf50@oracle.com> References: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> <5DE9AFD6.5070501@oracle.com> <86014195-f10d-3e8a-b0b0-e2b2aa0ccf50@oracle.com> Message-ID: <82ded646-7433-1c60-5b50-1f246511f7e5@oracle.com> The changes look good to me. /Andy On 12/6/2019 12:55 PM, Alexey Semenyuk wrote: > Initially the work was focused on [2] issue to fix icons assignment > for launchers created by jpackage. > In the process of working on the fix for [2] it turned out jpackage > test framework was lacking functionality to cover the fix in an > environment where installation of packages produced by jpackage is not > possible. This gap was filled with the patch for [1]. > The amount of work to fix [1] outweighed [2], so [1] became primary > fix in this bundle. > > Fixes can be decoupled and pushed as an independent patches. This will > require extra effort though. Would this be a better option? > > - Alexey > > On 12/5/2019 8:33 PM, Philip Race wrote: >> I don't understand the relationship between these two bugs. >> >> -phil >> >> On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: >>> Please review? fixes for [1] and [2]. Both target jpackage tool. >>> >>> The webrev is at [3]. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8233270 >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8230933 >>> >>> [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ >>> > From Nikola.Grcevski at microsoft.com Fri Dec 6 20:28:19 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Fri, 6 Dec 2019 20:28:19 +0000 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> Message-ID: Thank you Henry! I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://grcevski.github.io/JDK-8234076/webrev/) Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. Nikola diff -r bd436284147d src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 15:11:36 2019 -0500 @@ -130,6 +130,8 @@ } } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { stopExpansion = JNI_TRUE; + } else if (JLI_StrCCmp(arg, "--module=") == 0) { + idx = argsCount; } } else { if (!expectingNoDashArg) { diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 15:11:36 2019 -0500 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include "java.h" @@ -1015,6 +1016,17 @@ // sanity check, match the args we have, to the holy grail idx = JLI_GetAppArgIndex(); + + // First arg index is NOT_FOUND + if (idx < 0) { + // The only allowed value should be NOT_FOUND (-1) unless another change introduces + // a different negative index + assert (idx == -1); + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); + JLI_TraceLauncher("passing arguments as-is.\n"); + return NewPlatformStringArray(env, strv, argc); + } + isTool = (idx == 0); if (isTool) { idx++; } // skip tool name JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 15:11:36 2019 -0500 @@ -29,6 +29,7 @@ * jdk.jlink * @build BasicTest jdk.test.lib.compiler.CompilerUtils * @run testng BasicTest + * @bug 8234076 * @summary Basic test of starting an application as a module */ @@ -40,6 +41,8 @@ import jdk.test.lib.compiler.CompilerUtils; import jdk.test.lib.process.ProcessTools; +import jdk.test.lib.process.OutputAnalyzer; +import jdk.test.lib.Utils; import org.testng.annotations.BeforeTest; import org.testng.annotations.Test; @@ -70,6 +73,8 @@ // the module main class private static final String MAIN_CLASS = "jdk.test.Main"; + // for Windows specific launcher tests + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); @BeforeTest public void compileTestModule() throws Exception { @@ -259,4 +264,87 @@ assertTrue(exitValue != 0); } + + /** + * Helper method that creates a ProcessBuilder with command line arguments + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. + */ + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); + + return pb; + } + + /** + * Test the ability for the Windows launcher to do proper application argument + * detection and expansion, when using the long form module option and all passed in + * command line arguments are prefixed with a dash. + * + * These tests are not expected to work on *nixes, and are ignored. + */ + public void testWindowsWithLongFormModuleOption() throws Exception { + if (!IS_WINDOWS) { + return; + } + + String dir = MODS_DIR.toString(); + String mid = TEST_MODULE + "/" + MAIN_CLASS; + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help + // We should be able to find the argument --help as an application argument + ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + "--help")) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("F--help"); + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help + // We should be able to see argument expansion happen + ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", + "--help")) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("F--help") + .shouldContain("module-info.java"); + } + + + /** + * Test that --module= is terminating for VM argument processing just like --module + */ + public void testLongFormModuleOptionTermination() throws Exception { + String dir = MODS_DIR.toString(); + String mid = TEST_MODULE + "/" + MAIN_CLASS; + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be + // deemed as application arguments + OutputAnalyzer output = ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + "--module-path=" + dir, + "--module=" + mid)) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("argv[ 0] = '--module-path=" + dir) + .shouldContain("argv[ 1] = '--module=" + mid); + + if (IS_WINDOWS) { + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); + } + + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods + // This command line will not work as --module= is terminating and the module will be not found + int exitValue = exec("--module=" + mid, "--module-path" + dir); + assertTrue(exitValue != 0); + } } -----Original Message----- From: Henry Jen Sent: December 6, 2019 12:03 AM To: Nikola Grcevski Cc: Kumar Srinivasan ; Alan Bateman ; core-libs-dev at openjdk.java.net Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: > > Hello all again! > > Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: > > --- a/src/java.base/share/native/libjli/args.c > +++ b/src/java.base/share/native/libjli/args.c > @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. BTW, we need the patch to be hosted on cr.openjdk.java.net or you can attach the patch to the review thread if you are not yet an author. Cheers, Henry > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > > The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. > > I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. > > I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). > > I ran all the launcher tests on both Windows and Linux and all tests pass. > > Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. > > Thank you, > Nikola > > -----Original Message----- > From: Henry Jen > Sent: December 4, 2019 8:26 PM > To: Kumar Srinivasan ; Alan Bateman > ; Nikola Grcevski > > Cc: core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >> >> Hi Nikola, >> >> It looks ok to me, I will leave it to Henry and Alan to bless this. >> >> IMHO: I think we should fix it correctly now than later, I don't >> think it is all that difficult AFAICT all the launcher has to do is >> identify "--module==", then the next argument is the first index. >> > > I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. > > If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. > > FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. > > I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. > > I?ll let Alan to comment about the ?module option usage. > > The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > .oracle.com%2Fen%2Fjava%2Fjavase%2F13%2Fdocs%2Fspecs%2Fman%2Fjava.html > &data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C37e38c582bac4687 > e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 > 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY > %3D&reserved=0 > >> Kumar >> >> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >> Hi Henry and Kumar, >> >> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >> >> Please find my updated webrev here for your review: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc >> e >> vski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Gr >> c >> evski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86 >> f >> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ >> % >> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >> >> Cheers, >> >> Nikola >> >> -----Original Message----- >> From: Henry Jen >> Sent: December 3, 2019 11:39 AM >> To: Kumar Srinivasan >> Cc: Nikola Grcevski ; Alan Bateman >> ; core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> Kumar, >> >> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >> >> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >> >> Cheers, >> Henry >> >>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>> >>> Hi, >>> >>> Sorry for chiming in late in the review process, for what it's worth.... >>> >>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>> and subsequent crash, but it does not address wildcard arguments expansion. >>> >>> What if we have >>> % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>> Where jdk.compiler is a java compiler implementation (javac). >>> The user would expect the above compiler module to build all the .java files in that directory, >>> and this fix will not address that. >>> >>> Some background: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>> gs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola >>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>> Please see all the related bugs in the above JIRA issue. >>> >>> Paragraph #6 in this interview surmises the wild card behavior on Windows: >>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>> princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=0 >>> 2%7C01%7CNikola.Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d77 >>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>> ;reserved=0 >>> >>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>> .openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2 >>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>> ki%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f1 >>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>> Using the modules test framework may make the test simpler. >>> >>> Kumar Srinivasan >>> >>> >>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>> Hi Alan and Henry, >>> >>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>> >>> I created a webrev here for the change, including a new test in Arrrghs.java: >>> >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>> cevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola >>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>> >>> I copied the test validation and assertion style of other code inside the test class. >>> >>> Please let me know if you have any comments or suggestions. >>> >>> Thanks again! >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 2, 2019 12:26 PM >>> To: Alan Bateman >>> Cc: Nikola Grcevski ; >>> core-libs-dev at openjdk.java.net >>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>> >>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>> >>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>> >>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>> >>> Cheers, >>> Henry >>> >>> >>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>> >>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>> : >>>>> >>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>> >>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>> >>>> -Alan From alexey.semenyuk at oracle.com Fri Dec 6 20:51:16 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 6 Dec 2019 15:51:16 -0500 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: <3f557b9a-a5bc-221f-1a45-486d0bf36e6e@oracle.com> References: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> <5DE9AFD6.5070501@oracle.com> <3f557b9a-a5bc-221f-1a45-486d0bf36e6e@oracle.com> Message-ID: <1fa9ffc5-d0a8-786e-763b-180fcc64925c@oracle.com> On 12/5/2019 8:44 PM, Alexander Matveev wrote: > Hi Alexey, > > 1) Remove this file: > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.rej Done. webrev updated in place. > 2) Agree with Phil, they probably should be pushed as two separate bugs. Decoupling is not straightforward unfortunately: tests that cover additional launchers functionality contain fixes for both [1] and [2] CRs. If there would be no strong arguments against pushing the fixes in a single patch, I'd rather avoid decoupling. > 3) Do you know how to run installer tests with new changes? It is not > clear from code. Fix for [1] moved code to install packages produced by jpackage from manage_packages.sh script into jtreg helper classes. If you run tests locally with test_jpackage.sh script, nothing will change for you. - Alexey > > Changes itself looks fine. > > Thanks, > Alexander > > On 12/5/2019 5:33 PM, Philip Race wrote: >> I don't understand the relationship between these two bugs. >> >> -phil >> >> On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: >>> Please review? fixes for [1] and [2]. Both target jpackage tool. >>> >>> The webrev is at [3]. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8233270 >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8230933 >>> >>> [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ >>> > From philip.race at oracle.com Fri Dec 6 20:59:38 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 6 Dec 2019 12:59:38 -0800 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: <1fa9ffc5-d0a8-786e-763b-180fcc64925c@oracle.com> References: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> <5DE9AFD6.5070501@oracle.com> <3f557b9a-a5bc-221f-1a45-486d0bf36e6e@oracle.com> <1fa9ffc5-d0a8-786e-763b-180fcc64925c@oracle.com> Message-ID: On 12/6/19 12:51 PM, Alexey Semenyuk wrote: > > > On 12/5/2019 8:44 PM, Alexander Matveev wrote: >> Hi Alexey, >> >> 1) Remove this file: >> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.rej > Done. webrev updated in place. > >> 2) Agree with Phil, they probably should be pushed as two separate bugs. > Decoupling is not straightforward unfortunately: tests that cover > additional launchers functionality contain fixes for both [1] and [2] > CRs. So the synopsis reads like this is all about updating tests, and your email says "go read the bugs" and nothing more. I think most people like to see a description of the problem and the proposed solution written in the review request. I think the source code updates are what you need to highlight. And I don't think you have explained why it is so hard. Saying is is hard is not the same thing as explaining why. I think you should decouple unless you can provide that explanation. And definitely you need to provide explanation of the fix etc. -phil. > If there would be no strong arguments against pushing the fixes in a > single patch, I'd rather avoid decoupling. > >> 3) Do you know how to run installer tests with new changes? It is not >> clear from code. > Fix for [1] moved code to install packages produced by jpackage from > manage_packages.sh script into jtreg helper classes. > If you run tests locally with test_jpackage.sh script, nothing will > change for you. > > - Alexey >> >> Changes itself looks fine. >> >> Thanks, >> Alexander >> >> On 12/5/2019 5:33 PM, Philip Race wrote: >>> I don't understand the relationship between these two bugs. >>> >>> -phil >>> >>> On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: >>>> Please review? fixes for [1] and [2]. Both target jpackage tool. >>>> >>>> The webrev is at [3]. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233270 >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8230933 >>>> >>>> [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ >>>> >> > From paul.sandoz at oracle.com Fri Dec 6 21:04:57 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Dec 2019 13:04:57 -0800 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: I mostly looked at the API and implementation and not the tests. s/offset/add or plus ? add ?l? to the offset of this memory address the result of which is the offset of the returned memory address. If we ever have controlled operator overloading that?s how I would like to express it :-) Paul. VarHandles.java ? 40 static ClassValue> addressFactories = new ClassValue>() { 41 @Override 42 protected Map computeValue(Class type) { 43 return new ConcurrentHashMap<>(); 44 } 45 }; s/addressFactories/ADDRESS_FACTORIES/ Perhaps expose as ConcurrentMap to express concurrency requirements. May be useful to pre-size the map. JavaNioAccess.java ? 52 /** 53 * Constructs an heap ByteBuffer with given backing array, offset, capacity and segment. 54 */ 55 ByteBuffer newHeapByteBuffer(byte[] hb, int offset, int capacity, MemorySegmentProxy segment); 56 Formatting issue. FileChannelImpl.java ? 867 private static abstract class Unmapper 868 implements Runnable, UnmapperProxy 869 { 870 // may be required to close file 871 private static final NativeDispatcher nd = new FileDispatcherImpl(); 872 873 // keep track of mapped buffer usage 874 static volatile int count; 875 static volatile long totalSize; 876 static volatile long totalCapacity; These new field declarations are also declared on the concrete subtypes. Did you intend to remove the declarations from the latter? VarHandles ? I see you are relying on the fallback to lambda forms when linking the var handle, otherwise the explicit guard methods just explode :-) Clever generation of VH code on demand punching in live constants, while pre-cooking accessors for ?base" access. AddressVarHandleGenerator.java -- 355 private int returnInsn(Class type) { 356 switch (LambdaForm.BasicType.basicType(type)) { 357 case I_TYPE: return Opcodes.IRETURN; 358 case J_TYPE: return Opcodes.LRETURN; 359 case F_TYPE: return Opcodes.FRETURN; 360 case D_TYPE: return Opcodes.DRETURN; 361 case L_TYPE: return Opcodes.ARETURN; 362 case V_TYPE: return RETURN; 363 default: 364 throw new InternalError("unknown return type: " + type); 365 } 366 } Replace with expression form? (Same for following method too) I believe "JEP 361: Switch Expressions (Standard)? is integrated. GroupLayout.java ? 80 OptionalLong sizeof(List elems) { 81 long size = 0; 82 for (MemoryLayout elem : elems) { 83 if (AbstractLayout.optSize(elem).isPresent()) { 84 size = sizeOp.applyAsLong(size, elem.bitSize()); 85 } else { 86 return OptionalLong.empty(); 87 } 88 } 89 return OptionalLong.of(size); 90 } FWIW you can do this: OptionalLong sizeof(List elems) { return elems.stream().filter(e -> AbstractLayout.optSize(e).isPresent()).mapToLong(MemoryLayout::bitSize) .reduce(sizeOp); } It may be question why there is no way to query if a MemoryLayout has a size or not. Does it require a hasSize method? MemoryAddress.java ? Should MemoryAddress implement Comparable? MemoryHandles.java ? * As an example, consider the memory layout expressed by a {@link SequenceLayout} instance constructed as follows: * 
{@code
SequenceLayout seq = MemoryLayout.ofSequence(5,
    MemoryLayout.ofStruct(
        MemoryLayout.ofPaddingBits(32),
        MemoryLayout.ofValueBits(32).withName("value")
    ));
 * }
MemoryLayout.ofValueBits requires a byte order argument e.g.: MemoryLayout.ofValueBits(32, ByteOrder.BIG_ENDIAN) * 
{@code
VarHandle handle = MemoryHandles.varHandle(int.class); //(MemoryAddress) -> int
handle = MemoryHandles.withOffset(handle, 4); //(MemoryAddress) -> int
handle = MemoryHandles.withStride(handle, 8); //(MemoryAddress, long) -> int
 * }
MemoryHandles.varHandle requires a byte order argument e.g.: VarHandle handle = MemoryHandles.varHandle(int.class, ByteOrder.BIG_ENDIAN); //(MemoryAddress) -> int (See also SequenceLayout) 105 public static VarHandle varHandle(Class carrier, ByteOrder byteOrder) { You may need to specify what access modes are supported, as is the case for MethodHandles.byteBufferViewVarHandle, and also specify how comparison is performed for float/double with atomic update access modes i.e. copy and paste appropriate text. (Same applies to MemoryLayout.varHandle) SequenceLayout.java ? 118 @Override 119 public int hashCode() { 120 return super.hashCode() ^ elemCount.hashCode() ^ elementLayout.hashCode(); 121 } I commonly resort to using Objects.hashCode. Don?t have a strong preference here. I guess you might be concerned about efficient? package-info.java ? 30 * 
{@code
  31 static final VarHandle intHandle = MemoryHandles.varHandle(int.class);
  32 
  33 try (MemorySegment segment = MemorySegment.allocateNative(10 * 4)) {
  34    MemoryAddress base = segment.baseAddress();
  35    for (long i = 0 ; i < 10 ; i++) {
  36      intHandle.set(base.offset(i * 4), (int)i);
  37    }
  38  }
  39  * }
MemoryHandles.varHandle requires a byte order argument. (I wish we could compile code snippets in JavaDoc to surface errors.) MemoryAddressImpl ? 48 public MemoryAddressImpl(MemorySegmentImpl segment) { 49 this(segment, 0); 50 } IDE reporting this constructor is never used. MemorySegmentImpl.java ? 61 final static long NONCE = new Random().nextLong(); If a better quality NONCE is required do ?new SplittableRandom()..nextLong();? 186 private final boolean isSet(int mask) { 187 return (this.mask & mask) != 0; 188 } Unnecessary final modifier. Utils.java ? 143 MemoryScope scope = new MemoryScope(null, () -> unmapperProxy.unmap()); Replace with method ref. > On Dec 5, 2019, at 1:04 PM, Maurizio Cimadamore wrote: > > Hi, > as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code review for the corresponding core-libs and hotspot changes: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > A javadoc for the memory access API is also available here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > Here is a brief summary of the changes in java.base and hotspot (the remaining new files are implementation classes and tests for the new API): > > * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) > > * Modules.gmk - these changes are needed to require that the incubating module is loaded by the boot loader (otherwise the above changes are useless) > > * library_call.cpp - this one is a JIT compiler change to treat Thread.currentThread() as a well-known constant - which helps a lot in the confinement checks (thanks Vlad!) > > * various Buffer-related changes; these changes are needed because the memory access API allows a memory segment to be projected into a byte buffer, for interop reasons. As such, we need to insert a liveness check in the various get/put methods. Previously we had an implementation strategy where a BB was 'decorated' by a subclass called ScopedBuffer - but doing so required some changes to the BB API (e.g. making certain methods non-final, so that we could decorate them). Here I use an approach (which I have discussed with Alan) which doesn't require any public API changes, but needs to add a 'segment' field in Buffer - and then have constructors which keep track of this extra parameter. > > * FileChannel changes - these changes are required so that we can reuse the Unmapper class from the MemorySegment implementation, to deterministically deallocate a mapped memory segment. This should be a 'straight' refactoring, no change in behavior should occur here. Please double check. > > * VarHandles - this class now provides a factory to create memory access VarHandle - this is a bit tricky, since VarHandle cannot really be implemented outside java.base (e.g. VarForm is not public). So we do the usual trick where we define a bunch of proxy interfaces (see jdk/internal/access/foreign) have the classes in java.base refer to these - and then have the implementation classes of the memory access API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to provide access to otherwise hidden functionalities - e.g. creating a new scoped buffer, or retrieving the properties of a memory access handle (e.g. offset, stride etc.), so that we can implement the memory access API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the generation of the new memory address var handle implementations; there's an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access var handle is needed, we dynamically spin a new VH implementation which makes use of the right carrier. We need to spin because the VH can have a variable number of access coordinates (e.g. depending on the dimensions of the array to be accessed). But, under the hood, all the generated implementation will be using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all possible permutations of carriers/dimensions etc. Because of that, the tests might not be the easiest to look at, but they have proven to be pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where it differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is MemoryAddress has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same name but do something quite different (one is an accessor, another is a 'wither'). one obvious option is to rename the first to 'withOffset'. But I think that would lead to verbose code (since that is a very common operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers :-) > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, Roger, Joe and the Panama team for the feedback provided so far, which helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 > From joe.darcy at oracle.com Fri Dec 6 21:15:44 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 6 Dec 2019 13:15:44 -0800 Subject: JDK 14 RFR of JDK-8235514: Update record serialization tests to not use hard coded source versions Message-ID: <3bd68925-f3e1-ec5d-e849-065365642bc1@oracle.com> Hello, Please review the patch below to update to the records serialization tests to avoid hard-coded values for the -source argument during programmatic invocations of the compiler. Thanks, -Joe diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java --- a/test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java Fri Dec 06 12:13:25 2019 -0800 +++ b/test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java Fri Dec 06 13:13:45 2019 -0800 @@ -59,6 +59,7 @@ ? * constructor cannot be found during deserialization. ? */ ?public class BadCanonicalCtrTest { +??? private static final String VERSION = Integer.toString(Runtime.version().feature()); ???? // ClassLoader for creating instances of the records to test with. ???? ClassLoader goodRecordClassLoader; @@ -79,7 +80,7 @@ ???????? { ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("R1", ???????????????????? "public record R1 () implements java.io.Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? goodRecordClassLoader = new ByteCodeLoader("R1", byteCode, BadCanonicalCtrTest.class.getClassLoader()); ???????????? byte[] bc1 = removeConstructor(byteCode); ???????????? missingCtrClassLoader = new ByteCodeLoader("R1", bc1, BadCanonicalCtrTest.class.getClassLoader()); @@ -89,7 +90,7 @@ ???????? { ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("R2", ???????????????????? "public record R2 (int x, int y) implements java.io.Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? goodRecordClassLoader = new ByteCodeLoader("R2", byteCode, goodRecordClassLoader); ???????????? byte[] bc1 = removeConstructor(byteCode); ???????????? missingCtrClassLoader = new ByteCodeLoader("R2", bc1, missingCtrClassLoader); @@ -101,7 +102,7 @@ ???????????????????? "public record R3 (long l) implements java.io.Externalizable {" + ???????????????????? "??? public void writeExternal(java.io.ObjectOutput out) { }" + ???????????????????? "??? public void readExternal(java.io.ObjectInput in)??? { } }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? goodRecordClassLoader = new ByteCodeLoader("R3", byteCode, goodRecordClassLoader); ???????????? byte[] bc1 = removeConstructor(byteCode); ???????????? missingCtrClassLoader = new ByteCodeLoader("R3", bc1, missingCtrClassLoader); diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/ProhibitedMethods.java --- a/test/jdk/java/io/Serializable/records/ProhibitedMethods.java Fri Dec 06 12:13:25 2019 -0800 +++ b/test/jdk/java/io/Serializable/records/ProhibitedMethods.java Fri Dec 06 13:13:45 2019 -0800 @@ -69,6 +69,7 @@ ? * record objects. ? */ ?public class ProhibitedMethods { +??? private static final String VERSION = Integer.toString(Runtime.version().feature()); ???? public interface ThrowingExternalizable extends Externalizable { ???????? default void writeExternal(ObjectOutput out) { @@ -106,7 +107,7 @@ ???????? { ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("Foo", ???????????????????? "public record Foo () implements java.io.Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? byteCode = addWriteObject(byteCode); ???????????? byteCode = addReadObject(byteCode); ???????????? byteCode = addReadObjectNoData(byteCode); @@ -115,7 +116,7 @@ ???????? { ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("Bar", ???????????????????? "public record Bar (int x, int y) implements java.io.Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? byteCode = addWriteObject(byteCode); ???????????? byteCode = addReadObject(byteCode); ???????????? byteCode = addReadObjectNoData(byteCode); @@ -125,7 +126,7 @@ ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("Baz", ???????????????????? "import java.io.Serializable;" + ???????????????????? "public record Baz(U u, V v) implements Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? byteCode = addWriteObject(byteCode); ???????????? byteCode = addReadObject(byteCode); ???????????? byteCode = addReadObjectNoData(byteCode); diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java --- a/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java Fri Dec 06 12:13:25 2019 -0800 +++ b/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java Fri Dec 06 13:13:45 2019 -0800 @@ -64,6 +64,7 @@ ? * Checks that the serialPersistentFields declaration is effectively ignored. ? */ ?public class SerialPersistentFieldsTest { +??? private static final String VERSION = Integer.toString(Runtime.version().feature()); ???? ClassLoader serializableRecordLoader; @@ -85,7 +86,7 @@ ???????? {? // R1 ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("R1", ???????????????????? "public record R1 () implements java.io.Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? ObjectStreamField[] serialPersistentFields = { ???????????????????? new ObjectStreamField("s", String.class), ???????????????????? new ObjectStreamField("i", int.class), @@ -98,7 +99,7 @@ ???????? {? // R2 ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("R2", ???????????????????? "public record R2 (int x) implements java.io.Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? ObjectStreamField[] serialPersistentFields = { ???????????????????? new ObjectStreamField("s", String.class) ???????????? }; @@ -108,7 +109,7 @@ ???????? {? // R3 ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("R3", ???????????????????? "public record R3 (int x, int y) implements java.io.Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? ObjectStreamField[] serialPersistentFields = new ObjectStreamField[0]; ???????????? byteCode = addSerialPersistentFields(byteCode, serialPersistentFields); ???????????? serializableRecordLoader = new ByteCodeLoader("R3", byteCode, serializableRecordLoader); @@ -117,7 +118,7 @@ ???????????? byte[] byteCode = InMemoryJavaCompiler.compile("R4", ???????????????????? "import java.io.Serializable;" + ???????????????????? "public record R4(U u, V v) implements Serializable { }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? ObjectStreamField[] serialPersistentFields = { ???????????????????? new ObjectStreamField("v", String.class) ???????????? }; @@ -134,7 +135,7 @@ ???????????????????? "??? @Override public void readExternal(ObjectInput in) {\n" + ???????????????????? "??????? throw new AssertionError(\"should not reach here\");\n" + ???????????????????? "??? }? }", -??????????????????? "--enable-preview", "-source", "14"); +??????????????????? "--enable-preview", "-source", VERSION); ???????????? ObjectStreamField[] serialPersistentFields = { ???????????????????? new ObjectStreamField("v", String.class) ???????????? }; From lance.andersen at oracle.com Fri Dec 6 21:16:58 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 6 Dec 2019 16:16:58 -0500 Subject: JDK 14 RFR of JDK-8235514: Update record serialization tests to not use hard coded source versions In-Reply-To: <3bd68925-f3e1-ec5d-e849-065365642bc1@oracle.com> References: <3bd68925-f3e1-ec5d-e849-065365642bc1@oracle.com> Message-ID: <3954C93F-056A-4C21-AB6A-EC019027A4A5@oracle.com> +1 > On Dec 6, 2019, at 4:15 PM, Joe Darcy wrote: > > Hello, > > Please review the patch below to update to the records serialization tests to avoid hard-coded values for the -source argument during programmatic invocations of the compiler. > > Thanks, > > -Joe > > diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > --- a/test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java Fri Dec 06 12:13:25 2019 -0800 > +++ b/test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java Fri Dec 06 13:13:45 2019 -0800 > @@ -59,6 +59,7 @@ > * constructor cannot be found during deserialization. > */ > public class BadCanonicalCtrTest { > + private static final String VERSION = Integer.toString(Runtime.version().feature()); > > // ClassLoader for creating instances of the records to test with. > ClassLoader goodRecordClassLoader; > @@ -79,7 +80,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("R1", > "public record R1 () implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > goodRecordClassLoader = new ByteCodeLoader("R1", byteCode, BadCanonicalCtrTest.class.getClassLoader()); > byte[] bc1 = removeConstructor(byteCode); > missingCtrClassLoader = new ByteCodeLoader("R1", bc1, BadCanonicalCtrTest.class.getClassLoader()); > @@ -89,7 +90,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("R2", > "public record R2 (int x, int y) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > goodRecordClassLoader = new ByteCodeLoader("R2", byteCode, goodRecordClassLoader); > byte[] bc1 = removeConstructor(byteCode); > missingCtrClassLoader = new ByteCodeLoader("R2", bc1, missingCtrClassLoader); > @@ -101,7 +102,7 @@ > "public record R3 (long l) implements java.io.Externalizable {" + > " public void writeExternal(java.io.ObjectOutput out) { }" + > " public void readExternal(java.io.ObjectInput in) { } }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > goodRecordClassLoader = new ByteCodeLoader("R3", byteCode, goodRecordClassLoader); > byte[] bc1 = removeConstructor(byteCode); > missingCtrClassLoader = new ByteCodeLoader("R3", bc1, missingCtrClassLoader); > diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/ProhibitedMethods.java > --- a/test/jdk/java/io/Serializable/records/ProhibitedMethods.java Fri Dec 06 12:13:25 2019 -0800 > +++ b/test/jdk/java/io/Serializable/records/ProhibitedMethods.java Fri Dec 06 13:13:45 2019 -0800 > @@ -69,6 +69,7 @@ > * record objects. > */ > public class ProhibitedMethods { > + private static final String VERSION = Integer.toString(Runtime.version().feature()); > > public interface ThrowingExternalizable extends Externalizable { > default void writeExternal(ObjectOutput out) { > @@ -106,7 +107,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("Foo", > "public record Foo () implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > byteCode = addWriteObject(byteCode); > byteCode = addReadObject(byteCode); > byteCode = addReadObjectNoData(byteCode); > @@ -115,7 +116,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("Bar", > "public record Bar (int x, int y) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > byteCode = addWriteObject(byteCode); > byteCode = addReadObject(byteCode); > byteCode = addReadObjectNoData(byteCode); > @@ -125,7 +126,7 @@ > byte[] byteCode = InMemoryJavaCompiler.compile("Baz", > "import java.io.Serializable;" + > "public record Baz(U u, V v) implements Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > byteCode = addWriteObject(byteCode); > byteCode = addReadObject(byteCode); > byteCode = addReadObjectNoData(byteCode); > diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > --- a/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java Fri Dec 06 12:13:25 2019 -0800 > +++ b/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java Fri Dec 06 13:13:45 2019 -0800 > @@ -64,6 +64,7 @@ > * Checks that the serialPersistentFields declaration is effectively ignored. > */ > public class SerialPersistentFieldsTest { > + private static final String VERSION = Integer.toString(Runtime.version().feature()); > > ClassLoader serializableRecordLoader; > > @@ -85,7 +86,7 @@ > { // R1 > byte[] byteCode = InMemoryJavaCompiler.compile("R1", > "public record R1 () implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("s", String.class), > new ObjectStreamField("i", int.class), > @@ -98,7 +99,7 @@ > { // R2 > byte[] byteCode = InMemoryJavaCompiler.compile("R2", > "public record R2 (int x) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("s", String.class) > }; > @@ -108,7 +109,7 @@ > { // R3 > byte[] byteCode = InMemoryJavaCompiler.compile("R3", > "public record R3 (int x, int y) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = new ObjectStreamField[0]; > byteCode = addSerialPersistentFields(byteCode, serialPersistentFields); > serializableRecordLoader = new ByteCodeLoader("R3", byteCode, serializableRecordLoader); > @@ -117,7 +118,7 @@ > byte[] byteCode = InMemoryJavaCompiler.compile("R4", > "import java.io.Serializable;" + > "public record R4(U u, V v) implements Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("v", String.class) > }; > @@ -134,7 +135,7 @@ > " @Override public void readExternal(ObjectInput in) {\n" + > " throw new AssertionError(\"should not reach here\");\n" + > " } }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("v", String.class) > }; > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From alexander.matveev at oracle.com Fri Dec 6 22:33:32 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 6 Dec 2019 14:33:32 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> Message-ID: <25b286c1-8ba6-d673-b453-8c4a4b59481e@oracle.com> Looks good, but is there better way to exclude tests on Solaris? I do not like idea adding @requires for all tests. Thanks, Alexander On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: > Looks good. > > - Alexey > > On 12/6/2019 1:33 PM, Andy Herrick wrote: >> Please review this jpackager test fix for bug [1] at [2]. >> >> the fix adds "@requires (os.family == "linux") | (os.family == "mac") >> | (os.family == "windows")" to all jpackage tests that were not >> already filtered with "@requires (os.family == "XXX")" >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >> >> [2] http://cr.openjdk.java.net/~herrick/8235453/ >> >> /Andy >> > From henry.jen at oracle.com Fri Dec 6 22:44:44 2019 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 6 Dec 2019 14:44:44 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> Message-ID: <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> Thanks for the work, the test case covers that when ?module= is used before other options, which is good. But we need another to make sure that when ?module= is put in an argument file or environment variable, that should not be allowed. The fix is simple, we need to add that to isTerminalOp() method. Cheers, Henry > On Dec 6, 2019, at 12:28 PM, Nikola Grcevski wrote: > > Thank you Henry! > > I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. > > I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://grcevski.github.io/JDK-8234076/webrev/) > > Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 15:11:36 2019 -0500 > @@ -130,6 +130,8 @@ > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 15:11:36 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > > // sanity check, match the args we have, to the holy grail > idx = JLI_GetAppArgIndex(); > + > + // First arg index is NOT_FOUND > + if (idx < 0) { > + // The only allowed value should be NOT_FOUND (-1) unless another change introduces > + // a different negative index > + assert (idx == -1); > + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); > + JLI_TraceLauncher("passing arguments as-is.\n"); > + return NewPlatformStringArray(env, strv, argc); > + } > + > isTool = (idx == 0); > if (isTool) { idx++; } // skip tool name > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 15:11:36 2019 -0500 > @@ -29,6 +29,7 @@ > * jdk.jlink > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > * @run testng BasicTest > + * @bug 8234076 > * @summary Basic test of starting an application as a module > */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ > // the module main class > private static final String MAIN_CLASS = "jdk.test.Main"; > > + // for Windows specific launcher tests > + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); > > @BeforeTest > public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ > assertTrue(exitValue != 0); > } > > + > + /** > + * Helper method that creates a ProcessBuilder with command line arguments > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > + */ > + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { > + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > + return pb; > + } > + > + /** > + * Test the ability for the Windows launcher to do proper application argument > + * detection and expansion, when using the long form module option and all passed in > + * command line arguments are prefixed with a dash. > + * > + * These tests are not expected to work on *nixes, and are ignored. > + */ > + public void testWindowsWithLongFormModuleOption() throws Exception { > + if (!IS_WINDOWS) { > + return; > + } > + > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > + // We should be able to find the argument --help as an application argument > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help"); > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help > + // We should be able to see argument expansion happen > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help") > + .shouldContain("module-info.java"); > + } > + > + > + /** > + * Test that --module= is terminating for VM argument processing just like --module > + */ > + public void testLongFormModuleOptionTermination() throws Exception { > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS > + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be > + // deemed as application arguments > + OutputAnalyzer output = ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--module-path=" + dir, > + "--module=" + mid)) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("argv[ 0] = '--module-path=" + dir) > + .shouldContain("argv[ 1] = '--module=" + mid); > + > + if (IS_WINDOWS) { > + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); > + } > + > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > + // This command line will not work as --module= is terminating and the module will be not found > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > + assertTrue(exitValue != 0); > + } > } > > > -----Original Message----- > From: Henry Jen > Sent: December 6, 2019 12:03 AM > To: Nikola Grcevski > Cc: Kumar Srinivasan ; Alan Bateman ; core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > >> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: >> >> Hello all again! >> >> Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: >> >> --- a/src/java.base/share/native/libjli/args.c >> +++ b/src/java.base/share/native/libjli/args.c >> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { >> } >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >> stopExpansion = JNI_TRUE; >> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { > > I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. > > BTW, we need the patch to be hosted on cr.openjdk.java.net or you can attach the patch to the review thread if you are not yet an author. > > Cheers, > Henry > > >> + idx = argsCount; >> } >> } else { >> if (!expectingNoDashArg) { >> >> The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. >> >> I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. >> >> I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). >> >> I ran all the launcher tests on both Windows and Linux and all tests pass. >> >> Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. >> >> Thank you, >> Nikola >> >> -----Original Message----- >> From: Henry Jen >> Sent: December 4, 2019 8:26 PM >> To: Kumar Srinivasan ; Alan Bateman >> ; Nikola Grcevski >> >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >>> >>> Hi Nikola, >>> >>> It looks ok to me, I will leave it to Henry and Alan to bless this. >>> >>> IMHO: I think we should fix it correctly now than later, I don't >>> think it is all that difficult AFAICT all the launcher has to do is >>> identify "--module==", then the next argument is the first index. >>> >> >> I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. >> >> If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. >> >> FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. >> >> I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. >> >> I?ll let Alan to comment about the ?module option usage. >> >> The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs >> .oracle.com%2Fen%2Fjava%2Fjavase%2F13%2Fdocs%2Fspecs%2Fman%2Fjava.html >> &data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C37e38c582bac4687 >> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 >> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY >> %3D&reserved=0 >> >>> Kumar >>> >>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >>> Hi Henry and Kumar, >>> >>> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >>> >>> Please find my updated webrev here for your review: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc >>> e >>> vski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Gr >>> c >>> evski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86 >>> f >>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ >>> % >>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>> >>> Cheers, >>> >>> Nikola >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 3, 2019 11:39 AM >>> To: Kumar Srinivasan >>> Cc: Nikola Grcevski ; Alan Bateman >>> ; core-libs-dev at openjdk.java.net >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>> >>> Kumar, >>> >>> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >>> >>> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >>> >>> Cheers, >>> Henry >>> >>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>>> >>>> Hi, >>>> >>>> Sorry for chiming in late in the review process, for what it's worth.... >>>> >>>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>>> and subsequent crash, but it does not address wildcard arguments expansion. >>>> >>>> What if we have >>>> % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>>> Where jdk.compiler is a java compiler implementation (javac). >>>> The user would expect the above compiler module to build all the .java files in that directory, >>>> and this fix will not address that. >>>> >>>> Some background: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>>> gs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola >>>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>>> Please see all the related bugs in the above JIRA issue. >>>> >>>> Paragraph #6 in this interview surmises the wild card behavior on Windows: >>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>>> princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=0 >>>> 2%7C01%7CNikola.Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d77 >>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>>> ;reserved=0 >>>> >>>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>>> .openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2 >>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>>> ki%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f1 >>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>>> Using the modules test framework may make the test simpler. >>>> >>>> Kumar Srinivasan >>>> >>>> >>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>>> Hi Alan and Henry, >>>> >>>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>>> >>>> I created a webrev here for the change, including a new test in Arrrghs.java: >>>> >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>>> cevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola >>>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>> >>>> I copied the test validation and assertion style of other code inside the test class. >>>> >>>> Please let me know if you have any comments or suggestions. >>>> >>>> Thanks again! >>>> >>>> -----Original Message----- >>>> From: Henry Jen >>>> Sent: December 2, 2019 12:26 PM >>>> To: Alan Bateman >>>> Cc: Nikola Grcevski ; >>>> core-libs-dev at openjdk.java.net >>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>>> >>>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>>> >>>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>>> >>>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>>> >>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>>> : >>>>>> >>>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>>> >>>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>>> >>>>> -Alan From maurizio.cimadamore at oracle.com Fri Dec 6 23:50:21 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 23:50:21 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: <858356d6-229a-716e-7717-af6aaead2368@oracle.com> Thanks Paul, I'll do a pass and fix the issues you found. Some comments inline: On 06/12/2019 21:04, Paul Sandoz wrote: > I mostly looked at the API and implementation and not the tests. > > s/offset/add or plus ? add ?l? to the offset of this memory address the result of which is the offset of the returned memory address. > > If we ever have controlled operator overloading that?s how I would like to express it :-) > > Paul. > > > VarHandles.java > ? > > 40 static ClassValue> addressFactories = new ClassValue>() { > 41 @Override > 42 protected Map computeValue(Class type) { > 43 return new ConcurrentHashMap<>(); > 44 } > 45 }; > > s/addressFactories/ADDRESS_FACTORIES/ > > Perhaps expose as ConcurrentMap to express concurrency requirements. > > May be useful to pre-size the map. > > > JavaNioAccess.java > ? > > 52 /** > 53 * Constructs an heap ByteBuffer with given backing array, offset, capacity and segment. > 54 */ > 55 ByteBuffer newHeapByteBuffer(byte[] hb, int offset, int capacity, MemorySegmentProxy segment); > 56 > > Formatting issue. > > > FileChannelImpl.java > ? > > 867 private static abstract class Unmapper > 868 implements Runnable, UnmapperProxy > 869 { > 870 // may be required to close file > 871 private static final NativeDispatcher nd = new FileDispatcherImpl(); > 872 > 873 // keep track of mapped buffer usage > 874 static volatile int count; > 875 static volatile long totalSize; > 876 static volatile long totalCapacity; > > These new field declarations are also declared on the concrete subtypes. Did you intend to remove the declarations from the latter? Uhm - I might have messed up something... but I think the fields should be removed from the superclass - it's only the concrete subclasses using them, and they are being used inside synchronized blocks for their corresponding classes - so I think they are meant to be disjoint. I think I added them by accident in Unmapper. > > > > VarHandles > ? > > I see you are relying on the fallback to lambda forms when linking the var handle, otherwise the explicit guard methods just explode :-) > > Clever generation of VH code on demand punching in live constants, while pre-cooking accessors for ?base" access. > > > AddressVarHandleGenerator.java > -- > > 355 private int returnInsn(Class type) { > 356 switch (LambdaForm.BasicType.basicType(type)) { > 357 case I_TYPE: return Opcodes.IRETURN; > 358 case J_TYPE: return Opcodes.LRETURN; > 359 case F_TYPE: return Opcodes.FRETURN; > 360 case D_TYPE: return Opcodes.DRETURN; > 361 case L_TYPE: return Opcodes.ARETURN; > 362 case V_TYPE: return RETURN; > 363 default: > 364 throw new InternalError("unknown return type: " + type); > 365 } > 366 } > > Replace with expression form? (Same for following method too) I believe "JEP 361: Switch Expressions (Standard)? is integrated. > > > GroupLayout.java > ? > > 80 OptionalLong sizeof(List elems) { > 81 long size = 0; > 82 for (MemoryLayout elem : elems) { > 83 if (AbstractLayout.optSize(elem).isPresent()) { > 84 size = sizeOp.applyAsLong(size, elem.bitSize()); > 85 } else { > 86 return OptionalLong.empty(); > 87 } > 88 } > 89 return OptionalLong.of(size); > 90 } > > FWIW you can do this: > > OptionalLong sizeof(List elems) { > return elems.stream().filter(e -> AbstractLayout.optSize(e).isPresent()).mapToLong(MemoryLayout::bitSize) > .reduce(sizeOp); > } > > It may be question why there is no way to query if a MemoryLayout has a size or not. Does it require a hasSize method? I'm on the fence on that one. Yes for completeness it should be there... but doesn't seem all that useful either. I can see that, pulling on that string, you end up with an optional size (since sometimes the size isn't there) but that means all clients pay the price for the few layouts that use unspecified sequences. I was hoping to keep them under the rug to be honest. > > > MemoryAddress.java > ? > > Should MemoryAddress implement Comparable? I don't think so - as they don't form an order - two addresses are comparable only if their segments are the same. > > > > MemoryHandles.java > ? > > * As an example, consider the memory layout expressed by a {@link SequenceLayout} instance constructed as follows: > * 
{@code
> SequenceLayout seq = MemoryLayout.ofSequence(5,
>      MemoryLayout.ofStruct(
>          MemoryLayout.ofPaddingBits(32),
>          MemoryLayout.ofValueBits(32).withName("value")
>      ));
>   * }
> > > MemoryLayout.ofValueBits requires a byte order argument e.g.: > > MemoryLayout.ofValueBits(32, ByteOrder.BIG_ENDIAN) > > > * 
{@code
> VarHandle handle = MemoryHandles.varHandle(int.class); //(MemoryAddress) -> int
> handle = MemoryHandles.withOffset(handle, 4); //(MemoryAddress) -> int
> handle = MemoryHandles.withStride(handle, 8); //(MemoryAddress, long) -> int
>   * }
> > > MemoryHandles.varHandle requires a byte order argument e.g.: > > VarHandle handle = MemoryHandles.varHandle(int.class, ByteOrder.BIG_ENDIAN); //(MemoryAddress) -> int > > (See also SequenceLayout) Thanks for catching these > > > 105 public static VarHandle varHandle(Class carrier, ByteOrder byteOrder) { > > You may need to specify what access modes are supported, as is the case for MethodHandles.byteBufferViewVarHandle, and also specify how comparison is performed for float/double with atomic update access modes i.e. copy and paste appropriate text. (Same applies to MemoryLayout.varHandle) Gotcha > > > SequenceLayout.java > ? > > 118 @Override > 119 public int hashCode() { > 120 return super.hashCode() ^ elemCount.hashCode() ^ elementLayout.hashCode(); > 121 } > > I commonly resort to using Objects.hashCode. Don?t have a strong preference here. I guess you might be concerned about efficient? Not really, I agree this should just use Objects::hashCode > > > package-info.java > ? > > 30 * 
{@code
>    31 static final VarHandle intHandle = MemoryHandles.varHandle(int.class);
>    32
>    33 try (MemorySegment segment = MemorySegment.allocateNative(10 * 4)) {
>    34    MemoryAddress base = segment.baseAddress();
>    35    for (long i = 0 ; i < 10 ; i++) {
>    36      intHandle.set(base.offset(i * 4), (int)i);
>    37    }
>    38  }
>    39  * }
> > MemoryHandles.varHandle requires a byte order argument. > > (I wish we could compile code snippets in JavaDoc to surface errors.) > > > MemoryAddressImpl > ? > > 48 public MemoryAddressImpl(MemorySegmentImpl segment) { > 49 this(segment, 0); > 50 } > > > IDE reporting this constructor is never used. > > > MemorySegmentImpl.java > ? > > 61 final static long NONCE = new Random().nextLong(); > > If a better quality NONCE is required do ?new SplittableRandom()..nextLong();? > > > 186 private final boolean isSet(int mask) { > 187 return (this.mask & mask) != 0; > 188 } > > > Unnecessary final modifier. > > > Utils.java > ? > > 143 MemoryScope scope = new MemoryScope(null, () -> unmapperProxy.unmap()); > > > Replace with method ref. > Thanks Maurizio > > >> On Dec 5, 2019, at 1:04 PM, Maurizio Cimadamore wrote: >> >> Hi, >> as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code review for the corresponding core-libs and hotspot changes: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >> >> A javadoc for the memory access API is also available here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> Note: the patch passes tier1, tier2 and tier3 testing (**) >> >> >> Here is a brief summary of the changes in java.base and hotspot (the remaining new files are implementation classes and tests for the new API): >> >> * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) >> >> * Modules.gmk - these changes are needed to require that the incubating module is loaded by the boot loader (otherwise the above changes are useless) >> >> * library_call.cpp - this one is a JIT compiler change to treat Thread.currentThread() as a well-known constant - which helps a lot in the confinement checks (thanks Vlad!) >> >> * various Buffer-related changes; these changes are needed because the memory access API allows a memory segment to be projected into a byte buffer, for interop reasons. As such, we need to insert a liveness check in the various get/put methods. Previously we had an implementation strategy where a BB was 'decorated' by a subclass called ScopedBuffer - but doing so required some changes to the BB API (e.g. making certain methods non-final, so that we could decorate them). Here I use an approach (which I have discussed with Alan) which doesn't require any public API changes, but needs to add a 'segment' field in Buffer - and then have constructors which keep track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can reuse the Unmapper class from the MemorySegment implementation, to deterministically deallocate a mapped memory segment. This should be a 'straight' refactoring, no change in behavior should occur here. Please double check. >> >> * VarHandles - this class now provides a factory to create memory access VarHandle - this is a bit tricky, since VarHandle cannot really be implemented outside java.base (e.g. VarForm is not public). So we do the usual trick where we define a bunch of proxy interfaces (see jdk/internal/access/foreign) have the classes in java.base refer to these - and then have the implementation classes of the memory access API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to provide access to otherwise hidden functionalities - e.g. creating a new scoped buffer, or retrieving the properties of a memory access handle (e.g. offset, stride etc.), so that we can implement the memory access API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the generation of the new memory address var handle implementations; there's an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access var handle is needed, we dynamically spin a new VH implementation which makes use of the right carrier. We need to spin because the VH can have a variable number of access coordinates (e.g. depending on the dimensions of the array to be accessed). But, under the hood, all the generated implementation will be using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all possible permutations of carriers/dimensions etc. Because of that, the tests might not be the easiest to look at, but they have proven to be pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where it differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is MemoryAddress has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same name but do something quite different (one is an accessor, another is a 'wither'). one obvious option is to rename the first to 'withOffset'. But I think that would lead to verbose code (since that is a very common operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, Roger, Joe and the Panama team for the feedback provided so far, which helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >> From maurizio.cimadamore at oracle.com Fri Dec 6 23:51:35 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 6 Dec 2019 23:51:35 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: Message-ID: On 06/12/2019 18:29, Raffaello Giulietti wrote: > Hello, > > great job! > > I think that the doc of MemoryAddress.copy() should be explicit about > the direction of the copying, so it should either: Thanks! -? I'll rectify the doc to specify lower-to-higher. Maurizio > > * explicitly specify a direction, e.g., lower-to-higher addresses > > * or specify that in the case of an overlap the copying is smart > enough to not destroy the src bytes before they have landed in dst > > * or accept a negative third argument to encode a higher-to-lower > addresses copying direction. > > > Greetings > Raffaello > > > >> Hi, >> as part of the effort to upstream the changes related to JEP 370 >> (foreign memory access API) [1], I'd like to ask for a code review >> for the corresponding core-libs and hotspot changes: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >> >> A javadoc for the memory access API is also available here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Note: the patch passes tier1, tier2 and tier3 testing (**) >> >> >> Here is a brief summary of the changes in java.base and hotspot (the >> remaining new files are implementation classes and tests for the new >> API): >> >> * ciField.cpp - this one is to trust final fields in the foreign >> memory access implementation (otherwise VM doesn't trust memory >> segment bounds) >> >> * Modules.gmk - these changes are needed to require that the >> incubating module is loaded by the boot loader (otherwise the above >> changes are useless) >> >> * library_call.cpp - this one is a JIT compiler change to treat >> Thread.currentThread() as a well-known constant - which helps a lot >> in the confinement checks (thanks Vlad!) >> >> * various Buffer-related changes; these changes are needed because >> the memory access API allows a memory segment to be projected into a >> byte buffer, for interop reasons. As such, we need to insert a >> liveness check in the various get/put methods. Previously we had an >> implementation strategy where a BB was 'decorated' by a subclass >> called ScopedBuffer - but doing so required some changes to the BB >> API (e.g. making certain methods non-final, so that we could decorate >> them). Here I use an approach (which I have discussed with Alan) >> which doesn't require any public API? changes, but needs to add a >> 'segment' field in Buffer - and then have constructors which keep >> track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can >> reuse the Unmapper class from the MemorySegment implementation, to >> deterministically deallocate a mapped memory segment. This should be >> a 'straight' refactoring, no change in behavior should occur here. >> Please double check. >> >> * VarHandles - this class now provides a factory to create memory >> access VarHandle - this is a bit tricky, since VarHandle cannot >> really be implemented outside java.base (e.g. VarForm is not public). >> So we do the usual trick where we define a bunch of proxy interfaces >> (see jdk/internal/access/foreign) have the classes in java.base refer >> to these - and then have the implementation classes of the memory >> access API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >> to provide access to otherwise hidden functionalities - e.g. creating >> a new scoped buffer, or retrieving the properties of a memory access >> handle (e.g. offset, stride etc.), so that we can implement the >> memory access API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the >> generation of the new memory address var handle implementations; >> there's an helper class per carrier (e.g. >> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >> var handle is needed, we dynamically spin a new VH implementation >> which makes use of the right carrier. We need to spin because the VH >> can have a variable number of access coordinates (e.g. depending on >> the dimensions of the array to be accessed). But, under the hood, all >> the generated implementation will be using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all >> possible permutations of carriers/dimensions etc. Because of that, >> the tests might not be the easiest to look at, but they have proven >> to be pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where >> it differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is >> MemoryAddress has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same >> name but do something quite different (one is an accessor, another is >> a 'wither'). one obvious option is to rename the first to >> 'withOffset'. But I think that would lead to verbose code (since that >> is a very common operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice >> which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >> Stuart, Roger, Joe and the Panama team for the feedback provided so >> far, which helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >> but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 > > From fujie at loongson.cn Sat Dec 7 00:41:11 2019 From: fujie at loongson.cn (Jie Fu) Date: Sat, 7 Dec 2019 08:41:11 +0800 Subject: RFR: 8235482: [TESTBUG] PackageType LINUX_RPM should be excluded for jpackage tests on debian systems In-Reply-To: <716346c8-ced9-862b-b6d3-240b438ea3a0@oracle.com> References: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> <716346c8-ced9-862b-b6d3-240b438ea3a0@oracle.com> Message-ID: Hi Alexey, Thanks for your review and comments. I have two questions: ?- 1) Have you ever tried the rpm tests on a debian system? ?- 2) How to decide whether the rpm tests are supported on a debian system? Thanks a lot. Best regards, Jie On 2019/12/7 ??1:26, Alexey Semenyuk wrote: > This fix will disable running rpm tests on Debian systems that support > it. This is not a good idea. > If you need to exclude some packaging from jpackage tests, just run > jtreg with "jpackage.test.disabledPackagers" system property set to > the list of corresponding package types. E.g.: > -Djpackage.test.disabledPackagers=rpm will disable rpm packaging. > > - Alexey > > On 12/6/2019 7:51 AM, Jie Fu wrote: >> Hi all, >> >> May I get reviews for the small fix? >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235482 >> Webrev: http://cr.openjdk.java.net/~jiefu/8235482/webrev.00/ >> >> Thanks a lot. >> Best regards, >> Jie >> From philip.race at oracle.com Sat Dec 7 01:11:36 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 6 Dec 2019 17:11:36 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <25b286c1-8ba6-d673-b453-8c4a4b59481e@oracle.com> References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> <25b286c1-8ba6-d673-b453-8c4a4b59481e@oracle.com> Message-ID: Well we could deprecate and remove the solaris port :-) But until that is done this is the only way I know of. we could require all jpackage tests to include some helper code which decides if it is applicable but that will be more work upfront and many jpackage tests are already platform specific so @requires is not going away. -Phil. > On Dec 6, 2019, at 2:33 PM, Alexander Matveev wrote: > > Looks good, but is there better way to exclude tests on Solaris? I do not like idea adding @requires for all tests. > > Thanks, > Alexander > >> On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: >> Looks good. >> >> - Alexey >> >>> On 12/6/2019 1:33 PM, Andy Herrick wrote: >>> Please review this jpackager test fix for bug [1] at [2]. >>> >>> the fix adds "@requires (os.family == "linux") | (os.family == "mac") | (os.family == "windows")" to all jpackage tests that were not already filtered with "@requires (os.family == "XXX")" >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8235453/ >>> >>> /Andy >>> >> > From vyommani at gmail.com Sat Dec 7 03:36:44 2019 From: vyommani at gmail.com (Vyom Tiwari) Date: Sat, 7 Dec 2019 09:06:44 +0530 Subject: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed In-Reply-To: <0a09885f-dd8b-13e7-f042-752ce77b4cc7@oracle.com> References: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> <0a09885f-dd8b-13e7-f042-752ce77b4cc7@oracle.com> Message-ID: Hi Aleks, Changes looks OK to me, one minor bit you need to update @bug tag before pushing. Thanks, Vyom On Fri, Dec 6, 2019 at 11:41 PM Daniel Fuchs wrote: > Looks good to me Aleksei! > > best regards, > > -- daniel > > On 06/12/2019 17:33, Aleks Efimov wrote: > > Hi, > > > > InvalidLdapFilters test has been seen failing intermittently with > > timeouts. The cause of the observed failures could be the binding of > > test server to the wildcard address. > > Proposed fix binds the test server to the loopback address and uses the > > test library to construct LDAP provider URL. > > The modified test has been executed ~100 times alongside to other > > networking and JNDI tests: No failures have been observed. > > > > Webrev: http://cr.openjdk.java.net/~aefimov/8141685/00 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8141685 > > > > With Best Regards, > > Aleksei > > > > -- Thanks, Vyom From chris.hegarty at oracle.com Sat Dec 7 08:50:30 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 7 Dec 2019 08:50:30 +0000 Subject: JDK 14 RFR of JDK-8235514: Update record serialization tests to not use hard coded source versions In-Reply-To: <3bd68925-f3e1-ec5d-e849-065365642bc1@oracle.com> References: <3bd68925-f3e1-ec5d-e849-065365642bc1@oracle.com> Message-ID: <5EDAAEA4-99E2-48DF-BBEF-005ECA3E5DE7@oracle.com> Thanks for doing this Joe. The changes look good. -Chris. > On 6 Dec 2019, at 21:15, Joe Darcy wrote: > > Hello, > > Please review the patch below to update to the records serialization tests to avoid hard-coded values for the -source argument during programmatic invocations of the compiler. > > Thanks, > > -Joe > > diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java > --- a/test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java Fri Dec 06 12:13:25 2019 -0800 > +++ b/test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java Fri Dec 06 13:13:45 2019 -0800 > @@ -59,6 +59,7 @@ > * constructor cannot be found during deserialization. > */ > public class BadCanonicalCtrTest { > + private static final String VERSION = Integer.toString(Runtime.version().feature()); > > // ClassLoader for creating instances of the records to test with. > ClassLoader goodRecordClassLoader; > @@ -79,7 +80,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("R1", > "public record R1 () implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > goodRecordClassLoader = new ByteCodeLoader("R1", byteCode, BadCanonicalCtrTest.class.getClassLoader()); > byte[] bc1 = removeConstructor(byteCode); > missingCtrClassLoader = new ByteCodeLoader("R1", bc1, BadCanonicalCtrTest.class.getClassLoader()); > @@ -89,7 +90,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("R2", > "public record R2 (int x, int y) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > goodRecordClassLoader = new ByteCodeLoader("R2", byteCode, goodRecordClassLoader); > byte[] bc1 = removeConstructor(byteCode); > missingCtrClassLoader = new ByteCodeLoader("R2", bc1, missingCtrClassLoader); > @@ -101,7 +102,7 @@ > "public record R3 (long l) implements java.io.Externalizable {" + > " public void writeExternal(java.io.ObjectOutput out) { }" + > " public void readExternal(java.io.ObjectInput in) { } }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > goodRecordClassLoader = new ByteCodeLoader("R3", byteCode, goodRecordClassLoader); > byte[] bc1 = removeConstructor(byteCode); > missingCtrClassLoader = new ByteCodeLoader("R3", bc1, missingCtrClassLoader); > diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/ProhibitedMethods.java > --- a/test/jdk/java/io/Serializable/records/ProhibitedMethods.java Fri Dec 06 12:13:25 2019 -0800 > +++ b/test/jdk/java/io/Serializable/records/ProhibitedMethods.java Fri Dec 06 13:13:45 2019 -0800 > @@ -69,6 +69,7 @@ > * record objects. > */ > public class ProhibitedMethods { > + private static final String VERSION = Integer.toString(Runtime.version().feature()); > > public interface ThrowingExternalizable extends Externalizable { > default void writeExternal(ObjectOutput out) { > @@ -106,7 +107,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("Foo", > "public record Foo () implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > byteCode = addWriteObject(byteCode); > byteCode = addReadObject(byteCode); > byteCode = addReadObjectNoData(byteCode); > @@ -115,7 +116,7 @@ > { > byte[] byteCode = InMemoryJavaCompiler.compile("Bar", > "public record Bar (int x, int y) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > byteCode = addWriteObject(byteCode); > byteCode = addReadObject(byteCode); > byteCode = addReadObjectNoData(byteCode); > @@ -125,7 +126,7 @@ > byte[] byteCode = InMemoryJavaCompiler.compile("Baz", > "import java.io.Serializable;" + > "public record Baz(U u, V v) implements Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > byteCode = addWriteObject(byteCode); > byteCode = addReadObject(byteCode); > byteCode = addReadObjectNoData(byteCode); > diff -r 3b9efbac1b50 test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java > --- a/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java Fri Dec 06 12:13:25 2019 -0800 > +++ b/test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java Fri Dec 06 13:13:45 2019 -0800 > @@ -64,6 +64,7 @@ > * Checks that the serialPersistentFields declaration is effectively ignored. > */ > public class SerialPersistentFieldsTest { > + private static final String VERSION = Integer.toString(Runtime.version().feature()); > > ClassLoader serializableRecordLoader; > > @@ -85,7 +86,7 @@ > { // R1 > byte[] byteCode = InMemoryJavaCompiler.compile("R1", > "public record R1 () implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("s", String.class), > new ObjectStreamField("i", int.class), > @@ -98,7 +99,7 @@ > { // R2 > byte[] byteCode = InMemoryJavaCompiler.compile("R2", > "public record R2 (int x) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("s", String.class) > }; > @@ -108,7 +109,7 @@ > { // R3 > byte[] byteCode = InMemoryJavaCompiler.compile("R3", > "public record R3 (int x, int y) implements java.io.Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = new ObjectStreamField[0]; > byteCode = addSerialPersistentFields(byteCode, serialPersistentFields); > serializableRecordLoader = new ByteCodeLoader("R3", byteCode, serializableRecordLoader); > @@ -117,7 +118,7 @@ > byte[] byteCode = InMemoryJavaCompiler.compile("R4", > "import java.io.Serializable;" + > "public record R4(U u, V v) implements Serializable { }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("v", String.class) > }; > @@ -134,7 +135,7 @@ > " @Override public void readExternal(ObjectInput in) {\n" + > " throw new AssertionError(\"should not reach here\");\n" + > " } }", > - "--enable-preview", "-source", "14"); > + "--enable-preview", "-source", VERSION); > ObjectStreamField[] serialPersistentFields = { > new ObjectStreamField("v", String.class) > }; > From gerard.ziemski at oracle.com Sat Dec 7 13:34:28 2019 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Sat, 7 Dec 2019 07:34:28 -0600 Subject: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code" In-Reply-To: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com> References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com> Message-ID: Hi all, Please review this revision 2 of a cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself. The rev2 differs from rev1 in that it's simpler due to JDK-8234185, which was just checked in yesterday. Waiting for this fix to go in first, allowed us not to have to delete the jdk_util.h file, which in turn means that we don't have to touch all those files that used that include. bug: https://bugs.openjdk.java.net/browse/JDK-8223261 webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev2 tests: passes Mach5 tier1,2,3 (another tier1,2,3,4,5,6 in progress...) cheers From claes.redestad at oracle.com Sat Dec 7 13:44:02 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 7 Dec 2019 14:44:02 +0100 Subject: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code" In-Reply-To: References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com> Message-ID: Looks good to me! /Claes On 2019-12-07 14:34, gerard ziemski wrote: > Hi all, > > Please review this revision 2 of a cleanup, where we remove > JDK_GetVersionInfo0 and related code, since we can get build versions > directly from within the VM itself. > > The rev2 differs from rev1 in that it's simpler due to JDK-8234185, > which was just checked in yesterday. Waiting for this fix to go in > first, allowed us not to have to delete the jdk_util.h file, which in > turn means that we don't have to touch all those files that used that > include. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8223261 > webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev2 > tests: passes Mach5 tier1,2,3 (another tier1,2,3,4,5,6 in progress...) > > > cheers > From andy.herrick at oracle.com Sat Dec 7 13:48:56 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 7 Dec 2019 08:48:56 -0500 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> <25b286c1-8ba6-d673-b453-8c4a4b59481e@oracle.com> Message-ID: <2d0f4583-44b2-9fcf-a2d0-b0c8ca1a6249@oracle.com> Phil - are you approving this change ? - I think you are the only registered Reviewer. /Andy On 12/6/2019 8:11 PM, Phil Race wrote: > Well we could deprecate and remove the solaris port :-) > But until that is done this is the only way I know of. > we could require all jpackage tests to include some helper code which decides if it is applicable but that will be more work upfront and many jpackage tests are already platform specific so @requires is not going away. > > > -Phil. > >> On Dec 6, 2019, at 2:33 PM, Alexander Matveev wrote: >> >> Looks good, but is there better way to exclude tests on Solaris? I do not like idea adding @requires for all tests. >> >> Thanks, >> Alexander >> >>> On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: >>> Looks good. >>> >>> - Alexey >>> >>>> On 12/6/2019 1:33 PM, Andy Herrick wrote: >>>> Please review this jpackager test fix for bug [1] at [2]. >>>> >>>> the fix adds "@requires (os.family == "linux") | (os.family == "mac") | (os.family == "windows")" to all jpackage tests that were not already filtered with "@requires (os.family == "XXX")" >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >>>> >>>> [2] http://cr.openjdk.java.net/~herrick/8235453/ >>>> >>>> /Andy >>>> From christoph.langer at sap.com Sat Dec 7 15:15:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 7 Dec 2019 15:15:12 +0000 Subject: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code" In-Reply-To: References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com> Message-ID: Hi Gerard, this looks good. Cheers Christoph > -----Original Message----- > From: gerard ziemski > Sent: Samstag, 7. Dezember 2019 14:34 > To: hotspot-dev developers ; core-libs- > dev at openjdk.java.net; Claes Redestad ; > Mandy Chung ; David Holmes > ; Sergey Bylokhov > ; Langer, Christoph > > Subject: Re: RFR (M) 8223261 "JDK-8189208 followup - remove > JDK_GetVersionInfo0 and the supporting code" > > Hi all, > > Please review this revision 2 of a cleanup, where we remove > JDK_GetVersionInfo0 and related code, since we can get build versions > directly from within the VM itself. > > The rev2 differs from rev1 in that it's simpler due to JDK-8234185, > which was just checked in yesterday. Waiting for this fix to go in > first, allowed us not to have to delete the jdk_util.h file, which in > turn means that we don't have to touch all those files that used that > include. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8223261 > webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev2 > tests: passes Mach5 tier1,2,3 (another tier1,2,3,4,5,6 in progress...) > > > cheers From maurizio.cimadamore at oracle.com Sat Dec 7 19:02:24 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 7 Dec 2019 19:02:24 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: On 06/12/2019 21:04, Paul Sandoz wrote: > GroupLayout.java > ? > > 80 OptionalLong sizeof(List elems) { > 81 long size = 0; > 82 for (MemoryLayout elem : elems) { > 83 if (AbstractLayout.optSize(elem).isPresent()) { > 84 size = sizeOp.applyAsLong(size, elem.bitSize()); > 85 } else { > 86 return OptionalLong.empty(); > 87 } > 88 } > 89 return OptionalLong.of(size); > 90 } > > FWIW you can do this: > > OptionalLong sizeof(List elems) { > return elems.stream().filter(e -> AbstractLayout.optSize(e).isPresent()).mapToLong(MemoryLayout::bitSize) > .reduce(sizeOp); Looked at this more carefully - the code you suggest has a slightly different behavior than the one I wrote - note that the original code short-circuit when the first layout member with no size is encountered. IIUC your code will just drop unsized member layouts, and compute size on the rest - which is not what I had in mind. Am I understanding correctly? Maurizio From mandy.chung at oracle.com Sat Dec 7 19:33:55 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 7 Dec 2019 11:33:55 -0800 Subject: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code" In-Reply-To: References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com> Message-ID: <0d206768-674a-b462-cd7d-4dbbd5a21fdd@oracle.com> Looks good. Mandy On 12/7/19 5:34 AM, gerard ziemski wrote: > Hi all, > > Please review this revision 2 of a cleanup, where we remove > JDK_GetVersionInfo0 and related code, since we can get build versions > directly from within the VM itself. > > The rev2 differs from rev1 in that it's simpler due to JDK-8234185, > which was just checked in yesterday. Waiting for this fix to go in > first, allowed us not to have to delete the jdk_util.h file, which in > turn means that we don't have to touch all those files that used that > include. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8223261 > webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev2 > tests: passes Mach5 tier1,2,3 (another tier1,2,3,4,5,6 in progress...) > > > cheers > From philip.race at oracle.com Sat Dec 7 19:57:46 2019 From: philip.race at oracle.com (Philip Race) Date: Sat, 07 Dec 2019 11:57:46 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <2d0f4583-44b2-9fcf-a2d0-b0c8ca1a6249@oracle.com> References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> <25b286c1-8ba6-d673-b453-8c4a4b59481e@oracle.com> <2d0f4583-44b2-9fcf-a2d0-b0c8ca1a6249@oracle.com> Message-ID: <5DEC043A.8070806@oracle.com> Yes, since only a (relatively) small number of tests needed to be updated this is fine with me at least for now. So +1 -phil. On 12/7/19, 5:48 AM, Andy Herrick wrote: > Phil - are you approving this change ? - I think you are the only > registered Reviewer. > > /Andy > > On 12/6/2019 8:11 PM, Phil Race wrote: >> Well we could deprecate and remove the solaris port :-) >> But until that is done this is the only way I know of. >> we could require all jpackage tests to include some helper code which >> decides if it is applicable but that will be more work upfront and >> many jpackage tests are already platform specific so @requires is not >> going away. >> >> >> -Phil. >> >>> On Dec 6, 2019, at 2:33 PM, Alexander Matveev >>> wrote: >>> >>> Looks good, but is there better way to exclude tests on Solaris? I >>> do not like idea adding @requires for all tests. >>> >>> Thanks, >>> Alexander >>> >>>> On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: >>>> Looks good. >>>> >>>> - Alexey >>>> >>>>> On 12/6/2019 1:33 PM, Andy Herrick wrote: >>>>> Please review this jpackager test fix for bug [1] at [2]. >>>>> >>>>> the fix adds "@requires (os.family == "linux") | (os.family == >>>>> "mac") | (os.family == "windows")" to all jpackage tests that were >>>>> not already filtered with "@requires (os.family == "XXX")" >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >>>>> >>>>> [2] http://cr.openjdk.java.net/~herrick/8235453/ >>>>> >>>>> /Andy >>>>> From igor.ignatyev at oracle.com Sat Dec 7 20:07:32 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 7 Dec 2019 12:07:32 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <5DEC043A.8070806@oracle.com> References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> <25b286c1-8ba6-d673-b453-8c4a4b59481e@oracle.com> <2d0f4583-44b2-9fcf-a2d0-b0c8ca1a6249@oracle.com> <5DEC043A.8070806@oracle.com> Message-ID: can we just add '@modules jdk.incubator.jpackage' to test/jdk/tools/jpackage/junit/junit.java to solve that? or some of the tests run by test/jdk/tools/jpackage/junit/junit.java don't need jdk.incubator.jpackage module? -- Igor > On Dec 7, 2019, at 11:57 AM, Philip Race wrote: > > Yes, since only a (relatively) small number of tests needed to be updated > this is fine with me at least for now. So +1 > > -phil. > > On 12/7/19, 5:48 AM, Andy Herrick wrote: >> Phil - are you approving this change ? - I think you are the only registered Reviewer. >> >> /Andy >> >> On 12/6/2019 8:11 PM, Phil Race wrote: >>> Well we could deprecate and remove the solaris port :-) >>> But until that is done this is the only way I know of. >>> we could require all jpackage tests to include some helper code which decides if it is applicable but that will be more work upfront and many jpackage tests are already platform specific so @requires is not going away. >>> >>> >>> -Phil. >>> >>>> On Dec 6, 2019, at 2:33 PM, Alexander Matveev wrote: >>>> >>>> Looks good, but is there better way to exclude tests on Solaris? I do not like idea adding @requires for all tests. >>>> >>>> Thanks, >>>> Alexander >>>> >>>>> On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: >>>>> Looks good. >>>>> >>>>> - Alexey >>>>> >>>>>> On 12/6/2019 1:33 PM, Andy Herrick wrote: >>>>>> Please review this jpackager test fix for bug [1] at [2]. >>>>>> >>>>>> the fix adds "@requires (os.family == "linux") | (os.family == "mac") | (os.family == "windows")" to all jpackage tests that were not already filtered with "@requires (os.family == "XXX")" >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >>>>>> >>>>>> [2] http://cr.openjdk.java.net/~herrick/8235453/ >>>>>> >>>>>> /Andy >>>>>> From philip.race at oracle.com Sat Dec 7 21:43:19 2019 From: philip.race at oracle.com (Phil Race) Date: Sat, 7 Dec 2019 13:43:19 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> <25b286c1-8ba6-d673-b453-8c4a4b59481e@oracle.com> <2d0f4583-44b2-9fcf-a2d0-b0c8ca1a6249@oracle.com> <5DEC043A.8070806@oracle.com> Message-ID: <8BA5C013-32FC-415D-BD3A-A0D15B6D993B@oracle.com> All these tests specify this already so it doesn?t seem sufficient. -Phil. > On Dec 7, 2019, at 12:07 PM, Igor Ignatyev wrote: > > can we just add '@modules jdk.incubator.jpackage' to test/jdk/tools/jpackage/junit/junit.java to solve that? or some of the tests run by test/jdk/tools/jpackage/junit/junit.java don't need jdk.incubator.jpackage module? > > -- Igor > >> On Dec 7, 2019, at 11:57 AM, Philip Race wrote: >> >> Yes, since only a (relatively) small number of tests needed to be updated >> this is fine with me at least for now. So +1 >> >> -phil. >> >>> On 12/7/19, 5:48 AM, Andy Herrick wrote: >>> Phil - are you approving this change ? - I think you are the only registered Reviewer. >>> >>> /Andy >>> >>>> On 12/6/2019 8:11 PM, Phil Race wrote: >>>> Well we could deprecate and remove the solaris port :-) >>>> But until that is done this is the only way I know of. >>>> we could require all jpackage tests to include some helper code which decides if it is applicable but that will be more work upfront and many jpackage tests are already platform specific so @requires is not going away. >>>> >>>> >>>> -Phil. >>>> >>>>> On Dec 6, 2019, at 2:33 PM, Alexander Matveev wrote: >>>>> >>>>> Looks good, but is there better way to exclude tests on Solaris? I do not like idea adding @requires for all tests. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>>> On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: >>>>>> Looks good. >>>>>> >>>>>> - Alexey >>>>>> >>>>>>> On 12/6/2019 1:33 PM, Andy Herrick wrote: >>>>>>> Please review this jpackager test fix for bug [1] at [2]. >>>>>>> >>>>>>> the fix adds "@requires (os.family == "linux") | (os.family == "mac") | (os.family == "windows")" to all jpackage tests that were not already filtered with "@requires (os.family == "XXX")" >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >>>>>>> >>>>>>> [2] http://cr.openjdk.java.net/~herrick/8235453/ >>>>>>> >>>>>>> /Andy >>>>>>> > From igor.ignatyev at oracle.com Sat Dec 7 21:47:06 2019 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Sat, 7 Dec 2019 13:47:06 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <8BA5C013-32FC-415D-BD3A-A0D15B6D993B@oracle.com> References: <8BA5C013-32FC-415D-BD3A-A0D15B6D993B@oracle.com> Message-ID: <565272E3-3AB4-4798-A3AB-DE85677FD44A@oracle.com> As far as I can see only junit.java test is executed on Solaris and is the only one failing. jtreg uses @modules during test selection/filtering phase, so tests which have @modules A won?t be run on jdk which doesn?t have module A, hence it should be sufficient. If it?s not, we have a bug in jtreg. ? Igor > On Dec 7, 2019, at 1:43 PM, Phil Race wrote: > > ?All these tests specify this already so it doesn?t seem sufficient. > > -Phil. > >> On Dec 7, 2019, at 12:07 PM, Igor Ignatyev wrote: >> >> can we just add '@modules jdk.incubator.jpackage' to test/jdk/tools/jpackage/junit/junit.java to solve that? or some of the tests run by test/jdk/tools/jpackage/junit/junit.java don't need jdk.incubator.jpackage module? >> >> -- Igor >> >>>> On Dec 7, 2019, at 11:57 AM, Philip Race wrote: >>> >>> Yes, since only a (relatively) small number of tests needed to be updated >>> this is fine with me at least for now. So +1 >>> >>> -phil. >>> >>>> On 12/7/19, 5:48 AM, Andy Herrick wrote: >>>> Phil - are you approving this change ? - I think you are the only registered Reviewer. >>>> >>>> /Andy >>>> >>>>> On 12/6/2019 8:11 PM, Phil Race wrote: >>>>> Well we could deprecate and remove the solaris port :-) >>>>> But until that is done this is the only way I know of. >>>>> we could require all jpackage tests to include some helper code which decides if it is applicable but that will be more work upfront and many jpackage tests are already platform specific so @requires is not going away. >>>>> >>>>> >>>>> -Phil. >>>>> >>>>>> On Dec 6, 2019, at 2:33 PM, Alexander Matveev wrote: >>>>>> >>>>>> Looks good, but is there better way to exclude tests on Solaris? I do not like idea adding @requires for all tests. >>>>>> >>>>>> Thanks, >>>>>> Alexander >>>>>> >>>>>>> On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: >>>>>>> Looks good. >>>>>>> >>>>>>> - Alexey >>>>>>> >>>>>>>> On 12/6/2019 1:33 PM, Andy Herrick wrote: >>>>>>>> Please review this jpackager test fix for bug [1] at [2]. >>>>>>>> >>>>>>>> the fix adds "@requires (os.family == "linux") | (os.family == "mac") | (os.family == "windows")" to all jpackage tests that were not already filtered with "@requires (os.family == "XXX")" >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >>>>>>>> >>>>>>>> [2] http://cr.openjdk.java.net/~herrick/8235453/ >>>>>>>> >>>>>>>> /Andy >>>>>>>> >> > From philip.race at oracle.com Sat Dec 7 22:53:25 2019 From: philip.race at oracle.com (Phil Race) Date: Sat, 7 Dec 2019 14:53:25 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <565272E3-3AB4-4798-A3AB-DE85677FD44A@oracle.com> References: <8BA5C013-32FC-415D-BD3A-A0D15B6D993B@oracle.com> <565272E3-3AB4-4798-A3AB-DE85677FD44A@oracle.com> Message-ID: <3d281ba5-5fa9-ac17-1eb5-578813886e07@oracle.com> Ok. That makes sense. I was under the impression other tests were failing. So only the one update is needed for this and it is arguably just an omission. jpackage has a couple of types of requirement 1) run only on platforms that support jpackage - the @modiules will do this. 2) run only on a subset of (1) - ie one or more specific platforms that support jpackage If the tests being updated are all of type (2) then the @requires platform may still be merited but probably that is not the case - it sounds like (1), so I think Andy should add what you suggest but I expect the @requires is harmless to leave in too ... -phil. On 12/7/19 1:47 PM, Igor Ignatev wrote: > As far as I can see only junit.java test is executed on Solaris and is the only one failing. jtreg uses @modules during test selection/filtering phase, so tests which have @modules A won?t be run on jdk which doesn?t have module A, hence it should be sufficient. If it?s not, we have a bug in jtreg. > > ? Igor > >> On Dec 7, 2019, at 1:43 PM, Phil Race wrote: >> >> ?All these tests specify this already so it doesn?t seem sufficient. >> >> -Phil. >> >>> On Dec 7, 2019, at 12:07 PM, Igor Ignatyev wrote: >>> >>> can we just add '@modules jdk.incubator.jpackage' to test/jdk/tools/jpackage/junit/junit.java to solve that? or some of the tests run by test/jdk/tools/jpackage/junit/junit.java don't need jdk.incubator.jpackage module? >>> >>> -- Igor >>> >>>>> On Dec 7, 2019, at 11:57 AM, Philip Race wrote: >>>> Yes, since only a (relatively) small number of tests needed to be updated >>>> this is fine with me at least for now. So +1 >>>> >>>> -phil. >>>> >>>>> On 12/7/19, 5:48 AM, Andy Herrick wrote: >>>>> Phil - are you approving this change ? - I think you are the only registered Reviewer. >>>>> >>>>> /Andy >>>>> >>>>>> On 12/6/2019 8:11 PM, Phil Race wrote: >>>>>> Well we could deprecate and remove the solaris port :-) >>>>>> But until that is done this is the only way I know of. >>>>>> we could require all jpackage tests to include some helper code which decides if it is applicable but that will be more work upfront and many jpackage tests are already platform specific so @requires is not going away. >>>>>> >>>>>> >>>>>> -Phil. >>>>>> >>>>>>> On Dec 6, 2019, at 2:33 PM, Alexander Matveev wrote: >>>>>>> >>>>>>> Looks good, but is there better way to exclude tests on Solaris? I do not like idea adding @requires for all tests. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexander >>>>>>> >>>>>>>> On 12/6/2019 10:35 AM, Alexey Semenyuk wrote: >>>>>>>> Looks good. >>>>>>>> >>>>>>>> - Alexey >>>>>>>> >>>>>>>>> On 12/6/2019 1:33 PM, Andy Herrick wrote: >>>>>>>>> Please review this jpackager test fix for bug [1] at [2]. >>>>>>>>> >>>>>>>>> the fix adds "@requires (os.family == "linux") | (os.family == "mac") | (os.family == "windows")" to all jpackage tests that were not already filtered with "@requires (os.family == "XXX")" >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >>>>>>>>> >>>>>>>>> [2] http://cr.openjdk.java.net/~herrick/8235453/ >>>>>>>>> >>>>>>>>> /Andy >>>>>>>>> From john.r.rose at oracle.com Sat Dec 7 23:29:40 2019 From: john.r.rose at oracle.com (John Rose) Date: Sat, 7 Dec 2019 15:29:40 -0800 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <5c1689c5-43bf-3b4a-50e9-7376097f3087@oracle.com> Message-ID: On Dec 5, 2019, at 2:39 PM, Vladimir Ivanov wrote: > > Regarding hotspot changes: > >> * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) > > New packages aren't part of java.base. Considering the implementation resides in an incubator module, is it enough to consider them as trusted and well-known to the JVM? Yes, I think we can get away with this. IIUC, the effect you are observing is that java.base trusts something outside of itself. This is not new, and is OK as long as the ?something? can?t be spoofed by an untrusted party. ? John From david.holmes at oracle.com Sun Dec 8 00:27:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 8 Dec 2019 10:27:51 +1000 Subject: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code" In-Reply-To: References: <4623455a-2d90-e697-89b3-830d5becf8f9@oracle.com> Message-ID: <7b3eb0e0-0711-68b9-7a5f-dbc22d50488d@oracle.com> Looks good! Thanks, David On 7/12/2019 11:34 pm, gerard ziemski wrote: > Hi all, > > Please review this revision 2 of a cleanup, where we remove > JDK_GetVersionInfo0 and related code, since we can get build versions > directly from within the VM itself. > > The rev2 differs from rev1 in that it's simpler due to JDK-8234185, > which was just checked in yesterday. Waiting for this fix to go in > first, allowed us not to have to delete the jdk_util.h file, which in > turn means that we don't have to touch all those files that used that > include. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8223261 > webrev: http://cr.openjdk.java.net/~gziemski/8223261_rev2 > tests: passes Mach5 tier1,2,3 (another tier1,2,3,4,5,6 in progress...) > > > cheers > From maurizio.cimadamore at oracle.com Sun Dec 8 01:44:56 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 8 Dec 2019 01:44:56 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> Message-ID: <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> Another update: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3/ And a delta of the changes since last version (v2) here: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3_delta/ The javadoc has been updated inline here: http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html Summary of changes: * fixed some (cosmetic) issues in FileChannelmpl following offline discussion with Alan * changed tests group definition, so that now jdk_foreign is part of tier1_part3 * updated javadoc in various places to fix code samples (as per Paul comments) * updated javadoc in MemoryHandles to talk about access modes (as per Paul comments) - I added a new section on top, and then referred to in from all relevant places * some changes to use Objects.hash (as per Paul comments), and some minor refactor in the AddreddGenerator (to use switch expression) * tightened javadoc for MemoryAddress::copy - the method now is specified to throw IAE if the range of source/dest addresses overlap - I've fixed the impl and added a test (as per Raffaello comments) * tightened byte buffer VarHandle view - if the view is created from a byte buffer obtained from a segment (!!!) we should do a segment check - added tests And here's a list of the pending API-related issues. Since these are IMHO minor issues, I suggest we defer them to a followup minor cleanup, so that we can move ahead with finalization of the CSR with the current API. Here's the list: * Should MemoryAddress implement Comparable? I think the answer is "probably not" - an address doesn't have a 'length' so you can't really do a range comparison (maybe memory segments though?). For now, users can project to byte buffer and take it from there (since ByteBuffer <: Comparable) * should we have a? way to ask a Layout if its size is specified ? (Paul) * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much distance between these two semantically different operations (Paul suggested using 'add' - which I'm not enthusiastic about because it's not adding two addresses - it's adding a long to an address...) * MemorySegment::isAccessible() -- as the A* word is overloaded, some other name should be found? * MemorySegment::acquire() -- replace with MemorySegment::fork? Thanks Maurizio On 06/12/2019 10:43, Maurizio Cimadamore wrote: > Hi, > here's an updated version of the patch: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ > > And a delta of the changes since last version here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ > > The javadoc has been updated inline here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Summary of changes: > > * fixed spurious protected methods in AbstractLayout and subclasses > which leaked into API > * removed library_call.cpp changes, as these are being tracked > separately by Vlad > * compacted ILOAD code in AddressVarHandleGenerator > * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope > > I have made no changes to the *name* of the methods in the API. In > fact, I suggest we keep a list of the names we'd like to revisit, and > we address them all at once at the end of the review (once we're happy > with the contents). Here's a list of the current open naming issues: > > * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much > distance between these two semantically different operations > * MemorySegment::isAccessible() -- as the A* word is overloaded, some > other name should be found? > * MemorySegment::acquire() -- replace with MemorySegment::fork? > > Cheers > Maurizio > > > On 05/12/2019 21:04, Maurizio Cimadamore wrote: >> Hi, >> as part of the effort to upstream the changes related to JEP 370 >> (foreign memory access API) [1], I'd like to ask for a code review >> for the corresponding core-libs and hotspot changes: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >> >> A javadoc for the memory access API is also available here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Note: the patch passes tier1, tier2 and tier3 testing (**) >> >> >> Here is a brief summary of the changes in java.base and hotspot (the >> remaining new files are implementation classes and tests for the new >> API): >> >> * ciField.cpp - this one is to trust final fields in the foreign >> memory access implementation (otherwise VM doesn't trust memory >> segment bounds) >> >> * Modules.gmk - these changes are needed to require that the >> incubating module is loaded by the boot loader (otherwise the above >> changes are useless) >> >> * library_call.cpp - this one is a JIT compiler change to treat >> Thread.currentThread() as a well-known constant - which helps a lot >> in the confinement checks (thanks Vlad!) >> >> * various Buffer-related changes; these changes are needed because >> the memory access API allows a memory segment to be projected into a >> byte buffer, for interop reasons. As such, we need to insert a >> liveness check in the various get/put methods. Previously we had an >> implementation strategy where a BB was 'decorated' by a subclass >> called ScopedBuffer - but doing so required some changes to the BB >> API (e.g. making certain methods non-final, so that we could decorate >> them). Here I use an approach (which I have discussed with Alan) >> which doesn't require any public API changes, but needs to add a >> 'segment' field in Buffer - and then have constructors which keep >> track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can >> reuse the Unmapper class from the MemorySegment implementation, to >> deterministically deallocate a mapped memory segment. This should be >> a 'straight' refactoring, no change in behavior should occur here. >> Please double check. >> >> * VarHandles - this class now provides a factory to create memory >> access VarHandle - this is a bit tricky, since VarHandle cannot >> really be implemented outside java.base (e.g. VarForm is not public). >> So we do the usual trick where we define a bunch of proxy interfaces >> (see jdk/internal/access/foreign) have the classes in java.base refer >> to these - and then have the implementation classes of the memory >> access API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >> to provide access to otherwise hidden functionalities - e.g. creating >> a new scoped buffer, or retrieving the properties of a memory access >> handle (e.g. offset, stride etc.), so that we can implement the >> memory access API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the >> generation of the new memory address var handle implementations; >> there's an helper class per carrier (e.g. >> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >> var handle is needed, we dynamically spin a new VH implementation >> which makes use of the right carrier. We need to spin because the VH >> can have a variable number of access coordinates (e.g. depending on >> the dimensions of the array to be accessed). But, under the hood, all >> the generated implementation will be using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all >> possible permutations of carriers/dimensions etc. Because of that, >> the tests might not be the easiest to look at, but they have proven >> to be pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where >> it differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is >> MemoryAddress has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same >> name but do something quite different (one is an accessor, another is >> a 'wither'). one obvious option is to rename the first to >> 'withOffset'. But I think that would lead to verbose code (since that >> is a very common operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice >> which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >> Stuart, Roger, Joe and the Panama team for the feedback provided so >> far, which helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >> but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >> From ksrinifmt at gmail.com Sun Dec 8 03:27:52 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Sat, 7 Dec 2019 19:27:52 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> Message-ID: Hi, The launcher fix looks good, despite the launcher fix being simple, please note, it sometimes requires a lot more effort to write a test for it, please read on.... Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my memory and I recalled this change for VM's native memory tracking. http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/37d1442d53bc/test/tools/launcher/TestSpecialArgs.java#l243 Inspecting the above changeset, we might have to add another test for JVM native memory tracking, since this is a terminal argument. Maybe TestHelper could create a simple module, which prints its args, http://hg.openjdk.java.net/jdk/jdk/file/31882abe1494/test/jdk/tools/launcher/TestHelper.java Kumar Srinivasan On Fri, Dec 6, 2019 at 2:44 PM Henry Jen wrote: > Thanks for the work, the test case covers that when ?module= is used > before other options, which is good. > > But we need another to make sure that when ?module= is put in an argument > file or environment variable, that should not be allowed. The fix is > simple, we need to add that to isTerminalOp() method. > > Cheers, > Henry > > > On Dec 6, 2019, at 12:28 PM, Nikola Grcevski < > Nikola.Grcevski at microsoft.com> wrote: > > > > Thank you Henry! > > > > I have modified the fix in checkArg to use JLI_StrCCmp as suggested > below and I have extended the BasicTest.java (in > test/jdk/tools/launcher/modules/basic) with few additional tests. > > > > I don't have author status yet, therefore I'm attaching the patch right > after my signature. I also updated my external webrev if that's easier to > review (https://grcevski.github.io/JDK-8234076/webrev/) > > > > Thanks again to everyone for your help with this bug. If there are any > additional comments or suggestions please let me know. > > Nikola > > > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -130,6 +130,8 @@ > > } > > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > > stopExpansion = JNI_TRUE; > > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > > + idx = argsCount; > > } > > } else { > > if (!expectingNoDashArg) { > > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -34,6 +34,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include "java.h" > > @@ -1015,6 +1016,17 @@ > > > > // sanity check, match the args we have, to the holy grail > > idx = JLI_GetAppArgIndex(); > > + > > + // First arg index is NOT_FOUND > > + if (idx < 0) { > > + // The only allowed value should be NOT_FOUND (-1) unless > another change introduces > > + // a different negative index > > + assert (idx == -1); > > + JLI_TraceLauncher("Warning: first app arg index not found, > %d\n", idx); > > + JLI_TraceLauncher("passing arguments as-is.\n"); > > + return NewPlatformStringArray(env, strv, argc); > > + } > > + > > isTool = (idx == 0); > > if (isTool) { idx++; } // skip tool name > > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, > stdargs[idx].arg); > > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -29,6 +29,7 @@ > > * jdk.jlink > > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > > * @run testng BasicTest > > + * @bug 8234076 > > * @summary Basic test of starting an application as a module > > */ > > > > @@ -40,6 +41,8 @@ > > > > import jdk.test.lib.compiler.CompilerUtils; > > import jdk.test.lib.process.ProcessTools; > > +import jdk.test.lib.process.OutputAnalyzer; > > +import jdk.test.lib.Utils; > > > > import org.testng.annotations.BeforeTest; > > import org.testng.annotations.Test; > > @@ -70,6 +73,8 @@ > > // the module main class > > private static final String MAIN_CLASS = "jdk.test.Main"; > > > > + // for Windows specific launcher tests > > + static final boolean IS_WINDOWS = System.getProperty("os.name", > "unknown").startsWith("Windows"); > > > > @BeforeTest > > public void compileTestModule() throws Exception { > > @@ -259,4 +264,87 @@ > > assertTrue(exitValue != 0); > > } > > > > + > > + /** > > + * Helper method that creates a ProcessBuilder with command line > arguments > > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > > + */ > > + private ProcessBuilder createProcessWithLauncherDebugging(String... > cmds) { > > + ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > > + > > + return pb; > > + } > > + > > + /** > > + * Test the ability for the Windows launcher to do proper > application argument > > + * detection and expansion, when using the long form module option > and all passed in > > + * command line arguments are prefixed with a dash. > > + * > > + * These tests are not expected to work on *nixes, and are ignored. > > + */ > > + public void testWindowsWithLongFormModuleOption() throws Exception { > > + if (!IS_WINDOWS) { > > + return; > > + } > > + > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --help > > + // We should be able to find the argument --help as an > application argument > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help"); > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > <...src/test>/*.java --help > > + // We should be able to see argument expansion happen > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help") > > + .shouldContain("module-info.java"); > > + } > > + > > + > > + /** > > + * Test that --module= is terminating for VM argument processing > just like --module > > + */ > > + public void testLongFormModuleOptionTermination() throws Exception { > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --module-path=mods --module=$TESTMODULE/$MAINCLASS > > + // The first --module= will terminate the VM arguments > processing. The second pair of module-path and module will be > > + // deemed as application arguments > > + OutputAnalyzer output = ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--module-path=" + dir, > > + "--module=" + mid)) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("argv[ 0] = '--module-path=" + dir) > > + .shouldContain("argv[ 1] = '--module=" + mid); > > + > > + if (IS_WINDOWS) { > > + output.shouldContain("F--module-path=" + > dir).shouldContain("F--module=" + mid); > > + } > > + > > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > > + // This command line will not work as --module= is terminating > and the module will be not found > > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > > + assertTrue(exitValue != 0); > > + } > > } > > > > > > -----Original Message----- > > From: Henry Jen > > Sent: December 6, 2019 12:03 AM > > To: Nikola Grcevski > > Cc: Kumar Srinivasan ; Alan Bateman < > Alan.Bateman at oracle.com>; core-libs-dev at openjdk.java.net > > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > > > > >> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski < > Nikola.Grcevski at microsoft.com> wrote: > >> > >> Hello all again! > >> > >> Based on the suggestion by Kumar I made the following small patch to > checkArg src/java.base/share/native/libjli/args.c: > >> > >> --- a/src/java.base/share/native/libjli/args.c > >> +++ b/src/java.base/share/native/libjli/args.c > >> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { > >> } > >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > >> stopExpansion = JNI_TRUE; > >> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { > > > > I would suggest use JLI_StrCCmp as in java.c. I think combine this fix > with origin crash prevention for -1 is a safe approach and most compatible > to current behavior. > > > > BTW, we need the patch to be hosted on cr.openjdk.java.net or you can > attach the patch to the review thread if you are not yet an author. > > > > Cheers, > > Henry > > > > > >> + idx = argsCount; > >> } > >> } else { > >> if (!expectingNoDashArg) { > >> > >> The change is in common code and simply checks for the usage of > --module= and deems the next argument as the start of the application > arguments. I can confirm that using -m instead of --module doesn't allow > for the = separator to be used, so we only need to check for --module= if > this is a desired change. > >> > >> I tested with various combinations on the command line and I couldn't > find a set of arguments ordering that breaks the terminating quality of > --module. > >> > >> I also performed series of tests to try to break the argument expansion > on Windows with this change, but it worked in all instances. The testcase > is working correctly with this change, as well as the javac launcher > command as proposed by Kumar (java --module-path=mods > --module=jdk.compiler/com.sun.tools.javac.Main *.java). > >> > >> I ran all the launcher tests on both Windows and Linux and all tests > pass. > >> > >> Please let me know if this is a preferred approach to address this bug > or if you think there's a potential problem with the change. If this is an > acceptable fix I can create new webrev with set of tests for the various > edge cases I tried, and new launcher specific tests that ensure argument > expansion is performed on Windows with this module usage. > >> > >> Thank you, > >> Nikola > >> > >> -----Original Message----- > >> From: Henry Jen > >> Sent: December 4, 2019 8:26 PM > >> To: Kumar Srinivasan ; Alan Bateman > >> ; Nikola Grcevski > >> > >> Cc: core-libs-dev at openjdk.java.net > >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >> > >>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan > wrote: > >>> > >>> Hi Nikola, > >>> > >>> It looks ok to me, I will leave it to Henry and Alan to bless this. > >>> > >>> IMHO: I think we should fix it correctly now than later, I don't > >>> think it is all that difficult AFAICT all the launcher has to do is > >>> identify "--module==", then the next argument is the first index. > >>> > >> > >> I don?t disagree, if we can decide whether ?module= is allowed. Based > on my understanding and the document for java[1], the ?module= is not > necessarily correct. > >> > >> If we decided to accept it, the fix would be make sure the index set > correctly as Kumar suggested, and the fix can be relatively simple. > >> > >> FWIW, it?s still possible the index is NOT_FOUND if there is no main > class specified, but that should never cause crash as if no main class is > found, the launcher should either execute other terminal argument or > display help. > >> > >> I agree the fix is not complete as it only make sure no crash can > happen. It doesn?t actually make ?module= illegal and show help in case of > that. At this point, there is a discrepancy in launcher code regard ?module > usage, and we need to fix that. > >> > >> I?ll let Alan to comment about the ?module option usage. > >> > >> The webrev looks good to me, although I would like to see the test be > more close to other arguments processing test, but since this can only be > reproduced with ?module= usage, I assume this is not bad. > >> > >> [1] > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > >> .oracle.com%2Fen%2Fjava%2Fjavase%2F13%2Fdocs%2Fspecs%2Fman%2Fjava.html > >> &data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C37e38c582bac4687 > >> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 > >> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY > >> %3D&reserved=0 > >> > >>> Kumar > >>> > >>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski < > Nikola.Grcevski at microsoft.com> wrote: > >>> Hi Henry and Kumar, > >>> > >>> Thanks again for your comments! I have updated the test to be part of > test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve > the same amount of testing. I added a new test method inside BasicTest.java > and tested on both Windows and Linux. > >>> > >>> Please find my updated webrev here for your review: > >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc > >>> e > >>> vski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Gr > >>> c > >>> evski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86 > >>> f > >>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ > >>> % > >>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>> > >>> Cheers, > >>> > >>> Nikola > >>> > >>> -----Original Message----- > >>> From: Henry Jen > >>> Sent: December 3, 2019 11:39 AM > >>> To: Kumar Srinivasan > >>> Cc: Nikola Grcevski ; Alan Bateman > >>> ; core-libs-dev at openjdk.java.net > >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >>> > >>> Kumar, > >>> > >>> Great to have you look at this, you are correct, this patch doesn?t > address the wildcard expansion issue, but only to address the potential > crash if a main class is not specified as Nikola pointed out. > >>> > >>> We definitely need a follow up to fix wildcard expansion. The pointer > to simplify the test is helpful, it would make the test more obvious. > >>> > >>> Cheers, > >>> Henry > >>> > >>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan > wrote: > >>>> > >>>> Hi, > >>>> > >>>> Sorry for chiming in late in the review process, for what it's > worth.... > >>>> > >>>> 1. It is not at all clear to me if this solution is correct, yes it > averts the problem of not finding the main-class > >>>> and subsequent crash, but it does not address wildcard arguments > expansion. > >>>> > >>>> What if we have > >>>> % java --module-path=mods > --module=jdk.compiler/com.sun.tools.javac.Main *.java > >>>> Where jdk.compiler is a java compiler implementation (javac). > >>>> The user would expect the above compiler module to build all the > .java files in that directory, > >>>> and this fix will not address that. > >>>> > >>>> Some background: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > >>>> gs.openjdk.java.net%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola > >>>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b > >>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 > >>>> Please see all the related bugs in the above JIRA issue. > >>>> > >>>> Paragraph #6 in this interview surmises the wild card behavior on > Windows: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. > >>>> princeton.edu%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=0 > >>>> 2%7C01%7CNikola.Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d77 > >>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 > >>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& > >>>> ;reserved=0 > >>>> > >>>> 2. Though the arguments related tests are in Aaarghs.java the modules > related tests for the launcher are at: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg > >>>> .openjdk.java.net%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2 > >>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs > >>>> ki%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f1 > >>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE > >>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 > >>>> Using the modules test framework may make the test simpler. > >>>> > >>>> Kumar Srinivasan > >>>> > >>>> > >>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski < > Nikola.Grcevski at microsoft.com> wrote: > >>>> Hi Alan and Henry, > >>>> > >>>> Thank you for reviewing my email! Henry's observation matches mine, > the shared common code for all platforms in checkArg > (src/java.base/share/native/libjli/args.c) can potentially leave the > firstAppArgIndex static set to -1, if all passed command line arguments are > prefixed with a dash. Later on the arguments are validated, however we > might crash before then on Windows because of the negative index access. In > this case, the customer command was valid (modules usage) and the program > runs successfully. > >>>> > >>>> I created a webrev here for the change, including a new test in > Arrrghs.java: > >>>> > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr > >>>> cevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola > >>>> .Grcevski%40microsoft.com%7C6158f8460dcd4c39518708d7792228c5%7C72f98 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e > >>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>>> > >>>> I copied the test validation and assertion style of other code inside > the test class. > >>>> > >>>> Please let me know if you have any comments or suggestions. > >>>> > >>>> Thanks again! > >>>> > >>>> -----Original Message----- > >>>> From: Henry Jen > >>>> Sent: December 2, 2019 12:26 PM > >>>> To: Alan Bateman > >>>> Cc: Nikola Grcevski ; > >>>> core-libs-dev at openjdk.java.net > >>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > >>>> > >>>> The fix looks reasonable to me, basically, if the command argument > format is not legal, it?s possible we won?t find the main class when doing > argument file expansion, and the index is -1 which could cause crash on > Windows platform for the wildcard processing. > >>>> > >>>> I think we should add a test case for this, probably in > test/jdk/tools/launcher/Arrrghs.java. > >>>> > >>>> As I understand it, the argument validation is done in a later stage > after calling JLI_Launch. > >>>> > >>>> Cheers, > >>>> Henry > >>>> > >>>> > >>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman > wrote: > >>>>> > >>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: > >>>>>> : > >>>>>> > >>>>>> Please let me know if this approach is acceptable for the current > bug report and I'll make a webrev and include appropriate launcher tests. I > was thinking the tests should do extra validation on the output from > _JAVA_LAUNCHER_DEBUG on Windows. > >>>>>> > >>>>> I think you're in the right area but I would have expected the arg > index to 0 here. Henry Jen (cc'ed) might have some comments on this. > >>>>> > >>>>> -Alan > > From daniel.fuchs at oracle.com Sun Dec 8 10:48:35 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sun, 8 Dec 2019 10:48:35 +0000 Subject: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed In-Reply-To: References: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> <0a09885f-dd8b-13e7-f042-752ce77b4cc7@oracle.com> Message-ID: Hi Vyom, On 07/12/2019 03:36, Vyom Tiwari wrote: > Changes looks OK to me, one minor bit you? need to update @bug? tag > before pushing. We don't update @bug for test bugs (when the fix is in the the test itself). best regards, -- daniel From vyommani at gmail.com Sun Dec 8 11:34:24 2019 From: vyommani at gmail.com (Vyom Tiwari) Date: Sun, 8 Dec 2019 17:04:24 +0530 Subject: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed In-Reply-To: References: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> <0a09885f-dd8b-13e7-f042-752ce77b4cc7@oracle.com> Message-ID: Hi Daniel, Ok, thanks for the update. Vyom On Sun, Dec 8, 2019 at 4:19 PM Daniel Fuchs wrote: > Hi Vyom, > > On 07/12/2019 03:36, Vyom Tiwari wrote: > > Changes looks OK to me, one minor bit you need to update @bug tag > > before pushing. > > We don't update @bug for test bugs (when the fix is in the > the test itself). > > best regards, > > -- daniel > -- Thanks, Vyom From joe.darcy at oracle.com Sun Dec 8 18:58:32 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 8 Dec 2019 10:58:32 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base Message-ID: Hello, Please review this small API changes for JDK 15: ??? JDK-8230771: Remove terminally deprecated constructors in java.base ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ Patch below. Thanks, -Joe --- old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java 2019-12-08 10:56:14.223168685 -0800 +++ new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java 2019-12-08 10:56:13.999168685 -0800 @@ -40,12 +40,6 @@ ? * @since 11 ? */ ?public final class ConstantBootstraps { -??? /** -???? * Do not call. -???? */ -??? @Deprecated(forRemoval=true, since="14") -??? public ConstantBootstraps() {} - ???? // implements the upcall from the JVM, MethodHandleNatives.linkDynamicConstant: ???? /*non-public*/ ???? static Object makeConstant(MethodHandle bootstrapMethod, --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-12-08 10:56:14.775168685 -0800 +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-12-08 10:56:14.555168685 -0800 @@ -44,13 +44,6 @@ ? */ ?public class Modifier { ???? /** -???? * Do not call. -???? */ -??? @Deprecated(forRemoval=true, since="14") -??? public Modifier() {} - - -??? /** ????? * Return {@code true} if the integer argument includes the ????? * {@code public} modifier, {@code false} otherwise. ????? * From lance.andersen at oracle.com Sun Dec 8 19:23:14 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 8 Dec 2019 14:23:14 -0500 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: References: Message-ID: <4F2167C0-28DE-48E8-A154-771B5ED868BA@oracle.com> +1 > On Dec 8, 2019, at 1:58 PM, Joe Darcy wrote: > > Hello, > > Please review this small API changes for JDK 15: > > JDK-8230771: Remove terminally deprecated constructors in java.base > CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 > webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java 2019-12-08 10:56:14.223168685 -0800 > +++ new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java 2019-12-08 10:56:13.999168685 -0800 > @@ -40,12 +40,6 @@ > * @since 11 > */ > public final class ConstantBootstraps { > - /** > - * Do not call. > - */ > - @Deprecated(forRemoval=true, since="14") > - public ConstantBootstraps() {} > - > // implements the upcall from the JVM, MethodHandleNatives.linkDynamicConstant: > /*non-public*/ > static Object makeConstant(MethodHandle bootstrapMethod, > --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-12-08 10:56:14.775168685 -0800 > +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java 2019-12-08 10:56:14.555168685 -0800 > @@ -44,13 +44,6 @@ > */ > public class Modifier { > /** > - * Do not call. > - */ > - @Deprecated(forRemoval=true, since="14") > - public Modifier() {} > - > - > - /** > * Return {@code true} if the integer argument includes the > * {@code public} modifier, {@code false} otherwise. > * > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Sun Dec 8 20:31:44 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 8 Dec 2019 20:31:44 +0000 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: References: Message-ID: > On 8 Dec 2019, at 18:58, Joe Darcy wrote: > > Hello, > > Please review this small API changes for JDK 15: > > JDK-8230771: Remove terminally deprecated constructors in java.base > CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 > webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ LGTM. -Chris. From chris.hegarty at oracle.com Sun Dec 8 20:33:09 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 8 Dec 2019 20:33:09 +0000 Subject: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed In-Reply-To: References: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> <0a09885f-dd8b-13e7-f042-752ce77b4cc7@oracle.com> Message-ID: <6776002F-BE14-4531-AC6F-9BD0DE34D5DE@oracle.com> > On 8 Dec 2019, at 10:48, Daniel Fuchs wrote: > > Hi Vyom, > > On 07/12/2019 03:36, Vyom Tiwari wrote: >> Changes looks OK to me, one minor bit you need to update @bug tag before pushing. > > We don't update @bug for test bugs (when the fix is in the > the test itself). Correct. Doing so would add no real value. -Chris. From raffaello.giulietti at gmail.com Mon Dec 9 10:11:16 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 9 Dec 2019 11:11:16 +0100 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: Message-ID: Hi, will there be a MemoryAddress.move(MemoryAddress src, MemoryAddress dst, long bytes) method with POSIX memmove(3) semantics at some point? That would be useful, e.g., to "open a hole" into an array by shifting existing elements towards higher indices (provided there's room). MemoryAddress.copy(), with its lower-to-higher semantics, doesn't really help here, so without move() one would need to code an explicit loop for such a case, I guess. Not a big deal, just a little bit annoying. Greetings Raffaello On 2019-12-07 00:51, Maurizio Cimadamore wrote: > > On 06/12/2019 18:29, Raffaello Giulietti wrote: >> Hello, >> >> great job! >> >> I think that the doc of MemoryAddress.copy() should be explicit about >> the direction of the copying, so it should either: > > Thanks! -? I'll rectify the doc to specify lower-to-higher. > > Maurizio > >> >> * explicitly specify a direction, e.g., lower-to-higher addresses >> >> * or specify that in the case of an overlap the copying is smart >> enough to not destroy the src bytes before they have landed in dst >> >> * or accept a negative third argument to encode a higher-to-lower >> addresses copying direction. >> >> >> Greetings >> Raffaello >> >> >> >>> Hi, >>> as part of the effort to upstream the changes related to JEP 370 >>> (foreign memory access API) [1], I'd like to ask for a code review >>> for the corresponding core-libs and hotspot changes: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>> >>> A javadoc for the memory access API is also available here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>> >>> >>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>> >>> >>> Here is a brief summary of the changes in java.base and hotspot (the >>> remaining new files are implementation classes and tests for the new >>> API): >>> >>> * ciField.cpp - this one is to trust final fields in the foreign >>> memory access implementation (otherwise VM doesn't trust memory >>> segment bounds) >>> >>> * Modules.gmk - these changes are needed to require that the >>> incubating module is loaded by the boot loader (otherwise the above >>> changes are useless) >>> >>> * library_call.cpp - this one is a JIT compiler change to treat >>> Thread.currentThread() as a well-known constant - which helps a lot >>> in the confinement checks (thanks Vlad!) >>> >>> * various Buffer-related changes; these changes are needed because >>> the memory access API allows a memory segment to be projected into a >>> byte buffer, for interop reasons. As such, we need to insert a >>> liveness check in the various get/put methods. Previously we had an >>> implementation strategy where a BB was 'decorated' by a subclass >>> called ScopedBuffer - but doing so required some changes to the BB >>> API (e.g. making certain methods non-final, so that we could decorate >>> them). Here I use an approach (which I have discussed with Alan) >>> which doesn't require any public API? changes, but needs to add a >>> 'segment' field in Buffer - and then have constructors which keep >>> track of this extra parameter. >>> >>> * FileChannel changes - these changes are required so that we can >>> reuse the Unmapper class from the MemorySegment implementation, to >>> deterministically deallocate a mapped memory segment. This should be >>> a 'straight' refactoring, no change in behavior should occur here. >>> Please double check. >>> >>> * VarHandles - this class now provides a factory to create memory >>> access VarHandle - this is a bit tricky, since VarHandle cannot >>> really be implemented outside java.base (e.g. VarForm is not public). >>> So we do the usual trick where we define a bunch of proxy interfaces >>> (see jdk/internal/access/foreign) have the classes in java.base refer >>> to these - and then have the implementation classes of the memory >>> access API implement these interfaces. >>> >>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >>> to provide access to otherwise hidden functionalities - e.g. creating >>> a new scoped buffer, or retrieving the properties of a memory access >>> handle (e.g. offset, stride etc.), so that we can implement the >>> memory access API in its own separate module >>> >>> * GensrcVarHandles.gmk - these changes are needed to enable the >>> generation of the new memory address var handle implementations; >>> there's an helper class per carrier (e.g. >>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >>> var handle is needed, we dynamically spin a new VH implementation >>> which makes use of the right carrier. We need to spin because the VH >>> can have a variable number of access coordinates (e.g. depending on >>> the dimensions of the array to be accessed). But, under the hood, all >>> the generated implementation will be using the same helper class. >>> >>> * tests - we've tried to add fairly robust tests, often checking all >>> possible permutations of carriers/dimensions etc. Because of that, >>> the tests might not be the easiest to look at, but they have proven >>> to be pretty effective at shaking out issues. >>> >>> I think that covers the main aspects of the implementation and where >>> it differs from vanilla JDK. >>> >>> P.S. >>> >>> In the CSR review [2], Joe raised a fair point - which is >>> MemoryAddress has both: >>> >>> offset(long) --> move address of given offset >>> offset() --> return the offset of this address in its owning segment >>> >>> And this was considered suboptimal, given both methods use the same >>> name but do something quite different (one is an accessor, another is >>> a 'wither'). one obvious option is to rename the first to >>> 'withOffset'. But I think that would lead to verbose code (since that >>> is a very common operation). Other options are to: >>> >>> * rename offset(long) to move(long), advance(long), or something else >>> * drop offset() - but then add an overload of MemorySegment::asSlice >>> which takes an address instead of a plain long offset >>> >>> I'll leave the choice to the reviewers :-) >>> >>> >>> >>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>> Stuart, Roger, Joe and the Panama team for the feedback provided so >>> far, which helped to get the API in the shape it is today. >>> >>> Cheers >>> Maurizio >>> >>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >>> but that is unrelated to this patch, and it's a known failing test. >>> >>> [1] - https://openjdk.java.net/jeps/370 >>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >> >> From maurizio.cimadamore at oracle.com Mon Dec 9 11:10:32 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Dec 2019 11:10:32 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: Message-ID: Hi Raffaello, I think there is room to add more copy-related features in the future. One thing to note, however: the rationale behind having a 'copy' method is to expose a (safe) interface to the underlying Unsafe::copyMemory method - which is an hotspot intrinsic, hence understood and optimized by the JIT compiler. I'd say that, if we were to add another method like 'memmove' we'd have to work out the VM plumbing first - and then add the MemoryAddress API method. This has been the informal guiding principle for the operations exposed by this API. That said - I'll keep a note of the suggestion, and add it to the list. Cheers Maurizio On 09/12/2019 10:11, Raffaello Giulietti wrote: > Hi, > > will there be a > > MemoryAddress.move(MemoryAddress src, MemoryAddress dst, long bytes) > > method with POSIX memmove(3) semantics at some point? > > That would be useful, e.g., to "open a hole" into an array by shifting > existing elements towards higher indices (provided there's room). > > MemoryAddress.copy(), with its lower-to-higher semantics, doesn't > really help here, so without move() one would need to code an explicit > loop for such a case, I guess. Not a big deal, just a little bit > annoying. > > > Greetings > Raffaello > > > > On 2019-12-07 00:51, Maurizio Cimadamore wrote: >> >> On 06/12/2019 18:29, Raffaello Giulietti wrote: >>> Hello, >>> >>> great job! >>> >>> I think that the doc of MemoryAddress.copy() should be explicit >>> about the direction of the copying, so it should either: >> >> Thanks! -? I'll rectify the doc to specify lower-to-higher. >> >> Maurizio >> >>> >>> * explicitly specify a direction, e.g., lower-to-higher addresses >>> >>> * or specify that in the case of an overlap the copying is smart >>> enough to not destroy the src bytes before they have landed in dst >>> >>> * or accept a negative third argument to encode a higher-to-lower >>> addresses copying direction. >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>>> Hi, >>>> as part of the effort to upstream the changes related to JEP 370 >>>> (foreign memory access API) [1], I'd like to ask for a code review >>>> for the corresponding core-libs and hotspot changes: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>>> >>>> A javadoc for the memory access API is also available here: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>>> >>>> >>>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>>> >>>> >>>> Here is a brief summary of the changes in java.base and hotspot >>>> (the remaining new files are implementation classes and tests for >>>> the new API): >>>> >>>> * ciField.cpp - this one is to trust final fields in the foreign >>>> memory access implementation (otherwise VM doesn't trust memory >>>> segment bounds) >>>> >>>> * Modules.gmk - these changes are needed to require that the >>>> incubating module is loaded by the boot loader (otherwise the above >>>> changes are useless) >>>> >>>> * library_call.cpp - this one is a JIT compiler change to treat >>>> Thread.currentThread() as a well-known constant - which helps a lot >>>> in the confinement checks (thanks Vlad!) >>>> >>>> * various Buffer-related changes; these changes are needed because >>>> the memory access API allows a memory segment to be projected into >>>> a byte buffer, for interop reasons. As such, we need to insert a >>>> liveness check in the various get/put methods. Previously we had an >>>> implementation strategy where a BB was 'decorated' by a subclass >>>> called ScopedBuffer - but doing so required some changes to the BB >>>> API (e.g. making certain methods non-final, so that we could >>>> decorate them). Here I use an approach (which I have discussed with >>>> Alan) which doesn't require any public API? changes, but needs to >>>> add a 'segment' field in Buffer - and then have constructors which >>>> keep track of this extra parameter. >>>> >>>> * FileChannel changes - these changes are required so that we can >>>> reuse the Unmapper class from the MemorySegment implementation, to >>>> deterministically deallocate a mapped memory segment. This should >>>> be a 'straight' refactoring, no change in behavior should occur >>>> here. Please double check. >>>> >>>> * VarHandles - this class now provides a factory to create memory >>>> access VarHandle - this is a bit tricky, since VarHandle cannot >>>> really be implemented outside java.base (e.g. VarForm is not >>>> public). So we do the usual trick where we define a bunch of proxy >>>> interfaces (see jdk/internal/access/foreign) have the classes in >>>> java.base refer to these - and then have the implementation classes >>>> of the memory access API implement these interfaces. >>>> >>>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we >>>> need to provide access to otherwise hidden functionalities - e.g. >>>> creating a new scoped buffer, or retrieving the properties of a >>>> memory access handle (e.g. offset, stride etc.), so that we can >>>> implement the memory access API in its own separate module >>>> >>>> * GensrcVarHandles.gmk - these changes are needed to enable the >>>> generation of the new memory address var handle implementations; >>>> there's an helper class per carrier (e.g. >>>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory >>>> access var handle is needed, we dynamically spin a new VH >>>> implementation which makes use of the right carrier. We need to >>>> spin because the VH can have a variable number of access >>>> coordinates (e.g. depending on the dimensions of the array to be >>>> accessed). But, under the hood, all the generated implementation >>>> will be using the same helper class. >>>> >>>> * tests - we've tried to add fairly robust tests, often checking >>>> all possible permutations of carriers/dimensions etc. Because of >>>> that, the tests might not be the easiest to look at, but they have >>>> proven to be pretty effective at shaking out issues. >>>> >>>> I think that covers the main aspects of the implementation and >>>> where it differs from vanilla JDK. >>>> >>>> P.S. >>>> >>>> In the CSR review [2], Joe raised a fair point - which is >>>> MemoryAddress has both: >>>> >>>> offset(long) --> move address of given offset >>>> offset() --> return the offset of this address in its owning segment >>>> >>>> And this was considered suboptimal, given both methods use the same >>>> name but do something quite different (one is an accessor, another >>>> is a 'wither'). one obvious option is to rename the first to >>>> 'withOffset'. But I think that would lead to verbose code (since >>>> that is a very common operation). Other options are to: >>>> >>>> * rename offset(long) to move(long), advance(long), or something else >>>> * drop offset() - but then add an overload of >>>> MemorySegment::asSlice which takes an address instead of a plain >>>> long offset >>>> >>>> I'll leave the choice to the reviewers :-) >>>> >>>> >>>> >>>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>>> Stuart, Roger, Joe and the Panama team for the feedback provided so >>>> far, which helped to get the API in the shape it is today. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" >>>> - but that is unrelated to this patch, and it's a known failing test. >>>> >>>> [1] - https://openjdk.java.net/jeps/370 >>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>> >>> > From maurizio.cimadamore at oracle.com Mon Dec 9 11:33:03 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Dec 2019 11:33:03 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <86828be9-dfe5-2594-9c22-3cc7a67ad860@gmail.com> References: <86828be9-dfe5-2594-9c22-3cc7a67ad860@gmail.com> Message-ID: <34f90740-28ad-1a57-735a-eb1627a32f17@oracle.com> Yes, for bytes the 'swappiness' is redundant - that said, both the layout API and the MemoryHandles API will still ask for endianness regardless of the size, so having some extra (possibly redundant) constants is good. Also, as you might have noted from some of the comments on panama-dev, we're not really 100% sure of what the shape of this interface should be - there have been some proposals to use separate nested interfaces for BE vs. LE - e.g. interface MemoryLayouts { ?? interface BE { ?????? static MemoryLayout BITS_8 = ... ?????? static MemoryLayout BITS_16 = ... ?????? ... ?? } ?? interface LE { ?????? static MemoryLayout BITS_8 = ... ?????? static MemoryLayout BITS_16 = ... ?????? ... ?? } } And then let the user pick the right one using a single static import. If we go down that path, the duplication is kind of a forced move - so the current scheme leaves the door open for that. Thanks Maurizio On 06/12/2019 18:45, Raffaello Giulietti wrote: > Hi, > > MemoryLayouts exposes BITS_8_BE and BITS_8_LE. > > Is there a reason to have both or is just love for symmetries (which I > share)? > > > Greetings > Raffaello > > > > Hi, > > as part of the effort to upstream the changes related to JEP 370 > (foreign memory access API) [1], I'd like to ask for a code review for > the corresponding core-libs and hotspot changes: > > > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > > > A javadoc for the memory access API is also available here: > > > > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > > > > Here is a brief summary of the changes in java.base and hotspot (the > remaining new files are implementation classes and tests for the new > API): > > > > * ciField.cpp - this one is to trust final fields in the foreign > memory access implementation (otherwise VM doesn't trust memory > segment bounds) > > > > * Modules.gmk - these changes are needed to require that the > incubating module is loaded by the boot loader (otherwise the above > changes are useless) > > > > * library_call.cpp - this one is a JIT compiler change to treat > Thread.currentThread() as a well-known constant - which helps a lot in > the confinement checks (thanks Vlad!) > > > > * various Buffer-related changes; these changes are needed because > the memory access API allows a memory segment to be projected into a > byte buffer, for interop reasons. As such, we need to insert a > liveness check in the various get/put methods. Previously we had an > implementation strategy where a BB was 'decorated' by a subclass > called ScopedBuffer - but doing so required some changes to the BB API > (e.g. making certain methods non-final, so that we could decorate > them). Here I use an approach (which I have discussed with Alan) which > doesn't require any public API? changes, but needs to add a 'segment' > field in Buffer - and then have constructors which keep track of this > extra parameter. > > > > * FileChannel changes - these changes are required so that we can > reuse the Unmapper class from the MemorySegment implementation, to > deterministically deallocate a mapped memory segment. This should be a > 'straight' refactoring, no change in behavior should occur here. > Please double check. > > > > * VarHandles - this class now provides a factory to create memory > access VarHandle - this is a bit tricky, since VarHandle cannot really > be implemented outside java.base (e.g. VarForm is not public). So we > do the usual trick where we define a bunch of proxy interfaces (see > jdk/internal/access/foreign) have the classes in java.base refer to > these - and then have the implementation classes of the memory access > API implement these interfaces. > > > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we > need to provide access to otherwise hidden functionalities - e.g. > creating a new scoped buffer, or retrieving the properties of a memory > access handle (e.g. offset, stride etc.), so that we can implement the > memory access API in its own separate module > > > > * GensrcVarHandles.gmk - these changes are needed to enable the > generation of the new memory address var handle implementations; > there's an helper class per carrier (e.g. > VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access > var handle is needed, we dynamically spin a new VH implementation > which makes use of the right carrier. We need to spin because the VH > can have a variable number of access coordinates (e.g. depending on > the dimensions of the array to be accessed). But, under the hood, all > the generated implementation will be using the same helper class. > > > > * tests - we've tried to add fairly robust tests, often checking all > possible permutations of carriers/dimensions etc. Because of that, the > tests might not be the easiest to look at, but they have proven to be > pretty effective at shaking out issues. > > > > I think that covers the main aspects of the implementation and where > it differs from vanilla JDK. > > > > P.S. > > > > In the CSR review [2], Joe raised a fair point - which is > MemoryAddress has both: > > > > offset(long) --> move address of given offset > > offset() --> return the offset of this address in its owning segment > > > > And this was considered suboptimal, given both methods use the same > name but do something quite different (one is an accessor, another is > a 'wither'). one obvious option is to rename the first to > 'withOffset'. But I think that would lead to verbose code (since that > is a very common operation). Other options are to: > > > > * rename offset(long) to move(long), advance(long), or something else > > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > > > I'll leave the choice to the reviewers > > > > > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, > Stuart, Roger, Joe and the Panama team for the feedback provided so > far, which helped to get the API in the shape it is today. > > > > Cheers > > Maurizio > > > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" > - but that is unrelated to this patch, and it's a known failing test. > > > > [1] - https://openjdk.java.net/jeps/370 > > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 > From aleksej.efimov at oracle.com Mon Dec 9 12:32:19 2019 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 9 Dec 2019 12:32:19 +0000 Subject: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed In-Reply-To: <6776002F-BE14-4531-AC6F-9BD0DE34D5DE@oracle.com> References: <154251a7-05af-3114-dac5-8b57744e5db9@oracle.com> <0a09885f-dd8b-13e7-f042-752ce77b4cc7@oracle.com> <6776002F-BE14-4531-AC6F-9BD0DE34D5DE@oracle.com> Message-ID: <9f7072a8-9006-4c54-24e8-0ed30b8621a0@oracle.com> Daniel, Chris, Vyom, Thanks for your comments and reviews! About updating @bug tag: In general, I'm not adding the bug id if a fix is for the test itself, i.e. bug has 'noreg-self' label. - Aleksei On 08/12/2019 20:33, Chris Hegarty wrote: >> On 8 Dec 2019, at 10:48, Daniel Fuchs wrote: >> >> Hi Vyom, >> >> On 07/12/2019 03:36, Vyom Tiwari wrote: >>> Changes looks OK to me, one minor bit you need to update @bug tag before pushing. >> We don't update @bug for test bugs (when the fix is in the >> the test itself). > Correct. Doing so would add no real value. > > -Chris. > From chris.hegarty at oracle.com Mon Dec 9 12:51:07 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 9 Dec 2019 12:51:07 +0000 Subject: RFR [14] 8235550: Clarify record reflective support specification Message-ID: <9BE0B0CA-4A8C-4975-A21E-8F4163B68F8C@oracle.com> This is a review request for a change to add a clarification to the record related core reflection methods, that specifies what it means to be a record class and access to the record components. Discussed originally over on amber-spec-experts [1] I expanded the existing record reflection test and also added a new test ( with the original record push bug no. ) to cover security manager checks ( since I couldn't find an existing test ). Bug: https://bugs.openjdk.java.net/browse/JDK-8235550 CSR: https://bugs.openjdk.java.net/browse/JDK-8235583 Webrev: https://cr.openjdk.java.net/~chegar/8235550/webrev.00/ -Chris. [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001840.html From andy.herrick at oracle.com Mon Dec 9 14:33:41 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Dec 2019 09:33:41 -0500 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> Message-ID: <104f0614-86cb-d6a5-2365-dfc82cf945df@oracle.com> Please review this revised fix at [3]. This fix only adds "@modules jdk.incubator.jpackage" to junit.jar. [3] http://cr.openjdk.java.net/~herrick/8235453/webrev.02/ /Andy On 12/6/2019 1:33 PM, Andy Herrick wrote: > Please review this jpackager test fix for bug [1] at [2]. > > the fix adds "@requires (os.family == "linux") | (os.family == "mac") > | (os.family == "windows")" to all jpackage tests that were not > already filtered with "@requires (os.family == "XXX")" > > [1] https://bugs.openjdk.java.net/browse/JDK-8235453 > > [2] http://cr.openjdk.java.net/~herrick/8235453/ > > /Andy > From Roger.Riggs at oracle.com Mon Dec 9 15:31:53 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 9 Dec 2019 10:31:53 -0500 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: <00763a63-1441-e120-60bb-0313ae99a080@oracle.com> Hi, Great work! Comments, mostly related to readability: (Based on the 12/5 webrev) FileChannelImpl.java: 1008-1009: else should be on the same line as }. 1124-1125: use Objects.requireNonNull(mode, "mode"); 1132-1144: odd mix of use of? single line 'if' vs. with brackets. (yes, its copy/paste). ? One day will be a good use for switch-expr. JavaNioAccess.java: Since the javadoc is minimal here, a reference to the implementation class would be helpful. 47, 50:? The argument name "obj" is preferred over "ob". 52: fix indentation JavaLangInvokeAccess.java A refrence to the implementation class would be helpful for navigation/understanding. MethodHandleImpl.java 1807:? Using a consistent form of the alignment would be good; the ambiguity of the mask vs the power of two will be a source of bugs. (Even if the value is not checked to be a power of two or has all one bits). (Maybe an assert for doc/checking). VarHandleMemoryAddressBase.java: 37/42: It would be good to document the assumptions about the arguments including alignment and being checked or unchecked. Hopefully, somewhere they would be checked. For example, does the offset conform to the alignment? MemoryAddressProxy.java: 34: checkAccess should document the exception that is thrown when it fails That's it so far, Roger On 12/5/19 4:04 PM, Maurizio Cimadamore wrote: > Hi, > as part of the effort to upstream the changes related to JEP 370 > (foreign memory access API) [1], I'd like to ask for a code review for > the corresponding core-libs and hotspot changes: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > A javadoc for the memory access API is also available here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > Here is a brief summary of the changes in java.base and hotspot (the > remaining new files are implementation classes and tests for the new > API): > > * ciField.cpp - this one is to trust final fields in the foreign > memory access implementation (otherwise VM doesn't trust memory > segment bounds) > > * Modules.gmk - these changes are needed to require that the > incubating module is loaded by the boot loader (otherwise the above > changes are useless) > > * library_call.cpp - this one is a JIT compiler change to treat > Thread.currentThread() as a well-known constant - which helps a lot in > the confinement checks (thanks Vlad!) > > * various Buffer-related changes; these changes are needed because the > memory access API allows a memory segment to be projected into a byte > buffer, for interop reasons. As such, we need to insert a liveness > check in the various get/put methods. Previously we had an > implementation strategy where a BB was 'decorated' by a subclass > called ScopedBuffer - but doing so required some changes to the BB API > (e.g. making certain methods non-final, so that we could decorate > them). Here I use an approach (which I have discussed with Alan) which > doesn't require any public API changes, but needs to add a 'segment' > field in Buffer - and then have constructors which keep track of this > extra parameter. > > * FileChannel changes - these changes are required so that we can > reuse the Unmapper class from the MemorySegment implementation, to > deterministically deallocate a mapped memory segment. This should be a > 'straight' refactoring, no change in behavior should occur here. > Please double check. > > * VarHandles - this class now provides a factory to create memory > access VarHandle - this is a bit tricky, since VarHandle cannot really > be implemented outside java.base (e.g. VarForm is not public). So we > do the usual trick where we define a bunch of proxy interfaces (see > jdk/internal/access/foreign) have the classes in java.base refer to > these - and then have the implementation classes of the memory access > API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need > to provide access to otherwise hidden functionalities - e.g. creating > a new scoped buffer, or retrieving the properties of a memory access > handle (e.g. offset, stride etc.), so that we can implement the memory > access API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the > generation of the new memory address var handle implementations; > there's an helper class per carrier (e.g. > VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access > var handle is needed, we dynamically spin a new VH implementation > which makes use of the right carrier. We need to spin because the VH > can have a variable number of access coordinates (e.g. depending on > the dimensions of the array to be accessed). But, under the hood, all > the generated implementation will be using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all > possible permutations of carriers/dimensions etc. Because of that, the > tests might not be the easiest to look at, but they have proven to be > pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where > it differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is > MemoryAddress has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same > name but do something quite different (one is an accessor, another is > a 'wither'). one obvious option is to rename the first to > 'withOffset'. But I think that would lead to verbose code (since that > is a very common operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers :-) > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, > Stuart, Roger, Joe and the Panama team for the feedback provided so > far, which helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - > but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 > From maurizio.cimadamore at oracle.com Mon Dec 9 16:09:38 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Dec 2019 16:09:38 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <00763a63-1441-e120-60bb-0313ae99a080@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <00763a63-1441-e120-60bb-0313ae99a080@oracle.com> Message-ID: Thanks Roger, I will address your comments. Maurizio On 09/12/2019 15:31, Roger Riggs wrote: > Hi, > > Great work! > > > Comments, mostly related to readability: (Based on the 12/5 webrev) > > FileChannelImpl.java: > > 1008-1009: else should be on the same line as }. > 1124-1125: use Objects.requireNonNull(mode, "mode"); > > 1132-1144: odd mix of use of? single line 'if' vs. with brackets. > (yes, its copy/paste). > ? One day will be a good use for switch-expr. > > JavaNioAccess.java: > > Since the javadoc is minimal here, a reference to the implementation > class would be helpful. > > 47, 50:? The argument name "obj" is preferred over "ob". > 52: fix indentation > > JavaLangInvokeAccess.java > A refrence to the implementation class would be helpful for > navigation/understanding. > > MethodHandleImpl.java > 1807:? Using a consistent form of the alignment would be good; the > ambiguity of the mask vs the power of two will be a source of bugs. > (Even if the value is not checked to be a power of two or has all one > bits). > (Maybe an assert for doc/checking). > > > VarHandleMemoryAddressBase.java: > 37/42: It would be good to document the assumptions about the > arguments including alignment > and being checked or unchecked. Hopefully, somewhere they would be > checked. > For example, does the offset conform to the alignment? > > MemoryAddressProxy.java: > 34: checkAccess should document the exception that is thrown when it > fails > > That's it so far, Roger > > > > On 12/5/19 4:04 PM, Maurizio Cimadamore wrote: >> Hi, >> as part of the effort to upstream the changes related to JEP 370 >> (foreign memory access API) [1], I'd like to ask for a code review >> for the corresponding core-libs and hotspot changes: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >> >> A javadoc for the memory access API is also available here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Note: the patch passes tier1, tier2 and tier3 testing (**) >> >> >> Here is a brief summary of the changes in java.base and hotspot (the >> remaining new files are implementation classes and tests for the new >> API): >> >> * ciField.cpp - this one is to trust final fields in the foreign >> memory access implementation (otherwise VM doesn't trust memory >> segment bounds) >> >> * Modules.gmk - these changes are needed to require that the >> incubating module is loaded by the boot loader (otherwise the above >> changes are useless) >> >> * library_call.cpp - this one is a JIT compiler change to treat >> Thread.currentThread() as a well-known constant - which helps a lot >> in the confinement checks (thanks Vlad!) >> >> * various Buffer-related changes; these changes are needed because >> the memory access API allows a memory segment to be projected into a >> byte buffer, for interop reasons. As such, we need to insert a >> liveness check in the various get/put methods. Previously we had an >> implementation strategy where a BB was 'decorated' by a subclass >> called ScopedBuffer - but doing so required some changes to the BB >> API (e.g. making certain methods non-final, so that we could decorate >> them). Here I use an approach (which I have discussed with Alan) >> which doesn't require any public API changes, but needs to add a >> 'segment' field in Buffer - and then have constructors which keep >> track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can >> reuse the Unmapper class from the MemorySegment implementation, to >> deterministically deallocate a mapped memory segment. This should be >> a 'straight' refactoring, no change in behavior should occur here. >> Please double check. >> >> * VarHandles - this class now provides a factory to create memory >> access VarHandle - this is a bit tricky, since VarHandle cannot >> really be implemented outside java.base (e.g. VarForm is not public). >> So we do the usual trick where we define a bunch of proxy interfaces >> (see jdk/internal/access/foreign) have the classes in java.base refer >> to these - and then have the implementation classes of the memory >> access API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >> to provide access to otherwise hidden functionalities - e.g. creating >> a new scoped buffer, or retrieving the properties of a memory access >> handle (e.g. offset, stride etc.), so that we can implement the >> memory access API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the >> generation of the new memory address var handle implementations; >> there's an helper class per carrier (e.g. >> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >> var handle is needed, we dynamically spin a new VH implementation >> which makes use of the right carrier. We need to spin because the VH >> can have a variable number of access coordinates (e.g. depending on >> the dimensions of the array to be accessed). But, under the hood, all >> the generated implementation will be using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all >> possible permutations of carriers/dimensions etc. Because of that, >> the tests might not be the easiest to look at, but they have proven >> to be pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where >> it differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is >> MemoryAddress has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same >> name but do something quite different (one is an accessor, another is >> a 'wither'). one obvious option is to rename the first to >> 'withOffset'. But I think that would lead to verbose code (since that >> is a very common operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice >> which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >> Stuart, Roger, Joe and the Panama team for the feedback provided so >> far, which helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >> but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >> > From mandy.chung at oracle.com Mon Dec 9 17:10:50 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Dec 2019 09:10:50 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: References: Message-ID: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> Looks good. Mandy On 12/8/19 10:58 AM, Joe Darcy wrote: > Hello, > > Please review this small API changes for JDK 15: > > ??? JDK-8230771: Remove terminally deprecated constructors in java.base > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ > > Patch below. > > Thanks, > > -Joe > > --- > old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > 2019-12-08 10:56:14.223168685 -0800 > +++ > new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > 2019-12-08 10:56:13.999168685 -0800 > @@ -40,12 +40,6 @@ > ? * @since 11 > ? */ > ?public final class ConstantBootstraps { > -??? /** > -???? * Do not call. > -???? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public ConstantBootstraps() {} > - > ???? // implements the upcall from the JVM, > MethodHandleNatives.linkDynamicConstant: > ???? /*non-public*/ > ???? static Object makeConstant(MethodHandle bootstrapMethod, > --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java > 2019-12-08 10:56:14.775168685 -0800 > +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java > 2019-12-08 10:56:14.555168685 -0800 > @@ -44,13 +44,6 @@ > ? */ > ?public class Modifier { > ???? /** > -???? * Do not call. > -???? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public Modifier() {} > - > - > -??? /** > ????? * Return {@code true} if the integer argument includes the > ????? * {@code public} modifier, {@code false} otherwise. > ????? * > From victorwssilva at gmail.com Mon Dec 9 17:18:10 2019 From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva) Date: Mon, 9 Dec 2019 14:18:10 -0300 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> Message-ID: If you remove the deprecated constructor, the compiler will add a default one. Wouldn't it be a better idea to make the deprecated constructor private and throwing an exception? Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung escreveu: > Looks good. > > Mandy > > On 12/8/19 10:58 AM, Joe Darcy wrote: > > Hello, > > > > Please review this small API changes for JDK 15: > > > > JDK-8230771: Remove terminally deprecated constructors in java.base > > CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 > > webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ > > > > Patch below. > > > > Thanks, > > > > -Joe > > > > --- > > old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > > 2019-12-08 10:56:14.223168685 -0800 > > +++ > > new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > > 2019-12-08 10:56:13.999168685 -0800 > > @@ -40,12 +40,6 @@ > > * @since 11 > > */ > > public final class ConstantBootstraps { > > - /** > > - * Do not call. > > - */ > > - @Deprecated(forRemoval=true, since="14") > > - public ConstantBootstraps() {} > > - > > // implements the upcall from the JVM, > > MethodHandleNatives.linkDynamicConstant: > > /*non-public*/ > > static Object makeConstant(MethodHandle bootstrapMethod, > > --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java > > 2019-12-08 10:56:14.775168685 -0800 > > +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java > > 2019-12-08 10:56:14.555168685 -0800 > > @@ -44,13 +44,6 @@ > > */ > > public class Modifier { > > /** > > - * Do not call. > > - */ > > - @Deprecated(forRemoval=true, since="14") > > - public Modifier() {} > > - > > - > > - /** > > * Return {@code true} if the integer argument includes the > > * {@code public} modifier, {@code false} otherwise. > > * > > > > From daniel.fuchs at oracle.com Mon Dec 9 17:25:15 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 9 Dec 2019 17:25:15 +0000 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: References: Message-ID: <207147a8-c5da-7a6e-6221-994b5692d488@oracle.com> Hi Joe, I'm sure I'm going to say something stupid but: doesn't this adds back the public implicit no args constructors? best regards, -- daniel On 08/12/2019 18:58, Joe Darcy wrote: > Hello, > > Please review this small API changes for JDK 15: > > ??? JDK-8230771: Remove terminally deprecated constructors in java.base > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ > > Patch below. > > Thanks, > > -Joe > > --- > old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > 2019-12-08 10:56:14.223168685 -0800 > +++ > new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > 2019-12-08 10:56:13.999168685 -0800 > @@ -40,12 +40,6 @@ > ? * @since 11 > ? */ > ?public final class ConstantBootstraps { > -??? /** > -???? * Do not call. > -???? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public ConstantBootstraps() {} > - > ???? // implements the upcall from the JVM, > MethodHandleNatives.linkDynamicConstant: > ???? /*non-public*/ > ???? static Object makeConstant(MethodHandle bootstrapMethod, > --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java > 2019-12-08 10:56:14.775168685 -0800 > +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java > 2019-12-08 10:56:14.555168685 -0800 > @@ -44,13 +44,6 @@ > ? */ > ?public class Modifier { > ???? /** > -???? * Do not call. > -???? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public Modifier() {} > - > - > -??? /** > ????? * Return {@code true} if the integer argument includes the > ????? * {@code public} modifier, {@code false} otherwise. > ????? * > From mandy.chung at oracle.com Mon Dec 9 17:29:06 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Dec 2019 09:29:06 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> Message-ID: Good catch!? Daniel also pointed that out.? I overlooked it.? It needs to add back a private no-arg constructor. Mandy On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: > If you remove the deprecated constructor, the compiler will add a > default one. Wouldn't it be a better idea to make the deprecated > constructor private and throwing an exception? > > Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung > > escreveu: > > Looks good. > > Mandy > > On 12/8/19 10:58 AM, Joe Darcy wrote: > > Hello, > > > > Please review this small API changes for JDK 15: > > > > ??? JDK-8230771: Remove terminally deprecated constructors in > java.base > > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 > > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ > > > > Patch below. > > > > Thanks, > > > > -Joe > > > > --- > > > old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > > > 2019-12-08 10:56:14.223168685 -0800 > > +++ > > > new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > > > 2019-12-08 10:56:13.999168685 -0800 > > @@ -40,12 +40,6 @@ > > ? * @since 11 > > ? */ > > ?public final class ConstantBootstraps { > > -??? /** > > -???? * Do not call. > > -???? */ > > -??? @Deprecated(forRemoval=true, since="14") > > -??? public ConstantBootstraps() {} > > - > > ???? // implements the upcall from the JVM, > > MethodHandleNatives.linkDynamicConstant: > > ???? /*non-public*/ > > ???? static Object makeConstant(MethodHandle bootstrapMethod, > > --- old/src/java.base/share/classes/java/lang/reflect/Modifier.java > > 2019-12-08 10:56:14.775168685 -0800 > > +++ new/src/java.base/share/classes/java/lang/reflect/Modifier.java > > 2019-12-08 10:56:14.555168685 -0800 > > @@ -44,13 +44,6 @@ > > ? */ > > ?public class Modifier { > > ???? /** > > -???? * Do not call. > > -???? */ > > -??? @Deprecated(forRemoval=true, since="14") > > -??? public Modifier() {} > > - > > - > > -??? /** > > ????? * Return {@code true} if the integer argument includes the > > ????? * {@code public} modifier, {@code false} otherwise. > > ????? * > > > From joe.darcy at oracle.com Mon Dec 9 17:38:49 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 9 Dec 2019 09:38:49 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> Message-ID: <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> Doh! Will correct. That is why I want to get the no-arg constructor added as a javac warning (JDK-8071961) ;-) Thanks all for catching this, -Joe On 12/9/2019 9:29 AM, Mandy Chung wrote: > Good catch!? Daniel also pointed that out.? I overlooked it. It needs > to add back a private no-arg constructor. > > Mandy > > On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: >> If you remove the deprecated constructor, the compiler will add a >> default one. Wouldn't it be a better idea to make the deprecated >> constructor private and throwing an exception? >> >> Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung >> > escreveu: >> >> Looks good. >> >> Mandy >> >> On 12/8/19 10:58 AM, Joe Darcy wrote: >> > Hello, >> > >> > Please review this small API changes for JDK 15: >> > >> > ??? JDK-8230771: Remove terminally deprecated constructors in >> java.base >> > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 >> > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ >> > >> > Patch below. >> > >> > Thanks, >> > >> > -Joe >> > >> > --- >> > >> old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >> >> > 2019-12-08 10:56:14.223168685 -0800 >> > +++ >> > >> new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >> >> > 2019-12-08 10:56:13.999168685 -0800 >> > @@ -40,12 +40,6 @@ >> > ? * @since 11 >> > ? */ >> > ?public final class ConstantBootstraps { >> > -??? /** >> > -???? * Do not call. >> > -???? */ >> > -??? @Deprecated(forRemoval=true, since="14") >> > -??? public ConstantBootstraps() {} >> > - >> > ???? // implements the upcall from the JVM, >> > MethodHandleNatives.linkDynamicConstant: >> > ???? /*non-public*/ >> > ???? static Object makeConstant(MethodHandle bootstrapMethod, >> > --- >> old/src/java.base/share/classes/java/lang/reflect/Modifier.java >> > 2019-12-08 10:56:14.775168685 -0800 >> > +++ >> new/src/java.base/share/classes/java/lang/reflect/Modifier.java >> > 2019-12-08 10:56:14.555168685 -0800 >> > @@ -44,13 +44,6 @@ >> > ? */ >> > ?public class Modifier { >> > ???? /** >> > -???? * Do not call. >> > -???? */ >> > -??? @Deprecated(forRemoval=true, since="14") >> > -??? public Modifier() {} >> > - >> > - >> > -??? /** >> > ????? * Return {@code true} if the integer argument includes the >> > ????? * {@code public} modifier, {@code false} otherwise. >> > ????? * >> > >> > From philip.race at oracle.com Mon Dec 9 17:54:54 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 09 Dec 2019 09:54:54 -0800 Subject: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage" In-Reply-To: <104f0614-86cb-d6a5-2365-dfc82cf945df@oracle.com> References: <6101895f-9bc8-e3f6-7779-bc473875643b@oracle.com> <104f0614-86cb-d6a5-2365-dfc82cf945df@oracle.com> Message-ID: <5DEE8A6E.4030404@oracle.com> +1 -phil On 12/9/19, 6:33 AM, Andy Herrick wrote: > Please review this revised fix at [3]. > > This fix only adds "@modules jdk.incubator.jpackage" to junit.jar. > > [3] http://cr.openjdk.java.net/~herrick/8235453/webrev.02/ /Andy > > On 12/6/2019 1:33 PM, Andy Herrick wrote: >> Please review this jpackager test fix for bug [1] at [2]. >> >> the fix adds "@requires (os.family == "linux") | (os.family == "mac") >> | (os.family == "windows")" to all jpackage tests that were not >> already filtered with "@requires (os.family == "XXX")" >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235453 >> >> [2] http://cr.openjdk.java.net/~herrick/8235453/ >> >> /Andy >> From letuyang at amazon.com Mon Dec 9 18:04:46 2019 From: letuyang at amazon.com (Yang, Letu) Date: Mon, 9 Dec 2019 18:04:46 +0000 Subject: Turkish Time Zone name string and translation In-Reply-To: <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com> References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com> <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com> <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com> Message-ID: Thanks Naoto! Is there a separate ticket for the translation to other locales? Letu ?On 12/4/19, 12:36 PM, "naoto.sato at oracle.com" wrote: Looks good, assuming the change between 03 and 04 is to fix "no new line..." Naoto On 12/4/19 11:38 AM, Yang, Letu wrote: > Hi Naoto, > > Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ > > Letu > > On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" wrote: > > Looks good. > > Naoto > > On 11/22/19 9:55 PM, Yang, Letu wrote: > > Hi Naoto, > > > > Added it in the new webrev > > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks! > > > > Letu > > > > > > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote: > > Hi Letu, > > > > You might want to add lines for "Turkey" zone as well in LocaleData? > > > > Naoto > > > > On 11/22/19 4:16 PM, Yang, Letu wrote: > >> Hi Naoto, > >> > >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ > >> > >> Letu > >> > >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: > >> > >> Hi Letu, > >> > >> The change in the resource bundle file looks good. > >> > >> As to the regression test, I would avoid adding a separate file, instead > >> add some variations for > >> open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add > >> some lines in "LocaleData" file, which contains the expected resources > >> for the COMPAT locale provider. > >> > >> Naoto > >> > >> On 11/20/19 9:43 PM, Yang, Letu wrote: > >> > Hi Naoto, > >> > > >> > Thank you for the suggestions! > >> > > >> > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ > >> > > >> > Letu > >> > > >> > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: > >> > > >> > Hi Letu, > >> > > >> > Here are my comments to your changes: > >> > > >> > - You will need a regression test for this fix. Take a look at > >> > test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate > >> > test cases. > >> > > >> > - Fix comment should follow the OpenJDK changeset guideline [1] > >> > > >> > - As to the change itself, I would put "Turkey Summer Time"/"TRST" for > >> > the 3rd and 4th array elements. Even though Turkey time do not observe > >> > DST, names in those slots should reflect the DST (consistent to other names) > >> > > >> > - time zone id "Turkey" (line 1050) should also point to TRT array. > >> > > >> > Naoto > >> > > >> > [1] http://openjdk.java.net/guide/producingChangeset.html > >> > > >> > On 11/17/19 8:54 PM, Yang, Letu wrote: > >> > > Hi Naoto, > >> > > > >> > > Thank you for the clarification! > >> > > > >> > > Xin from my team has filed a JBS and uploaded my webrev: > >> > > https://bugs.openjdk.java.net/browse/JDK-8234288 > >> > > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ > >> > > > >> > > Letu > >> > > > >> > > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: > >> > > > >> > > Letu, > >> > > > >> > > Please go ahead and fix the issue in English resource. As to the > >> > > translation, Oracle l10n will translate it in appropriate locales. > >> > > > >> > > Naoto > >> > > > >> > > On 11/15/19 5:56 PM, Yang, Letu wrote: > >> > > > Hi Naoto > >> > > > > >> > > > Thank you for the quick response! We will file a ticket later today. > >> > > > > >> > > > Shall we make an effort on fixing and translating the strings, or you > >> > > > prefer to take care of it at Oracle? > >> > > > > >> > > > Letu > >> > > > > >> > > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: > >> > > > Hi Letu, > >> > > > > >> > > > Please file a JBS issue for this (component: core-libs, subcomponent: > >> > > > java.util:i18n). > >> > > > > >> > > > Naoto > >> > > > > >> > > > On 11/15/19 3:19 PM, Yang, Letu wrote: > >> > > >> Hi, > >> > > >> > >> > > >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: > >> > > >> > >> > > >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 > >> > > >> > >> > > >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS > > issue for this, but I > >> > > > am not sure whether we should fix this bug, or there is an existing > >> > > > procedure for this kind of bug which requires language translation. > >> > > >> > >> > > >> Letu > >> > > >> > >> > > >> > >> > > >> > >> > > > >> > > > >> > > >> > > >> > >> > > From joe.darcy at oracle.com Mon Dec 9 18:16:54 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 9 Dec 2019 10:16:54 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> Message-ID: <21ae2c12-f407-e7d9-ae38-9bb2bce51996@oracle.com> Corrected patch: diff -r 153e5f76551d src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java --- a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java Mon Dec 09 23:00:13 2019 +0530 +++ b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java Mon Dec 09 10:15:44 2019 -0800 @@ -43,8 +43,7 @@ ???? /** ????? * Do not call. ????? */ -??? @Deprecated(forRemoval=true, since="14") -??? public ConstantBootstraps() {} +??? private ConstantBootstraps() {throw new AssertionError();} ???? // implements the upcall from the JVM, MethodHandleNatives.linkDynamicConstant: ???? /*non-public*/ diff -r 153e5f76551d src/java.base/share/classes/java/lang/reflect/Modifier.java --- a/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon Dec 09 23:00:13 2019 +0530 +++ b/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon Dec 09 10:15:44 2019 -0800 @@ -46,8 +46,7 @@ ???? /** ????? * Do not call. ????? */ -??? @Deprecated(forRemoval=true, since="14") -??? public Modifier() {} +??? private Modifier() {throw new AssertionError();} ???? /** -Joe On 12/9/2019 9:38 AM, Joe Darcy wrote: > Doh! Will correct. That is why I want to get the no-arg constructor > added as a javac warning (JDK-8071961) ;-) > > Thanks all for catching this, > > -Joe > > On 12/9/2019 9:29 AM, Mandy Chung wrote: >> Good catch!? Daniel also pointed that out.? I overlooked it. It needs >> to add back a private no-arg constructor. >> >> Mandy >> >> On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: >>> If you remove the deprecated constructor, the compiler will add a >>> default one. Wouldn't it be a better idea to make the deprecated >>> constructor private and throwing an exception? >>> >>> Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung >>> > escreveu: >>> >>> ??? Looks good. >>> >>> ??? Mandy >>> >>> ??? On 12/8/19 10:58 AM, Joe Darcy wrote: >>> ??? > Hello, >>> ??? > >>> ??? > Please review this small API changes for JDK 15: >>> ??? > >>> ??? > ??? JDK-8230771: Remove terminally deprecated constructors in >>> ??? java.base >>> ??? > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 >>> ??? > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ >>> ??? > >>> ??? > Patch below. >>> ??? > >>> ??? > Thanks, >>> ??? > >>> ??? > -Joe >>> ??? > >>> ??? > --- >>> ??? > >>> old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>> >>> >>> ??? > 2019-12-08 10:56:14.223168685 -0800 >>> ??? > +++ >>> ??? > >>> new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>> >>> >>> ??? > 2019-12-08 10:56:13.999168685 -0800 >>> ??? > @@ -40,12 +40,6 @@ >>> ??? > ? * @since 11 >>> ??? > ? */ >>> ??? > ?public final class ConstantBootstraps { >>> ??? > -??? /** >>> ??? > -???? * Do not call. >>> ??? > -???? */ >>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>> ??? > -??? public ConstantBootstraps() {} >>> ??? > - >>> ??? > ???? // implements the upcall from the JVM, >>> ??? > MethodHandleNatives.linkDynamicConstant: >>> ??? > ???? /*non-public*/ >>> ??? > ???? static Object makeConstant(MethodHandle bootstrapMethod, >>> ??? > --- >>> old/src/java.base/share/classes/java/lang/reflect/Modifier.java >>> ??? > 2019-12-08 10:56:14.775168685 -0800 >>> ??? > +++ >>> new/src/java.base/share/classes/java/lang/reflect/Modifier.java >>> ??? > 2019-12-08 10:56:14.555168685 -0800 >>> ??? > @@ -44,13 +44,6 @@ >>> ??? > ? */ >>> ??? > ?public class Modifier { >>> ??? > ???? /** >>> ??? > -???? * Do not call. >>> ??? > -???? */ >>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>> ??? > -??? public Modifier() {} >>> ??? > - >>> ??? > - >>> ??? > -??? /** >>> ??? > ????? * Return {@code true} if the integer argument includes the >>> ??? > ????? * {@code public} modifier, {@code false} otherwise. >>> ??? > ????? * >>> ??? > >>> >> From peter.levart at gmail.com Mon Dec 9 18:16:47 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 9 Dec 2019 19:16:47 +0100 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: <55613fbc-a8b2-b4bb-d4f1-5b08c2b91014@gmail.com> Hi Maurizio, Nice work! I see the API prefixes each independent access to memory with a call to the following MemorySegmentImpl method: ?157???? @Override ?158???? public final void checkValidState() { ?159???????? if (owner != Thread.currentThread()) { ?160???????????? throw new IllegalStateException("Attempt to access segment outside owning thread"); ?161???????? } ?162???????? scope.checkAlive(); ?163???? } The 1st check is making sure the method is invoked in the "owner" thread, while the second is making sure that scope is still alive. The 2nd check is only correct if it is performed in the "owner" thread which is guaranteed. These two are checks of mutable fields in two places (objects). May I suggest a scheme that combines both checks and only tests for one value in one object on the hot path: - drop Thread owner field from MemorySegmentImpl - drop boolean isAlive field from MemoryScope - add Thread owner field to MemoryScope - delegate MemorySegment.isAlive() and MemorySegmentImpl.checkValidState() to MemoryScope: ??? final boolean isAlive() { ??????? return activeCount.get() >= UNACQUIRED; ??? } ??? final boolean isAccessible() { ??????? return Thread.currentThread() == owner; ??? } ??? final void checkAlive() { ??????? if (!isAlive()) { ??????????? throw new IllegalStateException("Segment is not alive"); ??????? } ??? } ??? final void checkValidState() { ??????? if (Thread.currentThread() != owner) { ??????????? checkAlive(); ??????????? throw new IllegalStateException("Attempt to access segment outside owning thread"); ??????? } ??? } - make MemoryScope.close() be the following: ??? void close() { ??????? // assert Thread.currentThread() == MemorySegmentImpl.owner ??????? if (!activeCount.compareAndSet(UNACQUIRED, CLOSED)) { ??????????? throw new IllegalStateException("Cannot close a segment that has active acquired views"); ??????? } ??????? owner = null; ??????? if (cleanupAction != null) { ??????????? cleanupAction.run(); ??????? } ??? } - make other arrangements that pass Thread.currentThread() to MemoryScope instead of to MemorySegmentImpl constructor. Voila, only (Thread.currentThread() != owner) check on the hot path! Notice that .isAlive() is now also thread-safe. Previously it wasn't. What do you think? Might this be better performance wise? Regards, Peter On 12/5/19 10:04 PM, Maurizio Cimadamore wrote: > Hi, > as part of the effort to upstream the changes related to JEP 370 > (foreign memory access API) [1], I'd like to ask for a code review for > the corresponding core-libs and hotspot changes: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ > > A javadoc for the memory access API is also available here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Note: the patch passes tier1, tier2 and tier3 testing (**) > > > Here is a brief summary of the changes in java.base and hotspot (the > remaining new files are implementation classes and tests for the new > API): > > * ciField.cpp - this one is to trust final fields in the foreign > memory access implementation (otherwise VM doesn't trust memory > segment bounds) > > * Modules.gmk - these changes are needed to require that the > incubating module is loaded by the boot loader (otherwise the above > changes are useless) > > * library_call.cpp - this one is a JIT compiler change to treat > Thread.currentThread() as a well-known constant - which helps a lot in > the confinement checks (thanks Vlad!) > > * various Buffer-related changes; these changes are needed because the > memory access API allows a memory segment to be projected into a byte > buffer, for interop reasons. As such, we need to insert a liveness > check in the various get/put methods. Previously we had an > implementation strategy where a BB was 'decorated' by a subclass > called ScopedBuffer - but doing so required some changes to the BB API > (e.g. making certain methods non-final, so that we could decorate > them). Here I use an approach (which I have discussed with Alan) which > doesn't require any public API changes, but needs to add a 'segment' > field in Buffer - and then have constructors which keep track of this > extra parameter. > > * FileChannel changes - these changes are required so that we can > reuse the Unmapper class from the MemorySegment implementation, to > deterministically deallocate a mapped memory segment. This should be a > 'straight' refactoring, no change in behavior should occur here. > Please double check. > > * VarHandles - this class now provides a factory to create memory > access VarHandle - this is a bit tricky, since VarHandle cannot really > be implemented outside java.base (e.g. VarForm is not public). So we > do the usual trick where we define a bunch of proxy interfaces (see > jdk/internal/access/foreign) have the classes in java.base refer to > these - and then have the implementation classes of the memory access > API implement these interfaces. > > * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need > to provide access to otherwise hidden functionalities - e.g. creating > a new scoped buffer, or retrieving the properties of a memory access > handle (e.g. offset, stride etc.), so that we can implement the memory > access API in its own separate module > > * GensrcVarHandles.gmk - these changes are needed to enable the > generation of the new memory address var handle implementations; > there's an helper class per carrier (e.g. > VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access > var handle is needed, we dynamically spin a new VH implementation > which makes use of the right carrier. We need to spin because the VH > can have a variable number of access coordinates (e.g. depending on > the dimensions of the array to be accessed). But, under the hood, all > the generated implementation will be using the same helper class. > > * tests - we've tried to add fairly robust tests, often checking all > possible permutations of carriers/dimensions etc. Because of that, the > tests might not be the easiest to look at, but they have proven to be > pretty effective at shaking out issues. > > I think that covers the main aspects of the implementation and where > it differs from vanilla JDK. > > P.S. > > In the CSR review [2], Joe raised a fair point - which is > MemoryAddress has both: > > offset(long) --> move address of given offset > offset() --> return the offset of this address in its owning segment > > And this was considered suboptimal, given both methods use the same > name but do something quite different (one is an accessor, another is > a 'wither'). one obvious option is to rename the first to > 'withOffset'. But I think that would lead to verbose code (since that > is a very common operation). Other options are to: > > * rename offset(long) to move(long), advance(long), or something else > * drop offset() - but then add an overload of MemorySegment::asSlice > which takes an address instead of a plain long offset > > I'll leave the choice to the reviewers :-) > > > > Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, > Stuart, Roger, Joe and the Panama team for the feedback provided so > far, which helped to get the API in the shape it is today. > > Cheers > Maurizio > > (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - > but that is unrelated to this patch, and it's a known failing test. > > [1] - https://openjdk.java.net/jeps/370 > [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 > From naoto.sato at oracle.com Mon Dec 9 18:19:13 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 9 Dec 2019 10:19:13 -0800 Subject: Turkish Time Zone name string and translation In-Reply-To: References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com> <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com> <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com> <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com> <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com> <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com> <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com> <32588966-0750-4916-8583-a4af328ecbcd@amazon.com> <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com> <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com> <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com> Message-ID: <0492c002-6698-7646-ed58-f98a9b85724a@oracle.com> Hi Letu, Those translation drops are usually integrated at the end of the development cycle, such as (for JDK 13): https://bugs.openjdk.java.net/browse/JDK-8227009 And I don't think the issue is created for JDK 14 yet. Naoto On 12/9/19 10:04 AM, Yang, Letu wrote: > Thanks Naoto! > > Is there a separate ticket for the translation to other locales? > > Letu > > ?On 12/4/19, 12:36 PM, "naoto.sato at oracle.com" wrote: > > Looks good, assuming the change between 03 and 04 is to fix "no new line..." > > Naoto > > On 12/4/19 11:38 AM, Yang, Letu wrote: > > Hi Naoto, > > > > Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ > > > > Letu > > > > On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" wrote: > > > > Looks good. > > > > Naoto > > > > On 11/22/19 9:55 PM, Yang, Letu wrote: > > > Hi Naoto, > > > > > > Added it in the new webrev > > > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks! > > > > > > Letu > > > > > > > > > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote: > > > Hi Letu, > > > > > > You might want to add lines for "Turkey" zone as well in LocaleData? > > > > > > Naoto > > > > > > On 11/22/19 4:16 PM, Yang, Letu wrote: > > >> Hi Naoto, > > >> > > >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/ > > >> > > >> Letu > > >> > > >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" wrote: > > >> > > >> Hi Letu, > > >> > > >> The change in the resource bundle file looks good. > > >> > > >> As to the regression test, I would avoid adding a separate file, instead > > >> add some variations for > > >> open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add > > >> some lines in "LocaleData" file, which contains the expected resources > > >> for the COMPAT locale provider. > > >> > > >> Naoto > > >> > > >> On 11/20/19 9:43 PM, Yang, Letu wrote: > > >> > Hi Naoto, > > >> > > > >> > Thank you for the suggestions! > > >> > > > >> > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/ > > >> > > > >> > Letu > > >> > > > >> > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" wrote: > > >> > > > >> > Hi Letu, > > >> > > > >> > Here are my comments to your changes: > > >> > > > >> > - You will need a regression test for this fix. Take a look at > > >> > test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate > > >> > test cases. > > >> > > > >> > - Fix comment should follow the OpenJDK changeset guideline [1] > > >> > > > >> > - As to the change itself, I would put "Turkey Summer Time"/"TRST" for > > >> > the 3rd and 4th array elements. Even though Turkey time do not observe > > >> > DST, names in those slots should reflect the DST (consistent to other names) > > >> > > > >> > - time zone id "Turkey" (line 1050) should also point to TRT array. > > >> > > > >> > Naoto > > >> > > > >> > [1] http://openjdk.java.net/guide/producingChangeset.html > > >> > > > >> > On 11/17/19 8:54 PM, Yang, Letu wrote: > > >> > > Hi Naoto, > > >> > > > > >> > > Thank you for the clarification! > > >> > > > > >> > > Xin from my team has filed a JBS and uploaded my webrev: > > >> > > https://bugs.openjdk.java.net/browse/JDK-8234288 > > >> > > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/ > > >> > > > > >> > > Letu > > >> > > > > >> > > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" wrote: > > >> > > > > >> > > Letu, > > >> > > > > >> > > Please go ahead and fix the issue in English resource. As to the > > >> > > translation, Oracle l10n will translate it in appropriate locales. > > >> > > > > >> > > Naoto > > >> > > > > >> > > On 11/15/19 5:56 PM, Yang, Letu wrote: > > >> > > > Hi Naoto > > >> > > > > > >> > > > Thank you for the quick response! We will file a ticket later today. > > >> > > > > > >> > > > Shall we make an effort on fixing and translating the strings, or you > > >> > > > prefer to take care of it at Oracle? > > >> > > > > > >> > > > Letu > > >> > > > > > >> > > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote: > > >> > > > Hi Letu, > > >> > > > > > >> > > > Please file a JBS issue for this (component: core-libs, subcomponent: > > >> > > > java.util:i18n). > > >> > > > > > >> > > > Naoto > > >> > > > > > >> > > > On 11/15/19 3:19 PM, Yang, Letu wrote: > > >> > > >> Hi, > > >> > > >> > > >> > > >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been updated yet: > > >> > > >> > > >> > > >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836 > > >> > > >> > > >> > > >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul". This also need to be updated for other locales. I can create a JBS > > > issue for this, but I > > >> > > > am not sure whether we should fix this bug, or there is an existing > > >> > > > procedure for this kind of bug which requires language translation. > > >> > > >> > > >> > > >> Letu > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > > > > > From mandy.chung at oracle.com Mon Dec 9 18:27:54 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Dec 2019 10:27:54 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: <21ae2c12-f407-e7d9-ae38-9bb2bce51996@oracle.com> References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> <21ae2c12-f407-e7d9-ae38-9bb2bce51996@oracle.com> Message-ID: <75d9770e-9bfb-74e4-ed60-d0709ab53e5e@oracle.com> It seems a bit overly cautious to throw AssertionError.? JDK has many private no-arg constructor and it can be as simple as empty constructor.? Just my preference. Mandy On 12/9/19 10:16 AM, Joe Darcy wrote: > Corrected patch: > > diff -r 153e5f76551d > src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > --- > a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > Mon Dec 09 23:00:13 2019 +0530 > +++ > b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java > Mon Dec 09 10:15:44 2019 -0800 > @@ -43,8 +43,7 @@ > ???? /** > ????? * Do not call. > ????? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public ConstantBootstraps() {} > +??? private ConstantBootstraps() {throw new AssertionError();} > > ???? // implements the upcall from the JVM, > MethodHandleNatives.linkDynamicConstant: > ???? /*non-public*/ > diff -r 153e5f76551d > src/java.base/share/classes/java/lang/reflect/Modifier.java > --- a/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon > Dec 09 23:00:13 2019 +0530 > +++ b/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon > Dec 09 10:15:44 2019 -0800 > @@ -46,8 +46,7 @@ > ???? /** > ????? * Do not call. > ????? */ > -??? @Deprecated(forRemoval=true, since="14") > -??? public Modifier() {} > +??? private Modifier() {throw new AssertionError();} > > > ???? /** > > -Joe > > On 12/9/2019 9:38 AM, Joe Darcy wrote: >> Doh! Will correct. That is why I want to get the no-arg constructor >> added as a javac warning (JDK-8071961) ;-) >> >> Thanks all for catching this, >> >> -Joe >> >> On 12/9/2019 9:29 AM, Mandy Chung wrote: >>> Good catch!? Daniel also pointed that out.? I overlooked it. It >>> needs to add back a private no-arg constructor. >>> >>> Mandy >>> >>> On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: >>>> If you remove the deprecated constructor, the compiler will add a >>>> default one. Wouldn't it be a better idea to make the deprecated >>>> constructor private and throwing an exception? >>>> >>>> Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung >>>> > escreveu: >>>> >>>> ??? Looks good. >>>> >>>> ??? Mandy >>>> >>>> ??? On 12/8/19 10:58 AM, Joe Darcy wrote: >>>> ??? > Hello, >>>> ??? > >>>> ??? > Please review this small API changes for JDK 15: >>>> ??? > >>>> ??? > ??? JDK-8230771: Remove terminally deprecated constructors in >>>> ??? java.base >>>> ??? > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 >>>> ??? > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ >>>> ??? > >>>> ??? > Patch below. >>>> ??? > >>>> ??? > Thanks, >>>> ??? > >>>> ??? > -Joe >>>> ??? > >>>> ??? > --- >>>> ??? > >>>> old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> >>>> >>>> ??? > 2019-12-08 10:56:14.223168685 -0800 >>>> ??? > +++ >>>> ??? > >>>> new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> >>>> >>>> ??? > 2019-12-08 10:56:13.999168685 -0800 >>>> ??? > @@ -40,12 +40,6 @@ >>>> ??? > ? * @since 11 >>>> ??? > ? */ >>>> ??? > ?public final class ConstantBootstraps { >>>> ??? > -??? /** >>>> ??? > -???? * Do not call. >>>> ??? > -???? */ >>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>> ??? > -??? public ConstantBootstraps() {} >>>> ??? > - >>>> ??? > ???? // implements the upcall from the JVM, >>>> ??? > MethodHandleNatives.linkDynamicConstant: >>>> ??? > ???? /*non-public*/ >>>> ??? > ???? static Object makeConstant(MethodHandle bootstrapMethod, >>>> ??? > --- >>>> old/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>> ??? > 2019-12-08 10:56:14.775168685 -0800 >>>> ??? > +++ >>>> new/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>> ??? > 2019-12-08 10:56:14.555168685 -0800 >>>> ??? > @@ -44,13 +44,6 @@ >>>> ??? > ? */ >>>> ??? > ?public class Modifier { >>>> ??? > ???? /** >>>> ??? > -???? * Do not call. >>>> ??? > -???? */ >>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>> ??? > -??? public Modifier() {} >>>> ??? > - >>>> ??? > - >>>> ??? > -??? /** >>>> ??? > ????? * Return {@code true} if the integer argument includes the >>>> ??? > ????? * {@code public} modifier, {@code false} otherwise. >>>> ??? > ????? * >>>> ??? > >>>> >>> From maurizio.cimadamore at oracle.com Mon Dec 9 18:31:06 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Dec 2019 18:31:06 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <55613fbc-a8b2-b4bb-d4f1-5b08c2b91014@gmail.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <55613fbc-a8b2-b4bb-d4f1-5b08c2b91014@gmail.com> Message-ID: <15774b62-48b5-3614-0fd3-b62060b9825a@oracle.com> Hi Peter, this looks like a clever optimization which basically takes advantage of the fact that you can only access a segment if you are the same thread as the segment owner. I think after we integrate, I'd love to give your approach a try and see what happens performance-wise. Right now we don't pay much for confinement check because the Thread owner is a final constant - so these checks are optimized away nicely. But we pay something for the liveness check, because the 'isAlive' field is mutable. I believe your approach won't change a lot here - it folds the two checks, but we were already paying zero for one of the two, so... Anyway - all this needs to be validated by adequate JMH-ing :-) Thanks very much for your comments! Maurizio On 09/12/2019 18:16, Peter Levart wrote: > Hi Maurizio, > > Nice work! > > I see the API prefixes each independent access to memory with a call > to the following MemorySegmentImpl method: > > ?157???? @Override > ?158???? public final void checkValidState() { > ?159???????? if (owner != Thread.currentThread()) { > ?160???????????? throw new IllegalStateException("Attempt to access > segment outside owning thread"); > ?161???????? } > ?162???????? scope.checkAlive(); > ?163???? } > > The 1st check is making sure the method is invoked in the "owner" > thread, while the second is making sure that scope is still alive. The > 2nd check is only correct if it is performed in the "owner" thread > which is guaranteed. These two are checks of mutable fields in two > places (objects). > > May I suggest a scheme that combines both checks and only tests for > one value in one object on the hot path: > > - drop Thread owner field from MemorySegmentImpl > - drop boolean isAlive field from MemoryScope > - add Thread owner field to MemoryScope > - delegate MemorySegment.isAlive() and > MemorySegmentImpl.checkValidState() to MemoryScope: > > ??? final boolean isAlive() { > ??????? return activeCount.get() >= UNACQUIRED; > ??? } > > ??? final boolean isAccessible() { > ??????? return Thread.currentThread() == owner; > ??? } > > ??? final void checkAlive() { > ??????? if (!isAlive()) { > ??????????? throw new IllegalStateException("Segment is not alive"); > ??????? } > ??? } > > ??? final void checkValidState() { > ??????? if (Thread.currentThread() != owner) { > ??????????? checkAlive(); > ??????????? throw new IllegalStateException("Attempt to access segment > outside owning thread"); > ??????? } > ??? } > > - make MemoryScope.close() be the following: > > ??? void close() { > ??????? // assert Thread.currentThread() == MemorySegmentImpl.owner > ??????? if (!activeCount.compareAndSet(UNACQUIRED, CLOSED)) { > ??????????? throw new IllegalStateException("Cannot close a segment > that has active acquired views"); > ??????? } > ??????? owner = null; > ??????? if (cleanupAction != null) { > ??????????? cleanupAction.run(); > ??????? } > ??? } > > - make other arrangements that pass Thread.currentThread() to > MemoryScope instead of to MemorySegmentImpl constructor. > > > Voila, only (Thread.currentThread() != owner) check on the hot path! > > Notice that .isAlive() is now also thread-safe. Previously it wasn't. > > > What do you think? Might this be better performance wise? > > Regards, Peter > > > On 12/5/19 10:04 PM, Maurizio Cimadamore wrote: >> Hi, >> as part of the effort to upstream the changes related to JEP 370 >> (foreign memory access API) [1], I'd like to ask for a code review >> for the corresponding core-libs and hotspot changes: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >> >> A javadoc for the memory access API is also available here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Note: the patch passes tier1, tier2 and tier3 testing (**) >> >> >> Here is a brief summary of the changes in java.base and hotspot (the >> remaining new files are implementation classes and tests for the new >> API): >> >> * ciField.cpp - this one is to trust final fields in the foreign >> memory access implementation (otherwise VM doesn't trust memory >> segment bounds) >> >> * Modules.gmk - these changes are needed to require that the >> incubating module is loaded by the boot loader (otherwise the above >> changes are useless) >> >> * library_call.cpp - this one is a JIT compiler change to treat >> Thread.currentThread() as a well-known constant - which helps a lot >> in the confinement checks (thanks Vlad!) >> >> * various Buffer-related changes; these changes are needed because >> the memory access API allows a memory segment to be projected into a >> byte buffer, for interop reasons. As such, we need to insert a >> liveness check in the various get/put methods. Previously we had an >> implementation strategy where a BB was 'decorated' by a subclass >> called ScopedBuffer - but doing so required some changes to the BB >> API (e.g. making certain methods non-final, so that we could decorate >> them). Here I use an approach (which I have discussed with Alan) >> which doesn't require any public API changes, but needs to add a >> 'segment' field in Buffer - and then have constructors which keep >> track of this extra parameter. >> >> * FileChannel changes - these changes are required so that we can >> reuse the Unmapper class from the MemorySegment implementation, to >> deterministically deallocate a mapped memory segment. This should be >> a 'straight' refactoring, no change in behavior should occur here. >> Please double check. >> >> * VarHandles - this class now provides a factory to create memory >> access VarHandle - this is a bit tricky, since VarHandle cannot >> really be implemented outside java.base (e.g. VarForm is not public). >> So we do the usual trick where we define a bunch of proxy interfaces >> (see jdk/internal/access/foreign) have the classes in java.base refer >> to these - and then have the implementation classes of the memory >> access API implement these interfaces. >> >> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need >> to provide access to otherwise hidden functionalities - e.g. creating >> a new scoped buffer, or retrieving the properties of a memory access >> handle (e.g. offset, stride etc.), so that we can implement the >> memory access API in its own separate module >> >> * GensrcVarHandles.gmk - these changes are needed to enable the >> generation of the new memory address var handle implementations; >> there's an helper class per carrier (e.g. >> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access >> var handle is needed, we dynamically spin a new VH implementation >> which makes use of the right carrier. We need to spin because the VH >> can have a variable number of access coordinates (e.g. depending on >> the dimensions of the array to be accessed). But, under the hood, all >> the generated implementation will be using the same helper class. >> >> * tests - we've tried to add fairly robust tests, often checking all >> possible permutations of carriers/dimensions etc. Because of that, >> the tests might not be the easiest to look at, but they have proven >> to be pretty effective at shaking out issues. >> >> I think that covers the main aspects of the implementation and where >> it differs from vanilla JDK. >> >> P.S. >> >> In the CSR review [2], Joe raised a fair point - which is >> MemoryAddress has both: >> >> offset(long) --> move address of given offset >> offset() --> return the offset of this address in its owning segment >> >> And this was considered suboptimal, given both methods use the same >> name but do something quite different (one is an accessor, another is >> a 'wither'). one obvious option is to rename the first to >> 'withOffset'. But I think that would lead to verbose code (since that >> is a very common operation). Other options are to: >> >> * rename offset(long) to move(long), advance(long), or something else >> * drop offset() - but then add an overload of MemorySegment::asSlice >> which takes an address instead of a plain long offset >> >> I'll leave the choice to the reviewers :-) >> >> >> >> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >> Stuart, Roger, Joe and the Panama team for the feedback provided so >> far, which helped to get the API in the shape it is today. >> >> Cheers >> Maurizio >> >> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - >> but that is unrelated to this patch, and it's a known failing test. >> >> [1] - https://openjdk.java.net/jeps/370 >> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >> > From paul.sandoz at oracle.com Mon Dec 9 18:36:58 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Dec 2019 10:36:58 -0800 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> Message-ID: Oops, my bad, in my haste I misread the original code. (Effectively a reduction on OptionalLong where empty dominates, but the code to write that is I think less clear than the imperative loop.) Paul. > On Dec 7, 2019, at 11:02 AM, Maurizio Cimadamore wrote: > > > On 06/12/2019 21:04, Paul Sandoz wrote: >> GroupLayout.java >> ? >> >> 80 OptionalLong sizeof(List elems) { >> 81 long size = 0; >> 82 for (MemoryLayout elem : elems) { >> 83 if (AbstractLayout.optSize(elem).isPresent()) { >> 84 size = sizeOp.applyAsLong(size, elem.bitSize()); >> 85 } else { >> 86 return OptionalLong.empty(); >> 87 } >> 88 } >> 89 return OptionalLong.of(size); >> 90 } >> >> FWIW you can do this: >> >> OptionalLong sizeof(List elems) { >> return elems.stream().filter(e -> AbstractLayout.optSize(e).isPresent()).mapToLong(MemoryLayout::bitSize) >> .reduce(sizeOp); > > > Looked at this more carefully - the code you suggest has a slightly different behavior than the one I wrote - note that the original code short-circuit when the first layout member with no size is encountered. IIUC your code will just drop unsized member layouts, and compute size on the rest - which is not what I had in mind. Am I understanding correctly? > > Maurizio > From maurizio.cimadamore at oracle.com Mon Dec 9 19:23:36 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Dec 2019 19:23:36 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> Message-ID: <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> Another iteration: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/ Delta of the changes since last version (v3) here: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4_delta/ The javadoc has been updated inline here: http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html Summary of changes: * Improved javadoc regarding alignment and access modes in MemoryHandles * related to the above, the memory access varhandle now checks for low-level VM alignment to for access other than get/set (as happens for regular byte buffer view var handle) * fixed MemoryHandles, JavaLangInvokeAccess, VarHandles, MethodHandleImpl to speak about alignmentMask, rather than alignment (as per Roger comments) * added some more javadoc to internal classes MemoryAddressProxy, VarHandleMemoryAddressBase, JavaNioAccess.java and JavaLangInvokeAccess.java? (as per Roger comments) * fixed mising {code} block around alignment param A in MemoryLayout::bitAlignment/bytesAlignment (as per offline comments from Daniel) * added positive test to TestMemoryCopy Cheers Maurizio On 08/12/2019 01:44, Maurizio Cimadamore wrote: > Another update: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3/ > > And a delta of the changes since last version (v2) here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3_delta/ > > The javadoc has been updated inline here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Summary of changes: > > * fixed some (cosmetic) issues in FileChannelmpl following offline > discussion with Alan > * changed tests group definition, so that now jdk_foreign is part of > tier1_part3 > * updated javadoc in various places to fix code samples (as per Paul > comments) > * updated javadoc in MemoryHandles to talk about access modes (as per > Paul comments) - I added a new section on top, and then referred to in > from all relevant places > * some changes to use Objects.hash (as per Paul comments), and some > minor refactor in the AddreddGenerator (to use switch expression) > * tightened javadoc for MemoryAddress::copy - the method now is > specified to throw IAE if the range of source/dest addresses overlap - > I've fixed the impl and added a test (as per Raffaello comments) > * tightened byte buffer VarHandle view - if the view is created from a > byte buffer obtained from a segment (!!!) we should do a segment check > - added tests > > > And here's a list of the pending API-related issues. Since these are > IMHO minor issues, I suggest we defer them to a followup minor > cleanup, so that we can move ahead with finalization of the CSR with > the current API. Here's the list: > > * Should MemoryAddress implement Comparable? I think the answer is > "probably not" - an address doesn't have a 'length' so you can't > really do a range comparison (maybe memory segments though?). For now, > users can project to byte buffer and take it from there (since > ByteBuffer <: Comparable) > * should we have a? way to ask a Layout if its size is specified ? (Paul) > * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much > distance between these two semantically different operations (Paul > suggested using 'add' - which I'm not enthusiastic about because it's > not adding two addresses - it's adding a long to an address...) > * MemorySegment::isAccessible() -- as the A* word is overloaded, some > other name should be found? > * MemorySegment::acquire() -- replace with MemorySegment::fork? > > Thanks > Maurizio > > On 06/12/2019 10:43, Maurizio Cimadamore wrote: >> Hi, >> here's an updated version of the patch: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ >> >> And a delta of the changes since last version here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ >> >> The javadoc has been updated inline here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Summary of changes: >> >> * fixed spurious protected methods in AbstractLayout and subclasses >> which leaked into API >> * removed library_call.cpp changes, as these are being tracked >> separately by Vlad >> * compacted ILOAD code in AddressVarHandleGenerator >> * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope >> >> I have made no changes to the *name* of the methods in the API. In >> fact, I suggest we keep a list of the names we'd like to revisit, and >> we address them all at once at the end of the review (once we're >> happy with the contents). Here's a list of the current open naming >> issues: >> >> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much >> distance between these two semantically different operations >> * MemorySegment::isAccessible() -- as the A* word is overloaded, some >> other name should be found? >> * MemorySegment::acquire() -- replace with MemorySegment::fork? >> >> Cheers >> Maurizio >> >> >> On 05/12/2019 21:04, Maurizio Cimadamore wrote: >>> Hi, >>> as part of the effort to upstream the changes related to JEP 370 >>> (foreign memory access API) [1], I'd like to ask for a code review >>> for the corresponding core-libs and hotspot changes: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>> >>> A javadoc for the memory access API is also available here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>> >>> >>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>> >>> >>> Here is a brief summary of the changes in java.base and hotspot (the >>> remaining new files are implementation classes and tests for the new >>> API): >>> >>> * ciField.cpp - this one is to trust final fields in the foreign >>> memory access implementation (otherwise VM doesn't trust memory >>> segment bounds) >>> >>> * Modules.gmk - these changes are needed to require that the >>> incubating module is loaded by the boot loader (otherwise the above >>> changes are useless) >>> >>> * library_call.cpp - this one is a JIT compiler change to treat >>> Thread.currentThread() as a well-known constant - which helps a lot >>> in the confinement checks (thanks Vlad!) >>> >>> * various Buffer-related changes; these changes are needed because >>> the memory access API allows a memory segment to be projected into a >>> byte buffer, for interop reasons. As such, we need to insert a >>> liveness check in the various get/put methods. Previously we had an >>> implementation strategy where a BB was 'decorated' by a subclass >>> called ScopedBuffer - but doing so required some changes to the BB >>> API (e.g. making certain methods non-final, so that we could >>> decorate them). Here I use an approach (which I have discussed with >>> Alan) which doesn't require any public API changes, but needs to add >>> a 'segment' field in Buffer - and then have constructors which keep >>> track of this extra parameter. >>> >>> * FileChannel changes - these changes are required so that we can >>> reuse the Unmapper class from the MemorySegment implementation, to >>> deterministically deallocate a mapped memory segment. This should be >>> a 'straight' refactoring, no change in behavior should occur here. >>> Please double check. >>> >>> * VarHandles - this class now provides a factory to create memory >>> access VarHandle - this is a bit tricky, since VarHandle cannot >>> really be implemented outside java.base (e.g. VarForm is not >>> public). So we do the usual trick where we define a bunch of proxy >>> interfaces (see jdk/internal/access/foreign) have the classes in >>> java.base refer to these - and then have the implementation classes >>> of the memory access API implement these interfaces. >>> >>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we >>> need to provide access to otherwise hidden functionalities - e.g. >>> creating a new scoped buffer, or retrieving the properties of a >>> memory access handle (e.g. offset, stride etc.), so that we can >>> implement the memory access API in its own separate module >>> >>> * GensrcVarHandles.gmk - these changes are needed to enable the >>> generation of the new memory address var handle implementations; >>> there's an helper class per carrier (e.g. >>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory >>> access var handle is needed, we dynamically spin a new VH >>> implementation which makes use of the right carrier. We need to spin >>> because the VH can have a variable number of access coordinates >>> (e.g. depending on the dimensions of the array to be accessed). But, >>> under the hood, all the generated implementation will be using the >>> same helper class. >>> >>> * tests - we've tried to add fairly robust tests, often checking all >>> possible permutations of carriers/dimensions etc. Because of that, >>> the tests might not be the easiest to look at, but they have proven >>> to be pretty effective at shaking out issues. >>> >>> I think that covers the main aspects of the implementation and where >>> it differs from vanilla JDK. >>> >>> P.S. >>> >>> In the CSR review [2], Joe raised a fair point - which is >>> MemoryAddress has both: >>> >>> offset(long) --> move address of given offset >>> offset() --> return the offset of this address in its owning segment >>> >>> And this was considered suboptimal, given both methods use the same >>> name but do something quite different (one is an accessor, another >>> is a 'wither'). one obvious option is to rename the first to >>> 'withOffset'. But I think that would lead to verbose code (since >>> that is a very common operation). Other options are to: >>> >>> * rename offset(long) to move(long), advance(long), or something else >>> * drop offset() - but then add an overload of MemorySegment::asSlice >>> which takes an address instead of a plain long offset >>> >>> I'll leave the choice to the reviewers :-) >>> >>> >>> >>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>> Stuart, Roger, Joe and the Panama team for the feedback provided so >>> far, which helped to get the API in the shape it is today. >>> >>> Cheers >>> Maurizio >>> >>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" >>> - but that is unrelated to this patch, and it's a known failing test. >>> >>> [1] - https://openjdk.java.net/jeps/370 >>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>> From brent.christian at oracle.com Mon Dec 9 20:10:30 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 9 Dec 2019 12:10:30 -0800 Subject: RFR 8235361 : JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...") Message-ID: <7067cf9e-ce40-f647-b889-97017359d216@oracle.com> Hi, As discussed[1] last month on this alias, JAR Class-Path entries[2] that encode an absolute Windows path (including a drive letter, so e.g. "/C:/path/to/file.jar") are ignored as of 8211941. Such entries are legal relative URLs, and should not be ignored. Please review my fix to correct this. Issue: https://bugs.openjdk.java.net/browse/JDK-8235361 Webrev: http://cr.openjdk.java.net/~bchristi/8235361/webrev06-open/ Thanks, -Brent 1. https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063491.html 2. https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute From jonathan.gibbons at oracle.com Mon Dec 9 20:17:23 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 9 Dec 2019 12:17:23 -0800 Subject: RFR 8235361 : JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...") In-Reply-To: <7067cf9e-ce40-f647-b889-97017359d216@oracle.com> References: <7067cf9e-ce40-f647-b889-97017359d216@oracle.com> Message-ID: <7dcdfa6e-2a99-55ca-6d54-3d0987104242@oracle.com> I note that javac now uses the same definition of tryResolveFile in its handling of Class-Path manifest entries, and so the behavior for the compiler and runtime should now be aligned. -- Jon On 12/09/2019 12:10 PM, Brent Christian wrote: > Hi, > > As discussed[1] last month on this alias, JAR Class-Path entries[2] > that encode an absolute Windows path (including a drive letter, so > e.g. "/C:/path/to/file.jar") are ignored as of 8211941. > > Such entries are legal relative URLs, and should not be ignored. > Please review my fix to correct this. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8235361 > Webrev: > http://cr.openjdk.java.net/~bchristi/8235361/webrev06-open/ > > Thanks, > -Brent > > 1. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063491.html > > 2. > https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute > From paul.sandoz at oracle.com Mon Dec 9 20:32:15 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 9 Dec 2019 12:32:15 -0800 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> Message-ID: +1 Paul. > On Dec 9, 2019, at 11:23 AM, Maurizio Cimadamore wrote: > > Another iteration: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/ > > Delta of the changes since last version (v3) here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4_delta/ > > The javadoc has been updated inline here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > Summary of changes: > > * Improved javadoc regarding alignment and access modes in MemoryHandles > * related to the above, the memory access varhandle now checks for low-level VM alignment to for access other than get/set (as happens for regular byte buffer view var handle) > * fixed MemoryHandles, JavaLangInvokeAccess, VarHandles, MethodHandleImpl to speak about alignmentMask, rather than alignment (as per Roger comments) > * added some more javadoc to internal classes MemoryAddressProxy, VarHandleMemoryAddressBase, JavaNioAccess.java and JavaLangInvokeAccess.java (as per Roger comments) > * fixed mising {code} block around alignment param A in MemoryLayout::bitAlignment/bytesAlignment (as per offline comments from Daniel) > * added positive test to TestMemoryCopy > > Cheers > Maurizio > > On 08/12/2019 01:44, Maurizio Cimadamore wrote: >> Another update: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3/ >> >> And a delta of the changes since last version (v2) here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3_delta/ >> >> The javadoc has been updated inline here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> Summary of changes: >> >> * fixed some (cosmetic) issues in FileChannelmpl following offline discussion with Alan >> * changed tests group definition, so that now jdk_foreign is part of tier1_part3 >> * updated javadoc in various places to fix code samples (as per Paul comments) >> * updated javadoc in MemoryHandles to talk about access modes (as per Paul comments) - I added a new section on top, and then referred to in from all relevant places >> * some changes to use Objects.hash (as per Paul comments), and some minor refactor in the AddreddGenerator (to use switch expression) >> * tightened javadoc for MemoryAddress::copy - the method now is specified to throw IAE if the range of source/dest addresses overlap - I've fixed the impl and added a test (as per Raffaello comments) >> * tightened byte buffer VarHandle view - if the view is created from a byte buffer obtained from a segment (!!!) we should do a segment check - added tests >> >> >> And here's a list of the pending API-related issues. Since these are IMHO minor issues, I suggest we defer them to a followup minor cleanup, so that we can move ahead with finalization of the CSR with the current API. Here's the list: >> >> * Should MemoryAddress implement Comparable? I think the answer is "probably not" - an address doesn't have a 'length' so you can't really do a range comparison (maybe memory segments though?). For now, users can project to byte buffer and take it from there (since ByteBuffer <: Comparable) >> * should we have a way to ask a Layout if its size is specified ? (Paul) >> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much distance between these two semantically different operations (Paul suggested using 'add' - which I'm not enthusiastic about because it's not adding two addresses - it's adding a long to an address...) >> * MemorySegment::isAccessible() -- as the A* word is overloaded, some other name should be found? >> * MemorySegment::acquire() -- replace with MemorySegment::fork? >> >> Thanks >> Maurizio >> >> On 06/12/2019 10:43, Maurizio Cimadamore wrote: >>> Hi, >>> here's an updated version of the patch: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ >>> >>> And a delta of the changes since last version here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ >>> >>> The javadoc has been updated inline here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>> >>> Summary of changes: >>> >>> * fixed spurious protected methods in AbstractLayout and subclasses which leaked into API >>> * removed library_call.cpp changes, as these are being tracked separately by Vlad >>> * compacted ILOAD code in AddressVarHandleGenerator >>> * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope >>> >>> I have made no changes to the *name* of the methods in the API. In fact, I suggest we keep a list of the names we'd like to revisit, and we address them all at once at the end of the review (once we're happy with the contents). Here's a list of the current open naming issues: >>> >>> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much distance between these two semantically different operations >>> * MemorySegment::isAccessible() -- as the A* word is overloaded, some other name should be found? >>> * MemorySegment::acquire() -- replace with MemorySegment::fork? >>> >>> Cheers >>> Maurizio >>> >>> >>> On 05/12/2019 21:04, Maurizio Cimadamore wrote: >>>> Hi, >>>> as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code review for the corresponding core-libs and hotspot changes: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>>> >>>> A javadoc for the memory access API is also available here: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>>> >>>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>>> >>>> >>>> Here is a brief summary of the changes in java.base and hotspot (the remaining new files are implementation classes and tests for the new API): >>>> >>>> * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) >>>> >>>> * Modules.gmk - these changes are needed to require that the incubating module is loaded by the boot loader (otherwise the above changes are useless) >>>> >>>> * library_call.cpp - this one is a JIT compiler change to treat Thread.currentThread() as a well-known constant - which helps a lot in the confinement checks (thanks Vlad!) >>>> >>>> * various Buffer-related changes; these changes are needed because the memory access API allows a memory segment to be projected into a byte buffer, for interop reasons. As such, we need to insert a liveness check in the various get/put methods. Previously we had an implementation strategy where a BB was 'decorated' by a subclass called ScopedBuffer - but doing so required some changes to the BB API (e.g. making certain methods non-final, so that we could decorate them). Here I use an approach (which I have discussed with Alan) which doesn't require any public API changes, but needs to add a 'segment' field in Buffer - and then have constructors which keep track of this extra parameter. >>>> >>>> * FileChannel changes - these changes are required so that we can reuse the Unmapper class from the MemorySegment implementation, to deterministically deallocate a mapped memory segment. This should be a 'straight' refactoring, no change in behavior should occur here. Please double check. >>>> >>>> * VarHandles - this class now provides a factory to create memory access VarHandle - this is a bit tricky, since VarHandle cannot really be implemented outside java.base (e.g. VarForm is not public). So we do the usual trick where we define a bunch of proxy interfaces (see jdk/internal/access/foreign) have the classes in java.base refer to these - and then have the implementation classes of the memory access API implement these interfaces. >>>> >>>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to provide access to otherwise hidden functionalities - e.g. creating a new scoped buffer, or retrieving the properties of a memory access handle (e.g. offset, stride etc.), so that we can implement the memory access API in its own separate module >>>> >>>> * GensrcVarHandles.gmk - these changes are needed to enable the generation of the new memory address var handle implementations; there's an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access var handle is needed, we dynamically spin a new VH implementation which makes use of the right carrier. We need to spin because the VH can have a variable number of access coordinates (e.g. depending on the dimensions of the array to be accessed). But, under the hood, all the generated implementation will be using the same helper class. >>>> >>>> * tests - we've tried to add fairly robust tests, often checking all possible permutations of carriers/dimensions etc. Because of that, the tests might not be the easiest to look at, but they have proven to be pretty effective at shaking out issues. >>>> >>>> I think that covers the main aspects of the implementation and where it differs from vanilla JDK. >>>> >>>> P.S. >>>> >>>> In the CSR review [2], Joe raised a fair point - which is MemoryAddress has both: >>>> >>>> offset(long) --> move address of given offset >>>> offset() --> return the offset of this address in its owning segment >>>> >>>> And this was considered suboptimal, given both methods use the same name but do something quite different (one is an accessor, another is a 'wither'). one obvious option is to rename the first to 'withOffset'. But I think that would lead to verbose code (since that is a very common operation). Other options are to: >>>> >>>> * rename offset(long) to move(long), advance(long), or something else >>>> * drop offset() - but then add an overload of MemorySegment::asSlice which takes an address instead of a plain long offset >>>> >>>> I'll leave the choice to the reviewers :-) >>>> >>>> >>>> >>>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, Roger, Joe and the Panama team for the feedback provided so far, which helped to get the API in the shape it is today. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - but that is unrelated to this patch, and it's a known failing test. >>>> >>>> [1] - https://openjdk.java.net/jeps/370 >>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>>> From joe.darcy at oracle.com Mon Dec 9 20:39:55 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 9 Dec 2019 12:39:55 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: <75d9770e-9bfb-74e4-ed60-d0709ab53e5e@oracle.com> References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> <21ae2c12-f407-e7d9-ae38-9bb2bce51996@oracle.com> <75d9770e-9bfb-74e4-ed60-d0709ab53e5e@oracle.com> Message-ID: Updated webrev: ??? http://cr.openjdk.java.net/~darcy/8230771.0/ Found a class extending Modifier to the the static definitions; I replaced this with a static import. To make sure a class isn't instantiated, I usually have it throw AssertionError or some exception, although as you say that isn't strictly necessary in all cases. Thanks, -Joe On 12/9/2019 10:27 AM, Mandy Chung wrote: > It seems a bit overly cautious to throw AssertionError.? JDK has many > private no-arg constructor and it can be as simple as empty > constructor.? Just my preference. > > Mandy > > On 12/9/19 10:16 AM, Joe Darcy wrote: >> Corrected patch: >> >> diff -r 153e5f76551d >> src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >> --- >> a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >> Mon Dec 09 23:00:13 2019 +0530 >> +++ >> b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >> Mon Dec 09 10:15:44 2019 -0800 >> @@ -43,8 +43,7 @@ >> ???? /** >> ????? * Do not call. >> ????? */ >> -??? @Deprecated(forRemoval=true, since="14") >> -??? public ConstantBootstraps() {} >> +??? private ConstantBootstraps() {throw new AssertionError();} >> >> ???? // implements the upcall from the JVM, >> MethodHandleNatives.linkDynamicConstant: >> ???? /*non-public*/ >> diff -r 153e5f76551d >> src/java.base/share/classes/java/lang/reflect/Modifier.java >> --- a/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon >> Dec 09 23:00:13 2019 +0530 >> +++ b/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon >> Dec 09 10:15:44 2019 -0800 >> @@ -46,8 +46,7 @@ >> ???? /** >> ????? * Do not call. >> ????? */ >> -??? @Deprecated(forRemoval=true, since="14") >> -??? public Modifier() {} >> +??? private Modifier() {throw new AssertionError();} >> >> >> ???? /** >> >> -Joe >> >> On 12/9/2019 9:38 AM, Joe Darcy wrote: >>> Doh! Will correct. That is why I want to get the no-arg constructor >>> added as a javac warning (JDK-8071961) ;-) >>> >>> Thanks all for catching this, >>> >>> -Joe >>> >>> On 12/9/2019 9:29 AM, Mandy Chung wrote: >>>> Good catch!? Daniel also pointed that out.? I overlooked it. It >>>> needs to add back a private no-arg constructor. >>>> >>>> Mandy >>>> >>>> On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: >>>>> If you remove the deprecated constructor, the compiler will add a >>>>> default one. Wouldn't it be a better idea to make the deprecated >>>>> constructor private and throwing an exception? >>>>> >>>>> Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung >>>>> > escreveu: >>>>> >>>>> ??? Looks good. >>>>> >>>>> ??? Mandy >>>>> >>>>> ??? On 12/8/19 10:58 AM, Joe Darcy wrote: >>>>> ??? > Hello, >>>>> ??? > >>>>> ??? > Please review this small API changes for JDK 15: >>>>> ??? > >>>>> ??? > ??? JDK-8230771: Remove terminally deprecated constructors in >>>>> ??? java.base >>>>> ??? > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 >>>>> ??? > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ >>>>> ??? > >>>>> ??? > Patch below. >>>>> ??? > >>>>> ??? > Thanks, >>>>> ??? > >>>>> ??? > -Joe >>>>> ??? > >>>>> ??? > --- >>>>> ??? > >>>>> old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>> >>>>> >>>>> ??? > 2019-12-08 10:56:14.223168685 -0800 >>>>> ??? > +++ >>>>> ??? > >>>>> new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>> >>>>> >>>>> ??? > 2019-12-08 10:56:13.999168685 -0800 >>>>> ??? > @@ -40,12 +40,6 @@ >>>>> ??? > ? * @since 11 >>>>> ??? > ? */ >>>>> ??? > ?public final class ConstantBootstraps { >>>>> ??? > -??? /** >>>>> ??? > -???? * Do not call. >>>>> ??? > -???? */ >>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>> ??? > -??? public ConstantBootstraps() {} >>>>> ??? > - >>>>> ??? > ???? // implements the upcall from the JVM, >>>>> ??? > MethodHandleNatives.linkDynamicConstant: >>>>> ??? > ???? /*non-public*/ >>>>> ??? > ???? static Object makeConstant(MethodHandle bootstrapMethod, >>>>> ??? > --- >>>>> old/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>> ??? > 2019-12-08 10:56:14.775168685 -0800 >>>>> ??? > +++ >>>>> new/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>> ??? > 2019-12-08 10:56:14.555168685 -0800 >>>>> ??? > @@ -44,13 +44,6 @@ >>>>> ??? > ? */ >>>>> ??? > ?public class Modifier { >>>>> ??? > ???? /** >>>>> ??? > -???? * Do not call. >>>>> ??? > -???? */ >>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>> ??? > -??? public Modifier() {} >>>>> ??? > - >>>>> ??? > - >>>>> ??? > -??? /** >>>>> ??? > ????? * Return {@code true} if the integer argument includes >>>>> the >>>>> ??? > ????? * {@code public} modifier, {@code false} otherwise. >>>>> ??? > ????? * >>>>> ??? > >>>>> >>>> > From maurizio.cimadamore at oracle.com Mon Dec 9 21:30:20 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 9 Dec 2019 21:30:20 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: Message-ID: Hi again, after some offline discussions with the hotspot team, it became clear that the recently added restriction on source/destination segments being disjoint is redundant and that Unsafe::copyMemory can cope with overlap. For now I'l keep the API as is, but I will file a followup issue to remove the restriction from the API - which, I think, will also address your issue around lack of memmove ability. Thanks Maurizio On 09/12/2019 11:10, Maurizio Cimadamore wrote: > Hi Raffaello, > I think there is room to add more copy-related features in the future. > One thing to note, however: the rationale behind having a 'copy' > method is to expose a (safe) interface to the underlying > Unsafe::copyMemory method - which is an hotspot intrinsic, hence > understood and optimized by the JIT compiler. I'd say that, if we were > to add another method like 'memmove' we'd have to work out the VM > plumbing first - and then add the MemoryAddress API method. This has > been the informal guiding principle for the operations exposed by this > API. > > That said - I'll keep a note of the suggestion, and add it to the list. > > Cheers > Maurizio > > On 09/12/2019 10:11, Raffaello Giulietti wrote: >> Hi, >> >> will there be a >> >> MemoryAddress.move(MemoryAddress src, MemoryAddress dst, long bytes) >> >> method with POSIX memmove(3) semantics at some point? >> >> That would be useful, e.g., to "open a hole" into an array by >> shifting existing elements towards higher indices (provided there's >> room). >> >> MemoryAddress.copy(), with its lower-to-higher semantics, doesn't >> really help here, so without move() one would need to code an >> explicit loop for such a case, I guess. Not a big deal, just a little >> bit annoying. >> >> >> Greetings >> Raffaello >> >> >> >> On 2019-12-07 00:51, Maurizio Cimadamore wrote: >>> >>> On 06/12/2019 18:29, Raffaello Giulietti wrote: >>>> Hello, >>>> >>>> great job! >>>> >>>> I think that the doc of MemoryAddress.copy() should be explicit >>>> about the direction of the copying, so it should either: >>> >>> Thanks! -? I'll rectify the doc to specify lower-to-higher. >>> >>> Maurizio >>> >>>> >>>> * explicitly specify a direction, e.g., lower-to-higher addresses >>>> >>>> * or specify that in the case of an overlap the copying is smart >>>> enough to not destroy the src bytes before they have landed in dst >>>> >>>> * or accept a negative third argument to encode a higher-to-lower >>>> addresses copying direction. >>>> >>>> >>>> Greetings >>>> Raffaello >>>> >>>> >>>> >>>>> Hi, >>>>> as part of the effort to upstream the changes related to JEP 370 >>>>> (foreign memory access API) [1], I'd like to ask for a code review >>>>> for the corresponding core-libs and hotspot changes: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>>>> >>>>> A javadoc for the memory access API is also available here: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>>>> >>>>> >>>>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>>>> >>>>> >>>>> Here is a brief summary of the changes in java.base and hotspot >>>>> (the remaining new files are implementation classes and tests for >>>>> the new API): >>>>> >>>>> * ciField.cpp - this one is to trust final fields in the foreign >>>>> memory access implementation (otherwise VM doesn't trust memory >>>>> segment bounds) >>>>> >>>>> * Modules.gmk - these changes are needed to require that the >>>>> incubating module is loaded by the boot loader (otherwise the >>>>> above changes are useless) >>>>> >>>>> * library_call.cpp - this one is a JIT compiler change to treat >>>>> Thread.currentThread() as a well-known constant - which helps a >>>>> lot in the confinement checks (thanks Vlad!) >>>>> >>>>> * various Buffer-related changes; these changes are needed because >>>>> the memory access API allows a memory segment to be projected into >>>>> a byte buffer, for interop reasons. As such, we need to insert a >>>>> liveness check in the various get/put methods. Previously we had >>>>> an implementation strategy where a BB was 'decorated' by a >>>>> subclass called ScopedBuffer - but doing so required some changes >>>>> to the BB API (e.g. making certain methods non-final, so that we >>>>> could decorate them). Here I use an approach (which I have >>>>> discussed with Alan) which doesn't require any public API changes, >>>>> but needs to add a 'segment' field in Buffer - and then have >>>>> constructors which keep track of this extra parameter. >>>>> >>>>> * FileChannel changes - these changes are required so that we can >>>>> reuse the Unmapper class from the MemorySegment implementation, to >>>>> deterministically deallocate a mapped memory segment. This should >>>>> be a 'straight' refactoring, no change in behavior should occur >>>>> here. Please double check. >>>>> >>>>> * VarHandles - this class now provides a factory to create memory >>>>> access VarHandle - this is a bit tricky, since VarHandle cannot >>>>> really be implemented outside java.base (e.g. VarForm is not >>>>> public). So we do the usual trick where we define a bunch of proxy >>>>> interfaces (see jdk/internal/access/foreign) have the classes in >>>>> java.base refer to these - and then have the implementation >>>>> classes of the memory access API implement these interfaces. >>>>> >>>>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we >>>>> need to provide access to otherwise hidden functionalities - e.g. >>>>> creating a new scoped buffer, or retrieving the properties of a >>>>> memory access handle (e.g. offset, stride etc.), so that we can >>>>> implement the memory access API in its own separate module >>>>> >>>>> * GensrcVarHandles.gmk - these changes are needed to enable the >>>>> generation of the new memory address var handle implementations; >>>>> there's an helper class per carrier (e.g. >>>>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory >>>>> access var handle is needed, we dynamically spin a new VH >>>>> implementation which makes use of the right carrier. We need to >>>>> spin because the VH can have a variable number of access >>>>> coordinates (e.g. depending on the dimensions of the array to be >>>>> accessed). But, under the hood, all the generated implementation >>>>> will be using the same helper class. >>>>> >>>>> * tests - we've tried to add fairly robust tests, often checking >>>>> all possible permutations of carriers/dimensions etc. Because of >>>>> that, the tests might not be the easiest to look at, but they have >>>>> proven to be pretty effective at shaking out issues. >>>>> >>>>> I think that covers the main aspects of the implementation and >>>>> where it differs from vanilla JDK. >>>>> >>>>> P.S. >>>>> >>>>> In the CSR review [2], Joe raised a fair point - which is >>>>> MemoryAddress has both: >>>>> >>>>> offset(long) --> move address of given offset >>>>> offset() --> return the offset of this address in its owning segment >>>>> >>>>> And this was considered suboptimal, given both methods use the >>>>> same name but do something quite different (one is an accessor, >>>>> another is a 'wither'). one obvious option is to rename the first >>>>> to 'withOffset'. But I think that would lead to verbose code >>>>> (since that is a very common operation). Other options are to: >>>>> >>>>> * rename offset(long) to move(long), advance(long), or something else >>>>> * drop offset() - but then add an overload of >>>>> MemorySegment::asSlice which takes an address instead of a plain >>>>> long offset >>>>> >>>>> I'll leave the choice to the reviewers :-) >>>>> >>>>> >>>>> >>>>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>>>> Stuart, Roger, Joe and the Panama team for the feedback provided >>>>> so far, which helped to get the API in the shape it is today. >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>>> (**) There is one failure, for >>>>> "java/util/TimeZone/Bug6329116.java" - but that is unrelated to >>>>> this patch, and it's a known failing test. >>>>> >>>>> [1] - https://openjdk.java.net/jeps/370 >>>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>>> >>>> >> From joe.darcy at oracle.com Mon Dec 9 21:34:25 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 9 Dec 2019 13:34:25 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> <21ae2c12-f407-e7d9-ae38-9bb2bce51996@oracle.com> <75d9770e-9bfb-74e4-ed60-d0709ab53e5e@oracle.com> Message-ID: <6c096c92-3b12-c0f7-dbf2-b5e914e46511@oracle.com> PS That should be ??? http://cr.openjdk.java.net/~darcy/8230771.1 Cheers, -Joe On 12/9/2019 12:39 PM, Joe Darcy wrote: > Updated webrev: > > ??? http://cr.openjdk.java.net/~darcy/8230771.0/ > > Found a class extending Modifier to the the static definitions; I > replaced this with a static import. > > To make sure a class isn't instantiated, I usually have it throw > AssertionError or some exception, although as you say that isn't > strictly necessary in all cases. > > Thanks, > > -Joe > > On 12/9/2019 10:27 AM, Mandy Chung wrote: >> It seems a bit overly cautious to throw AssertionError.? JDK has many >> private no-arg constructor and it can be as simple as empty >> constructor.? Just my preference. >> >> Mandy >> >> On 12/9/19 10:16 AM, Joe Darcy wrote: >>> Corrected patch: >>> >>> diff -r 153e5f76551d >>> src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>> --- >>> a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>> Mon Dec 09 23:00:13 2019 +0530 >>> +++ >>> b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>> Mon Dec 09 10:15:44 2019 -0800 >>> @@ -43,8 +43,7 @@ >>> ???? /** >>> ????? * Do not call. >>> ????? */ >>> -??? @Deprecated(forRemoval=true, since="14") >>> -??? public ConstantBootstraps() {} >>> +??? private ConstantBootstraps() {throw new AssertionError();} >>> >>> ???? // implements the upcall from the JVM, >>> MethodHandleNatives.linkDynamicConstant: >>> ???? /*non-public*/ >>> diff -r 153e5f76551d >>> src/java.base/share/classes/java/lang/reflect/Modifier.java >>> --- a/src/java.base/share/classes/java/lang/reflect/Modifier.java >>> Mon Dec 09 23:00:13 2019 +0530 >>> +++ b/src/java.base/share/classes/java/lang/reflect/Modifier.java >>> Mon Dec 09 10:15:44 2019 -0800 >>> @@ -46,8 +46,7 @@ >>> ???? /** >>> ????? * Do not call. >>> ????? */ >>> -??? @Deprecated(forRemoval=true, since="14") >>> -??? public Modifier() {} >>> +??? private Modifier() {throw new AssertionError();} >>> >>> >>> ???? /** >>> >>> -Joe >>> >>> On 12/9/2019 9:38 AM, Joe Darcy wrote: >>>> Doh! Will correct. That is why I want to get the no-arg constructor >>>> added as a javac warning (JDK-8071961) ;-) >>>> >>>> Thanks all for catching this, >>>> >>>> -Joe >>>> >>>> On 12/9/2019 9:29 AM, Mandy Chung wrote: >>>>> Good catch!? Daniel also pointed that out.? I overlooked it. It >>>>> needs to add back a private no-arg constructor. >>>>> >>>>> Mandy >>>>> >>>>> On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: >>>>>> If you remove the deprecated constructor, the compiler will add a >>>>>> default one. Wouldn't it be a better idea to make the deprecated >>>>>> constructor private and throwing an exception? >>>>>> >>>>>> Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung >>>>>> > escreveu: >>>>>> >>>>>> ??? Looks good. >>>>>> >>>>>> ??? Mandy >>>>>> >>>>>> ??? On 12/8/19 10:58 AM, Joe Darcy wrote: >>>>>> ??? > Hello, >>>>>> ??? > >>>>>> ??? > Please review this small API changes for JDK 15: >>>>>> ??? > >>>>>> ??? > ??? JDK-8230771: Remove terminally deprecated constructors in >>>>>> ??? java.base >>>>>> ??? > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 >>>>>> ??? > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ >>>>>> ??? > >>>>>> ??? > Patch below. >>>>>> ??? > >>>>>> ??? > Thanks, >>>>>> ??? > >>>>>> ??? > -Joe >>>>>> ??? > >>>>>> ??? > --- >>>>>> ??? > >>>>>> old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>>> >>>>>> >>>>>> ??? > 2019-12-08 10:56:14.223168685 -0800 >>>>>> ??? > +++ >>>>>> ??? > >>>>>> new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>>> >>>>>> >>>>>> ??? > 2019-12-08 10:56:13.999168685 -0800 >>>>>> ??? > @@ -40,12 +40,6 @@ >>>>>> ??? > ? * @since 11 >>>>>> ??? > ? */ >>>>>> ??? > ?public final class ConstantBootstraps { >>>>>> ??? > -??? /** >>>>>> ??? > -???? * Do not call. >>>>>> ??? > -???? */ >>>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>>> ??? > -??? public ConstantBootstraps() {} >>>>>> ??? > - >>>>>> ??? > ???? // implements the upcall from the JVM, >>>>>> ??? > MethodHandleNatives.linkDynamicConstant: >>>>>> ??? > ???? /*non-public*/ >>>>>> ??? > ???? static Object makeConstant(MethodHandle bootstrapMethod, >>>>>> ??? > --- >>>>>> old/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>>> ??? > 2019-12-08 10:56:14.775168685 -0800 >>>>>> ??? > +++ >>>>>> new/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>>> ??? > 2019-12-08 10:56:14.555168685 -0800 >>>>>> ??? > @@ -44,13 +44,6 @@ >>>>>> ??? > ? */ >>>>>> ??? > ?public class Modifier { >>>>>> ??? > ???? /** >>>>>> ??? > -???? * Do not call. >>>>>> ??? > -???? */ >>>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>>> ??? > -??? public Modifier() {} >>>>>> ??? > - >>>>>> ??? > - >>>>>> ??? > -??? /** >>>>>> ??? > ????? * Return {@code true} if the integer argument >>>>>> includes the >>>>>> ??? > ????? * {@code public} modifier, {@code false} otherwise. >>>>>> ??? > ????? * >>>>>> ??? > >>>>>> >>>>> >> From andy.herrick at oracle.com Mon Dec 9 21:42:36 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Dec 2019 16:42:36 -0500 Subject: RFR: JDK-8234867: Issue warning for mutually exclusive options on jpackage command line Message-ID: Please review simple fix [2] for jpackage bug [1] fixing error message for mutually exclusive options. /Andy [1] https://bugs.openjdk.java.net/browse/JDK-8234867 [2] http://cr.openjdk.java.net/~herrick/8234867/webrev.01/ From raffaello.giulietti at gmail.com Mon Dec 9 21:43:27 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 9 Dec 2019 22:43:27 +0100 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: Message-ID: <19cdb67f-35ec-2b5c-e590-f4d0874430c3@gmail.com> Fine, thanks! Raffaello On 2019-12-09 22:30, Maurizio Cimadamore wrote: > Hi again, > after some offline discussions with the hotspot team, it became clear > that the recently added restriction on source/destination segments being > disjoint is redundant and that Unsafe::copyMemory can cope with overlap. > For now I'l keep the API as is, but I will file a followup issue to > remove the restriction from the API - which, I think, will also address > your issue around lack of memmove ability. > > Thanks > Maurizio > > On 09/12/2019 11:10, Maurizio Cimadamore wrote: >> Hi Raffaello, >> I think there is room to add more copy-related features in the future. >> One thing to note, however: the rationale behind having a 'copy' >> method is to expose a (safe) interface to the underlying >> Unsafe::copyMemory method - which is an hotspot intrinsic, hence >> understood and optimized by the JIT compiler. I'd say that, if we were >> to add another method like 'memmove' we'd have to work out the VM >> plumbing first - and then add the MemoryAddress API method. This has >> been the informal guiding principle for the operations exposed by this >> API. >> >> That said - I'll keep a note of the suggestion, and add it to the list. >> >> Cheers >> Maurizio >> >> On 09/12/2019 10:11, Raffaello Giulietti wrote: >>> Hi, >>> >>> will there be a >>> >>> MemoryAddress.move(MemoryAddress src, MemoryAddress dst, long bytes) >>> >>> method with POSIX memmove(3) semantics at some point? >>> >>> That would be useful, e.g., to "open a hole" into an array by >>> shifting existing elements towards higher indices (provided there's >>> room). >>> >>> MemoryAddress.copy(), with its lower-to-higher semantics, doesn't >>> really help here, so without move() one would need to code an >>> explicit loop for such a case, I guess. Not a big deal, just a little >>> bit annoying. >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> On 2019-12-07 00:51, Maurizio Cimadamore wrote: >>>> >>>> On 06/12/2019 18:29, Raffaello Giulietti wrote: >>>>> Hello, >>>>> >>>>> great job! >>>>> >>>>> I think that the doc of MemoryAddress.copy() should be explicit >>>>> about the direction of the copying, so it should either: >>>> >>>> Thanks! -? I'll rectify the doc to specify lower-to-higher. >>>> >>>> Maurizio >>>> >>>>> >>>>> * explicitly specify a direction, e.g., lower-to-higher addresses >>>>> >>>>> * or specify that in the case of an overlap the copying is smart >>>>> enough to not destroy the src bytes before they have landed in dst >>>>> >>>>> * or accept a negative third argument to encode a higher-to-lower >>>>> addresses copying direction. >>>>> >>>>> >>>>> Greetings >>>>> Raffaello >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> as part of the effort to upstream the changes related to JEP 370 >>>>>> (foreign memory access API) [1], I'd like to ask for a code review >>>>>> for the corresponding core-libs and hotspot changes: >>>>>> >>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>>>>> >>>>>> A javadoc for the memory access API is also available here: >>>>>> >>>>>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>>>>> >>>>>> >>>>>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>>>>> >>>>>> >>>>>> Here is a brief summary of the changes in java.base and hotspot >>>>>> (the remaining new files are implementation classes and tests for >>>>>> the new API): >>>>>> >>>>>> * ciField.cpp - this one is to trust final fields in the foreign >>>>>> memory access implementation (otherwise VM doesn't trust memory >>>>>> segment bounds) >>>>>> >>>>>> * Modules.gmk - these changes are needed to require that the >>>>>> incubating module is loaded by the boot loader (otherwise the >>>>>> above changes are useless) >>>>>> >>>>>> * library_call.cpp - this one is a JIT compiler change to treat >>>>>> Thread.currentThread() as a well-known constant - which helps a >>>>>> lot in the confinement checks (thanks Vlad!) >>>>>> >>>>>> * various Buffer-related changes; these changes are needed because >>>>>> the memory access API allows a memory segment to be projected into >>>>>> a byte buffer, for interop reasons. As such, we need to insert a >>>>>> liveness check in the various get/put methods. Previously we had >>>>>> an implementation strategy where a BB was 'decorated' by a >>>>>> subclass called ScopedBuffer - but doing so required some changes >>>>>> to the BB API (e.g. making certain methods non-final, so that we >>>>>> could decorate them). Here I use an approach (which I have >>>>>> discussed with Alan) which doesn't require any public API changes, >>>>>> but needs to add a 'segment' field in Buffer - and then have >>>>>> constructors which keep track of this extra parameter. >>>>>> >>>>>> * FileChannel changes - these changes are required so that we can >>>>>> reuse the Unmapper class from the MemorySegment implementation, to >>>>>> deterministically deallocate a mapped memory segment. This should >>>>>> be a 'straight' refactoring, no change in behavior should occur >>>>>> here. Please double check. >>>>>> >>>>>> * VarHandles - this class now provides a factory to create memory >>>>>> access VarHandle - this is a bit tricky, since VarHandle cannot >>>>>> really be implemented outside java.base (e.g. VarForm is not >>>>>> public). So we do the usual trick where we define a bunch of proxy >>>>>> interfaces (see jdk/internal/access/foreign) have the classes in >>>>>> java.base refer to these - and then have the implementation >>>>>> classes of the memory access API implement these interfaces. >>>>>> >>>>>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we >>>>>> need to provide access to otherwise hidden functionalities - e.g. >>>>>> creating a new scoped buffer, or retrieving the properties of a >>>>>> memory access handle (e.g. offset, stride etc.), so that we can >>>>>> implement the memory access API in its own separate module >>>>>> >>>>>> * GensrcVarHandles.gmk - these changes are needed to enable the >>>>>> generation of the new memory address var handle implementations; >>>>>> there's an helper class per carrier (e.g. >>>>>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory >>>>>> access var handle is needed, we dynamically spin a new VH >>>>>> implementation which makes use of the right carrier. We need to >>>>>> spin because the VH can have a variable number of access >>>>>> coordinates (e.g. depending on the dimensions of the array to be >>>>>> accessed). But, under the hood, all the generated implementation >>>>>> will be using the same helper class. >>>>>> >>>>>> * tests - we've tried to add fairly robust tests, often checking >>>>>> all possible permutations of carriers/dimensions etc. Because of >>>>>> that, the tests might not be the easiest to look at, but they have >>>>>> proven to be pretty effective at shaking out issues. >>>>>> >>>>>> I think that covers the main aspects of the implementation and >>>>>> where it differs from vanilla JDK. >>>>>> >>>>>> P.S. >>>>>> >>>>>> In the CSR review [2], Joe raised a fair point - which is >>>>>> MemoryAddress has both: >>>>>> >>>>>> offset(long) --> move address of given offset >>>>>> offset() --> return the offset of this address in its owning segment >>>>>> >>>>>> And this was considered suboptimal, given both methods use the >>>>>> same name but do something quite different (one is an accessor, >>>>>> another is a 'wither'). one obvious option is to rename the first >>>>>> to 'withOffset'. But I think that would lead to verbose code >>>>>> (since that is a very common operation). Other options are to: >>>>>> >>>>>> * rename offset(long) to move(long), advance(long), or something else >>>>>> * drop offset() - but then add an overload of >>>>>> MemorySegment::asSlice which takes an address instead of a plain >>>>>> long offset >>>>>> >>>>>> I'll leave the choice to the reviewers :-) >>>>>> >>>>>> >>>>>> >>>>>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>>>>> Stuart, Roger, Joe and the Panama team for the feedback provided >>>>>> so far, which helped to get the API in the shape it is today. >>>>>> >>>>>> Cheers >>>>>> Maurizio >>>>>> >>>>>> (**) There is one failure, for >>>>>> "java/util/TimeZone/Bug6329116.java" - but that is unrelated to >>>>>> this patch, and it's a known failing test. >>>>>> >>>>>> [1] - https://openjdk.java.net/jeps/370 >>>>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>>>> >>>>> >>> From Nikola.Grcevski at microsoft.com Mon Dec 9 21:58:19 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Mon, 9 Dec 2019 21:58:19 +0000 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> Message-ID: Hi Henry and Kumar, Thank you again for the review! I have added the fix to isTerminalOpt and used both of your suggestions to make new tests. With native memory tracking enabled, I could actually see a crash on both Linux and Windows without the suggested fix. I tested the changes again on both Linux and Windows, and the new unit tests fail if isTerminalOpt doesn?t check for ?module= as per Henry's suggestion. I'm attaching the new patch (my apologies for the size) at the bottom of this email after my signature. If I haven't covered certain aspects in the new tests please let me know, I'm more than happy to extend them further. I've updated the webrev to reflect the latest patch if it's easier to read: https://grcevski.github.io/JDK-8234076/webrev/ Thanks again! Nikola diff -r bd436284147d src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/share/native/libjli/args.c Mon Dec 09 16:08:54 2019 -0500 @@ -130,6 +130,8 @@ } } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { stopExpansion = JNI_TRUE; + } else if (JLI_StrCCmp(arg, "--module=") == 0) { + idx = argsCount; } } else { if (!expectingNoDashArg) { @@ -449,6 +451,7 @@ return JLI_StrCmp(arg, "-jar") == 0 || JLI_StrCmp(arg, "-m") == 0 || JLI_StrCmp(arg, "--module") == 0 || + JLI_StrCCmp(arg, "--module=") == 0 || JLI_StrCmp(arg, "--dry-run") == 0 || JLI_StrCmp(arg, "-h") == 0 || JLI_StrCmp(arg, "-?") == 0 || diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/windows/native/libjli/java_md.c Mon Dec 09 16:08:54 2019 -0500 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include "java.h" @@ -1015,6 +1016,17 @@ // sanity check, match the args we have, to the holy grail idx = JLI_GetAppArgIndex(); + + // First arg index is NOT_FOUND + if (idx < 0) { + // The only allowed value should be NOT_FOUND (-1) unless another change introduces + // a different negative index + assert (idx == -1); + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); + JLI_TraceLauncher("passing arguments as-is.\n"); + return NewPlatformStringArray(env, strv, argc); + } + isTool = (idx == 0); if (isTool) { idx++; } // skip tool name JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Mon Dec 09 16:08:54 2019 -0500 @@ -37,6 +37,8 @@ import java.util.List; import java.util.Map; import java.util.regex.Pattern; +import java.nio.file.Paths; +import java.nio.file.Path; public class ArgsEnvVar extends TestHelper { private static File testJar = null; @@ -153,6 +155,7 @@ List.of("-jar", "test.jar"), List.of("-m", "test/Foo"), List.of("--module", "test/Foo"), + List.of("--module=test/Foo"), List.of("--dry-run"), List.of("-h"), List.of("-?"), @@ -241,6 +244,101 @@ verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); } + /** + * Helper method to initialize a simple module that just prints the passed in arguments + */ + private void initModulesDir(File modulesDir) throws IOException { + if (modulesDir.exists()) { + recursiveDelete(modulesDir); + } + + modulesDir.mkdirs(); + + File srcDir = new File(modulesDir, "src"); + File modsDir = new File(modulesDir, "mods"); + File testDir = new File(srcDir, "test"); + File launcherTestDir = new File(testDir, "launcher"); + srcDir.mkdir(); + modsDir.mkdir(); + testDir.mkdir(); + launcherTestDir.mkdir(); + + ArrayList scratchpad = new ArrayList<>(); + scratchpad.add("module test {}"); + createFile(new File(testDir, "module-info.java"), scratchpad); + scratchpad.clear(); + scratchpad.add("package launcher;"); + scratchpad.add("import java.util.Arrays;"); + scratchpad.add("public class Main {"); + scratchpad.add("public static void main(String[] args) {"); + scratchpad.add("System.out.println(Arrays.toString(args));"); + scratchpad.add("}"); + scratchpad.add("}"); + createFile(new File(launcherTestDir, "Main.java"), scratchpad); + } + + @Test + // That that we can correctly handle the module longform argument option + // when supplied in an argument file + public void modulesInArgsFile() throws IOException { + File cwd = new File("."); + File testModuleDir = new File(cwd, "modules_test"); + + initModulesDir(testModuleDir); + + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); + + // test module / main class + String MODULE_OPTION = "--module=test/launcher.Main"; + String TEST_MODULE = "test"; + + // javac -d mods/test src/test/** + TestResult tr = doExec( + javacCmd, + "-d", MODS_DIR.toString(), + "--module-source-path", SRC_DIR.toString(), + "--module", TEST_MODULE); + + if (!tr.isOK()) { + System.out.println("test did not compile"); + throw new RuntimeException("Error: modules test did not compile"); + } + + // verify the terminating ability of --module= through environment variables + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); + tr = doExec(env, javaCmd); + tr.checkNegative(); + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); + if (!tr.testStatus) { + System.out.println(tr); + throw new RuntimeException("test fails"); + } + + // check that specifying --module and --module-path with file works + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); + tr.contains("[--hello]"); + if (!tr.testStatus) { + System.out.println(tr); + throw new RuntimeException("test fails"); + } + + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); + tr.checkNegative(); + if (!tr.testStatus) { + System.out.println(tr); + throw new RuntimeException("test fails"); + } + + // clean-up + argFile.delete(); + argFile1.delete(); + recursiveDelete(testModuleDir); + } + public static void main(String... args) throws Exception { init(); ArgsEnvVar a = new ArgsEnvVar(); diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Mon Dec 09 16:08:54 2019 -0500 @@ -246,6 +246,10 @@ if (!tr.contains("Error: Could not find or load main class AbsentClass")) { throw new RuntimeException("Test Fails"); } + + // Make sure we handle correctly the module long form (--module=) + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); + ensureNoWarnings(tr); } void ensureNoWarnings(TestResult tr) { diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Mon Dec 09 16:08:54 2019 -0500 @@ -29,6 +29,7 @@ * jdk.jlink * @build BasicTest jdk.test.lib.compiler.CompilerUtils * @run testng BasicTest + * @bug 8234076 * @summary Basic test of starting an application as a module */ @@ -40,6 +41,8 @@ import jdk.test.lib.compiler.CompilerUtils; import jdk.test.lib.process.ProcessTools; +import jdk.test.lib.process.OutputAnalyzer; +import jdk.test.lib.Utils; import org.testng.annotations.BeforeTest; import org.testng.annotations.Test; @@ -70,6 +73,8 @@ // the module main class private static final String MAIN_CLASS = "jdk.test.Main"; + // for Windows specific launcher tests + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); @BeforeTest public void compileTestModule() throws Exception { @@ -259,4 +264,87 @@ assertTrue(exitValue != 0); } + + /** + * Helper method that creates a ProcessBuilder with command line arguments + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. + */ + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); + + return pb; + } + + /** + * Test the ability for the Windows launcher to do proper application argument + * detection and expansion, when using the long form module option and all passed in + * command line arguments are prefixed with a dash. + * + * These tests are not expected to work on *nixes, and are ignored. + */ + public void testWindowsWithLongFormModuleOption() throws Exception { + if (!IS_WINDOWS) { + return; + } + + String dir = MODS_DIR.toString(); + String mid = TEST_MODULE + "/" + MAIN_CLASS; + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help + // We should be able to find the argument --help as an application argument + ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + "--help")) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("F--help"); + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help + // We should be able to see argument expansion happen + ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", + "--help")) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("F--help") + .shouldContain("module-info.java"); + } + + + /** + * Test that --module= is terminating for VM argument processing just like --module + */ + public void testLongFormModuleOptionTermination() throws Exception { + String dir = MODS_DIR.toString(); + String mid = TEST_MODULE + "/" + MAIN_CLASS; + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be + // deemed as application arguments + OutputAnalyzer output = ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + "--module-path=" + dir, + "--module=" + mid)) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("argv[ 0] = '--module-path=" + dir) + .shouldContain("argv[ 1] = '--module=" + mid); + + if (IS_WINDOWS) { + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); + } + + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods + // This command line will not work as --module= is terminating and the module will be not found + int exitValue = exec("--module=" + mid, "--module-path" + dir); + assertTrue(exitValue != 0); + } } From: Kumar Srinivasan Sent: December 7, 2019 10:28 PM To: Henry Jen Cc: Nikola Grcevski ; Alan Bateman ; core-libs-dev at openjdk.java.net Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate Hi, The launcher fix looks good, despite the launcher fix being simple, please note,? it sometimes requires a lot more effort to write a test for it, please read on.... Henry excellent catch wrt. ?isTerminalOp the launcher!!!, that tickled my memory and I recalled? this change for VM's native memory tracking. https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875799903&sdata=WOjzJJtIY0y4rB2liNkH4nUMNLq2uEnJ8J01gWFgt5w%3D&reserved=0 Inspecting the above changeset, we might have to add another test for JVM native memory tracking, since this is a terminal argument.? Maybe TestHelper could create a simple module, which prints its args, https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875809897&sdata=1GLeqSPxVRhGVgE7Cxf6w5l%2F34uOHCGTq2fRIjoxaGg%3D&reserved=0 Kumar Srinivasan On Fri, Dec 6, 2019 at 2:44 PM Henry Jen wrote: Thanks for the work, the test case covers that when ?module= is used before other options, which is good. But we need another to make sure that when ?module= is put in an argument file or environment variable, that should not be allowed. The fix is simple, we need to add that to isTerminalOp() method. Cheers, Henry > On Dec 6, 2019, at 12:28 PM, Nikola Grcevski wrote: > > Thank you Henry! > > I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. > > I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875809897&sdata=4iDS4fvjQlBxrGBhaLz3lHIWM7gNvFrvz01cqw%2B6O34%3D&reserved=0) > > Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c? ? ? ? Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/share/native/libjli/args.c? ? ? ? Fri Dec 06 15:11:36 2019 -0500 > @@ -130,6 +130,8 @@ >? ? ? ? ? ? ?} >? ? ? ? ?} else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >? ? ? ? ? ? ?stopExpansion = JNI_TRUE; > +? ? ? ? } else if (JLI_StrCCmp(arg, "--module=") == 0) { > +? ? ? ? ? ? idx = argsCount; >? ? ? ? ?} >? ? ?} else { >? ? ? ? ?if (!expectingNoDashArg) { > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c? ?Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c? ?Fri Dec 06 15:11:36 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > >? ? ?// sanity check, match the args we have, to the holy grail >? ? ?idx = JLI_GetAppArgIndex(); > + > +? ? // First arg index is NOT_FOUND > +? ? if (idx < 0) { > +? ? ? ? // The only allowed value should be NOT_FOUND (-1) unless another change introduces > +? ? ? ? // a different negative index > +? ? ? ? assert (idx == -1); > +? ? ? ? JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); > +? ? ? ? JLI_TraceLauncher("passing arguments as-is.\n"); > +? ? ? ? return NewPlatformStringArray(env, strv, argc); > +? ? } > + >? ? ?isTool = (idx == 0); >? ? ?if (isTool) { idx++; } // skip tool name >? ? ?JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java? ? Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java? ? Fri Dec 06 15:11:36 2019 -0500 > @@ -29,6 +29,7 @@ >? *? ? ? ? ? jdk.jlink >? * @build BasicTest jdk.test.lib.compiler.CompilerUtils >? * @run testng BasicTest > + * @bug 8234076 >? * @summary Basic test of starting an application as a module >? */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ >? ? ?// the module main class >? ? ?private static final String MAIN_CLASS = "jdk.test.Main"; > > +? ? // for Windows specific launcher tests > +? ? static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875809897&sdata=uU7AkmEbqKgfgeONT8Cvkr0YX57x1xNmtLkqq1AMIsg%3D&reserved=0", "unknown").startsWith("Windows"); > >? ? ?@BeforeTest >? ? ?public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ >? ? ? ? ?assertTrue(exitValue != 0); >? ? ?} > > + > +? ? /** > +? ? ?* Helper method that creates a ProcessBuilder with command line arguments > +? ? ?* while setting the _JAVA_LAUNCHER_DEBUG environment variable. > +? ? ?*/ > +? ? private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { > +? ? ? ? ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > +? ? ? ? pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > +? ? ? ? return pb; > +? ? } > + > +? ? ?/** > +? ? ?* Test the ability for the Windows launcher to do proper application argument > +? ? ?* detection and expansion, when using the long form module option and all passed in > +? ? ?* command line arguments are prefixed with a dash. > +? ? ?* > +? ? ?* These tests are not expected to work on *nixes, and are ignored. > +? ? ?*/ > +? ? public void testWindowsWithLongFormModuleOption() throws Exception { > +? ? ? ? if (!IS_WINDOWS) { > +? ? ? ? ? ? return; > +? ? ? ? } > + > +? ? ? ? String dir = MODS_DIR.toString(); > +? ? ? ? String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > +? ? ? ? // We should be able to find the argument --help as an application argument > +? ? ? ? ProcessTools.executeProcess( > +? ? ? ? ? ? createProcessWithLauncherDebugging( > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid, > +? ? ? ? ? ? ? ? "--help")) > +? ? ? ? ? ? .outputTo(System.out) > +? ? ? ? ? ? .errorTo(System.out) > +? ? ? ? ? ? .shouldContain("F--help"); > + > +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help > +? ? ? ? // We should be able to see argument expansion happen > +? ? ? ? ProcessTools.executeProcess( > +? ? ? ? ? ? createProcessWithLauncherDebugging( > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid, > +? ? ? ? ? ? ? ? SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > +? ? ? ? ? ? ? ? "--help")) > +? ? ? ? ? ? .outputTo(System.out) > +? ? ? ? ? ? .errorTo(System.out) > +? ? ? ? ? ? .shouldContain("F--help") > +? ? ? ? ? ? .shouldContain("module-info.java"); > +? ? } > + > + > +? ? /** > +? ? ?* Test that --module= is terminating for VM argument processing just like --module > +? ? ?*/ > +? ? public void testLongFormModuleOptionTermination() throws Exception { > +? ? ? ? String dir = MODS_DIR.toString(); > +? ? ? ? String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS > +? ? ? ? // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be > +? ? ? ? // deemed as application arguments > +? ? ? ? OutputAnalyzer output = ProcessTools.executeProcess( > +? ? ? ? ? ? createProcessWithLauncherDebugging( > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid, > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid)) > +? ? ? ? ? ? .outputTo(System.out) > +? ? ? ? ? ? .errorTo(System.out) > +? ? ? ? ? ? .shouldContain("argv[ 0] = '--module-path=" + dir) > +? ? ? ? ? ? .shouldContain("argv[ 1] = '--module=" + mid); > + > +? ? ? ? if (IS_WINDOWS) { > +? ? ? ? ? ? output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); > +? ? ? ? } > + > +? ? ? ? // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > +? ? ? ? // This command line will not work as --module= is terminating and the module will be not found > +? ? ? ? int exitValue = exec("--module=" + mid, "--module-path" + dir); > +? ? ? ? assertTrue(exitValue != 0); > +? ? } > } > > > -----Original Message----- > From: Henry Jen > Sent: December 6, 2019 12:03 AM > To: Nikola Grcevski > Cc: Kumar Srinivasan ; Alan Bateman ; mailto:core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > >> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: >> >> Hello all again! >> >> Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: >> >> --- a/src/java.base/share/native/libjli/args.c >> +++ b/src/java.base/share/native/libjli/args.c >> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { >>? ? ? ? ? ? } >>? ? ? ? } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>? ? ? ? ? ? stopExpansion = JNI_TRUE; >> +? ? ? ? } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { > > I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. > > BTW, we need the patch to be hosted on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875819891&sdata=tijtj%2BHkXylb4Qa3liw8EetRWX8bQlsrYD%2FkAgwnrGE%3D&reserved=0 or you can attach the patch to the review thread if you are not yet an author. > > Cheers, > Henry > > >> +? ? ? ? ? ? idx = argsCount; >>? ? ? ? } >>? ? } else { >>? ? ? ? if (!expectingNoDashArg) { >> >> The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. >> >> I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. >> >> I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). >> >> I ran all the launcher tests on both Windows and Linux and all tests pass. >> >> Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. >> >> Thank you, >> Nikola >> >> -----Original Message----- >> From: Henry Jen >> Sent: December 4, 2019 8:26 PM >> To: Kumar Srinivasan ; Alan Bateman >> ; Nikola Grcevski >> >> Cc: mailto:core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >>> >>> Hi Nikola, >>> >>> It looks ok to me, I will leave it to Henry and Alan to bless this. >>> >>> IMHO: I think we should fix it correctly now than later, I don't >>> think it is all that difficult AFAICT all the launcher has? to do is >>> identify "--module==", then the next argument is the first index. >>> >> >> I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. >> >> If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. >> >> FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. >> >> I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. >> >> I?ll let Alan to comment about the ?module option usage. >> >> The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs >> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875819891&sdata=tYr7X%2BWKsRBDhE4kk8ES09i8kU3AXUbvfjON%2B3pi3rQ%3D&reserved=0%2Fen%2Fjava%2Fjavase%2F13%2Fdocs%2Fspecs%2Fman%2Fjava.html >> &data=02%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875829886&sdata=3GAF3YmLHzB0dGE%2FrBgKZb6I%2FfioqRqg1quz5zEI%2F%2Fs%3D&reserved=0%7C37e38c582bac4687 >> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 >> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY >> %3D&reserved=0 >> >>> Kumar >>> >>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >>> Hi Henry and Kumar, >>> >>> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >>> >>> Please find my updated webrev here for your review: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc >>> e >>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875829886&sdata=bO71uLpbZgNDfN6uuYmhGXWBBUbc8jVpXthnzMb%2B3fw%3D&reserved=0%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Gr >>> c >>> evski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875839882&sdata=B9ioFEVQ9x7taxjCeY5KHvHxOhmmG0Ohapg%2BEPsynfc%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86 >>> f >>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ >>> % >>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>> >>> Cheers, >>> >>> Nikola >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 3, 2019 11:39 AM >>> To: Kumar Srinivasan >>> Cc: Nikola Grcevski ; Alan Bateman >>> ; mailto:core-libs-dev at openjdk.java.net >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>> >>> Kumar, >>> >>> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >>> >>> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >>> >>> Cheers, >>> Henry >>> >>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>>> >>>> Hi, >>>> >>>> Sorry for chiming in? late in the review process, for what it's worth.... >>>> >>>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>>>? ?and subsequent crash,? but it does not address? wildcard arguments expansion. >>>> >>>>? ?What if we have >>>>? ?% java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>>>? ?Where jdk.compiler is a java compiler implementation (javac). >>>>? ?The user would expect the above compiler module to build all the .java files in that directory, >>>>? ?and this fix will not address that. >>>> >>>> Some background: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875839882&sdata=N3%2F56AMtNgfBH%2FNYNJj8%2Fviw07WmugWhKi1Pwz11ecw%3D&reserved=0%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola >>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875849875&sdata=b2IlaMBcOlTUjNI3gG6Kxkoza8w0N4tkeFX6dUrRQl0%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>>> Please see all the related bugs in the above JIRA issue. >>>> >>>> Paragraph #6 in this interview surmises the wild card behavior on? Windows: >>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875849875&sdata=MU2LIp0wJy1%2FW1B3648xH%2BpM%2F%2F3OvpYg6Bg81sREAbk%3D&reserved=0%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=0 >>>> 2%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875859867&sdata=tQ%2FiuszakwoOxL9dQT1NAmXCDj0qOv%2BpRmwCBTbyHaA%3D&reserved=0%7C6158f8460dcd4c39518708d77 >>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>>> ;reserved=0 >>>> >>>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>>> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875859867&sdata=4MYjDinmHFMeWZ3LxDoJMbsw8Fiu%2FEX6YVQnPNbn7Ag%3D&reserved=0%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2 >>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>>> ki%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875869862&sdata=yMmLqFu99DcB7a6GqXiOZlolyxDKD0zfNliRsz1NuuE%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f1 >>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>>> Using the modules test framework may make the test simpler. >>>> >>>> Kumar Srinivasan >>>> >>>> >>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>>> Hi Alan and Henry, >>>> >>>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>>> >>>> I created a webrev here for the change, including a new test in Arrrghs.java: >>>> >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875869862&sdata=F2CPkGKG7IdCZUtCtX36eWNoCizZrOSwK1sHyQ1DqQQ%3D&reserved=0%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola >>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875869862&sdata=yMmLqFu99DcB7a6GqXiOZlolyxDKD0zfNliRsz1NuuE%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f98 >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>> >>>> I copied the test validation and assertion style of other code inside the test class. >>>> >>>> Please let me know if you have any comments or suggestions. >>>> >>>> Thanks again! >>>> >>>> -----Original Message----- >>>> From: Henry Jen >>>> Sent: December 2, 2019 12:26 PM >>>> To: Alan Bateman >>>> Cc: Nikola Grcevski ; >>>> mailto:core-libs-dev at openjdk.java.net >>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>>> >>>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>>> >>>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>>> >>>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>>> >>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>>> : >>>>>> >>>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>>> >>>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>>> >>>>> -Alan From mandy.chung at oracle.com Mon Dec 9 22:01:21 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Dec 2019 14:01:21 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: <6c096c92-3b12-c0f7-dbf2-b5e914e46511@oracle.com> References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> <21ae2c12-f407-e7d9-ae38-9bb2bce51996@oracle.com> <75d9770e-9bfb-74e4-ed60-d0709ab53e5e@oracle.com> <6c096c92-3b12-c0f7-dbf2-b5e914e46511@oracle.com> Message-ID: <9494d531-097f-a368-ccaf-d723a2d21bca@oracle.com> +1 Mandy On 12/9/19 1:34 PM, Joe Darcy wrote: > PS That should be > > ??? http://cr.openjdk.java.net/~darcy/8230771.1 > > Cheers, > > -Joe > > On 12/9/2019 12:39 PM, Joe Darcy wrote: >> Updated webrev: >> >> ??? http://cr.openjdk.java.net/~darcy/8230771.0/ >> >> Found a class extending Modifier to the the static definitions; I >> replaced this with a static import. >> >> To make sure a class isn't instantiated, I usually have it throw >> AssertionError or some exception, although as you say that isn't >> strictly necessary in all cases. >> >> Thanks, >> >> -Joe >> >> On 12/9/2019 10:27 AM, Mandy Chung wrote: >>> It seems a bit overly cautious to throw AssertionError.? JDK has >>> many private no-arg constructor and it can be as simple as empty >>> constructor.? Just my preference. >>> >>> Mandy >>> >>> On 12/9/19 10:16 AM, Joe Darcy wrote: >>>> Corrected patch: >>>> >>>> diff -r 153e5f76551d >>>> src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> --- >>>> a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> Mon Dec 09 23:00:13 2019 +0530 >>>> +++ >>>> b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> Mon Dec 09 10:15:44 2019 -0800 >>>> @@ -43,8 +43,7 @@ >>>> ???? /** >>>> ????? * Do not call. >>>> ????? */ >>>> -??? @Deprecated(forRemoval=true, since="14") >>>> -??? public ConstantBootstraps() {} >>>> +??? private ConstantBootstraps() {throw new AssertionError();} >>>> >>>> ???? // implements the upcall from the JVM, >>>> MethodHandleNatives.linkDynamicConstant: >>>> ???? /*non-public*/ >>>> diff -r 153e5f76551d >>>> src/java.base/share/classes/java/lang/reflect/Modifier.java >>>> --- a/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>> Mon Dec 09 23:00:13 2019 +0530 >>>> +++ b/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>> Mon Dec 09 10:15:44 2019 -0800 >>>> @@ -46,8 +46,7 @@ >>>> ???? /** >>>> ????? * Do not call. >>>> ????? */ >>>> -??? @Deprecated(forRemoval=true, since="14") >>>> -??? public Modifier() {} >>>> +??? private Modifier() {throw new AssertionError();} >>>> >>>> >>>> ???? /** >>>> >>>> -Joe >>>> >>>> On 12/9/2019 9:38 AM, Joe Darcy wrote: >>>>> Doh! Will correct. That is why I want to get the no-arg >>>>> constructor added as a javac warning (JDK-8071961) ;-) >>>>> >>>>> Thanks all for catching this, >>>>> >>>>> -Joe >>>>> >>>>> On 12/9/2019 9:29 AM, Mandy Chung wrote: >>>>>> Good catch!? Daniel also pointed that out.? I overlooked it. It >>>>>> needs to add back a private no-arg constructor. >>>>>> >>>>>> Mandy >>>>>> >>>>>> On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: >>>>>>> If you remove the deprecated constructor, the compiler will add >>>>>>> a default one. Wouldn't it be a better idea to make the >>>>>>> deprecated constructor private and throwing an exception? >>>>>>> >>>>>>> Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung >>>>>>> > escreveu: >>>>>>> >>>>>>> ??? Looks good. >>>>>>> >>>>>>> ??? Mandy >>>>>>> >>>>>>> ??? On 12/8/19 10:58 AM, Joe Darcy wrote: >>>>>>> ??? > Hello, >>>>>>> ??? > >>>>>>> ??? > Please review this small API changes for JDK 15: >>>>>>> ??? > >>>>>>> ??? > ??? JDK-8230771: Remove terminally deprecated constructors in >>>>>>> ??? java.base >>>>>>> ??? > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 >>>>>>> ??? > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ >>>>>>> ??? > >>>>>>> ??? > Patch below. >>>>>>> ??? > >>>>>>> ??? > Thanks, >>>>>>> ??? > >>>>>>> ??? > -Joe >>>>>>> ??? > >>>>>>> ??? > --- >>>>>>> ??? > >>>>>>> old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>>>> >>>>>>> >>>>>>> ??? > 2019-12-08 10:56:14.223168685 -0800 >>>>>>> ??? > +++ >>>>>>> ??? > >>>>>>> new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>>>> >>>>>>> >>>>>>> ??? > 2019-12-08 10:56:13.999168685 -0800 >>>>>>> ??? > @@ -40,12 +40,6 @@ >>>>>>> ??? > ? * @since 11 >>>>>>> ??? > ? */ >>>>>>> ??? > ?public final class ConstantBootstraps { >>>>>>> ??? > -??? /** >>>>>>> ??? > -???? * Do not call. >>>>>>> ??? > -???? */ >>>>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>>>> ??? > -??? public ConstantBootstraps() {} >>>>>>> ??? > - >>>>>>> ??? > ???? // implements the upcall from the JVM, >>>>>>> ??? > MethodHandleNatives.linkDynamicConstant: >>>>>>> ??? > ???? /*non-public*/ >>>>>>> ??? > ???? static Object makeConstant(MethodHandle bootstrapMethod, >>>>>>> ??? > --- >>>>>>> old/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>>>> ??? > 2019-12-08 10:56:14.775168685 -0800 >>>>>>> ??? > +++ >>>>>>> new/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>>>> ??? > 2019-12-08 10:56:14.555168685 -0800 >>>>>>> ??? > @@ -44,13 +44,6 @@ >>>>>>> ??? > ? */ >>>>>>> ??? > ?public class Modifier { >>>>>>> ??? > ???? /** >>>>>>> ??? > -???? * Do not call. >>>>>>> ??? > -???? */ >>>>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>>>> ??? > -??? public Modifier() {} >>>>>>> ??? > - >>>>>>> ??? > - >>>>>>> ??? > -??? /** >>>>>>> ??? > ????? * Return {@code true} if the integer argument >>>>>>> includes the >>>>>>> ??? > ????? * {@code public} modifier, {@code false} otherwise. >>>>>>> ??? > ????? * >>>>>>> ??? > >>>>>>> >>>>>> >>> From mandy.chung at oracle.com Mon Dec 9 22:15:46 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Dec 2019 14:15:46 -0800 Subject: RFR 8235361 : JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...") In-Reply-To: <7dcdfa6e-2a99-55ca-6d54-3d0987104242@oracle.com> References: <7067cf9e-ce40-f647-b889-97017359d216@oracle.com> <7dcdfa6e-2a99-55ca-6d54-3d0987104242@oracle.com> Message-ID: <916368d2-6287-21e3-06ae-249a05ff7855@oracle.com> On 12/9/19 12:17 PM, Jonathan Gibbons wrote: > I note that javac now uses the same definition of tryResolveFile in > its handling of Class-Path manifest entries, and so the behavior for > the compiler and runtime should now be aligned. > Yay! This patch looks good to me. Mandy > -- Jon > > > On 12/09/2019 12:10 PM, Brent Christian wrote: >> Hi, >> >> As discussed[1] last month on this alias, JAR Class-Path entries[2] >> that encode an absolute Windows path (including a drive letter, so >> e.g. "/C:/path/to/file.jar") are ignored as of 8211941. >> >> Such entries are legal relative URLs, and should not be ignored. >> Please review my fix to correct this. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8235361 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8235361/webrev06-open/ >> >> Thanks, >> -Brent >> >> 1. >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063491.html >> >> 2. >> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute >> > From brent.christian at oracle.com Mon Dec 9 22:26:37 2019 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 9 Dec 2019 14:26:37 -0800 Subject: Class-Path (in jar file) semantics different between Java 11 and 13 (on Windows)? In-Reply-To: References: <15bf7cd7-8549-8266-a460-1d0bb4359f84@gmail.com> Message-ID: <56fb7ccc-0687-578b-bb17-a1c4480d2d1e@oracle.com> FYI, a fix for this (8235361[1]) is in review: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/063934.html -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8235361 From alexander.matveev at oracle.com Mon Dec 9 22:36:59 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 9 Dec 2019 14:36:59 -0800 Subject: RFR: JDK-8234867: Issue warning for mutually exclusive options on jpackage command line In-Reply-To: References: Message-ID: Looks good. Thanks, Alexander On 12/9/2019 1:42 PM, Andy Herrick wrote: > Please review simple fix [2] for jpackage bug [1] > > fixing error message for mutually exclusive options. > > /Andy > > [1] https://bugs.openjdk.java.net/browse/JDK-8234867 > > [2] http://cr.openjdk.java.net/~herrick/8234867/webrev.01/ > From andy.herrick at oracle.com Mon Dec 9 23:17:55 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Dec 2019 18:17:55 -0500 Subject: RFR: JDK-8235601: redundant code in IOUtils.java Message-ID: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> Please review simple jpackage fir for issue [1] at [2] /Andy [1] https://bugs.openjdk.java.net/browse/JDK-8235601 [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ /Andy From philip.race at oracle.com Mon Dec 9 23:53:24 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 9 Dec 2019 15:53:24 -0800 Subject: RFR: JDK-8235601: redundant code in IOUtils.java In-Reply-To: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> References: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> Message-ID: <1d3f4ff3-0a6c-1935-1830-9e7c1bfae305@oracle.com> > [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ This does not bring up the expected webrev -phil. On 12/9/19 3:17 PM, Andy Herrick wrote: > Please review simple jpackage fir for issue [1] at [2] > > /Andy > > [1] https://bugs.openjdk.java.net/browse/JDK-8235601 > > [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ > > /Andy > From stuart.marks at oracle.com Tue Dec 10 00:14:40 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 9 Dec 2019 16:14:40 -0800 Subject: JDK 15 RFR of JDK-8230771: Remove terminally deprecated constructors in java.base In-Reply-To: <6c096c92-3b12-c0f7-dbf2-b5e914e46511@oracle.com> References: <060d85f8-551e-0a38-c757-201349bb3eb9@oracle.com> <2d7721f4-4045-b969-f2bc-cb22620cb538@oracle.com> <21ae2c12-f407-e7d9-ae38-9bb2bce51996@oracle.com> <75d9770e-9bfb-74e4-ed60-d0709ab53e5e@oracle.com> <6c096c92-3b12-c0f7-dbf2-b5e914e46511@oracle.com> Message-ID: <0e12c038-7107-6bd7-1440-b54954795c3c@oracle.com> Hi Joe, The revised webrev looks good. Side note on whether a private constructor should be empty or should throw some Throwable. There are actually two (or more) use cases for private constructors: 1) intending to prevent instances from being created other than through well-controlled APIs, such as static factory methods; and 2) intending to prevent instances from being created at all. In case 1) an empty constructor might be perfectly reasonable. In case 2) an empty constructor might accidentally allow an instance to be created, if the code is later modified, or possibly reflectively. Throwing an exception from this constructor is a good indication of the intent that instances never be created. Throwing AssertionError seems reasonable but it might not be idiomatically the best exception type. However, I won't quibble about the exception type. I think there probably are cases in the JDK where we use a private, empty constructor in cases where no instances are ever intended to be created. (I know of at least one, because I wrote it.) It might be worthwhile to modify these to throw an exception instead. s'marks On 12/9/19 1:34 PM, Joe Darcy wrote: > PS That should be > > ??? http://cr.openjdk.java.net/~darcy/8230771.1 > > Cheers, > > -Joe > > On 12/9/2019 12:39 PM, Joe Darcy wrote: >> Updated webrev: >> >> ??? http://cr.openjdk.java.net/~darcy/8230771.0/ >> >> Found a class extending Modifier to the the static definitions; I replaced >> this with a static import. >> >> To make sure a class isn't instantiated, I usually have it throw >> AssertionError or some exception, although as you say that isn't strictly >> necessary in all cases. >> >> Thanks, >> >> -Joe >> >> On 12/9/2019 10:27 AM, Mandy Chung wrote: >>> It seems a bit overly cautious to throw AssertionError.? JDK has many private >>> no-arg constructor and it can be as simple as empty constructor.? Just my >>> preference. >>> >>> Mandy >>> >>> On 12/9/19 10:16 AM, Joe Darcy wrote: >>>> Corrected patch: >>>> >>>> diff -r 153e5f76551d >>>> src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> --- a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> Mon Dec 09 23:00:13 2019 +0530 >>>> +++ b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>> Mon Dec 09 10:15:44 2019 -0800 >>>> @@ -43,8 +43,7 @@ >>>> ???? /** >>>> ????? * Do not call. >>>> ????? */ >>>> -??? @Deprecated(forRemoval=true, since="14") >>>> -??? public ConstantBootstraps() {} >>>> +??? private ConstantBootstraps() {throw new AssertionError();} >>>> >>>> ???? // implements the upcall from the JVM, >>>> MethodHandleNatives.linkDynamicConstant: >>>> ???? /*non-public*/ >>>> diff -r 153e5f76551d >>>> src/java.base/share/classes/java/lang/reflect/Modifier.java >>>> --- a/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon Dec 09 >>>> 23:00:13 2019 +0530 >>>> +++ b/src/java.base/share/classes/java/lang/reflect/Modifier.java Mon Dec 09 >>>> 10:15:44 2019 -0800 >>>> @@ -46,8 +46,7 @@ >>>> ???? /** >>>> ????? * Do not call. >>>> ????? */ >>>> -??? @Deprecated(forRemoval=true, since="14") >>>> -??? public Modifier() {} >>>> +??? private Modifier() {throw new AssertionError();} >>>> >>>> >>>> ???? /** >>>> >>>> -Joe >>>> >>>> On 12/9/2019 9:38 AM, Joe Darcy wrote: >>>>> Doh! Will correct. That is why I want to get the no-arg constructor added >>>>> as a javac warning (JDK-8071961) ;-) >>>>> >>>>> Thanks all for catching this, >>>>> >>>>> -Joe >>>>> >>>>> On 12/9/2019 9:29 AM, Mandy Chung wrote: >>>>>> Good catch!? Daniel also pointed that out.? I overlooked it. It needs to >>>>>> add back a private no-arg constructor. >>>>>> >>>>>> Mandy >>>>>> >>>>>> On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote: >>>>>>> If you remove the deprecated constructor, the compiler will add a default >>>>>>> one. Wouldn't it be a better idea to make the deprecated constructor >>>>>>> private and throwing an exception? >>>>>>> >>>>>>> Em seg., 9 de dez. de 2019 ?s 14:13, Mandy Chung >>>>>> > escreveu: >>>>>>> >>>>>>> ??? Looks good. >>>>>>> >>>>>>> ??? Mandy >>>>>>> >>>>>>> ??? On 12/8/19 10:58 AM, Joe Darcy wrote: >>>>>>> ??? > Hello, >>>>>>> ??? > >>>>>>> ??? > Please review this small API changes for JDK 15: >>>>>>> ??? > >>>>>>> ??? > ??? JDK-8230771: Remove terminally deprecated constructors in >>>>>>> ??? java.base >>>>>>> ??? > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8235548 >>>>>>> ??? > ??? webrev: http://cr.openjdk.java.net/~darcy/8230771.0/ >>>>>>> ??? > >>>>>>> ??? > Patch below. >>>>>>> ??? > >>>>>>> ??? > Thanks, >>>>>>> ??? > >>>>>>> ??? > -Joe >>>>>>> ??? > >>>>>>> ??? > --- >>>>>>> ??? > >>>>>>> old/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>>>> >>>>>>> ??? > 2019-12-08 10:56:14.223168685 -0800 >>>>>>> ??? > +++ >>>>>>> ??? > >>>>>>> new/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java >>>>>>> >>>>>>> ??? > 2019-12-08 10:56:13.999168685 -0800 >>>>>>> ??? > @@ -40,12 +40,6 @@ >>>>>>> ??? > ? * @since 11 >>>>>>> ??? > ? */ >>>>>>> ??? > ?public final class ConstantBootstraps { >>>>>>> ??? > -??? /** >>>>>>> ??? > -???? * Do not call. >>>>>>> ??? > -???? */ >>>>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>>>> ??? > -??? public ConstantBootstraps() {} >>>>>>> ??? > - >>>>>>> ??? > ???? // implements the upcall from the JVM, >>>>>>> ??? > MethodHandleNatives.linkDynamicConstant: >>>>>>> ??? > ???? /*non-public*/ >>>>>>> ??? > ???? static Object makeConstant(MethodHandle bootstrapMethod, >>>>>>> ??? > --- >>>>>>> old/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>>>> ??? > 2019-12-08 10:56:14.775168685 -0800 >>>>>>> ??? > +++ >>>>>>> new/src/java.base/share/classes/java/lang/reflect/Modifier.java >>>>>>> ??? > 2019-12-08 10:56:14.555168685 -0800 >>>>>>> ??? > @@ -44,13 +44,6 @@ >>>>>>> ??? > ? */ >>>>>>> ??? > ?public class Modifier { >>>>>>> ??? > ???? /** >>>>>>> ??? > -???? * Do not call. >>>>>>> ??? > -???? */ >>>>>>> ??? > -??? @Deprecated(forRemoval=true, since="14") >>>>>>> ??? > -??? public Modifier() {} >>>>>>> ??? > - >>>>>>> ??? > - >>>>>>> ??? > -??? /** >>>>>>> ??? > ????? * Return {@code true} if the integer argument includes the >>>>>>> ??? > ????? * {@code public} modifier, {@code false} otherwise. >>>>>>> ??? > ????? * >>>>>>> ??? > >>>>>>> >>>>>> >>> From andy.herrick at oracle.com Tue Dec 10 01:26:42 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 9 Dec 2019 20:26:42 -0500 Subject: RFR: JDK-8235601: redundant code in IOUtils.java In-Reply-To: <1d3f4ff3-0a6c-1935-1830-9e7c1bfae305@oracle.com> References: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> <1d3f4ff3-0a6c-1935-1830-9e7c1bfae305@oracle.com> Message-ID: <0d708344-249c-b50c-7fd9-2eea548e4768@oracle.com> On 12/9/2019 6:53 PM, Phil Race wrote: > > [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ > > This does not bring up the expected webrev My apologies - I uploaded the wrong webrev - It should be fixed now. /Andy > > -phil. > > On 12/9/19 3:17 PM, Andy Herrick wrote: >> Please review simple jpackage fix for issue [1] at [2] >> >> /Andy >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235601 >> >> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ >> >> /Andy >> > From alexander.matveev at oracle.com Tue Dec 10 01:28:43 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 9 Dec 2019 17:28:43 -0800 Subject: RFR: JDK-8235601: redundant code in IOUtils.java In-Reply-To: <0d708344-249c-b50c-7fd9-2eea548e4768@oracle.com> References: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> <1d3f4ff3-0a6c-1935-1830-9e7c1bfae305@oracle.com> <0d708344-249c-b50c-7fd9-2eea548e4768@oracle.com> Message-ID: Hi Andy, Looks good. Thanks, Alexander On 12/9/2019 5:26 PM, Andy Herrick wrote: > > On 12/9/2019 6:53 PM, Phil Race wrote: >> > [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ >> >> This does not bring up the expected webrev > > My apologies - I uploaded the wrong webrev - It should be fixed now. > > /Andy > >> >> -phil. >> >> On 12/9/19 3:17 PM, Andy Herrick wrote: >>> Please review simple jpackage fix for issue [1] at [2] >>> >>> /Andy >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235601 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ >>> >>> /Andy >>> >> From philip.race at oracle.com Tue Dec 10 02:18:48 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 09 Dec 2019 18:18:48 -0800 Subject: RFR: JDK-8235601: redundant code in IOUtils.java In-Reply-To: <0d708344-249c-b50c-7fd9-2eea548e4768@oracle.com> References: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> <1d3f4ff3-0a6c-1935-1830-9e7c1bfae305@oracle.com> <0d708344-249c-b50c-7fd9-2eea548e4768@oracle.com> Message-ID: <5DEF0088.20509@oracle.com> +1 -phil. On 12/9/19, 5:26 PM, Andy Herrick wrote: > > On 12/9/2019 6:53 PM, Phil Race wrote: >> > [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ >> >> This does not bring up the expected webrev > > My apologies - I uploaded the wrong webrev - It should be fixed now. > > /Andy > >> >> -phil. >> >> On 12/9/19 3:17 PM, Andy Herrick wrote: >>> Please review simple jpackage fix for issue [1] at [2] >>> >>> /Andy >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235601 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ >>> >>> /Andy >>> >> From fujie at loongson.cn Tue Dec 10 02:26:20 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 10 Dec 2019 10:26:20 +0800 Subject: RFR: 8235625: [TESTBUG] tools/jpackage/share/JavaOptionsEqualsTest.java fails with debug VMs Message-ID: Hi all, May I get reviews for the small fix? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235625 Webrev: http://cr.openjdk.java.net/~jiefu/8235625/webrev.00/ Thanks a lot. Best regards, Jie From philip.race at oracle.com Tue Dec 10 03:17:25 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 9 Dec 2019 19:17:25 -0800 Subject: RFR: JDK-8234867: Issue warning for mutually exclusive options on jpackage command line In-Reply-To: References: Message-ID: <0AA07DDA-D7B7-433B-8F95-08AAB9263ED2@oracle.com> +1 -Phil. > On Dec 9, 2019, at 2:36 PM, Alexander Matveev wrote: > > Looks good. > > Thanks, > Alexander > >> On 12/9/2019 1:42 PM, Andy Herrick wrote: >> Please review simple fix [2] for jpackage bug [1] >> >> fixing error message for mutually exclusive options. >> >> /Andy >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8234867 >> >> [2] http://cr.openjdk.java.net/~herrick/8234867/webrev.01/ >> > From Alan.Bateman at oracle.com Tue Dec 10 06:31:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Dec 2019 06:31:15 +0000 Subject: RFR: JDK-8235601: redundant code in IOUtils.java In-Reply-To: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> References: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> Message-ID: <359595d2-891f-7a97-9810-b3e44ea8cb5e@oracle.com> On 09/12/2019 23:17, Andy Herrick wrote: > Please review simple jpackage fir for issue [1] at [2] transformFrom is not guaranteed to transfer all bytes so you can't ignore the return value. I assume you could replace move/all of this with a Files.copy that specifies REPLACE_EXISTING and COPY_ATTRIBUTES. -Alan From Alan.Bateman at oracle.com Tue Dec 10 06:32:29 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Dec 2019 06:32:29 +0000 Subject: RFR 8235361 : JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...") In-Reply-To: <7067cf9e-ce40-f647-b889-97017359d216@oracle.com> References: <7067cf9e-ce40-f647-b889-97017359d216@oracle.com> Message-ID: <2cfb6f75-f0c8-b8b2-89a4-168cd607106c@oracle.com> On 09/12/2019 20:10, Brent Christian wrote: > Hi, > > As discussed[1] last month on this alias, JAR Class-Path entries[2] > that encode an absolute Windows path (including a drive letter, so > e.g. "/C:/path/to/file.jar") are ignored as of 8211941. > > Such entries are legal relative URLs, and should not be ignored. > Please review my fix to correct this. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8235361 > Webrev: > http://cr.openjdk.java.net/~bchristi/8235361/webrev06-open/ Looks good. -Alan From daniel.peintner at gmail.com Tue Dec 10 08:42:01 2019 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Tue, 10 Dec 2019 09:42:01 +0100 Subject: RFR: 8235482: [TESTBUG] PackageType LINUX_RPM should be excluded for jpackage tests on debian systems In-Reply-To: References: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> <716346c8-ced9-862b-b6d3-240b438ea3a0@oracle.com> Message-ID: All, I think I have a related question/problem. I was able to run the latest jpackage build (14-jpackage+1-70 (2019/11/12)) successfully on Windows creating msi and on Ubuntu creating deb. However, I fail to create a rpm package. I tried both, openSUSE Leap 15.1 and also Fedora 31. Both fail with the statement: Error: Invalid or unsupported type: [rpm] Is this a known error? I am using the badass-runtime-plugin [1] but I don't think the plugin is causing issues. Thanks, -- Daniel [1] https://github.com/beryx/badass-runtime-plugin/ On Sat, Dec 7, 2019 at 1:42 AM Jie Fu wrote: > Hi Alexey, > > Thanks for your review and comments. > > I have two questions: > - 1) Have you ever tried the rpm tests on a debian system? > - 2) How to decide whether the rpm tests are supported on a debian > system? > > Thanks a lot. > Best regards, > Jie > > On 2019/12/7 ??1:26, Alexey Semenyuk wrote: > > This fix will disable running rpm tests on Debian systems that support > > it. This is not a good idea. > > If you need to exclude some packaging from jpackage tests, just run > > jtreg with "jpackage.test.disabledPackagers" system property set to > > the list of corresponding package types. E.g.: > > -Djpackage.test.disabledPackagers=rpm will disable rpm packaging. > > > > - Alexey > > > > On 12/6/2019 7:51 AM, Jie Fu wrote: > >> Hi all, > >> > >> May I get reviews for the small fix? > >> > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235482 > >> Webrev: http://cr.openjdk.java.net/~jiefu/8235482/webrev.00/ > >> > >> Thanks a lot. > >> Best regards, > >> Jie > >> > > From adinn at redhat.com Tue Dec 10 10:03:01 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 10 Dec 2019 10:03:01 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> Message-ID: <432d8c39-58a0-4fde-fff0-e58d2a1e3049@redhat.com> Hi Maurizio, It's nice to see this squeezing into jdk14. On 09/12/2019 19:23, Maurizio Cimadamore wrote: > Another iteration: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/ I eyeballed all the changes to the Buffer classes and saw no issues. Also, apologies for the mixed brace/nobrace else-if cascade in FileChannelImpl.java spotted by Roger which was my fault -- I should really have introduced braces uniformly across the whole if/else-if/else sequence. Also, I reran pmem tests to verify that your buffer changes don't disrupt the behaviour of sync mapped byte buffers and all is well. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From maurizio.cimadamore at oracle.com Tue Dec 10 10:04:54 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 10 Dec 2019 10:04:54 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <432d8c39-58a0-4fde-fff0-e58d2a1e3049@redhat.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> <432d8c39-58a0-4fde-fff0-e58d2a1e3049@redhat.com> Message-ID: <9971153b-f07e-e6df-76e2-b01ca9a8fac3@oracle.com> Thanks for the extra testing! Maurizio On 10/12/2019 10:03, Andrew Dinn wrote: > Hi Maurizio, > > It's nice to see this squeezing into jdk14. > > On 09/12/2019 19:23, Maurizio Cimadamore wrote: >> Another iteration: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/ > I eyeballed all the changes to the Buffer classes and saw no issues. > Also, apologies for the mixed brace/nobrace else-if cascade in > FileChannelImpl.java spotted by Roger which was my fault -- I should > really have introduced braces uniformly across the whole if/else-if/else > sequence. > > Also, I reran pmem tests to verify that your buffer changes don't > disrupt the behaviour of sync mapped byte buffers and all is well. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From chris.hegarty at oracle.com Tue Dec 10 11:08:28 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 Dec 2019 11:08:28 +0000 Subject: RFR [14] 8235531: Update record serialization migration tests to not use hard coded source versions Message-ID: <0D44D4B3-F2CE-4CA1-81E4-D72F021AF218@oracle.com> In preparation for the imminent arrival of 15 to jdk/jdk, this change replaces the hardcoded source version, used to invoke the compiler programmatically, with the runtime feature version, similar to JDK-8235514. I tested this change along side the changes for 8225361 - "Start of release updates for JDK 15" - and the record serialization migration tests pass successfully. --- a/test/jdk/java/io/Serializable/records/migration/AbstractTest.java +++ b/test/jdk/java/io/Serializable/records/migration/AbstractTest.java @@ -32,48 +32,50 @@ import java.net.URI; import java.net.URL; import java.net.URLClassLoader; import java.nio.file.Path; import jdk.test.lib.compiler.CompilerUtils; import org.testng.annotations.BeforeTest; import static org.testng.Assert.*; /** * An abstract superclass for tests that require to serialize and deserialize * record-like and record classes. Can be used for determining migration and * interop between record-like and record classes. */ public class AbstractTest { + private static final String VERSION = Integer.toString(Runtime.version().feature()); + static final String TEST_SRC = System.getProperty("test.src", "."); static final String TEST_CLASSES = System.getProperty("test.classes", "."); static final Path TEST_CLASSES_DIR = Path.of(TEST_CLASSES); static final Path PLAIN_SRC_DIR = Path.of(TEST_SRC, "plain"); static final Path PLAIN_DEST_DIR = Path.of("plain"); static final Path RECORD_SRC_DIR = Path.of(TEST_SRC, "record"); static final Path RECORD_DEST_DIR = Path.of("record"); @BeforeTest public void setup() throws IOException { assertTrue(CompilerUtils.compile(PLAIN_SRC_DIR, PLAIN_DEST_DIR, - "--enable-preview", "-source", "14", + "--enable-preview", "-source", VERSION, "--class-path", TEST_CLASSES_DIR.toString())); assertTrue(CompilerUtils.compile(RECORD_SRC_DIR, RECORD_DEST_DIR, - "--enable-preview", "-source", "14", + "--enable-preview", "-source", VERSION, "--class-path", TEST_CLASSES_DIR.toString())); } static byte[] serialize(T obj) throws IOException { ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(obj); oos.close(); return baos.toByteArray(); } @SuppressWarnings("unchecked") static T deserializeAsPlain(byte[] streamBytes) throws IOException, ClassNotFoundException { -Chris. From maurizio.cimadamore at oracle.com Tue Dec 10 12:39:28 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 10 Dec 2019 12:39:28 +0000 Subject: RFR [14] 8235550: Clarify record reflective support specification In-Reply-To: <9BE0B0CA-4A8C-4975-A21E-8F4163B68F8C@oracle.com> References: <9BE0B0CA-4A8C-4975-A21E-8F4163B68F8C@oracle.com> Message-ID: Looks good. Minor nits: * in getRecordComponents there are some utterings of "true", "false" and "null" which are not surrounded by a {@code } block. * any reason as to why the j.l.Record class is not cached in a static field? On the CSR: * "These arose when finalizing and completing the runtime CSR" - please add a link to the CSR * "It's direct superclass must be |java.lang.Record,| and" --- s/it's/its * "in it's specification ... guaranteed --- s/it's/its and also s/guaranteed/guarantee * "We thought it kinda nice to be able to avoid returning null, but in hindsight" - "While initially it was considered desirable to avoid returning null, in hindsight" Added myself as reviewer Thanks Maurizio On 09/12/2019 12:51, Chris Hegarty wrote: > This is a review request for a change to add a clarification to the > record related core reflection methods, that specifies what it means to > be a record class and access to the record components. Discussed > originally over on amber-spec-experts [1] > > I expanded the existing record reflection test and also added a new test > ( with the original record push bug no. ) to cover security manager > checks ( since I couldn't find an existing test ). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235550 > CSR: https://bugs.openjdk.java.net/browse/JDK-8235583 > Webrev: https://cr.openjdk.java.net/~chegar/8235550/webrev.00/ > > -Chris. > > [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001840.html From maurizio.cimadamore at oracle.com Tue Dec 10 12:51:21 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 10 Dec 2019 12:51:21 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> Message-ID: <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> And, another, small iteration http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v5 Delta compared to previous version (v4): http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v5_delta Javadoc updated in place: http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html Summary of changes: * Peter pointed out that the logic for checking overflow in MemoryScope::acquire was bogus, as once we had an overflow, the segment was rendered useless (as the count stayed in negative overflowed state) - separately, Paul pointed out that it would be better to roll in our atomic loops, and just use a VarHandle instead of atomic integer - I've rewritten MemoryScope quite a bit, to implement these changes; I think the result is much cleaner than before. Note that, in the new code, the boolean flag is gone, and we just use the int count for everything (thanks to Jorn for the nice observation). * Peter also pointer out that the isAlive() check is not thread-safe; I now have named the liveness-check-related methods explicitly (and added some javadoc), so that it's clear when they can be called safely * removed call to checkAlive from MemorySegment::acquire - MemoryScope;:acquire will check that anyway * fixed rough javadoc comment on MemoryLayout::withName * dropped non-overlapping restriction on MemoryAddress::copy (and fixed test accordingly) Maurizio On 09/12/2019 19:23, Maurizio Cimadamore wrote: > Another iteration: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/ > > Delta of the changes since last version (v3) here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4_delta/ > > The javadoc has been updated inline here: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Summary of changes: > > * Improved javadoc regarding alignment and access modes in MemoryHandles > * related to the above, the memory access varhandle now checks for > low-level VM alignment to for access other than get/set (as happens > for regular byte buffer view var handle) > * fixed MemoryHandles, JavaLangInvokeAccess, VarHandles, > MethodHandleImpl to speak about alignmentMask, rather than alignment > (as per Roger comments) > * added some more javadoc to internal classes MemoryAddressProxy, > VarHandleMemoryAddressBase, JavaNioAccess.java and > JavaLangInvokeAccess.java? (as per Roger comments) > * fixed mising {code} block around alignment param A in > MemoryLayout::bitAlignment/bytesAlignment (as per offline comments > from Daniel) > * added positive test to TestMemoryCopy > > Cheers > Maurizio > > On 08/12/2019 01:44, Maurizio Cimadamore wrote: >> Another update: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3/ >> >> And a delta of the changes since last version (v2) here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3_delta/ >> >> The javadoc has been updated inline here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> >> Summary of changes: >> >> * fixed some (cosmetic) issues in FileChannelmpl following offline >> discussion with Alan >> * changed tests group definition, so that now jdk_foreign is part of >> tier1_part3 >> * updated javadoc in various places to fix code samples (as per Paul >> comments) >> * updated javadoc in MemoryHandles to talk about access modes (as per >> Paul comments) - I added a new section on top, and then referred to >> in from all relevant places >> * some changes to use Objects.hash (as per Paul comments), and some >> minor refactor in the AddreddGenerator (to use switch expression) >> * tightened javadoc for MemoryAddress::copy - the method now is >> specified to throw IAE if the range of source/dest addresses overlap >> - I've fixed the impl and added a test (as per Raffaello comments) >> * tightened byte buffer VarHandle view - if the view is created from >> a byte buffer obtained from a segment (!!!) we should do a segment >> check - added tests >> >> >> And here's a list of the pending API-related issues. Since these are >> IMHO minor issues, I suggest we defer them to a followup minor >> cleanup, so that we can move ahead with finalization of the CSR with >> the current API. Here's the list: >> >> * Should MemoryAddress implement Comparable? I think the answer is >> "probably not" - an address doesn't have a 'length' so you can't >> really do a range comparison (maybe memory segments though?). For >> now, users can project to byte buffer and take it from there (since >> ByteBuffer <: Comparable) >> * should we have a? way to ask a Layout if its size is specified ? >> (Paul) >> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much >> distance between these two semantically different operations (Paul >> suggested using 'add' - which I'm not enthusiastic about because it's >> not adding two addresses - it's adding a long to an address...) >> * MemorySegment::isAccessible() -- as the A* word is overloaded, some >> other name should be found? >> * MemorySegment::acquire() -- replace with MemorySegment::fork? >> >> Thanks >> Maurizio >> >> On 06/12/2019 10:43, Maurizio Cimadamore wrote: >>> Hi, >>> here's an updated version of the patch: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ >>> >>> And a delta of the changes since last version here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ >>> >>> The javadoc has been updated inline here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>> >>> >>> Summary of changes: >>> >>> * fixed spurious protected methods in AbstractLayout and subclasses >>> which leaked into API >>> * removed library_call.cpp changes, as these are being tracked >>> separately by Vlad >>> * compacted ILOAD code in AddressVarHandleGenerator >>> * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope >>> >>> I have made no changes to the *name* of the methods in the API. In >>> fact, I suggest we keep a list of the names we'd like to revisit, >>> and we address them all at once at the end of the review (once we're >>> happy with the contents). Here's a list of the current open naming >>> issues: >>> >>> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not >>> much distance between these two semantically different operations >>> * MemorySegment::isAccessible() -- as the A* word is overloaded, >>> some other name should be found? >>> * MemorySegment::acquire() -- replace with MemorySegment::fork? >>> >>> Cheers >>> Maurizio >>> >>> >>> On 05/12/2019 21:04, Maurizio Cimadamore wrote: >>>> Hi, >>>> as part of the effort to upstream the changes related to JEP 370 >>>> (foreign memory access API) [1], I'd like to ask for a code review >>>> for the corresponding core-libs and hotspot changes: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>>> >>>> A javadoc for the memory access API is also available here: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>>> >>>> >>>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>>> >>>> >>>> Here is a brief summary of the changes in java.base and hotspot >>>> (the remaining new files are implementation classes and tests for >>>> the new API): >>>> >>>> * ciField.cpp - this one is to trust final fields in the foreign >>>> memory access implementation (otherwise VM doesn't trust memory >>>> segment bounds) >>>> >>>> * Modules.gmk - these changes are needed to require that the >>>> incubating module is loaded by the boot loader (otherwise the above >>>> changes are useless) >>>> >>>> * library_call.cpp - this one is a JIT compiler change to treat >>>> Thread.currentThread() as a well-known constant - which helps a lot >>>> in the confinement checks (thanks Vlad!) >>>> >>>> * various Buffer-related changes; these changes are needed because >>>> the memory access API allows a memory segment to be projected into >>>> a byte buffer, for interop reasons. As such, we need to insert a >>>> liveness check in the various get/put methods. Previously we had an >>>> implementation strategy where a BB was 'decorated' by a subclass >>>> called ScopedBuffer - but doing so required some changes to the BB >>>> API (e.g. making certain methods non-final, so that we could >>>> decorate them). Here I use an approach (which I have discussed with >>>> Alan) which doesn't require any public API changes, but needs to >>>> add a 'segment' field in Buffer - and then have constructors which >>>> keep track of this extra parameter. >>>> >>>> * FileChannel changes - these changes are required so that we can >>>> reuse the Unmapper class from the MemorySegment implementation, to >>>> deterministically deallocate a mapped memory segment. This should >>>> be a 'straight' refactoring, no change in behavior should occur >>>> here. Please double check. >>>> >>>> * VarHandles - this class now provides a factory to create memory >>>> access VarHandle - this is a bit tricky, since VarHandle cannot >>>> really be implemented outside java.base (e.g. VarForm is not >>>> public). So we do the usual trick where we define a bunch of proxy >>>> interfaces (see jdk/internal/access/foreign) have the classes in >>>> java.base refer to these - and then have the implementation classes >>>> of the memory access API implement these interfaces. >>>> >>>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we >>>> need to provide access to otherwise hidden functionalities - e.g. >>>> creating a new scoped buffer, or retrieving the properties of a >>>> memory access handle (e.g. offset, stride etc.), so that we can >>>> implement the memory access API in its own separate module >>>> >>>> * GensrcVarHandles.gmk - these changes are needed to enable the >>>> generation of the new memory address var handle implementations; >>>> there's an helper class per carrier (e.g. >>>> VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory >>>> access var handle is needed, we dynamically spin a new VH >>>> implementation which makes use of the right carrier. We need to >>>> spin because the VH can have a variable number of access >>>> coordinates (e.g. depending on the dimensions of the array to be >>>> accessed). But, under the hood, all the generated implementation >>>> will be using the same helper class. >>>> >>>> * tests - we've tried to add fairly robust tests, often checking >>>> all possible permutations of carriers/dimensions etc. Because of >>>> that, the tests might not be the easiest to look at, but they have >>>> proven to be pretty effective at shaking out issues. >>>> >>>> I think that covers the main aspects of the implementation and >>>> where it differs from vanilla JDK. >>>> >>>> P.S. >>>> >>>> In the CSR review [2], Joe raised a fair point - which is >>>> MemoryAddress has both: >>>> >>>> offset(long) --> move address of given offset >>>> offset() --> return the offset of this address in its owning segment >>>> >>>> And this was considered suboptimal, given both methods use the same >>>> name but do something quite different (one is an accessor, another >>>> is a 'wither'). one obvious option is to rename the first to >>>> 'withOffset'. But I think that would lead to verbose code (since >>>> that is a very common operation). Other options are to: >>>> >>>> * rename offset(long) to move(long), advance(long), or something else >>>> * drop offset() - but then add an overload of >>>> MemorySegment::asSlice which takes an address instead of a plain >>>> long offset >>>> >>>> I'll leave the choice to the reviewers :-) >>>> >>>> >>>> >>>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, >>>> Stuart, Roger, Joe and the Panama team for the feedback provided so >>>> far, which helped to get the API in the shape it is today. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" >>>> - but that is unrelated to this patch, and it's a known failing test. >>>> >>>> [1] - https://openjdk.java.net/jeps/370 >>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>>> From chris.hegarty at oracle.com Tue Dec 10 14:34:37 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 Dec 2019 14:34:37 +0000 Subject: RFR [14] 8235550: Clarify record reflective support specification In-Reply-To: References: <9BE0B0CA-4A8C-4975-A21E-8F4163B68F8C@oracle.com> Message-ID: <2BE6E3EC-174F-4D04-BFD1-1024DB3F0367@oracle.com> Maurizio, > On 10 Dec 2019, at 12:39, Maurizio Cimadamore wrote: > > Looks good. Thank you. I updated and finalised the CSR. > Minor nits: > > * in getRecordComponents there are some utterings of "true", "false" and "null" which are not surrounded by a {@code } block. > > * any reason as to why the j.l.Record class is not cached in a static field? > No reason. Done. Changes over the previous webrev: diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java +++ b/src/java.base/share/classes/java/lang/Class.java @@ -2278,9 +2278,9 @@ *

The components are returned in the same order that they are declared * in the record header. The array is empty if this record class has no * components. If the class is not a record class, that is {@link - * #isRecord()} returns false, then this method returns null. Conversely, if - * {@link #isRecord()} returns true, then this method returns a non-null - * value. + * #isRecord()} returns {@code false}, then this method returns {@code null}. + * Conversely, if {@link #isRecord()} returns {@code true}, then this method + * returns a non-null value. * * @return An array of {@code RecordComponent} objects representing all the * record components of this record class, or {@code null} if this @@ -3596,8 +3596,7 @@ this.getSuperclass() == java.lang.Enum.class; } - /** Returns java.lang.Record.class */ + /** java.lang.Record.class */ + private static final Class JAVA_LANG_RECORD_CLASS = javaLangRecordClass(); private static Class javaLangRecordClass() { try { return Class.forName0("java.lang.Record", false, null, null); @@ -3631,7 +3630,7 @@ @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.RECORDS, essentialAPI=false) public boolean isRecord() { - return getSuperclass() == javaLangRecordClass() && isRecord0(); + return getSuperclass() == JAVA_LANG_RECORD_CLASS && isRecord0(); } // Fetches the factory for reflective objects Complete webrev: https://cr.openjdk.java.net/~chegar/8235550/webrev.01/ -Chris. From maurizio.cimadamore at oracle.com Tue Dec 10 14:53:19 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 10 Dec 2019 14:53:19 +0000 Subject: RFR [14] 8235550: Clarify record reflective support specification In-Reply-To: <2BE6E3EC-174F-4D04-BFD1-1024DB3F0367@oracle.com> References: <9BE0B0CA-4A8C-4975-A21E-8F4163B68F8C@oracle.com> <2BE6E3EC-174F-4D04-BFD1-1024DB3F0367@oracle.com> Message-ID: Looks good Maurizio On 10/12/2019 14:34, Chris Hegarty wrote: > Maurizio, > >> On 10 Dec 2019, at 12:39, Maurizio Cimadamore >> > > wrote: >> >> Looks good. >> > Thank you. I updated and finalised the CSR. >> >> Minor nits: >> >> * in getRecordComponents there are some utterings of "true", "false" >> and "null" which are not surrounded by a {@code } block. >> >> * any reason as to why the j.l.Record class is not cached in a static >> field? >> > No reason. Done. > > Changes over the previous webrev: > > diff --git a/src/java.base/share/classes/java/lang/Class.java > b/src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java > +++ b/src/java.base/share/classes/java/lang/Class.java > @@ -2278,9 +2278,9 @@ > ? ? ? *

The components are returned in the same order that they > are declared > ? ? ? * in the record header. The array is empty if this record class > has no > ? ? ? * components. If the class is not a record class, that is {@link > -?? ??* #isRecord()} returns false, then this method returns null. > Conversely, if > -?? ??* {@link #isRecord()} returns true, then this method returns a > non-null > -?? ??* value. > +?? ? * #isRecord()} returns {@code false}, then this method returns > {@code null}. > +?? ? * Conversely, if {@link #isRecord()} returns {@code true}, then > this method > +?? ? * returns a non-null value. > ? ? ? * > ? ? ? * @return? An array of {@code RecordComponent} objects > representing all the > ? ? ? *? ? ? ? ? record components of this record class, or {@code > null} if this > @@ -3596,8 +3596,7 @@ > ?? ? ? ? this.getSuperclass() == java.lang.Enum.class; > ?? ? } > > > > - ? ?/** Returns java.lang.Record.class */ > + ? ?/** java.lang.Record.class */ > + ???private static final Class JAVA_LANG_RECORD_CLASS = > javaLangRecordClass(); > ?? ? private static Class javaLangRecordClass() { > ?? ? ? ? try { > ?? ? ? ? ? ? return Class.forName0("java.lang.Record", false, null, null); > @@ -3631,7 +3630,7 @@ > @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.RECORDS, > ? ? essentialAPI=false) > ?? ? public boolean isRecord() { > - ? ? ???return getSuperclass() == javaLangRecordClass() && isRecord0(); > + ? ? ? ?return getSuperclass() == JAVA_LANG_RECORD_CLASS && isRecord0(); > ? ? ?} > > > ?? ? // Fetches the factory for reflective objects > Complete webrev: > https://cr.openjdk.java.net/~chegar/8235550/webrev.01/ > > -Chris. From andy.herrick at oracle.com Tue Dec 10 15:01:58 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 10 Dec 2019 10:01:58 -0500 Subject: RFR: JDK-8235601: redundant code in IOUtils.java In-Reply-To: <359595d2-891f-7a97-9810-b3e44ea8cb5e@oracle.com> References: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> <359595d2-891f-7a97-9810-b3e44ea8cb5e@oracle.com> Message-ID: <4c5a9adc-e76b-41d6-d061-03e9316674fd@oracle.com> I have filed JDK-8235667 to address that separately.? I agree the whole method should be replaced by a Files.copy operation, but because that is not related to the problem being addressed here, I went ahead and pushed that fix and filed this new issue. /Andy On 12/10/2019 1:31 AM, Alan Bateman wrote: > On 09/12/2019 23:17, Andy Herrick wrote: >> Please review simple jpackage fir for issue [1] at [2] > transformFrom is not guaranteed to transfer all bytes so you can't > ignore the return value. I assume you could replace move/all of this > with a Files.copy that specifies REPLACE_EXISTING and COPY_ATTRIBUTES. > > -Alan From alexey.semenyuk at oracle.com Tue Dec 10 15:53:19 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 10 Dec 2019 10:53:19 -0500 Subject: RFR: 8235482: [TESTBUG] PackageType LINUX_RPM should be excluded for jpackage tests on debian systems In-Reply-To: References: <5c6b58ed-0d7b-25a0-a4f4-92cf1ee6613d@loongson.cn> <716346c8-ced9-862b-b6d3-240b438ea3a0@oracle.com> Message-ID: <633a065b-9924-8710-e468-89e4ed919dd1@oracle.com> Daniel, You need to have 'rpmbuild' and 'rpm' command in the path to enable jpackage build rpm packages. - Alexey On 12/10/2019 3:42 AM, Daniel Peintner wrote: > All, > > I think I have a related question/problem. > > I was able to run the latest jpackage build (14-jpackage+1-70 > (2019/11/12)) successfully on Windows creating msi and on Ubuntu > creating deb. > > However, I fail to create a rpm package. I tried both, openSUSE Leap > 15.1 and also Fedora 31. > > Both fail with the statement: > Error: Invalid or unsupported type: [rpm] > > Is this a known error? > > I am using the badass-runtime-plugin [1] but I don't think the plugin > is causing issues. > > Thanks, > > -- Daniel > > [1] https://github.com/beryx/badass-runtime-plugin/ > > > > > On Sat, Dec 7, 2019 at 1:42 AM Jie Fu > wrote: > > Hi Alexey, > > Thanks for your review and comments. > > I have two questions: > ??- 1) Have you ever tried the rpm tests on a debian system? > ??- 2) How to decide whether the rpm tests are supported on a > debian system? > > Thanks a lot. > Best regards, > Jie > > On 2019/12/7 ??1:26, Alexey Semenyuk wrote: > > This fix will disable running rpm tests on Debian systems that > support > > it. This is not a good idea. > > If you need to exclude some packaging from jpackage tests, just run > > jtreg with "jpackage.test.disabledPackagers" system property set to > > the list of corresponding package types. E.g.: > > -Djpackage.test.disabledPackagers=rpm will disable rpm packaging. > > > > - Alexey > > > > On 12/6/2019 7:51 AM, Jie Fu wrote: > >> Hi all, > >> > >> May I get reviews for the small fix? > >> > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235482 > >> Webrev: http://cr.openjdk.java.net/~jiefu/8235482/webrev.00/ > >> > >> Thanks a lot. > >> Best regards, > >> Jie > >> > From alexey.semenyuk at oracle.com Tue Dec 10 15:53:59 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 10 Dec 2019 10:53:59 -0500 Subject: RFR: 8235625: [TESTBUG] tools/jpackage/share/JavaOptionsEqualsTest.java fails with debug VMs In-Reply-To: References: Message-ID: Looks good. - Alexey On 12/9/2019 9:26 PM, Jie Fu wrote: > Hi all, > > May I get reviews for the small fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235625 > Webrev: http://cr.openjdk.java.net/~jiefu/8235625/webrev.00/ > > Thanks a lot. > Best regards, > Jie > From alexey.semenyuk at oracle.com Tue Dec 10 16:06:41 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 10 Dec 2019 11:06:41 -0500 Subject: RFR: JDK-8235601: redundant code in IOUtils.java In-Reply-To: <0d708344-249c-b50c-7fd9-2eea548e4768@oracle.com> References: <17065a4c-f985-4214-bddf-391d639ed707@oracle.com> <1d3f4ff3-0a6c-1935-1830-9e7c1bfae305@oracle.com> <0d708344-249c-b50c-7fd9-2eea548e4768@oracle.com> Message-ID: Looks good. - Alexey On 12/9/2019 8:26 PM, Andy Herrick wrote: > > On 12/9/2019 6:53 PM, Phil Race wrote: >> > [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ >> >> This does not bring up the expected webrev > > My apologies - I uploaded the wrong webrev - It should be fixed now. > > /Andy > >> >> -phil. >> >> On 12/9/19 3:17 PM, Andy Herrick wrote: >>> Please review simple jpackage fix for issue [1] at [2] >>> >>> /Andy >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235601 >>> >>> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/ >>> >>> /Andy >>> >> From alexey.semenyuk at oracle.com Tue Dec 10 16:09:38 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 10 Dec 2019 11:09:38 -0500 Subject: RFR: JDK-8234867: Issue warning for mutually exclusive options on jpackage command line In-Reply-To: References: Message-ID: <0ca32017-a465-5318-8daa-57044df7b347@oracle.com> Looks good. - Alexey On 12/9/2019 4:42 PM, Andy Herrick wrote: > Please review simple fix [2] for jpackage bug [1] > > fixing error message for mutually exclusive options. > > /Andy > > [1] https://bugs.openjdk.java.net/browse/JDK-8234867 > > [2] http://cr.openjdk.java.net/~herrick/8234867/webrev.01/ > From andy.herrick at oracle.com Tue Dec 10 17:56:07 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 10 Dec 2019 12:56:07 -0500 Subject: RFR: JDK-8235667: IOUtils.copyFile() problems. Message-ID: <95feef53-1a70-f92a-614d-a8a4a9fab1d4@oracle.com> Please review the jpackage fix at [1] to issue [2]. This is a change to jpackage/internal/IOUtils.copyFile() to essentially replace it's content with a call to Files.copy() [1] http://cr.openjdk.java.net/~herrick/8235667/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8235667 /Andy From joe.darcy at oracle.com Tue Dec 10 18:07:27 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 10 Dec 2019 10:07:27 -0800 Subject: RFR [14] 8235531: Update record serialization migration tests to not use hard coded source versions In-Reply-To: <0D44D4B3-F2CE-4CA1-81E4-D72F021AF218@oracle.com> References: <0D44D4B3-F2CE-4CA1-81E4-D72F021AF218@oracle.com> Message-ID: Looks good Chris; thanks, -Joe On 12/10/2019 3:08 AM, Chris Hegarty wrote: > In preparation for the imminent arrival of 15 to jdk/jdk, this change > replaces the hardcoded source version, used to invoke the compiler > programmatically, with the runtime feature version, similar to > JDK-8235514. > > I tested this change along side the changes for 8225361 - "Start of > release updates for JDK 15" - and the record serialization migration > tests pass successfully. > > --- a/test/jdk/java/io/Serializable/records/migration/AbstractTest.java > +++ b/test/jdk/java/io/Serializable/records/migration/AbstractTest.java > @@ -32,48 +32,50 @@ > import java.net.URI; > import java.net.URL; > import java.net.URLClassLoader; > import java.nio.file.Path; > import jdk.test.lib.compiler.CompilerUtils; > import org.testng.annotations.BeforeTest; > import static org.testng.Assert.*; > > /** > * An abstract superclass for tests that require to serialize and deserialize > * record-like and record classes. Can be used for determining migration and > * interop between record-like and record classes. > */ > public class AbstractTest { > > + private static final String VERSION = Integer.toString(Runtime.version().feature()); > + > static final String TEST_SRC = System.getProperty("test.src", "."); > static final String TEST_CLASSES = System.getProperty("test.classes", "."); > static final Path TEST_CLASSES_DIR = Path.of(TEST_CLASSES); > > static final Path PLAIN_SRC_DIR = Path.of(TEST_SRC, "plain"); > static final Path PLAIN_DEST_DIR = Path.of("plain"); > > static final Path RECORD_SRC_DIR = Path.of(TEST_SRC, "record"); > static final Path RECORD_DEST_DIR = Path.of("record"); > > @BeforeTest > public void setup() throws IOException { > assertTrue(CompilerUtils.compile(PLAIN_SRC_DIR, PLAIN_DEST_DIR, > - "--enable-preview", "-source", "14", > + "--enable-preview", "-source", VERSION, > "--class-path", TEST_CLASSES_DIR.toString())); > > assertTrue(CompilerUtils.compile(RECORD_SRC_DIR, RECORD_DEST_DIR, > - "--enable-preview", "-source", "14", > + "--enable-preview", "-source", VERSION, > "--class-path", TEST_CLASSES_DIR.toString())); > } > > static byte[] serialize(T obj) throws IOException { > ByteArrayOutputStream baos = new ByteArrayOutputStream(); > ObjectOutputStream oos = new ObjectOutputStream(baos); > oos.writeObject(obj); > oos.close(); > return baos.toByteArray(); > } > > @SuppressWarnings("unchecked") > static T deserializeAsPlain(byte[] streamBytes) > throws IOException, ClassNotFoundException > { > > > -Chris. > From paul.sandoz at oracle.com Tue Dec 10 18:45:35 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 10 Dec 2019 10:45:35 -0800 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> Message-ID: <12784CB4-7357-4F19-B307-1AE8354D40F7@oracle.com> > On Dec 10, 2019, at 4:51 AM, Maurizio Cimadamore wrote: > > And, another, small iteration > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v5 > > Delta compared to previous version (v4): > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v5_delta > > Javadoc updated in place: > > http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html > > > Summary of changes: > > * Peter pointed out that the logic for checking overflow in MemoryScope::acquire was bogus, as once we had an overflow, the segment was rendered useless (as the count stayed in negative overflowed state) - separately, Paul pointed out that it would be better to roll in our atomic loops, and just use a VarHandle instead of atomic integer - I've rewritten MemoryScope quite a bit, to implement these changes; I think the result is much cleaner than before. Note that, in the new code, the boolean flag is gone, and we just use the int count for everything (thanks to Jorn for the nice observation). MemoryScope changes look good. In j.u.concurrent we use ExceptionInInitializerError in the static blocks when there is an error looking up the VH, FWIW close can also fail because it has already been closed but the exception message does not distinguish between the two states (active or already closed). Paul. > > * Peter also pointer out that the isAlive() check is not thread-safe; I now have named the liveness-check-related methods explicitly (and added some javadoc), so that it's clear when they can be called safely > > * removed call to checkAlive from MemorySegment::acquire - MemoryScope;:acquire will check that anyway > > * fixed rough javadoc comment on MemoryLayout::withName > > * dropped non-overlapping restriction on MemoryAddress::copy (and fixed test accordingly) > > Maurizio > > > On 09/12/2019 19:23, Maurizio Cimadamore wrote: >> Another iteration: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/ >> >> Delta of the changes since last version (v3) here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4_delta/ >> >> The javadoc has been updated inline here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >> >> Summary of changes: >> >> * Improved javadoc regarding alignment and access modes in MemoryHandles >> * related to the above, the memory access varhandle now checks for low-level VM alignment to for access other than get/set (as happens for regular byte buffer view var handle) >> * fixed MemoryHandles, JavaLangInvokeAccess, VarHandles, MethodHandleImpl to speak about alignmentMask, rather than alignment (as per Roger comments) >> * added some more javadoc to internal classes MemoryAddressProxy, VarHandleMemoryAddressBase, JavaNioAccess.java and JavaLangInvokeAccess.java (as per Roger comments) >> * fixed mising {code} block around alignment param A in MemoryLayout::bitAlignment/bytesAlignment (as per offline comments from Daniel) >> * added positive test to TestMemoryCopy >> >> Cheers >> Maurizio >> >> On 08/12/2019 01:44, Maurizio Cimadamore wrote: >>> Another update: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3/ >>> >>> And a delta of the changes since last version (v2) here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3_delta/ >>> >>> The javadoc has been updated inline here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>> >>> Summary of changes: >>> >>> * fixed some (cosmetic) issues in FileChannelmpl following offline discussion with Alan >>> * changed tests group definition, so that now jdk_foreign is part of tier1_part3 >>> * updated javadoc in various places to fix code samples (as per Paul comments) >>> * updated javadoc in MemoryHandles to talk about access modes (as per Paul comments) - I added a new section on top, and then referred to in from all relevant places >>> * some changes to use Objects.hash (as per Paul comments), and some minor refactor in the AddreddGenerator (to use switch expression) >>> * tightened javadoc for MemoryAddress::copy - the method now is specified to throw IAE if the range of source/dest addresses overlap - I've fixed the impl and added a test (as per Raffaello comments) >>> * tightened byte buffer VarHandle view - if the view is created from a byte buffer obtained from a segment (!!!) we should do a segment check - added tests >>> >>> >>> And here's a list of the pending API-related issues. Since these are IMHO minor issues, I suggest we defer them to a followup minor cleanup, so that we can move ahead with finalization of the CSR with the current API. Here's the list: >>> >>> * Should MemoryAddress implement Comparable? I think the answer is "probably not" - an address doesn't have a 'length' so you can't really do a range comparison (maybe memory segments though?). For now, users can project to byte buffer and take it from there (since ByteBuffer <: Comparable) >>> * should we have a way to ask a Layout if its size is specified ? (Paul) >>> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much distance between these two semantically different operations (Paul suggested using 'add' - which I'm not enthusiastic about because it's not adding two addresses - it's adding a long to an address...) >>> * MemorySegment::isAccessible() -- as the A* word is overloaded, some other name should be found? >>> * MemorySegment::acquire() -- replace with MemorySegment::fork? >>> >>> Thanks >>> Maurizio >>> >>> On 06/12/2019 10:43, Maurizio Cimadamore wrote: >>>> Hi, >>>> here's an updated version of the patch: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2/ >>>> >>>> And a delta of the changes since last version here: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v2_delta/ >>>> >>>> The javadoc has been updated inline here: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>>> >>>> Summary of changes: >>>> >>>> * fixed spurious protected methods in AbstractLayout and subclasses which leaked into API >>>> * removed library_call.cpp changes, as these are being tracked separately by Vlad >>>> * compacted ILOAD code in AddressVarHandleGenerator >>>> * replaced uses of ++i/--i with i + 1/i - 1 in MemoryScope >>>> >>>> I have made no changes to the *name* of the methods in the API. In fact, I suggest we keep a list of the names we'd like to revisit, and we address them all at once at the end of the review (once we're happy with the contents). Here's a list of the current open naming issues: >>>> >>>> * MemoryAddress::offset() vs. MemoryAddress::offset(long) -- not much distance between these two semantically different operations >>>> * MemorySegment::isAccessible() -- as the A* word is overloaded, some other name should be found? >>>> * MemorySegment::acquire() -- replace with MemorySegment::fork? >>>> >>>> Cheers >>>> Maurizio >>>> >>>> >>>> On 05/12/2019 21:04, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code review for the corresponding core-libs and hotspot changes: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8234049/ >>>>> >>>>> A javadoc for the memory access API is also available here: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc/jdk/incubator/foreign/package-summary.html >>>>> >>>>> Note: the patch passes tier1, tier2 and tier3 testing (**) >>>>> >>>>> >>>>> Here is a brief summary of the changes in java.base and hotspot (the remaining new files are implementation classes and tests for the new API): >>>>> >>>>> * ciField.cpp - this one is to trust final fields in the foreign memory access implementation (otherwise VM doesn't trust memory segment bounds) >>>>> >>>>> * Modules.gmk - these changes are needed to require that the incubating module is loaded by the boot loader (otherwise the above changes are useless) >>>>> >>>>> * library_call.cpp - this one is a JIT compiler change to treat Thread.currentThread() as a well-known constant - which helps a lot in the confinement checks (thanks Vlad!) >>>>> >>>>> * various Buffer-related changes; these changes are needed because the memory access API allows a memory segment to be projected into a byte buffer, for interop reasons. As such, we need to insert a liveness check in the various get/put methods. Previously we had an implementation strategy where a BB was 'decorated' by a subclass called ScopedBuffer - but doing so required some changes to the BB API (e.g. making certain methods non-final, so that we could decorate them). Here I use an approach (which I have discussed with Alan) which doesn't require any public API changes, but needs to add a 'segment' field in Buffer - and then have constructors which keep track of this extra parameter. >>>>> >>>>> * FileChannel changes - these changes are required so that we can reuse the Unmapper class from the MemorySegment implementation, to deterministically deallocate a mapped memory segment. This should be a 'straight' refactoring, no change in behavior should occur here. Please double check. >>>>> >>>>> * VarHandles - this class now provides a factory to create memory access VarHandle - this is a bit tricky, since VarHandle cannot really be implemented outside java.base (e.g. VarForm is not public). So we do the usual trick where we define a bunch of proxy interfaces (see jdk/internal/access/foreign) have the classes in java.base refer to these - and then have the implementation classes of the memory access API implement these interfaces. >>>>> >>>>> * JavaNIOAccess, JavaLangInvokeAccess - because of the above, we need to provide access to otherwise hidden functionalities - e.g. creating a new scoped buffer, or retrieving the properties of a memory access handle (e.g. offset, stride etc.), so that we can implement the memory access API in its own separate module >>>>> >>>>> * GensrcVarHandles.gmk - these changes are needed to enable the generation of the new memory address var handle implementations; there's an helper class per carrier (e.g. VarHandleMemoryAddressAsBytes, ...). At runtime, when a memory access var handle is needed, we dynamically spin a new VH implementation which makes use of the right carrier. We need to spin because the VH can have a variable number of access coordinates (e.g. depending on the dimensions of the array to be accessed). But, under the hood, all the generated implementation will be using the same helper class. >>>>> >>>>> * tests - we've tried to add fairly robust tests, often checking all possible permutations of carriers/dimensions etc. Because of that, the tests might not be the easiest to look at, but they have proven to be pretty effective at shaking out issues. >>>>> >>>>> I think that covers the main aspects of the implementation and where it differs from vanilla JDK. >>>>> >>>>> P.S. >>>>> >>>>> In the CSR review [2], Joe raised a fair point - which is MemoryAddress has both: >>>>> >>>>> offset(long) --> move address of given offset >>>>> offset() --> return the offset of this address in its owning segment >>>>> >>>>> And this was considered suboptimal, given both methods use the same name but do something quite different (one is an accessor, another is a 'wither'). one obvious option is to rename the first to 'withOffset'. But I think that would lead to verbose code (since that is a very common operation). Other options are to: >>>>> >>>>> * rename offset(long) to move(long), advance(long), or something else >>>>> * drop offset() - but then add an overload of MemorySegment::asSlice which takes an address instead of a plain long offset >>>>> >>>>> I'll leave the choice to the reviewers :-) >>>>> >>>>> >>>>> >>>>> Finally, I'd like to thank Mark, Brian, John, Alan, Paul, Vlad, Stuart, Roger, Joe and the Panama team for the feedback provided so far, which helped to get the API in the shape it is today. >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>>> (**) There is one failure, for "java/util/TimeZone/Bug6329116.java" - but that is unrelated to this patch, and it's a known failing test. >>>>> >>>>> [1] - https://openjdk.java.net/jeps/370 >>>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8234050 >>>>> From andy.herrick at oracle.com Tue Dec 10 20:00:45 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 10 Dec 2019 15:00:45 -0500 Subject: RFR: JDK-8235667: IOUtils.copyFile() problems. In-Reply-To: <95feef53-1a70-f92a-614d-a8a4a9fab1d4@oracle.com> References: <95feef53-1a70-f92a-614d-a8a4a9fab1d4@oracle.com> Message-ID: <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> On 12/10/2019 12:56 PM, Andy Herrick wrote: > Please review the jpackage fix at [1] to issue [2]. > > This is a change to jpackage/internal/IOUtils.copyFile() to > essentially replace it's content with a call to Files.copy() > > [1] http://cr.openjdk.java.net/~herrick/8235667/webrev.01/ > > [2] https://bugs.openjdk.java.net/browse/JDK-8235667 > > /Andy > given the suggestion: > The method ignores the return from mkdirs, you could replace that with > Files.createDirectories if you want the IOException. I have revised the webrev at [3] [3] http://cr.openjdk.java.net/~herrick/8235667/webrev.02/ /Andy From hohensee at amazon.com Tue Dec 10 20:16:31 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 10 Dec 2019 20:16:31 +0000 Subject: [8u] RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com> References: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com> Message-ID: <03766CF0-CA07-47A5-AEBD-A0E451FAD87B@amazon.com> Lgtm. I'll sponsor it and tag the JBS issue with jdk8u-fix-request. Thanks, Paul ?On 12/9/19, 4:55 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: Hi Adam, This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing list (jdk8u-dev not jdk-updates-dev; bcc'ed the latter) and fixing the subject line. Thanks, Severin On Thu, 2019-10-03 at 15:53 +0100, Adam Farley8 wrote: > Hey all, > > Four GPLv2 files in 8u seem to be missing the classpath exception from the > copyright section. > > Requesting reviews and a sponsor. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227715 > > Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > 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 alexander.matveev at oracle.com Tue Dec 10 21:35:04 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 10 Dec 2019 13:35:04 -0800 Subject: RFR: JDK-8235252: Repair run_tests.sh by locating jtreg locally Message-ID: <35a28018-d1d0-f077-d143-6500877e6856@oracle.com> Please review simple script fix [2] for jpackage bug [1]. ?- Modified script to download jtreg bundle from URL provided by environment variable JTREG_BUNDLE_URL. Thanks, Alexander [1] https://bugs.openjdk.java.net/browse/JDK-8235252 [2] http://cr.openjdk.java.net/~almatvee/8235252/webrev.00/ From jonathan.gibbons at oracle.com Tue Dec 10 21:49:30 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Dec 2019 13:49:30 -0800 Subject: RFR: JDK-8235252: Repair run_tests.sh by locating jtreg locally In-Reply-To: <35a28018-d1d0-f077-d143-6500877e6856@oracle.com> References: <35a28018-d1d0-f077-d143-6500877e6856@oracle.com> Message-ID: This seems ... surprising. Why is the instance of jtreg used for all the other tests not good enough here? -- Jon On 12/10/19 1:35 PM, Alexander Matveev wrote: > Please review simple script fix [2] for jpackage bug [1]. > > ?- Modified script to download jtreg bundle from URL provided by > environment variable JTREG_BUNDLE_URL. > > Thanks, > Alexander > > [1] https://bugs.openjdk.java.net/browse/JDK-8235252 > > [2] http://cr.openjdk.java.net/~almatvee/8235252/webrev.00/ From alexander.matveev at oracle.com Tue Dec 10 22:24:22 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 10 Dec 2019 14:24:22 -0800 Subject: RFR: JDK-8235667: IOUtils.copyFile() problems. In-Reply-To: <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> References: <95feef53-1a70-f92a-614d-a8a4a9fab1d4@oracle.com> <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> Message-ID: <51a1381c-9ccb-3834-6353-d74b226a0462@oracle.com> Looks good. Thanks, Alexander On 12/10/2019 12:00 PM, Andy Herrick wrote: > > On 12/10/2019 12:56 PM, Andy Herrick wrote: >> Please review the jpackage fix at [1] to issue [2]. >> >> This is a change to jpackage/internal/IOUtils.copyFile() to >> essentially replace it's content with a call to Files.copy() >> >> [1] http://cr.openjdk.java.net/~herrick/8235667/webrev.01/ >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8235667 >> >> /Andy >> > given the suggestion: >> The method ignores the return from mkdirs, you could replace that >> with Files.createDirectories if you want the IOException. > > I have revised the webrev at [3] > > [3] http://cr.openjdk.java.net/~herrick/8235667/webrev.02/ > > /Andy > From alexey.semenyuk at oracle.com Tue Dec 10 23:32:50 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 10 Dec 2019 18:32:50 -0500 Subject: RFR: JDK-8235252: Repair run_tests.sh by locating jtreg locally In-Reply-To: References: <35a28018-d1d0-f077-d143-6500877e6856@oracle.com> Message-ID: <2b553034-66cc-7615-1f1c-951b0b441e94@oracle.com> http://cr.openjdk.java.net/~almatvee/8235252/webrev.01/ looks good. - Alexey On 12/10/2019 4:49 PM, Jonathan Gibbons wrote: > This seems ... surprising. > > Why is the instance of jtreg used for all the other tests not good > enough here? > > -- Jon > > On 12/10/19 1:35 PM, Alexander Matveev wrote: >> Please review simple script fix [2] for jpackage bug [1]. >> >> ?- Modified script to download jtreg bundle from URL provided by >> environment variable JTREG_BUNDLE_URL. >> >> Thanks, >> Alexander >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235252 >> >> [2] http://cr.openjdk.java.net/~almatvee/8235252/webrev.00/ From alexey.semenyuk at oracle.com Tue Dec 10 23:33:15 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 10 Dec 2019 18:33:15 -0500 Subject: RFR: JDK-8235667: IOUtils.copyFile() problems. In-Reply-To: <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> References: <95feef53-1a70-f92a-614d-a8a4a9fab1d4@oracle.com> <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> Message-ID: <89400b44-8d31-dd05-1181-f3fe5a3854df@oracle.com> Looks good. - Alexey On 12/10/2019 3:00 PM, Andy Herrick wrote: > > On 12/10/2019 12:56 PM, Andy Herrick wrote: >> Please review the jpackage fix at [1] to issue [2]. >> >> This is a change to jpackage/internal/IOUtils.copyFile() to >> essentially replace it's content with a call to Files.copy() >> >> [1] http://cr.openjdk.java.net/~herrick/8235667/webrev.01/ >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8235667 >> >> /Andy >> > given the suggestion: >> The method ignores the return from mkdirs, you could replace that >> with Files.createDirectories if you want the IOException. > > I have revised the webrev at [3] > > [3] http://cr.openjdk.java.net/~herrick/8235667/webrev.02/ > > /Andy > From alexander.matveev at oracle.com Tue Dec 10 23:54:08 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 10 Dec 2019 15:54:08 -0800 Subject: RFR: JDK-8235252: Repair run_tests.sh by locating jtreg locally In-Reply-To: <2b553034-66cc-7615-1f1c-951b0b441e94@oracle.com> References: <35a28018-d1d0-f077-d143-6500877e6856@oracle.com> <2b553034-66cc-7615-1f1c-951b0b441e94@oracle.com> Message-ID: <8a0c2957-71e0-18cc-96b7-6d651919e0f6@oracle.com> http://cr.openjdk.java.net/~almatvee/8235252/webrev.01/ - Updated script to use JT_HOME first if set, then use JT_BUNDLE_URL if set. - Also, renamed JTREG_ to JT_ in variables names to align with rest of JDK. Not sure why we did not use jtreg used by all the other tests. run_tests.sh used for convenience to generate and verify packages generated by jpackage. This process done in 5 stages: generating packages (jtreg test), installation (requires user input), verify installation, uninstall (requires user input) and verify uninstall. This is why we using helper script to simplify this process. Thanks, Alexander On 12/10/2019 3:32 PM, Alexey Semenyuk wrote: > http://cr.openjdk.java.net/~almatvee/8235252/webrev.01/ looks good. > > - Alexey > > On 12/10/2019 4:49 PM, Jonathan Gibbons wrote: >> This seems ... surprising. >> >> Why is the instance of jtreg used for all the other tests not good >> enough here? >> >> -- Jon >> >> On 12/10/19 1:35 PM, Alexander Matveev wrote: >>> Please review simple script fix [2] for jpackage bug [1]. >>> >>> ?- Modified script to download jtreg bundle from URL provided by >>> environment variable JTREG_BUNDLE_URL. >>> >>> Thanks, >>> Alexander >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235252 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8235252/webrev.00/ > From maurizio.cimadamore at oracle.com Wed Dec 11 00:13:39 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 11 Dec 2019 00:13:39 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <12784CB4-7357-4F19-B307-1AE8354D40F7@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> <12784CB4-7357-4F19-B307-1AE8354D40F7@oracle.com> Message-ID: <523d08f4-5604-3a2d-7245-733a5fdc028b@oracle.com> On 10/12/2019 18:45, Paul Sandoz wrote: > MemoryScope changes look good. > > In j.u.concurrent we use ExceptionInInitializerError in the static blocks when there is an error looking up the VH, > > FWIW close can also fail because it has already been closed but the exception message does not distinguish between the two states (active or already closed). > > Paul. > Hi Paul, would something like this be satisfactory? diff -r 50ef46599c56 src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java --- a/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java Tue Dec 10 16:28:03 2019 +0000 +++ b/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java Wed Dec 11 00:12:20 2019 +0000 @@ -48,7 +48,7 @@ ???????? try { ???????????? COUNT_HANDLE = MethodHandles.lookup().findVarHandle(MemoryScope.class, "activeCount", int.class); ???????? } catch (Throwable ex) { -??????????? throw new IllegalStateException(ex); +??????????? throw new ExceptionInInitializerError(ex); ???????? } ???? } @@ -107,6 +107,9 @@ ???? void close() { ???????? if (!COUNT_HANDLE.compareAndSet(this, UNACQUIRED, CLOSED)) { +??????????? //first check if already closed... +??????????? checkAliveConfined(); +??????????? //...if not, then we have acquired views that are still active ???????????? throw new IllegalStateException("Cannot close a segment that has active acquired views"); ???????? } ???????? if (cleanupAction != null) { If you need a full webrev please let me know. Thanks Maurizio From ksrinifmt at gmail.com Wed Dec 11 01:42:47 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Tue, 10 Dec 2019 17:42:47 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> Message-ID: [Resend; cc'ing the group] Hi Nikola, Generally looks great to me. I would have moved initModulesDir to TestHelper.createSimpleModule(File dir). TestHelper.java contains a collection of test related utilities needed by the launcher, it will help someone else use it to create a simple module. I would have rewritten this + ArrayList scratchpad = new ArrayList<>(); + scratchpad.add("module test {}"); + createFile(new File(testDir, "module-info.java"), scratchpad); + scratchpad.clear(); + scratchpad.add("package launcher;"); + scratchpad.add("import java.util.Arrays;"); + scratchpad.add("public class Main {"); + scratchpad.add("public static void main(String[] args) {"); + scratchpad.add("System.out.println(Arrays.toString(args));"); + scratchpad.add("}"); + scratchpad.add("}"); + createFile(new File(launcherTestDir, "Main.java"), scratchpad); as follows: String a1[] = {"module test{}"}; createFile(new File(testDir, "module-info.java", Arrays.asList(a1)); String a2[] = { "package launcher;", .... .... } createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(a2)); This might make the code neater. Besides that, looks very good. Thanks Kumar On Mon, Dec 9, 2019 at 1:58 PM Nikola Grcevski < Nikola.Grcevski at microsoft.com> wrote: > Hi Henry and Kumar, > > Thank you again for the review! I have added the fix to isTerminalOpt and > used both of your suggestions to make new tests. > With native memory tracking enabled, I could actually see a crash on both > Linux and Windows without the suggested fix. > > I tested the changes again on both Linux and Windows, and the new unit > tests fail if isTerminalOpt doesn?t check for ?module= > as per Henry's suggestion. > > I'm attaching the new patch (my apologies for the size) at the bottom of > this email after my signature. If I haven't covered > certain aspects in the new tests please let me know, I'm more than happy > to extend them further. I've updated the webrev > to reflect the latest patch if it's easier to read: > https://grcevski.github.io/JDK-8234076/webrev/ > > Thanks again! > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 > +0800 > +++ b/src/java.base/share/native/libjli/args.c Mon Dec 09 16:08:54 2019 > -0500 > @@ -130,6 +130,8 @@ > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > @@ -449,6 +451,7 @@ > return JLI_StrCmp(arg, "-jar") == 0 || > JLI_StrCmp(arg, "-m") == 0 || > JLI_StrCmp(arg, "--module") == 0 || > + JLI_StrCCmp(arg, "--module=") == 0 || > JLI_StrCmp(arg, "--dry-run") == 0 || > JLI_StrCmp(arg, "-h") == 0 || > JLI_StrCmp(arg, "-?") == 0 || > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c Mon Dec 09 > 16:08:54 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > > // sanity check, match the args we have, to the holy grail > idx = JLI_GetAppArgIndex(); > + > + // First arg index is NOT_FOUND > + if (idx < 0) { > + // The only allowed value should be NOT_FOUND (-1) unless another > change introduces > + // a different negative index > + assert (idx == -1); > + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", > idx); > + JLI_TraceLauncher("passing arguments as-is.\n"); > + return NewPlatformStringArray(env, strv, argc); > + } > + > isTool = (idx == 0); > if (isTool) { idx++; } // skip tool name > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, > stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java > --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 > +0800 > +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Mon Dec 09 16:08:54 2019 > -0500 > @@ -37,6 +37,8 @@ > import java.util.List; > import java.util.Map; > import java.util.regex.Pattern; > +import java.nio.file.Paths; > +import java.nio.file.Path; > > public class ArgsEnvVar extends TestHelper { > private static File testJar = null; > @@ -153,6 +155,7 @@ > List.of("-jar", "test.jar"), > List.of("-m", "test/Foo"), > List.of("--module", "test/Foo"), > + List.of("--module=test/Foo"), > List.of("--dry-run"), > List.of("-h"), > List.of("-?"), > @@ -241,6 +244,101 @@ > verifyOptions(List.of("--add-exports", > "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); > } > > + /** > + * Helper method to initialize a simple module that just prints the > passed in arguments > + */ > + private void initModulesDir(File modulesDir) throws IOException { > + if (modulesDir.exists()) { > + recursiveDelete(modulesDir); > + } > + > + modulesDir.mkdirs(); > + > + File srcDir = new File(modulesDir, "src"); > + File modsDir = new File(modulesDir, "mods"); > + File testDir = new File(srcDir, "test"); > + File launcherTestDir = new File(testDir, "launcher"); > + srcDir.mkdir(); > + modsDir.mkdir(); > + testDir.mkdir(); > + launcherTestDir.mkdir(); > + > + ArrayList scratchpad = new ArrayList<>(); > + scratchpad.add("module test {}"); > + createFile(new File(testDir, "module-info.java"), scratchpad); > + scratchpad.clear(); > + scratchpad.add("package launcher;"); > + scratchpad.add("import java.util.Arrays;"); > + scratchpad.add("public class Main {"); > + scratchpad.add("public static void main(String[] args) {"); > + scratchpad.add("System.out.println(Arrays.toString(args));"); > + scratchpad.add("}"); > + scratchpad.add("}"); > + createFile(new File(launcherTestDir, "Main.java"), scratchpad); > + } > + > + @Test > + // That that we can correctly handle the module longform argument > option > + // when supplied in an argument file > + public void modulesInArgsFile() throws IOException { > + File cwd = new File("."); > + File testModuleDir = new File(cwd, "modules_test"); > + > + initModulesDir(testModuleDir); > + > + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); > + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), > "mods"); > + > + // test module / main class > + String MODULE_OPTION = "--module=test/launcher.Main"; > + String TEST_MODULE = "test"; > + > + // javac -d mods/test src/test/** > + TestResult tr = doExec( > + javacCmd, > + "-d", MODS_DIR.toString(), > + "--module-source-path", SRC_DIR.toString(), > + "--module", TEST_MODULE); > + > + if (!tr.isOK()) { > + System.out.println("test did not compile"); > + throw new RuntimeException("Error: modules test did not > compile"); > + } > + > + // verify the terminating ability of --module= through > environment variables > + File argFile = createArgFile("cmdargs", List.of("--module-path", > MODS_DIR.toString(), MODULE_OPTION, "--hello")); > + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); > + tr = doExec(env, javaCmd); > + tr.checkNegative(); > + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is > not allowed in environment variable JDK_JAVA_OPTIONS"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check that specifying --module and --module-path with file > works > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); > + tr.contains("[--hello]"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check with reversed --module-path and --module in the > arguments file, this will fail, --module= is terminating > + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, > "--module-path", MODS_DIR.toString(), "--hello")); > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); > + tr.checkNegative(); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // clean-up > + argFile.delete(); > + argFile1.delete(); > + recursiveDelete(testModuleDir); > + } > + > public static void main(String... args) throws Exception { > init(); > ArgsEnvVar a = new ArgsEnvVar(); > diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java > --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Mon Dec 09 > 16:08:54 2019 -0500 > @@ -246,6 +246,10 @@ > if (!tr.contains("Error: Could not find or load main class > AbsentClass")) { > throw new RuntimeException("Test Fails"); > } > + > + // Make sure we handle correctly the module long form (--module=) > + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", > "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); > + ensureNoWarnings(tr); > } > > void ensureNoWarnings(TestResult tr) { > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Mon Dec 09 > 16:08:54 2019 -0500 > @@ -29,6 +29,7 @@ > * jdk.jlink > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > * @run testng BasicTest > + * @bug 8234076 > * @summary Basic test of starting an application as a module > */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ > // the module main class > private static final String MAIN_CLASS = "jdk.test.Main"; > > + // for Windows specific launcher tests > + static final boolean IS_WINDOWS = System.getProperty("os.name", > "unknown").startsWith("Windows"); > > @BeforeTest > public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ > assertTrue(exitValue != 0); > } > > + > + /** > + * Helper method that creates a ProcessBuilder with command line > arguments > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > + */ > + private ProcessBuilder createProcessWithLauncherDebugging(String... > cmds) { > + ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > + return pb; > + } > + > + /** > + * Test the ability for the Windows launcher to do proper application > argument > + * detection and expansion, when using the long form module option > and all passed in > + * command line arguments are prefixed with a dash. > + * > + * These tests are not expected to work on *nixes, and are ignored. > + */ > + public void testWindowsWithLongFormModuleOption() throws Exception { > + if (!IS_WINDOWS) { > + return; > + } > + > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > + // We should be able to find the argument --help as an > application argument > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help"); > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > <...src/test>/*.java --help > + // We should be able to see argument expansion happen > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help") > + .shouldContain("module-info.java"); > + } > + > + > + /** > + * Test that --module= is terminating for VM argument processing just > like --module > + */ > + public void testLongFormModuleOptionTermination() throws Exception { > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --module-path=mods --module=$TESTMODULE/$MAINCLASS > + // The first --module= will terminate the VM arguments > processing. The second pair of module-path and module will be > + // deemed as application arguments > + OutputAnalyzer output = ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--module-path=" + dir, > + "--module=" + mid)) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("argv[ 0] = '--module-path=" + dir) > + .shouldContain("argv[ 1] = '--module=" + mid); > + > + if (IS_WINDOWS) { > + output.shouldContain("F--module-path=" + > dir).shouldContain("F--module=" + mid); > + } > + > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > + // This command line will not work as --module= is terminating > and the module will be not found > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > + assertTrue(exitValue != 0); > + } > } > > > From: Kumar Srinivasan > Sent: December 7, 2019 10:28 PM > To: Henry Jen > Cc: Nikola Grcevski ; Alan Bateman < > Alan.Bateman at oracle.com>; core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > Hi, > > The launcher fix looks good, despite the launcher fix being simple, please > note, > it sometimes requires a lot more effort to write a test for it, please > read on.... > > Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my > memory and I recalled > this change for VM's native memory tracking. > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875799903&sdata=WOjzJJtIY0y4rB2liNkH4nUMNLq2uEnJ8J01gWFgt5w%3D&reserved=0 > Inspecting the above changeset, we might have to add another test for JVM > native memory tracking, > since this is a terminal argument. > > Maybe TestHelper could create a simple module, which prints its args, > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875809897&sdata=1GLeqSPxVRhGVgE7Cxf6w5l%2F34uOHCGTq2fRIjoxaGg%3D&reserved=0 > > Kumar Srinivasan > > On Fri, Dec 6, 2019 at 2:44 PM Henry Jen > wrote: > Thanks for the work, the test case covers that when ?module= is used > before other options, which is good. > > But we need another to make sure that when ?module= is put in an argument > file or environment variable, that should not be allowed. The fix is > simple, we need to add that to isTerminalOp() method. > > Cheers, > Henry > > > On Dec 6, 2019, at 12:28 PM, Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > > > > Thank you Henry! > > > > I have modified the fix in checkArg to use JLI_StrCCmp as suggested > below and I have extended the BasicTest.java (in > test/jdk/tools/launcher/modules/basic) with few additional tests. > > > > I don't have author status yet, therefore I'm attaching the patch right > after my signature. I also updated my external webrev if that's easier to > review ( > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875809897&sdata=4iDS4fvjQlBxrGBhaLz3lHIWM7gNvFrvz01cqw%2B6O34%3D&reserved=0 > ) > > > > Thanks again to everyone for your help with this bug. If there are any > additional comments or suggestions please let me know. > > Nikola > > > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -130,6 +130,8 @@ > > } > > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > > stopExpansion = JNI_TRUE; > > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > > + idx = argsCount; > > } > > } else { > > if (!expectingNoDashArg) { > > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -34,6 +34,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include "java.h" > > @@ -1015,6 +1016,17 @@ > > > > // sanity check, match the args we have, to the holy grail > > idx = JLI_GetAppArgIndex(); > > + > > + // First arg index is NOT_FOUND > > + if (idx < 0) { > > + // The only allowed value should be NOT_FOUND (-1) unless > another change introduces > > + // a different negative index > > + assert (idx == -1); > > + JLI_TraceLauncher("Warning: first app arg index not found, > %d\n", idx); > > + JLI_TraceLauncher("passing arguments as-is.\n"); > > + return NewPlatformStringArray(env, strv, argc); > > + } > > + > > isTool = (idx == 0); > > if (isTool) { idx++; } // skip tool name > > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, > stdargs[idx].arg); > > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -29,6 +29,7 @@ > > * jdk.jlink > > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > > * @run testng BasicTest > > + * @bug 8234076 > > * @summary Basic test of starting an application as a module > > */ > > > > @@ -40,6 +41,8 @@ > > > > import jdk.test.lib.compiler.CompilerUtils; > > import jdk.test.lib.process.ProcessTools; > > +import jdk.test.lib.process.OutputAnalyzer; > > +import jdk.test.lib.Utils; > > > > import org.testng.annotations.BeforeTest; > > import org.testng.annotations.Test; > > @@ -70,6 +73,8 @@ > > // the module main class > > private static final String MAIN_CLASS = "jdk.test.Main"; > > > > + // for Windows specific launcher tests > > + static final boolean IS_WINDOWS = System.getProperty(" > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875809897&sdata=uU7AkmEbqKgfgeONT8Cvkr0YX57x1xNmtLkqq1AMIsg%3D&reserved=0", > "unknown").startsWith("Windows"); > > > > @BeforeTest > > public void compileTestModule() throws Exception { > > @@ -259,4 +264,87 @@ > > assertTrue(exitValue != 0); > > } > > > > + > > + /** > > + * Helper method that creates a ProcessBuilder with command line > arguments > > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > > + */ > > + private ProcessBuilder createProcessWithLauncherDebugging(String... > cmds) { > > + ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > > + > > + return pb; > > + } > > + > > + /** > > + * Test the ability for the Windows launcher to do proper > application argument > > + * detection and expansion, when using the long form module option > and all passed in > > + * command line arguments are prefixed with a dash. > > + * > > + * These tests are not expected to work on *nixes, and are ignored. > > + */ > > + public void testWindowsWithLongFormModuleOption() throws Exception { > > + if (!IS_WINDOWS) { > > + return; > > + } > > + > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --help > > + // We should be able to find the argument --help as an > application argument > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help"); > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > <...src/test>/*.java --help > > + // We should be able to see argument expansion happen > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help") > > + .shouldContain("module-info.java"); > > + } > > + > > + > > + /** > > + * Test that --module= is terminating for VM argument processing > just like --module > > + */ > > + public void testLongFormModuleOptionTermination() throws Exception { > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --module-path=mods --module=$TESTMODULE/$MAINCLASS > > + // The first --module= will terminate the VM arguments > processing. The second pair of module-path and module will be > > + // deemed as application arguments > > + OutputAnalyzer output = ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--module-path=" + dir, > > + "--module=" + mid)) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("argv[ 0] = '--module-path=" + dir) > > + .shouldContain("argv[ 1] = '--module=" + mid); > > + > > + if (IS_WINDOWS) { > > + output.shouldContain("F--module-path=" + > dir).shouldContain("F--module=" + mid); > > + } > > + > > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > > + // This command line will not work as --module= is terminating > and the module will be not found > > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > > + assertTrue(exitValue != 0); > > + } > > } > > > > > > -----Original Message----- > > From: Henry Jen > > Sent: December 6, 2019 12:03 AM > > To: Nikola Grcevski > > Cc: Kumar Srinivasan ; Alan Bateman Alan.Bateman at oracle.com>; mailto:core-libs-dev at openjdk.java.net > > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > > > > >> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > >> > >> Hello all again! > >> > >> Based on the suggestion by Kumar I made the following small patch to > checkArg src/java.base/share/native/libjli/args.c: > >> > >> --- a/src/java.base/share/native/libjli/args.c > >> +++ b/src/java.base/share/native/libjli/args.c > >> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { > >> } > >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > >> stopExpansion = JNI_TRUE; > >> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { > > > > I would suggest use JLI_StrCCmp as in java.c. I think combine this fix > with origin crash prevention for -1 is a safe approach and most compatible > to current behavior. > > > > BTW, we need the patch to be hosted on > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875819891&sdata=tijtj%2BHkXylb4Qa3liw8EetRWX8bQlsrYD%2FkAgwnrGE%3D&reserved=0 > or you can attach the patch to the review thread if you are not yet an > author. > > > > Cheers, > > Henry > > > > > >> + idx = argsCount; > >> } > >> } else { > >> if (!expectingNoDashArg) { > >> > >> The change is in common code and simply checks for the usage of > --module= and deems the next argument as the start of the application > arguments. I can confirm that using -m instead of --module doesn't allow > for the = separator to be used, so we only need to check for --module= if > this is a desired change. > >> > >> I tested with various combinations on the command line and I couldn't > find a set of arguments ordering that breaks the terminating quality of > --module. > >> > >> I also performed series of tests to try to break the argument expansion > on Windows with this change, but it worked in all instances. The testcase > is working correctly with this change, as well as the javac launcher > command as proposed by Kumar (java --module-path=mods > --module=jdk.compiler/com.sun.tools.javac.Main *.java). > >> > >> I ran all the launcher tests on both Windows and Linux and all tests > pass. > >> > >> Please let me know if this is a preferred approach to address this bug > or if you think there's a potential problem with the change. If this is an > acceptable fix I can create new webrev with set of tests for the various > edge cases I tried, and new launcher specific tests that ensure argument > expansion is performed on Windows with this module usage. > >> > >> Thank you, > >> Nikola > >> > >> -----Original Message----- > >> From: Henry Jen > >> Sent: December 4, 2019 8:26 PM > >> To: Kumar Srinivasan ; Alan Bateman > >> ; Nikola Grcevski > >> > >> Cc: mailto:core-libs-dev at openjdk.java.net > >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >> > >>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan ksrinifmt at gmail.com> wrote: > >>> > >>> Hi Nikola, > >>> > >>> It looks ok to me, I will leave it to Henry and Alan to bless this. > >>> > >>> IMHO: I think we should fix it correctly now than later, I don't > >>> think it is all that difficult AFAICT all the launcher has to do is > >>> identify "--module==", then the next argument is the first index. > >>> > >> > >> I don?t disagree, if we can decide whether ?module= is allowed. Based > on my understanding and the document for java[1], the ?module= is not > necessarily correct. > >> > >> If we decided to accept it, the fix would be make sure the index set > correctly as Kumar suggested, and the fix can be relatively simple. > >> > >> FWIW, it?s still possible the index is NOT_FOUND if there is no main > class specified, but that should never cause crash as if no main class is > found, the launcher should either execute other terminal argument or > display help. > >> > >> I agree the fix is not complete as it only make sure no crash can > happen. It doesn?t actually make ?module= illegal and show help in case of > that. At this point, there is a discrepancy in launcher code regard ?module > usage, and we need to fix that. > >> > >> I?ll let Alan to comment about the ?module option usage. > >> > >> The webrev looks good to me, although I would like to see the test be > more close to other arguments processing test, but since this can only be > reproduced with ?module= usage, I assume this is not bad. > >> > >> [1] > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > >> . > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875819891&sdata=tYr7X%2BWKsRBDhE4kk8ES09i8kU3AXUbvfjON%2B3pi3rQ%3D&reserved=0%2Fen%2Fjava%2Fjavase%2F13%2Fdocs%2Fspecs%2Fman%2Fjava.html > >> &data=02%7C01%7CNikola.Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875829886&sdata=3GAF3YmLHzB0dGE%2FrBgKZb6I%2FfioqRqg1quz5zEI%2F%2Fs%3D&reserved=0%7C37e38c582bac4687 > >> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 > >> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY > >> %3D&reserved=0 > >> > >>> Kumar > >>> > >>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > >>> Hi Henry and Kumar, > >>> > >>> Thanks again for your comments! I have updated the test to be part of > test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve > the same amount of testing. I added a new test method inside BasicTest.java > and tested on both Windows and Linux. > >>> > >>> Please find my updated webrev here for your review: > >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc > >>> e > >>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875829886&sdata=bO71uLpbZgNDfN6uuYmhGXWBBUbc8jVpXthnzMb%2B3fw%3D&reserved=0%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Gr > >>> c > >>> evski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875839882&sdata=B9ioFEVQ9x7taxjCeY5KHvHxOhmmG0Ohapg%2BEPsynfc%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86 > >>> f > >>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ > >>> % > >>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>> > >>> Cheers, > >>> > >>> Nikola > >>> > >>> -----Original Message----- > >>> From: Henry Jen > >>> Sent: December 3, 2019 11:39 AM > >>> To: Kumar Srinivasan > >>> Cc: Nikola Grcevski ; Alan > Bateman > >>> ; mailto: > core-libs-dev at openjdk.java.net > >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >>> > >>> Kumar, > >>> > >>> Great to have you look at this, you are correct, this patch doesn?t > address the wildcard expansion issue, but only to address the potential > crash if a main class is not specified as Nikola pointed out. > >>> > >>> We definitely need a follow up to fix wildcard expansion. The pointer > to simplify the test is helpful, it would make the test more obvious. > >>> > >>> Cheers, > >>> Henry > >>> > >>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan ksrinifmt at gmail.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Sorry for chiming in late in the review process, for what it's > worth.... > >>>> > >>>> 1. It is not at all clear to me if this solution is correct, yes it > averts the problem of not finding the main-class > >>>> and subsequent crash, but it does not address wildcard arguments > expansion. > >>>> > >>>> What if we have > >>>> % java --module-path=mods > --module=jdk.compiler/com.sun.tools.javac.Main *.java > >>>> Where jdk.compiler is a java compiler implementation (javac). > >>>> The user would expect the above compiler module to build all the > .java files in that directory, > >>>> and this fix will not address that. > >>>> > >>>> Some background: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > >>>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875839882&sdata=N3%2F56AMtNgfBH%2FNYNJj8%2Fviw07WmugWhKi1Pwz11ecw%3D&reserved=0%2Fbrowse%2FJDK-7146424&data=02%7C01%7CNikola > >>>> .Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875849875&sdata=b2IlaMBcOlTUjNI3gG6Kxkoza8w0N4tkeFX6dUrRQl0%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f98 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b > >>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 > >>>> Please see all the related bugs in the above JIRA issue. > >>>> > >>>> Paragraph #6 in this interview surmises the wild card behavior on > Windows: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. > >>>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875849875&sdata=MU2LIp0wJy1%2FW1B3648xH%2BpM%2F%2F3OvpYg6Bg81sREAbk%3D&reserved=0%2F~hos%2Fmike%2Ftranscripts%2Fkernighan.htm&data=0 > >>>> 2%7C01%7CNikola.Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875859867&sdata=tQ%2FiuszakwoOxL9dQT1NAmXCDj0qOv%2BpRmwCBTbyHaA%3D&reserved=0%7C6158f8460dcd4c39518708d77 > >>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 > >>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& > >>>> ;reserved=0 > >>>> > >>>> 2. Though the arguments related tests are in Aaarghs.java the modules > related tests for the launcher are at: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg > >>>> . > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875859867&sdata=4MYjDinmHFMeWZ3LxDoJMbsw8Fiu%2FEX6YVQnPNbn7Ag%3D&reserved=0%2Fjdk%2Fjdk13%2Ffile%2F0368f3a073a9%2Ftest%2Fjdk%2 > >>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs > >>>> ki% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875869862&sdata=yMmLqFu99DcB7a6GqXiOZlolyxDKD0zfNliRsz1NuuE%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f988bf86f1 > >>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE > >>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 > >>>> Using the modules test framework may make the test simpler. > >>>> > >>>> Kumar Srinivasan > >>>> > >>>> > >>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > >>>> Hi Alan and Henry, > >>>> > >>>> Thank you for reviewing my email! Henry's observation matches mine, > the shared common code for all platforms in checkArg > (src/java.base/share/native/libjli/args.c) can potentially leave the > firstAppArgIndex static set to -1, if all passed command line arguments are > prefixed with a dash. Later on the arguments are validated, however we > might crash before then on Windows because of the negative index access. In > this case, the customer command was valid (modules usage) and the program > runs successfully. > >>>> > >>>> I created a webrev here for the change, including a new test in > Arrrghs.java: > >>>> > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr > >>>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875869862&sdata=F2CPkGKG7IdCZUtCtX36eWNoCizZrOSwK1sHyQ1DqQQ%3D&reserved=0%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola > >>>> .Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Ca7c43b46284843df631308d77b8ea31a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637113724875869862&sdata=yMmLqFu99DcB7a6GqXiOZlolyxDKD0zfNliRsz1NuuE%3D&reserved=0%7C6158f8460dcd4c39518708d7792228c5%7C72f98 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e > >>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>>> > >>>> I copied the test validation and assertion style of other code inside > the test class. > >>>> > >>>> Please let me know if you have any comments or suggestions. > >>>> > >>>> Thanks again! > >>>> > >>>> -----Original Message----- > >>>> From: Henry Jen > >>>> Sent: December 2, 2019 12:26 PM > >>>> To: Alan Bateman > >>>> Cc: Nikola Grcevski ; > >>>> mailto:core-libs-dev at openjdk.java.net > >>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > >>>> > >>>> The fix looks reasonable to me, basically, if the command argument > format is not legal, it?s possible we won?t find the main class when doing > argument file expansion, and the index is -1 which could cause crash on > Windows platform for the wildcard processing. > >>>> > >>>> I think we should add a test case for this, probably in > test/jdk/tools/launcher/Arrrghs.java. > >>>> > >>>> As I understand it, the argument validation is done in a later stage > after calling JLI_Launch. > >>>> > >>>> Cheers, > >>>> Henry > >>>> > >>>> > >>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman Alan.Bateman at oracle.com> wrote: > >>>>> > >>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: > >>>>>> : > >>>>>> > >>>>>> Please let me know if this approach is acceptable for the current > bug report and I'll make a webrev and include appropriate launcher tests. I > was thinking the tests should do extra validation on the output from > _JAVA_LAUNCHER_DEBUG on Windows. > >>>>>> > >>>>> I think you're in the right area but I would have expected the arg > index to 0 here. Henry Jen (cc'ed) might have some comments on this. > >>>>> > >>>>> -Alan > From alexander.matveev at oracle.com Wed Dec 11 03:24:48 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 10 Dec 2019 19:24:48 -0800 Subject: RFR: JDK-8234284: [dmg] Change DMG background image to TIFF Message-ID: <2c091e8e-5549-4b64-fd85-1411c170188e@oracle.com> Please review fix [2] for jpackage bug [1]. ?- Changed background image for DMG to TIFF format, which can be used to embed 2x image to support HiDPI displays. Thanks, Alexander [1] https://bugs.openjdk.java.net/browse/JDK-8234284 [2] http://cr.openjdk.java.net/~almatvee/8234284/webrev.00/ From Sergey.Bylokhov at oracle.com Wed Dec 11 09:00:45 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Dec 2019 01:00:45 -0800 Subject: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS Message-ID: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 This change adds the "screen capture on the test failure" feature on macOS and Linux. - On Linux, it is implemented by the "gnome-screenshot" command(in case of multiscreen+xinerama the whole big screen will be saved to the "screen.png" file). - On macOS it is implemented by the "screencapture" command, note that I have used 1 file per screen, if the number of screens less than 5, other files will be ignored. -- Best regards, Sergey. From fujie at loongson.cn Wed Dec 11 09:56:44 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 11 Dec 2019 17:56:44 +0800 Subject: RFR: 8235625: [TESTBUG] tools/jpackage/share/JavaOptionsEqualsTest.java fails with debug VMs In-Reply-To: References: Message-ID: Hi Alexey, Thanks for your review [1]. May I get one more review from a reviewer? Thanks a lot. Best regards, Jie [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/063967.html On 2019/12/10 ??10:26, Jie Fu wrote: > Hi all, > > May I get reviews for the small fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235625 > Webrev: http://cr.openjdk.java.net/~jiefu/8235625/webrev.00/ > > Thanks a lot. > Best regards, > Jie > From christoph.langer at sap.com Wed Dec 11 10:02:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Dec 2019 10:02:44 +0000 Subject: RFR (S): 8235750: [jpackage] Cleanup imports in WinMsiBundler.java Message-ID: Hi, please review this import statements cleanup for src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/WinMsiBundler.java. I stumbled over an issue when I imported the jpackage project into Eclipse. Due to importing both, static jdk.incubator.jpackage.internal.StandardBundlerParam.* and static jdk.incubator.jpackage.internal.WindowsBundlerParam.*, Eclipse thinks some symbols are ambiguous. I would also remove an unused list object. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235750.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8235750 Thanks Christoph From OGATAK at jp.ibm.com Wed Dec 11 11:17:33 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 11 Dec 2019 20:17:33 +0900 Subject: RFR: JDK-8229871: Improve performance of Method.copy() and leafCopy() In-Reply-To: References: <80be43d7-826b-355a-6b8d-bf75ce3630e7@oracle.com> <14b28640-cd16-c672-c4bb-754116e882da@gmail.com> Message-ID: Hi, I re-evaluated the performance of Peter's improvement [1] using the same base version. Sorry for taking long time, but it took time to verify if results are reliable. The Peter's version reduced elapsed time of a micro bench [2] that repeatedly calls Class.getMethods() by 30.3%. However, this change did not affect so much on the scores of macro benchmarks, like SPECjbb2015 and DaCapo. For SPECjbb2015, critical jOPS improved by 0.4%, but max jOPS degraded by 0.1%. (75 percentile of 20 runs) The magnitude of the improvement/degradation was very small, in any way. For DaCapo, performance differences range from +2.9% (tradebeans) to -2.6% (lusearch) in 60 percentile of 50 runs. Since DaCapo scores tends to fluctuate from run to run, I think this result is in a range of run-to-run variation. May I ask to push this change to the repository? I guess these programs don't use extensively use reflective method invocation, but it does improve performance of Method.copy(). Or should I need to find a macro benchmark that extensively use reflective method invocation? [1] http://cr.openjdk.java.net/~plevart/jdk-dev/ 8229871_Method.methodAccessor/webrev.01/ [2] http://cr.openjdk.java.net/~ogatak/8229871/GetMethodsBench.java Regards, Ogata Kazunori Ogata/Japan/IBM wrote on 2019/10/31 01:46:45: > From: Kazunori Ogata/Japan/IBM > To: Peter Levart > Cc: core-libs-dev at openjdk.java.net > Date: 2019/10/31 01:46 > Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() and leafCopy() > > Hi Peter, > > Thank you very much for your updated fix and sorry to be late to reply. > > I found that the performance data I posted earlier was wrong because I > fetched the latest code before building the JVM with your fix, while I > still used older JVM as the base version. The new build picked up > JDK-8230020 [1], which reverts JDK-8225670 [2] that degraded performance > of SPECjbb2015. Unfortunately, the base version only included [2]... > > Your new version [3] apparently looks better. I'll update my base JVM and > measure the performance of [3]. > > Regards, > Ogata > > [1] https://bugs.openjdk.java.net/browse/JDK-8230020 > [2] https://bugs.openjdk.java.net/browse/JDK-8225670 > [3] http://cr.openjdk.java.net/~plevart/jdk-dev/ > 8229871_Method.methodAccessor/webrev.01/ > > Peter Levart wrote on 2019/10/24 06:09:54: > > > From: Peter Levart > > To: Kazunori Ogata > > Cc: core-libs-dev at openjdk.java.net > > Date: 2019/10/24 06:10 > > Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of > > Method.copy() and leafCopy() > > > > Hi Ogata, > > > > I finally managed to find some time to experiment with this. To measure > > invocation performance I created the following JMH benchmark [1]. It > > measures the invocation speed of instance and static methods using either: > > - direct invocation (bytecodes) > > - invocation via constant Method instance > > - invocation via variable Method instance > > > > Here are the results using unmodified JDK 14 build (baseline): > > > > Benchmark Mode Cnt Score > > Error Units > > ReflectionSpeedBenchmark.instanceDirect avgt 10 2.272 ? > > 0.002 ns/op > > ReflectionSpeedBenchmark.instanceReflectiveConst avgt 10 16.609 ? > > 0.162 ns/op > > ReflectionSpeedBenchmark.instanceReflectiveVar avgt 10 16.715 ? > > 0.163 ns/op > > ReflectionSpeedBenchmark.staticDirect avgt 10 2.275 ? > > 0.012 ns/op > > ReflectionSpeedBenchmark.staticReflectiveConst avgt 10 16.351 ? > > 0.330 ns/op > > ReflectionSpeedBenchmark.staticReflectiveVar avgt 10 16.259 ? > > 0.196 ns/op > > > > Your webrev.04 [2] has a slight (~ 6%) improvement for constant Method > > instance (i.e. assigned to static final field): > > > > Benchmark Mode Cnt Score > > Error Units > > ReflectionSpeedBenchmark.instanceDirect avgt 10 2.273 ? > > 0.003 ns/op > > ReflectionSpeedBenchmark.instanceReflectiveConst avgt 10 15.628 ? > > 0.115 ns/op > > ReflectionSpeedBenchmark.instanceReflectiveVar avgt 10 16.706 ? > > 0.144 ns/op > > ReflectionSpeedBenchmark.staticDirect avgt 10 2.277 ? > > 0.008 ns/op > > ReflectionSpeedBenchmark.staticReflectiveConst avgt 10 15.285 ? > > 0.109 ns/op > > ReflectionSpeedBenchmark.staticReflectiveVar avgt 10 16.600 ? > > 0.222 ns/op > > > > Now I have prepared another variant [3] that replaces > > DelegatingMethodAccessorImpl with SlowFastMethodAccessorImpl and > > produces the following result: > > > > Benchmark Mode Cnt Score > > Error Units > > ReflectionSpeedBenchmark.instanceDirect avgt 10 2.371 ? > > 0.027 ns/op > > ReflectionSpeedBenchmark.instanceReflectiveConst avgt 10 7.161 ? > > 0.066 ns/op > > ReflectionSpeedBenchmark.instanceReflectiveVar avgt 10 16.501 ? > > 0.154 ns/op > > ReflectionSpeedBenchmark.staticDirect avgt 10 2.373 ? > > 0.017 ns/op > > ReflectionSpeedBenchmark.staticReflectiveConst avgt 10 6.971 ? > > 0.103 ns/op > > ReflectionSpeedBenchmark.staticReflectiveVar avgt 10 15.893 ? > > 0.110 ns/op > > > > This is more than twice as fast as the baseline for constant Method > > instances while not degrading performance for variable Method instances. > > > > > > [1] http://cr.openjdk.java.net/~plevart/jdk-dev/ > 8229871_Method.methodAccessor/ReflectionSpeedBenchmark.java > > [2] http://cr.openjdk.java.net/~ogatak/8229871/webrev.04/ > > [3] http://cr.openjdk.java.net/~plevart/jdk-dev/ > 8229871_Method.methodAccessor/webrev.01/ > > > > > > Could you spin this one [3] on your SPECjbb2015 benchmark to see if it > > still performs favorably? > > > > > > Regards, Peter > > > > On 10/11/19 12:17 PM, Kazunori Ogata wrote: > > > Hi Peter, > > > > > > Thank you for the comment and suggestion of the fix. > > > > > > I tried to pick up your change w.r.t. methodAccessor: > > > https://urldefense.proofpoint.com/v2/url? > > u=https-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev. > > 04_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=-xRlUE3M_VEQ_pLDsVNMsIneJ7tKig8ElUy8vmAQoUM&e= > > > > > > > > > Regarding micro benchmark, my original motivation of this change is to > > > improve performance of Class.getMethods(), which calls Method.copy() for > > > each declared method to create a copy of Method[]. > > > > > > I measured my simple microbench: > > > https://urldefense.proofpoint.com/v2/url? > > > u=https-3A__cr.openjdk.java.net_-7Eogatak_8229871_GetMethodsBench.java&d=DwIDaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=Phaibyh6EWjUKos14T7aQfBzSGcH4stxqnhQFkEZsp4&e= > > > > > > Base code: Elapsed time = 4808 ms > > > webrev.01: Elapsed time = 4536 ms (+ 6%) > > > webrev.02: Elapsed time = 2331 ms (+106%) > > > webrev.04: Elapsed time = 3746 ms (+ 28%) > > > > > > I'll measure larger benchmark and try to think if we can reduce the > > > overhead of memory barrier. > > > > > > > > > Regards, > > > Ogata > > > > > > > > > Peter Levart wrote on 2019/10/09 16:44:13: > > > > > >> From: Peter Levart > > >> To: Kazunori Ogata , core-libs-dev at openjdk.java.net > > >> Date: 2019/10/09 16:44 > > >> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Improve performance of > > >> Method.copy() and leafCopy() > > >> > > >> Hi Ogata, > > >> > > >> May I just add that volatile field ensured that MethodAccessor object > > > was > > >> correctly published. DelegatingMethodAccessortImpl is not safe to be > > >> published via data race because it contains plain `delegate` field > > >> initialized in the constructor. In addition, the object that is first > > >> assigned to that field is NativeMethodAccessorImpl which has plain > > >> `parent` field. You can get NPE when invoking the Method.invoke from > > >> multuiple threads if Method.methodAccessor is not volatile. > > >> > > >> In addition, It would be nice to have two microbenchmarks exercising: > > >> a) Method copy performance > > >> b) Method invocation performance > > >> > > >> Regards, Peter > > >> > > >> P.S. When exploring the possibility of an alternative MethodAccessor > > >> implementation (using MethodHandle(s)): > > >> > > >> > > > https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk-2Ddev_6824466-5FMHReflectionAccessors_&d=DwIDaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=LKR_2z3fvXB0IYUryijzgd-jH6wG3Mr2UmiOMKviFGU&e= > > >> webrev.00.2/ > > >> > > >> ...I found out that it was possible to re-arrange the play between > > >> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and generated > > >> MethodAccessor in such a way that the DelegatingMethodAccessortImpl > > >> becomes safe to be published via data race. This allowed for > > >> Method.methodAccessor field to become plain field. In addition this > > > field > > >> can be made @Stable which further optimizes access to MethodAccessor > > >> instance when Method instance can be constant-folded, which showed in > > >> special microbenchmarks. > > >> > > >> So perhaps you could try to use above implementation (just changes to > > >> DelegatingMethodAccessorImpl, NativeMethodAccessorImpl and part of > > >> Reflection factory but without MH* stuff) and measure it against current > > >> and your implementation (which as shown above has a data-race flaw). > > >> On 10/8/19 12:23 PM, Kazunori Ogata wrote: > > >> Hi all, > > >> > > >> I posted two changes and got reply that performance evaluation is > > > needed. > > >> I found that making Method.methodAccessor non-volatile (webrev.02) is > > >> better than avoid copying methodAccessor value when it is null > > >> (webrev.01), as shown below. > > >> > > >> So I'd like to ask review of the former change. I updated weberv using > > >> the latest code base (though there was no difference from webrev.02): > > >> > > >> Webrev: https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev. > > 03_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=xm_iw74CmqAabV2cctZfI75t28_DCXP9VFVjHcnQXp4&e= > > >> > > >> Bug: https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8229871&d=DwIDaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=bzRkFq845mYFriH7TirkzA4JzG0m47x09kebpHfMgTw&e= > > >> > > >> > > >> For this performance evaluation, I calculated 75 percentile of 9 runs of > > >> SPECjbb2015 and 60 percentile of 50 runs of DaCapo to omit outliers. I > > >> bound a JVM to a NUMA node and set the number of GC threads to the same > > > as > > >> the number of physical cores. These tuning reduced run-to-run > > > fluctuation > > >> on POWER (as usual...). > > >> > > >> SPECjbb2015: > > >> webrev.02: critical jOPS +1.6%, max jOPS +0.2% > > >> webrev.01: critical jOPS +0.4%, max jOPS +0.2% > > >> > > >> > > >> For DaCapo, some benchmark still improved performance and some degraded, > > >> but the geometric mean of all benchmarks were small: > > >> weberv.02: +0.3% > > >> weberv.01: +0.2% > > >> > > >> The difference of improvement/degradation between the two changes in > > > each > > >> benchmark were less than 0.8%. > > >> > > >> The range of improvement/degradation in each benchmark were: > > >> webrev.02: between +2.4% and -1.0% > > >> webrev.01: between +1.6% and -1.8% > > >> > > >> > > >> So I think webrev.02 (i.e., making methodAccessor non-volatile) is a > > > good > > >> change, since it improved SPECjbb critical jOPS by 1.6%. > > >> > > >> > > >> Regards, > > >> Ogata > > >> > > >> > > >> Kazunori Ogata/Japan/IBM wrote on 2019/08/27 15:41:39: > > >> > > >> From: Kazunori Ogata/Japan/IBM > > >> To: Mandy Chung > > >> Cc: core-libs-dev at openjdk.java.net > > >> Date: 2019/08/27 15:41 > > >> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() and > > >> leafCopy() > > >> Hi Mandy, > > >> > > >> Let me post interim results of the performance evaluation, though I'm > > >> still measuring benchmarks and analyzing them. > > >> > > >> For SPECjbb2015, skipping storing null (webrev.01) was faster than > > >> making > > >> methodAccessor non-volatile (webrev.02). The improvements of each of > > >> the > > >> patches in maxJOPS/criticalJOPS were 2.6%/3.9% and 1.8%/2.9%, > > >> respectively. This is only an average of six runs. > > >> > > >> For DaCapo, the results were mixed. In some benchmark, both of the > > >> changes degraded performance. In some others, webrev.01 was better, but > > > > > >> weberv.02 was better in some others. > > >> > > >> I'll continue evaluation, but it is helpful if you could give me some > > >> hints on why webrev.01 can be better than webrev.02 in SPECjbb2015. > > >> > > >> Regards, > > >> Ogata > > >> > > >> Kazunori Ogata/Japan/IBM wrote on 2019/08/21 20:02:41: > > >> > > >> From: Kazunori Ogata/Japan/IBM > > >> To: Mandy Chung > > >> Cc: core-libs-dev at openjdk.java.net > > >> Date: 2019/08/21 20:02 > > >> Subject: Re: RFR: JDK-8229871: Improve performance of Method.copy() > > >> and leafCopy() > > >> Hi Mandy, > > >> > > >> Thank you for reviewing the webrev. I updated it to add a space after > > >> "if" and also put four spaces for indentation (it was three). > > >> > > >> https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev. > > 01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=qLT9k5xsheWZfU7ocimSbEMANQDnelEUqqiR5X-Zio4&e= > > >> > > >> Thank you so much for checking the history of fieldAccessor. I was > > >> surprised that fieldAccessor was made non-volatile in JDK5, but > > >> methodAccessor was left as volatile for 15 years after that... > > >> > > >> I agree we need benchmark data. My simple micro benchmark that > > >> repeats > > >> invoking Class.getMethods() improved performance by 70% when it made > > >> non- > > >> volatile (as shown in the following webrev). I'll try to run larger > > >> benchmarks, such as SPECjbb2015, to see real impact. > > >> > > >> https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev. > > 02_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=aq50ONJW0fK7CBk1upVkJekAbRrDsZygPkWrjL_sM4I&e= > > >> > > >> Regards, > > >> Ogata > > >> > > >> Mandy Chung wrote on 2019/08/21 01:21:42: > > >> > > >> From: Mandy Chung > > >> To: Kazunori Ogata > > >> Cc: core-libs-dev at openjdk.java.net > > >> Date: 2019/08/21 01:21 > > >> Subject: [EXTERNAL] Re: RFR: JDK-8229871: Imporve performance of > > >> Method.copy() and leafCopy() > > >> > > >> Hi Ogata, > > >> > > >> The patch looks okay. Nit: please add a space between if and (. > > >> > > >> About volatile methodAccessor field, I checked the history. Both > > >> fieldAccessor and methodAccessor were started as volatile and the > > >> fieldAccessor declaration was updated due to JDK-5044412. As you > > >> observe, I think the methodAccessor field could be made > > >> non-volatile. > > >> OTOH that might impact when it's inflated to spin bytecode for this > > >> method invocation. I don't know how importance to keep its volatile > > >> vs > > >> non-volatile in practice without doing benchmarking/real application > > >> testing. > > >> > > >> Mandy > > >> > > >> On 8/19/19 2:51 AM, Kazunori Ogata wrote: > > >> Hi, > > >> > > >> May I have review for "JDK-8229871: Imporve performance of > > >> Method.copy() > > >> and leafCopy()"? > > >> > > >> Method.copy() and leafCopy() creates a copy of a Method object > > >> with > > >> sharing MethodAccessor object. Since the methodAccessor field is a > > >> volatile variable, copying this field needs memory fence to ensure > > >> the > > >> field is visible to all threads on the weak memory platforms such > > >> as POWER > > >> and ARM. > > >> > > >> When the methodAccessor of the root object is null (i.e., not > > >> initialized > > >> yet), we do not need to copy the null value because this field of > > >> the > > >> copied object has been initialized to null in the constructor. We > > >> can > > >> reduce overhead of the memory fence only when the root's > > >> methodAccessor is > > >> non-null. This change improved performance by 5.8% using a micro > > >> benchmark > > >> that repeatedly invokes Class.getMethods(). > > >> > > >> Bug: https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8229871&d=DwIDaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=bzRkFq845mYFriH7TirkzA4JzG0m47x09kebpHfMgTw&e= > > >> > > >> Webrev: https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eogatak_8229871_webrev. > > 00_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=kWMN3Fiqhqdlc9lMvgHDA1VViBz9r2Eb- > > K9uCUrU_Yw&s=lGQy-Xy0ofp8d551jCUZdwmZ_OD4sXsMaoRKWzwer4o&e= > > >> > > >> > > >> By the way, why Method.methodAccessor is volatile, while > > >> Field.fieldAccessor and Field.overrideFieldAccessor are not > > >> volatile? I > > >> know the use of volatile reduces probability of creating > > >> duplicated method > > >> accessor, but the chance still exists. I couldn't find the > > >> difference > > >> between Method and Field classes to make Method.methodAccessor > > >> volatile. > > >> If we can make it non-volatile, it is more preferable than a quick > > >> hack > > >> above. > > >> > > >> > > >> Regards, > > >> Ogata > > >> > > >> > > >> > > > > > > > From daniel.fuchs at oracle.com Wed Dec 11 12:41:29 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 11 Dec 2019 12:41:29 +0000 Subject: Multi Part publisher for java.net.http.HttpClient In-Reply-To: References: Message-ID: Hi Behrang, net-dev is a better list to discuss networking/http related topics. On 03/12/2019 12:22, Behrang Saeedzadeh wrote:> Hi all, > > Are there any plans to implement a "multipart/form-data" BodyPublisher in > Java 14 or later? There are no plans - especially not for 14 since we will be in ramp down 1 this week, but I have logged JDK-8235761 [1] to do some investigation. best regards, -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8235761 From adam.farley at uk.ibm.com Wed Dec 11 13:40:55 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 11 Dec 2019 13:40:55 +0000 Subject: [8u] RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <03766CF0-CA07-47A5-AEBD-A0E451FAD87B@amazon.com> References: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com> <03766CF0-CA07-47A5-AEBD-A0E451FAD87B@amazon.com> Message-ID: Thanks Paul. :) Best Regards Adam Farley IBM Runtimes "Hohensee, Paul" wrote on 10/12/2019 20:16:31: > From: "Hohensee, Paul" > To: Severin Gehwolf , Adam Farley8 > , Java Core Libs > Cc: jdk8u-dev > Date: 10/12/2019 20:16 > Subject: [EXTERNAL] Re: [8u] RFR: JDK-8227715: GPLv2 files missing > Classpath Exception > > Lgtm. I'll sponsor it and tag the JBS issue with jdk8u-fix-request. > > Thanks, > Paul > > On 12/9/19, 4:55 AM, "jdk-updates-dev on behalf of Severin Gehwolf" > sgehwolf at redhat.com> wrote: > > Hi Adam, > > This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing > list (jdk8u-dev not jdk-updates-dev; bcc'ed the latter) and fixing the > subject line. > > Thanks, > Severin > > On Thu, 2019-10-03 at 15:53 +0100, Adam Farley8 wrote: > > Hey all, > > > > Four GPLv2 files in 8u seem to be missing the classpath > exception from the > > copyright section. > > > > Requesting reviews and a sponsor. > > > > Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwIGaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=gGc3DrrilmAIAlwaC6- > vFT21V7D84BZe_VZQIf8fkwM&s=qVamtGae0EU0YxWoCT5MRcR6UDNhj24dXGfhRbiTSRI&e= > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwIGaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=gGc3DrrilmAIAlwaC6- > vFT21V7D84BZe_VZQIf8fkwM&s=zIEaw-NL_AdX8VPn2_vZwSK09tAlhYEZOPax8dOuXG8&e= > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > 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 andy.herrick at oracle.com Wed Dec 11 14:22:57 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 09:22:57 -0500 Subject: RFR: 8235625: [TESTBUG] tools/jpackage/share/JavaOptionsEqualsTest.java fails with debug VMs In-Reply-To: References: Message-ID: <8be96b2a-ca80-0ab3-9a87-cb8e57e08f99@oracle.com> yes - looks good /Andy On 12/9/2019 9:26 PM, Jie Fu wrote: > Hi all, > > May I get reviews for the small fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8235625 > Webrev: http://cr.openjdk.java.net/~jiefu/8235625/webrev.00/ > > Thanks a lot. > Best regards, > Jie > From andy.herrick at oracle.com Wed Dec 11 14:25:23 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 09:25:23 -0500 Subject: RFR (S): 8235750: [jpackage] Cleanup imports in WinMsiBundler.java In-Reply-To: References: Message-ID: looks good - thank you. /Andy On 12/11/2019 5:02 AM, Langer, Christoph wrote: > Hi, > > please review this import statements cleanup for src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/WinMsiBundler.java. I stumbled over an issue when I imported the jpackage project into Eclipse. > > Due to importing both, static jdk.incubator.jpackage.internal.StandardBundlerParam.* and static jdk.incubator.jpackage.internal.WindowsBundlerParam.*, Eclipse thinks some symbols are ambiguous. > > I would also remove an unused list object. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235750.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8235750 > > Thanks > Christoph > From andy.herrick at oracle.com Wed Dec 11 14:49:48 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 09:49:48 -0500 Subject: RFR: JDK-8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation Message-ID: <93e61bfc-43f4-b215-b2ce-43b367d6dcd9@oracle.com> Please review simple jpackage fix for issue [1] at [2] [1] https://bugs.openjdk.java.net/browse/JDK-8235767 [2] http://cr.openjdk.java.net/~herrick/8235767/webrev.01/ /Andy From andy.herrick at oracle.com Wed Dec 11 14:54:25 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 09:54:25 -0500 Subject: RFR: JDK-8234284: [dmg] Change DMG background image to TIFF In-Reply-To: <2c091e8e-5549-4b64-fd85-1411c170188e@oracle.com> References: <2c091e8e-5549-4b64-fd85-1411c170188e@oracle.com> Message-ID: Fix looks fine to me. adding build-dev since even this simple a makefile change should be reviewed by build-dev On 12/10/2019 10:24 PM, Alexander Matveev wrote: > Please review fix [2] for jpackage bug [1]. > > ?- Changed background image for DMG to TIFF format, which can be used > to embed 2x image to support HiDPI displays. > > Thanks, > Alexander > > [1] https://bugs.openjdk.java.net/browse/JDK-8234284 > > [2] http://cr.openjdk.java.net/~almatvee/8234284/webrev.00/ From maurizio.cimadamore at oracle.com Wed Dec 11 15:39:51 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 11 Dec 2019 15:39:51 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <523d08f4-5604-3a2d-7245-733a5fdc028b@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> <12784CB4-7357-4F19-B307-1AE8354D40F7@oracle.com> <523d08f4-5604-3a2d-7245-733a5fdc028b@oracle.com> Message-ID: I went ahead and created a new revision: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6/ Delta from latest (v5) here: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6_delta/ No javadoc chnages here. Summary of changes: * addressed Paul feedback on MemoryScope * on further testing, I found two issues on var handle construction from layouts: ?? - PathElement.sequenceElement(long) does not add the sequence element offset to the new path element offset ?? - the layout path machiner does not check that strides are a multiple of alignment - this allow creation of 'bad' var handles which are guaranteed not to work in for all indices - consider this layout: var seq = MemoryLayout.ofSequence(JAVA_SHORT.withBitAlignment(32)); The above layout has an issue: the element requests 32-bit alignent, but the elements are only 16 bits apart. So, for odd access indices, there will be an alignment exception. If you create a VarHandle with combinators, strides are checked against alignment, so it is not possible to obtain a VarHandle for the above layout. But with the Layout API is possible, because the layout path machinery does not enforce same restriction. I've now fixed the code in LayoutPath (most of the changes are due to a rename from 'scale' to 'stride') to take care of this. Bonus point: since offsets must satisfy alignment, and all strides must also satisfy same alignment - it follows that whetever offset can come out of the VH index machinery, it will be aligned. This means that, in the VarHandle code we can just check the base address. In other words, the memory location accessed by the VarHandle will be something like (below N denotes alignment, s1..sn are strides, O1..Om are offsets): address = base + offset where: offset = N * s1 * i1 + N * s2 * i2 ... + N * sn * in + N * O1 + N * O2 + ... N * Om = N * (s1 * i1 + s2 * i2 ... + sn * in + O1 + O2 + ... Om) = N * K So, in order to show that the "address" is aligned, we only have to show that "base" is a multiple of N. This helps a lot, as e.g. when looping through a native array, the base array stays the same, and only the offset part changes, which means C2 will have no troubles hoisting out the alignment check out of the loop. As things appear stable, I do not plan to make any other changes to the implementation/API ahead of integration, unless there's something critical which reviewers think should be fixed. Thanks Maurizio On 11/12/2019 00:13, Maurizio Cimadamore wrote: > > On 10/12/2019 18:45, Paul Sandoz wrote: >> MemoryScope changes look good. >> >> In j.u.concurrent we use ExceptionInInitializerError in the static >> blocks when there is an error looking up the VH, >> >> FWIW close can also fail because it has already been closed but the >> exception message does not distinguish between the two states (active >> or already closed). >> ? Paul. >> > Hi Paul, > > would something like this be satisfactory? > > > diff -r 50ef46599c56 > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java > --- > a/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java > Tue Dec 10 16:28:03 2019 +0000 > +++ > b/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java > Wed Dec 11 00:12:20 2019 +0000 > @@ -48,7 +48,7 @@ > ???????? try { > ???????????? COUNT_HANDLE = > MethodHandles.lookup().findVarHandle(MemoryScope.class, "activeCount", > int.class); > ???????? } catch (Throwable ex) { > -??????????? throw new IllegalStateException(ex); > +??????????? throw new ExceptionInInitializerError(ex); > ???????? } > ???? } > > @@ -107,6 +107,9 @@ > > ???? void close() { > ???????? if (!COUNT_HANDLE.compareAndSet(this, UNACQUIRED, CLOSED)) { > +??????????? //first check if already closed... > +??????????? checkAliveConfined(); > +??????????? //...if not, then we have acquired views that are still > active > ???????????? throw new IllegalStateException("Cannot close a segment > that has active acquired views"); > ???????? } > ???????? if (cleanupAction != null) { > > > > If you need a full webrev please let me know. > > Thanks > Maurizio > From andy.herrick at oracle.com Wed Dec 11 15:42:09 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 10:42:09 -0500 Subject: RFR: JDK-8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation In-Reply-To: <93e61bfc-43f4-b215-b2ce-43b367d6dcd9@oracle.com> References: <93e61bfc-43f4-b215-b2ce-43b367d6dcd9@oracle.com> Message-ID: The revised webrev at [3] is confirmed by the submitter to fix the build. please review /Andy [3] http://cr.openjdk.java.net/~herrick/8235767/webrev.02/ On 12/11/2019 9:49 AM, Andy Herrick wrote: > Please review simple jpackage fix for issue [1] at [2] > > [1] https://bugs.openjdk.java.net/browse/JDK-8235767 > > [2] http://cr.openjdk.java.net/~herrick/8235767/webrev.01/ > > /Andy > From rkennke at redhat.com Wed Dec 11 15:50:17 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 11 Dec 2019 16:50:17 +0100 Subject: RFR: JDK-8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation In-Reply-To: References: <93e61bfc-43f4-b215-b2ce-43b367d6dcd9@oracle.com> Message-ID: <5841970c-de64-b636-330e-306ed30aa922@redhat.com> That fix looks good to me. Thanks! Roman > The revised webrev at [3] is confirmed by the submitter to fix the build. > > please review > > /Andy > > [3] http://cr.openjdk.java.net/~herrick/8235767/webrev.02/ > > On 12/11/2019 9:49 AM, Andy Herrick wrote: >> Please review simple jpackage fix for issue [1] at [2] >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235767 >> >> [2] http://cr.openjdk.java.net/~herrick/8235767/webrev.01/ >> >> /Andy >> > From erik.joelsson at oracle.com Wed Dec 11 15:52:50 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Dec 2019 07:52:50 -0800 Subject: RFR: JDK-8234284: [dmg] Change DMG background image to TIFF In-Reply-To: References: <2c091e8e-5549-4b64-fd85-1411c170188e@oracle.com> Message-ID: <8a8bf510-c161-946d-a896-b2648987926f@oracle.com> Build change looks good. /Erik On 2019-12-11 06:54, Andy Herrick wrote: > Fix looks fine to me. > > adding build-dev since even this simple a makefile change should be > reviewed by build-dev > > On 12/10/2019 10:24 PM, Alexander Matveev wrote: >> Please review fix [2] for jpackage bug [1]. >> >> ?- Changed background image for DMG to TIFF format, which can be used >> to embed 2x image to support HiDPI displays. >> >> Thanks, >> Alexander >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8234284 >> >> [2] http://cr.openjdk.java.net/~almatvee/8234284/webrev.00/ From aeubanks at google.com Wed Dec 11 16:06:41 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 11 Dec 2019 08:06:41 -0800 Subject: RFR: 8235730: Incorrect javadoc in MatchKind Message-ID: Hi, could I get a review for a trivial and tiny doc fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8235730 Webrev: http://cr.openjdk.java.net/~aeubanks/8235730/webrev.00/ From alexey.semenyuk at oracle.com Wed Dec 11 16:16:43 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Dec 2019 11:16:43 -0500 Subject: RFR: JDK-8234284: [dmg] Change DMG background image to TIFF In-Reply-To: <2c091e8e-5549-4b64-fd85-1411c170188e@oracle.com> References: <2c091e8e-5549-4b64-fd85-1411c170188e@oracle.com> Message-ID: Looks good. - Alexey On 12/10/2019 10:24 PM, Alexander Matveev wrote: > Please review fix [2] for jpackage bug [1]. > > ?- Changed background image for DMG to TIFF format, which can be used > to embed 2x image to support HiDPI displays. > > Thanks, > Alexander > > [1] https://bugs.openjdk.java.net/browse/JDK-8234284 > > [2] http://cr.openjdk.java.net/~almatvee/8234284/webrev.00/ From alexey.semenyuk at oracle.com Wed Dec 11 16:24:03 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Dec 2019 11:24:03 -0500 Subject: RFR (S): 8235750: [jpackage] Cleanup imports in WinMsiBundler.java In-Reply-To: References: Message-ID: <1902afa9-8619-cf4e-b8b5-4429b1960e55@oracle.com> Looks good. - Alexey On 12/11/2019 9:25 AM, Andy Herrick wrote: > looks good - thank you. > > /Andy > > On 12/11/2019 5:02 AM, Langer, Christoph wrote: >> Hi, >> >> please review this import statements cleanup for >> src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/WinMsiBundler.java. >> I stumbled over an issue when I imported the jpackage project into >> Eclipse. >> >> Due to importing both, static >> jdk.incubator.jpackage.internal.StandardBundlerParam.* and static >> jdk.incubator.jpackage.internal.WindowsBundlerParam.*, Eclipse thinks >> some symbols are ambiguous. >> >> I would also remove an unused list object. >> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235750.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235750 >> >> Thanks >> Christoph >> From alexey.semenyuk at oracle.com Wed Dec 11 16:26:30 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Dec 2019 11:26:30 -0500 Subject: RFR: JDK-8235767: Compilation failure caused by JDK-8212780: Packaging Tool Implementation In-Reply-To: References: <93e61bfc-43f4-b215-b2ce-43b367d6dcd9@oracle.com> Message-ID: Looks good. - Alexey On 12/11/2019 10:42 AM, Andy Herrick wrote: > The revised webrev at [3] is confirmed by the submitter to fix the build. > > please review > > /Andy > > [3] http://cr.openjdk.java.net/~herrick/8235767/webrev.02/ > > On 12/11/2019 9:49 AM, Andy Herrick wrote: >> Please review simple jpackage fix for issue [1] at [2] >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235767 >> >> [2] http://cr.openjdk.java.net/~herrick/8235767/webrev.01/ >> >> /Andy >> From pavel.rappo at oracle.com Wed Dec 11 16:28:38 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 11 Dec 2019 16:28:38 +0000 Subject: RFR: 8235730: Incorrect javadoc in MatchKind In-Reply-To: References: Message-ID: <78F949A9-8AAD-4B23-BAF4-7016E5887B1A@oracle.com> Looks good to me. Trivially, update the copyright years before pushing. This is one of those changes that decrease the entropy, but have little visible effects on the outside world. Neither MatchOps nor MatchOps.MatchKind type should be visible in the online API docs. P.S. I'm not a Reviewer. > On 11 Dec 2019, at 16:06, Arthur Eubanks wrote: > > Hi, could I get a review for a trivial and tiny doc fix? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235730 > Webrev: http://cr.openjdk.java.net/~aeubanks/8235730/webrev.00/ From martinrb at google.com Wed Dec 11 16:40:43 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 Dec 2019 08:40:43 -0800 Subject: RFR: 8235730: Incorrect javadoc in MatchKind In-Reply-To: <78F949A9-8AAD-4B23-BAF4-7016E5887B1A@oracle.com> References: <78F949A9-8AAD-4B23-BAF4-7016E5887B1A@oracle.com> Message-ID: Looks good to me. My own policy is to never update Oracle copyright years for changes by a non-Oracle employee. On Wed, Dec 11, 2019 at 8:30 AM Pavel Rappo wrote: > Looks good to me. Trivially, update the copyright years before pushing. > > This is one of those changes that decrease the entropy, but have little > visible effects on the outside world. Neither MatchOps nor > MatchOps.MatchKind type should be visible in the online API docs. > > P.S. I'm not a Reviewer. > > > On 11 Dec 2019, at 16:06, Arthur Eubanks wrote: > > > > Hi, could I get a review for a trivial and tiny doc fix? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235730 > > Webrev: http://cr.openjdk.java.net/~aeubanks/8235730/webrev.00/ > > From spliterator at gmail.com Wed Dec 11 16:41:29 2019 From: spliterator at gmail.com (Stefan Zobel) Date: Wed, 11 Dec 2019 17:41:29 +0100 Subject: RFR: 8235730: Incorrect javadoc in MatchKind In-Reply-To: References: Message-ID: FWIW, I believe this bug is duplicate of https://bugs.openjdk.java.net/browse/JDK-8213238 Regards, Stefan Am Mi., 11. Dez. 2019 um 17:07 Uhr schrieb Arthur Eubanks : > > Hi, could I get a review for a trivial and tiny doc fix? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235730 > Webrev: http://cr.openjdk.java.net/~aeubanks/8235730/webrev.00/ From paul.sandoz at oracle.com Wed Dec 11 16:43:17 2019 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 11 Dec 2019 08:43:17 -0800 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> <12784CB4-7357-4F19-B307-1AE8354D40F7@oracle.com> <523d08f4-5604-3a2d-7245-733a5fdc028b@oracle.com> Message-ID: <6C8BC7CC-6210-4DD3-BBAB-A7F52C1F8A07@oracle.com> Looks very good, Paul. > On Dec 11, 2019, at 7:39 AM, Maurizio Cimadamore wrote: > > I went ahead and created a new revision: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6/ > Delta from latest (v5) here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6_delta/ > No javadoc chnages here. > > Summary of changes: > > * addressed Paul feedback on MemoryScope > * on further testing, I found two issues on var handle construction from layouts: > - PathElement.sequenceElement(long) does not add the sequence element offset to the new path element offset > - the layout path machiner does not check that strides are a multiple of alignment - this allow creation of 'bad' var handles which are guaranteed not to work in for all indices - consider this layout: > > var seq = MemoryLayout.ofSequence(JAVA_SHORT.withBitAlignment(32)); > > The above layout has an issue: the element requests 32-bit alignent, but the elements are only 16 bits apart. So, for odd access indices, there will be an alignment exception. > > If you create a VarHandle with combinators, strides are checked against alignment, so it is not possible to obtain a VarHandle for the above layout. But with the Layout API is possible, because the layout path machinery does not enforce same restriction. > > I've now fixed the code in LayoutPath (most of the changes are due to a rename from 'scale' to 'stride') to take care of this. > > Bonus point: since offsets must satisfy alignment, and all strides must also satisfy same alignment - it follows that whetever offset can come out of the VH index machinery, it will be aligned. This means that, in the VarHandle code we can just check the base address. In other words, the memory location accessed by the VarHandle will be something like (below N denotes alignment, s1..sn are strides, O1..Om are offsets): > > > > address = base + offset > > where: > > offset = N * s1 * i1 + N * s2 * i2 ... + N * sn * in + N * O1 + N * O2 + ... N * Om > = N * (s1 * i1 + s2 * i2 ... + sn * in + O1 + O2 + ... Om) > = N * K > > > > So, in order to show that the "address" is aligned, we only have to show that "base" is a multiple of N. This helps a lot, as e.g. when looping through a native array, the base array stays the same, and only the offset part changes, which means C2 will have no troubles hoisting out the alignment check out of the loop. > > > As things appear stable, I do not plan to make any other changes to the implementation/API ahead of integration, unless there's something critical which reviewers think should be fixed. > > Thanks > Maurizio > > > > > On 11/12/2019 00:13, Maurizio Cimadamore wrote: >> >> On 10/12/2019 18:45, Paul Sandoz wrote: >>> MemoryScope changes look good. >>> >>> In j.u.concurrent we use ExceptionInInitializerError in the static blocks when there is an error looking up the VH, >>> >>> FWIW close can also fail because it has already been closed but the exception message does not distinguish between the two states (active or already closed). >>> Paul. >>> >> Hi Paul, >> >> would something like this be satisfactory? >> >> >> diff -r 50ef46599c56 src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java >> --- a/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java Tue Dec 10 16:28:03 2019 +0000 >> +++ b/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java Wed Dec 11 00:12:20 2019 +0000 >> @@ -48,7 +48,7 @@ >> try { >> COUNT_HANDLE = MethodHandles.lookup().findVarHandle(MemoryScope.class, "activeCount", int.class); >> } catch (Throwable ex) { >> - throw new IllegalStateException(ex); >> + throw new ExceptionInInitializerError(ex); >> } >> } >> >> @@ -107,6 +107,9 @@ >> >> void close() { >> if (!COUNT_HANDLE.compareAndSet(this, UNACQUIRED, CLOSED)) { >> + //first check if already closed... >> + checkAliveConfined(); >> + //...if not, then we have acquired views that are still active >> throw new IllegalStateException("Cannot close a segment that has active acquired views"); >> } >> if (cleanupAction != null) { >> >> >> >> If you need a full webrev please let me know. >> >> Thanks >> Maurizio >> From aeubanks at google.com Wed Dec 11 16:52:07 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 11 Dec 2019 08:52:07 -0800 Subject: RFR: 8235730: Incorrect javadoc in MatchKind In-Reply-To: References: Message-ID: Thanks for the reviews! I hadn't seen that duplicate, thanks for the pointer. On Wed, Dec 11, 2019 at 8:41 AM Stefan Zobel wrote: > FWIW, I believe this bug is duplicate of > https://bugs.openjdk.java.net/browse/JDK-8213238 > > Regards, > Stefan > > Am Mi., 11. Dez. 2019 um 17:07 Uhr schrieb Arthur Eubanks < > aeubanks at google.com>: > > > > Hi, could I get a review for a trivial and tiny doc fix? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235730 > > Webrev: http://cr.openjdk.java.net/~aeubanks/8235730/webrev.00/ > From stuart.marks at oracle.com Wed Dec 11 17:18:15 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 11 Dec 2019 09:18:15 -0800 Subject: RFR: 8235730: Incorrect javadoc in MatchKind In-Reply-To: References: Message-ID: <7c80549e-f18a-2d23-d511-d3beff937b01@oracle.com> Indeed it is, thanks. Resolved. s'marks On 12/11/19 8:41 AM, Stefan Zobel wrote: > FWIW, I believe this bug is duplicate of > https://bugs.openjdk.java.net/browse/JDK-8213238 > > Regards, > Stefan > > Am Mi., 11. Dez. 2019 um 17:07 Uhr schrieb Arthur Eubanks : >> >> Hi, could I get a review for a trivial and tiny doc fix? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8235730 >> Webrev: http://cr.openjdk.java.net/~aeubanks/8235730/webrev.00/ From Nikola.Grcevski at microsoft.com Wed Dec 11 18:04:29 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Wed, 11 Dec 2019 18:04:29 +0000 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> Message-ID: Thank you again for reviewing my code Kumar! I have applied your refactoring suggestions. Using the array approach as you suggested made the test code a lot more tidier. I?m attaching the updated patch after my signature and the external webrev is here for reference: https://grcevski.github.io/JDK-8234076/webrev/ Cheers, Nikola diff -r bd436284147d src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/share/native/libjli/args.c Wed Dec 11 12:09:29 2019 -0500 @@ -130,6 +130,8 @@ } } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { stopExpansion = JNI_TRUE; + } else if (JLI_StrCCmp(arg, "--module=") == 0) { + idx = argsCount; } } else { if (!expectingNoDashArg) { @@ -449,6 +451,7 @@ return JLI_StrCmp(arg, "-jar") == 0 || JLI_StrCmp(arg, "-m") == 0 || JLI_StrCmp(arg, "--module") == 0 || + JLI_StrCCmp(arg, "--module=") == 0 || JLI_StrCmp(arg, "--dry-run") == 0 || JLI_StrCmp(arg, "-h") == 0 || JLI_StrCmp(arg, "-?") == 0 || diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/windows/native/libjli/java_md.c Wed Dec 11 12:09:29 2019 -0500 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include "java.h" @@ -1015,6 +1016,17 @@ // sanity check, match the args we have, to the holy grail idx = JLI_GetAppArgIndex(); + + // First arg index is NOT_FOUND + if (idx < 0) { + // The only allowed value should be NOT_FOUND (-1) unless another change introduces + // a different negative index + assert (idx == -1); + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); + JLI_TraceLauncher("passing arguments as-is.\n"); + return NewPlatformStringArray(env, strv, argc); + } + isTool = (idx == 0); if (isTool) { idx++; } // skip tool name JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Wed Dec 11 12:09:29 2019 -0500 @@ -37,6 +37,8 @@ import java.util.List; import java.util.Map; import java.util.regex.Pattern; +import java.nio.file.Paths; +import java.nio.file.Path; public class ArgsEnvVar extends TestHelper { private static File testJar = null; @@ -153,6 +155,7 @@ List.of("-jar", "test.jar"), List.of("-m", "test/Foo"), List.of("--module", "test/Foo"), + List.of("--module=test/Foo"), List.of("--dry-run"), List.of("-h"), List.of("-?"), @@ -241,6 +244,69 @@ verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); } + + @Test + // That that we can correctly handle the module longform argument option + // when supplied in an argument file + public void modulesInArgsFile() throws IOException { + File cwd = new File("."); + File testModuleDir = new File(cwd, "modules_test"); + + createEchoArgumentsModule(testModuleDir); + + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); + + // test module / main class + String MODULE_OPTION = "--module=test/launcher.Main"; + String TEST_MODULE = "test"; + + // javac -d mods/test src/test/** + TestResult tr = doExec( + javacCmd, + "-d", MODS_DIR.toString(), + "--module-source-path", SRC_DIR.toString(), + "--module", TEST_MODULE); + + if (!tr.isOK()) { + System.out.println("test did not compile"); + throw new RuntimeException("Error: modules test did not compile"); + } + + // verify the terminating ability of --module= through environment variables + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); + tr = doExec(env, javaCmd); + tr.checkNegative(); + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); + if (!tr.testStatus) { + System.out.println(tr); + throw new RuntimeException("test fails"); + } + + // check that specifying --module and --module-path with file works + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); + tr.contains("[--hello]"); + if (!tr.testStatus) { + System.out.println(tr); + throw new RuntimeException("test fails"); + } + + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); + tr.checkNegative(); + if (!tr.testStatus) { + System.out.println(tr); + throw new RuntimeException("test fails"); + } + + // clean-up + argFile.delete(); + argFile1.delete(); + recursiveDelete(testModuleDir); + } + public static void main(String... args) throws Exception { init(); ArgsEnvVar a = new ArgsEnvVar(); diff -r bd436284147d test/jdk/tools/launcher/TestHelper.java --- a/test/jdk/tools/launcher/TestHelper.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/TestHelper.java Wed Dec 11 12:09:29 2019 -0500 @@ -500,6 +500,40 @@ return Locale.getDefault().getLanguage().equals("en"); } + /** + * Helper method to initialize a simple module that just prints the passed in arguments + */ + static void createEchoArgumentsModule(File modulesDir) throws IOException { + if (modulesDir.exists()) { + recursiveDelete(modulesDir); + } + + modulesDir.mkdirs(); + + File srcDir = new File(modulesDir, "src"); + File modsDir = new File(modulesDir, "mods"); + File testDir = new File(srcDir, "test"); + File launcherTestDir = new File(testDir, "launcher"); + srcDir.mkdir(); + modsDir.mkdir(); + testDir.mkdir(); + launcherTestDir.mkdir(); + + String[] moduleInfoCode = { "module test {}" }; + createFile(new File(testDir, "module-info.java"), Arrays.asList(moduleInfoCode)); + + String[] moduleCode = { + "package launcher;", + "import java.util.Arrays;", + "public class Main {", + "public static void main(String[] args) {", + "System.out.println(Arrays.toString(args));", + "}", + "}" + }; + createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(moduleCode)); + } + /* * A class to encapsulate the test results and stuff, with some ease * of use methods to check the test results. diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Wed Dec 11 12:09:29 2019 -0500 @@ -246,6 +246,10 @@ if (!tr.contains("Error: Could not find or load main class AbsentClass")) { throw new RuntimeException("Test Fails"); } + + // Make sure we handle correctly the module long form (--module=) + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); + ensureNoWarnings(tr); } void ensureNoWarnings(TestResult tr) { diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Dec 11 12:09:29 2019 -0500 @@ -29,6 +29,7 @@ * jdk.jlink * @build BasicTest jdk.test.lib.compiler.CompilerUtils * @run testng BasicTest + * @bug 8234076 * @summary Basic test of starting an application as a module */ @@ -40,6 +41,8 @@ import jdk.test.lib.compiler.CompilerUtils; import jdk.test.lib.process.ProcessTools; +import jdk.test.lib.process.OutputAnalyzer; +import jdk.test.lib.Utils; import org.testng.annotations.BeforeTest; import org.testng.annotations.Test; @@ -70,6 +73,8 @@ // the module main class private static final String MAIN_CLASS = "jdk.test.Main"; + // for Windows specific launcher tests + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); @BeforeTest public void compileTestModule() throws Exception { @@ -259,4 +264,87 @@ assertTrue(exitValue != 0); } + + /** + * Helper method that creates a ProcessBuilder with command line arguments + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. + */ + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); + + return pb; + } + + /** + * Test the ability for the Windows launcher to do proper application argument + * detection and expansion, when using the long form module option and all passed in + * command line arguments are prefixed with a dash. + * + * These tests are not expected to work on *nixes, and are ignored. + */ + public void testWindowsWithLongFormModuleOption() throws Exception { + if (!IS_WINDOWS) { + return; + } + + String dir = MODS_DIR.toString(); + String mid = TEST_MODULE + "/" + MAIN_CLASS; + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help + // We should be able to find the argument --help as an application argument + ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + "--help")) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("F--help"); + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help + // We should be able to see argument expansion happen + ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", + "--help")) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("F--help") + .shouldContain("module-info.java"); + } + + + /** + * Test that --module= is terminating for VM argument processing just like --module + */ + public void testLongFormModuleOptionTermination() throws Exception { + String dir = MODS_DIR.toString(); + String mid = TEST_MODULE + "/" + MAIN_CLASS; + + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be + // deemed as application arguments + OutputAnalyzer output = ProcessTools.executeProcess( + createProcessWithLauncherDebugging( + "--module-path=" + dir, + "--module=" + mid, + "--module-path=" + dir, + "--module=" + mid)) + .outputTo(System.out) + .errorTo(System.out) + .shouldContain("argv[ 0] = '--module-path=" + dir) + .shouldContain("argv[ 1] = '--module=" + mid); + + if (IS_WINDOWS) { + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); + } + + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods + // This command line will not work as --module= is terminating and the module will be not found + int exitValue = exec("--module=" + mid, "--module-path" + dir); + assertTrue(exitValue != 0); + } } From: Kumar Srinivasan Sent: December 10, 2019 8:43 PM To: Nikola Grcevski Cc: Henry Jen ; Alan Bateman ; core-libs-dev at openjdk.java.net Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate [Resend; cc'ing the group] Hi Nikola, Generally looks great to me. I would have moved initModulesDir to TestHelper.createSimpleModule(File dir).? TestHelper.java contains a collection of test related utilities needed by the launcher, it will help someone else use it to create a simple module. I would have rewritten this +? ? ? ? ArrayList scratchpad = new ArrayList<>(); +? ? ? ? scratchpad.add("module test {}"); +? ? ? ? createFile(new File(testDir, "module-info.java"), scratchpad); +? ? ? ? scratchpad.clear(); +? ? ? ? scratchpad.add("package launcher;"); +? ? ? ? scratchpad.add("import java.util.Arrays;"); +? ? ? ? scratchpad.add("public class Main {"); +? ? ? ? scratchpad.add("public static void main(String[] args) {"); +? ? ? ? scratchpad.add("System.out.println(Arrays.toString(args));"); +? ? ? ? scratchpad.add("}"); +? ? ? ? scratchpad.add("}"); +? ? ? ? createFile(new File(launcherTestDir, "Main.java"), scratchpad); as follows: String a1[] = {"module test{}"}; createFile(new File(testDir, "module-info.java", Arrays.asList(a1)); String a2[] = { ? ? ?"package launcher;", ? ? ?.... ? ? .... } createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(a2)); This might make the code neater. Besides that, looks very good. Thanks Kumar On Mon, Dec 9, 2019 at 1:58 PM Nikola Grcevski wrote: Hi Henry and Kumar, Thank you again for the review! I have added the fix to isTerminalOpt and used both of your suggestions to make new tests. With native memory tracking enabled, I could actually see a crash on both Linux and Windows without the suggested fix. I tested the changes again on both Linux and Windows, and the new unit tests fail if isTerminalOpt doesn?t check for ?module= as per Henry's suggestion. I'm attaching the new patch (my apologies for the size) at the bottom of this email after my signature. If I haven't covered certain aspects in the new tests please let me know, I'm more than happy to extend them further. I've updated the webrev to reflect the latest patch if it's easier to read: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=XcriPrQ%2B9rypJN6IShAKU2%2Fz5sZE%2BMCWT3gHyVg3Y3s%3D&reserved=0 Thanks again! Nikola diff -r bd436284147d src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c? Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/share/native/libjli/args.c? Mon Dec 09 16:08:54 2019 -0500 @@ -130,6 +130,8 @@ ? ? ? ? ? ? ?} ? ? ? ? ?} else if (JLI_StrCmp(arg, "--disable- at files") == 0) { ? ? ? ? ? ? ?stopExpansion = JNI_TRUE; +? ? ? ? } else if (JLI_StrCCmp(arg, "--module=") == 0) { +? ? ? ? ? ? idx = argsCount; ? ? ? ? ?} ? ? ?} else { ? ? ? ? ?if (!expectingNoDashArg) { @@ -449,6 +451,7 @@ ? ? ?return JLI_StrCmp(arg, "-jar") == 0 || ? ? ? ? ? ? JLI_StrCmp(arg, "-m") == 0 || ? ? ? ? ? ? JLI_StrCmp(arg, "--module") == 0 || +? ? ? ? ? ?JLI_StrCCmp(arg, "--module=") == 0 || ? ? ? ? ? ? JLI_StrCmp(arg, "--dry-run") == 0 || ? ? ? ? ? ? JLI_StrCmp(arg, "-h") == 0 || ? ? ? ? ? ? JLI_StrCmp(arg, "-?") == 0 || diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c --- a/src/java.base/windows/native/libjli/java_md.c? ? ?Wed Nov 20 08:12:14 2019 +0800 +++ b/src/java.base/windows/native/libjli/java_md.c? ? ?Mon Dec 09 16:08:54 2019 -0500 @@ -34,6 +34,7 @@ ?#include ?#include ?#include +#include ?#include ?#include "java.h" @@ -1015,6 +1016,17 @@ ? ? ?// sanity check, match the args we have, to the holy grail ? ? ?idx = JLI_GetAppArgIndex(); + +? ? // First arg index is NOT_FOUND +? ? if (idx < 0) { +? ? ? ? // The only allowed value should be NOT_FOUND (-1) unless another change introduces +? ? ? ? // a different negative index +? ? ? ? assert (idx == -1); +? ? ? ? JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); +? ? ? ? JLI_TraceLauncher("passing arguments as-is.\n"); +? ? ? ? return NewPlatformStringArray(env, strv, argc); +? ? } + ? ? ?isTool = (idx == 0); ? ? ?if (isTool) { idx++; } // skip tool name ? ? ?JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java --- a/test/jdk/tools/launcher/ArgsEnvVar.java? ?Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/ArgsEnvVar.java? ?Mon Dec 09 16:08:54 2019 -0500 @@ -37,6 +37,8 @@ ?import java.util.List; ?import java.util.Map; ?import java.util.regex.Pattern; +import java.nio.file.Paths; +import java.nio.file.Path; ?public class ArgsEnvVar extends TestHelper { ? ? ?private static File testJar = null; @@ -153,6 +155,7 @@ ? ? ? ? ? ? ? ? ?List.of("-jar", "test.jar"), ? ? ? ? ? ? ? ? ?List.of("-m", "test/Foo"), ? ? ? ? ? ? ? ? ?List.of("--module", "test/Foo"), +? ? ? ? ? ? ? ? List.of("--module=test/Foo"), ? ? ? ? ? ? ? ? ?List.of("--dry-run"), ? ? ? ? ? ? ? ? ?List.of("-h"), ? ? ? ? ? ? ? ? ?List.of("-?"), @@ -241,6 +244,101 @@ ? ? ? ? ?verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); ? ? ?} +? ? /** +? ? ?* Helper method to initialize a simple module that just prints the passed in arguments +? ? ?*/ +? ? private void initModulesDir(File modulesDir) throws IOException { +? ? ? ? if (modulesDir.exists()) { +? ? ? ? ? ? recursiveDelete(modulesDir); +? ? ? ? } + +? ? ? ? modulesDir.mkdirs(); + +? ? ? ? File srcDir = new File(modulesDir, "src"); +? ? ? ? File modsDir = new File(modulesDir, "mods"); +? ? ? ? File testDir = new File(srcDir, "test"); +? ? ? ? File launcherTestDir = new File(testDir, "launcher"); +? ? ? ? srcDir.mkdir(); +? ? ? ? modsDir.mkdir(); +? ? ? ? testDir.mkdir(); +? ? ? ? launcherTestDir.mkdir(); + +? ? ? ? ArrayList scratchpad = new ArrayList<>(); +? ? ? ? scratchpad.add("module test {}"); +? ? ? ? createFile(new File(testDir, "module-info.java"), scratchpad); +? ? ? ? scratchpad.clear(); +? ? ? ? scratchpad.add("package launcher;"); +? ? ? ? scratchpad.add("import java.util.Arrays;"); +? ? ? ? scratchpad.add("public class Main {"); +? ? ? ? scratchpad.add("public static void main(String[] args) {"); +? ? ? ? scratchpad.add("System.out.println(Arrays.toString(args));"); +? ? ? ? scratchpad.add("}"); +? ? ? ? scratchpad.add("}"); +? ? ? ? createFile(new File(launcherTestDir, "Main.java"), scratchpad); +? ? } + +? ? @Test +? ? // That that we can correctly handle the module longform argument option +? ? // when supplied in an argument file +? ? public void modulesInArgsFile() throws IOException { +? ? ? ? File cwd = new File("."); +? ? ? ? File testModuleDir = new File(cwd, "modules_test"); + +? ? ? ? initModulesDir(testModuleDir); + +? ? ? ? Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); +? ? ? ? Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); + +? ? ? ? // test module / main class +? ? ? ? String MODULE_OPTION = "--module=test/launcher.Main"; +? ? ? ? String TEST_MODULE = "test"; + +? ? ? ? // javac -d mods/test src/test/** +? ? ? ? TestResult tr = doExec( +? ? ? ? ? ? javacCmd, +? ? ? ? ? ? "-d", MODS_DIR.toString(), +? ? ? ? ? ? "--module-source-path", SRC_DIR.toString(), +? ? ? ? ? ? "--module", TEST_MODULE); + +? ? ? ? if (!tr.isOK()) { +? ? ? ? ? ? System.out.println("test did not compile"); +? ? ? ? ? ? throw new RuntimeException("Error: modules test did not compile"); +? ? ? ? } + +? ? ? ? // verify the terminating ability of --module= through environment variables +? ? ? ? File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); +? ? ? ? env.put(JDK_JAVA_OPTIONS, "@cmdargs"); +? ? ? ? tr = doExec(env, javaCmd); +? ? ? ? tr.checkNegative(); +? ? ? ? tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); +? ? ? ? if (!tr.testStatus) { +? ? ? ? ? ? System.out.println(tr); +? ? ? ? ? ? throw new RuntimeException("test fails"); +? ? ? ? } + +? ? ? ? // check that specifying --module and --module-path with file works +? ? ? ? tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); +? ? ? ? tr.contains("[--hello]"); +? ? ? ? if (!tr.testStatus) { +? ? ? ? ? ? System.out.println(tr); +? ? ? ? ? ? throw new RuntimeException("test fails"); +? ? ? ? } + +? ? ? ? // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating +? ? ? ? File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); +? ? ? ? tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); +? ? ? ? tr.checkNegative(); +? ? ? ? if (!tr.testStatus) { +? ? ? ? ? ? System.out.println(tr); +? ? ? ? ? ? throw new RuntimeException("test fails"); +? ? ? ? } + +? ? ? ? // clean-up +? ? ? ? argFile.delete(); +? ? ? ? argFile1.delete(); +? ? ? ? recursiveDelete(testModuleDir); +? ? } + ? ? ?public static void main(String... args) throws Exception { ? ? ? ? ?init(); ? ? ? ? ?ArgsEnvVar a = new ArgsEnvVar(); diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java --- a/test/jdk/tools/launcher/TestSpecialArgs.java? ? ? Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/TestSpecialArgs.java? ? ? Mon Dec 09 16:08:54 2019 -0500 @@ -246,6 +246,10 @@ ? ? ? ? ?if (!tr.contains("Error: Could not find or load main class AbsentClass")) { ? ? ? ? ? ? ?throw new RuntimeException("Test Fails"); ? ? ? ? ?} + +? ? ? ? // Make sure we handle correctly the module long form (--module=) +? ? ? ? tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); +? ? ? ? ensureNoWarnings(tr); ? ? ?} ? ? ?void ensureNoWarnings(TestResult tr) { diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java? ? ? Wed Nov 20 08:12:14 2019 +0800 +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java? ? ? Mon Dec 09 16:08:54 2019 -0500 @@ -29,6 +29,7 @@ ? *? ? ? ? ? jdk.jlink ? * @build BasicTest jdk.test.lib.compiler.CompilerUtils ? * @run testng BasicTest + * @bug 8234076 ? * @summary Basic test of starting an application as a module ? */ @@ -40,6 +41,8 @@ ?import jdk.test.lib.compiler.CompilerUtils; ?import jdk.test.lib.process.ProcessTools; +import jdk.test.lib.process.OutputAnalyzer; +import jdk.test.lib.Utils; ?import org.testng.annotations.BeforeTest; ?import org.testng.annotations.Test; @@ -70,6 +73,8 @@ ? ? ?// the module main class ? ? ?private static final String MAIN_CLASS = "jdk.test.Main"; +? ? // for Windows specific launcher tests +? ? static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=kgi%2B5Ob%2FqX45oTtLSTalwXeQqIct1EUD1k30KOddm5c%3D&reserved=0", "unknown").startsWith("Windows"); ? ? ?@BeforeTest ? ? ?public void compileTestModule() throws Exception { @@ -259,4 +264,87 @@ ? ? ? ? ?assertTrue(exitValue != 0); ? ? ?} + +? ? /** +? ? ?* Helper method that creates a ProcessBuilder with command line arguments +? ? ?* while setting the _JAVA_LAUNCHER_DEBUG environment variable. +? ? ?*/ +? ? private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { +? ? ? ? ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); +? ? ? ? pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); + +? ? ? ? return pb; +? ? } + +? ? ?/** +? ? ?* Test the ability for the Windows launcher to do proper application argument +? ? ?* detection and expansion, when using the long form module option and all passed in +? ? ?* command line arguments are prefixed with a dash. +? ? ?* +? ? ?* These tests are not expected to work on *nixes, and are ignored. +? ? ?*/ +? ? public void testWindowsWithLongFormModuleOption() throws Exception { +? ? ? ? if (!IS_WINDOWS) { +? ? ? ? ? ? return; +? ? ? ? } + +? ? ? ? String dir = MODS_DIR.toString(); +? ? ? ? String mid = TEST_MODULE + "/" + MAIN_CLASS; + +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help +? ? ? ? // We should be able to find the argument --help as an application argument +? ? ? ? ProcessTools.executeProcess( +? ? ? ? ? ? createProcessWithLauncherDebugging( +? ? ? ? ? ? ? ? "--module-path=" + dir, +? ? ? ? ? ? ? ? "--module=" + mid, +? ? ? ? ? ? ? ? "--help")) +? ? ? ? ? ? .outputTo(System.out) +? ? ? ? ? ? .errorTo(System.out) +? ? ? ? ? ? .shouldContain("F--help"); + +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help +? ? ? ? // We should be able to see argument expansion happen +? ? ? ? ProcessTools.executeProcess( +? ? ? ? ? ? createProcessWithLauncherDebugging( +? ? ? ? ? ? ? ? "--module-path=" + dir, +? ? ? ? ? ? ? ? "--module=" + mid, +? ? ? ? ? ? ? ? SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", +? ? ? ? ? ? ? ? "--help")) +? ? ? ? ? ? .outputTo(System.out) +? ? ? ? ? ? .errorTo(System.out) +? ? ? ? ? ? .shouldContain("F--help") +? ? ? ? ? ? .shouldContain("module-info.java"); +? ? } + + +? ? /** +? ? ?* Test that --module= is terminating for VM argument processing just like --module +? ? ?*/ +? ? public void testLongFormModuleOptionTermination() throws Exception { +? ? ? ? String dir = MODS_DIR.toString(); +? ? ? ? String mid = TEST_MODULE + "/" + MAIN_CLASS; + +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS +? ? ? ? // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be +? ? ? ? // deemed as application arguments +? ? ? ? OutputAnalyzer output = ProcessTools.executeProcess( +? ? ? ? ? ? createProcessWithLauncherDebugging( +? ? ? ? ? ? ? ? "--module-path=" + dir, +? ? ? ? ? ? ? ? "--module=" + mid, +? ? ? ? ? ? ? ? "--module-path=" + dir, +? ? ? ? ? ? ? ? "--module=" + mid)) +? ? ? ? ? ? .outputTo(System.out) +? ? ? ? ? ? .errorTo(System.out) +? ? ? ? ? ? .shouldContain("argv[ 0] = '--module-path=" + dir) +? ? ? ? ? ? .shouldContain("argv[ 1] = '--module=" + mid); + +? ? ? ? if (IS_WINDOWS) { +? ? ? ? ? ? output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); +? ? ? ? } + +? ? ? ? // java --module=$TESTMODULE/$MAINCLASS --module-path=mods +? ? ? ? // This command line will not work as --module= is terminating and the module will be not found +? ? ? ? int exitValue = exec("--module=" + mid, "--module-path" + dir); +? ? ? ? assertTrue(exitValue != 0); +? ? } ?} From: Kumar Srinivasan Sent: December 7, 2019 10:28 PM To: Henry Jen Cc: Nikola Grcevski ; Alan Bateman ; mailto:core-libs-dev at openjdk.java.net Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate Hi, The launcher fix looks good, despite the launcher fix being simple, please note,? it sometimes requires a lot more effort to write a test for it, please read on.... Henry excellent catch wrt. ?isTerminalOp the launcher!!!, that tickled my memory and I recalled? this change for VM's native memory tracking. https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=P3l7Y932pcZ14WwbszC0%2BIN%2BUcS2QrAizwT0Idqa6yQ%3D&reserved=0 Inspecting the above changeset, we might have to add another test for JVM native memory tracking, since this is a terminal argument.? Maybe TestHelper could create a simple module, which prints its args, https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=iaKDsz3aVTdEumV4eOMj5SbA9WtSHT6ADA4KEMoqwgw%3D&reserved=0 Kumar Srinivasan On Fri, Dec 6, 2019 at 2:44 PM Henry Jen wrote: Thanks for the work, the test case covers that when ?module= is used before other options, which is good. But we need another to make sure that when ?module= is put in an argument file or environment variable, that should not be allowed. The fix is simple, we need to add that to isTerminalOp() method. Cheers, Henry > On Dec 6, 2019, at 12:28 PM, Nikola Grcevski wrote: > > Thank you Henry! > > I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. > > I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=KrUiucM4CY4G1aADtTMhHwJxr3e7ATJDMMxX5uG3b14%3D&reserved=0) > > Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c? ? ? ? Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/share/native/libjli/args.c? ? ? ? Fri Dec 06 15:11:36 2019 -0500 > @@ -130,6 +130,8 @@ >? ? ? ? ? ? ?} >? ? ? ? ?} else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >? ? ? ? ? ? ?stopExpansion = JNI_TRUE; > +? ? ? ? } else if (JLI_StrCCmp(arg, "--module=") == 0) { > +? ? ? ? ? ? idx = argsCount; >? ? ? ? ?} >? ? ?} else { >? ? ? ? ?if (!expectingNoDashArg) { > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c? ?Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c? ?Fri Dec 06 15:11:36 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > >? ? ?// sanity check, match the args we have, to the holy grail >? ? ?idx = JLI_GetAppArgIndex(); > + > +? ? // First arg index is NOT_FOUND > +? ? if (idx < 0) { > +? ? ? ? // The only allowed value should be NOT_FOUND (-1) unless another change introduces > +? ? ? ? // a different negative index > +? ? ? ? assert (idx == -1); > +? ? ? ? JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); > +? ? ? ? JLI_TraceLauncher("passing arguments as-is.\n"); > +? ? ? ? return NewPlatformStringArray(env, strv, argc); > +? ? } > + >? ? ?isTool = (idx == 0); >? ? ?if (isTool) { idx++; } // skip tool name >? ? ?JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java? ? Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java? ? Fri Dec 06 15:11:36 2019 -0500 > @@ -29,6 +29,7 @@ >? *? ? ? ? ? jdk.jlink >? * @build BasicTest jdk.test.lib.compiler.CompilerUtils >? * @run testng BasicTest > + * @bug 8234076 >? * @summary Basic test of starting an application as a module >? */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ >? ? ?// the module main class >? ? ?private static final String MAIN_CLASS = "jdk.test.Main"; > > +? ? // for Windows specific launcher tests > +? ? static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=3FmeinWv8eFAn8IWUozJWE2OKKaOP9QUFV75TIpu%2Bjk%3D&reserved=0", "unknown").startsWith("Windows"); > >? ? ?@BeforeTest >? ? ?public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ >? ? ? ? ?assertTrue(exitValue != 0); >? ? ?} > > + > +? ? /** > +? ? ?* Helper method that creates a ProcessBuilder with command line arguments > +? ? ?* while setting the _JAVA_LAUNCHER_DEBUG environment variable. > +? ? ?*/ > +? ? private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { > +? ? ? ? ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > +? ? ? ? pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > +? ? ? ? return pb; > +? ? } > + > +? ? ?/** > +? ? ?* Test the ability for the Windows launcher to do proper application argument > +? ? ?* detection and expansion, when using the long form module option and all passed in > +? ? ?* command line arguments are prefixed with a dash. > +? ? ?* > +? ? ?* These tests are not expected to work on *nixes, and are ignored. > +? ? ?*/ > +? ? public void testWindowsWithLongFormModuleOption() throws Exception { > +? ? ? ? if (!IS_WINDOWS) { > +? ? ? ? ? ? return; > +? ? ? ? } > + > +? ? ? ? String dir = MODS_DIR.toString(); > +? ? ? ? String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > +? ? ? ? // We should be able to find the argument --help as an application argument > +? ? ? ? ProcessTools.executeProcess( > +? ? ? ? ? ? createProcessWithLauncherDebugging( > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid, > +? ? ? ? ? ? ? ? "--help")) > +? ? ? ? ? ? .outputTo(System.out) > +? ? ? ? ? ? .errorTo(System.out) > +? ? ? ? ? ? .shouldContain("F--help"); > + > +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help > +? ? ? ? // We should be able to see argument expansion happen > +? ? ? ? ProcessTools.executeProcess( > +? ? ? ? ? ? createProcessWithLauncherDebugging( > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid, > +? ? ? ? ? ? ? ? SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", > +? ? ? ? ? ? ? ? "--help")) > +? ? ? ? ? ? .outputTo(System.out) > +? ? ? ? ? ? .errorTo(System.out) > +? ? ? ? ? ? .shouldContain("F--help") > +? ? ? ? ? ? .shouldContain("module-info.java"); > +? ? } > + > + > +? ? /** > +? ? ?* Test that --module= is terminating for VM argument processing just like --module > +? ? ?*/ > +? ? public void testLongFormModuleOptionTermination() throws Exception { > +? ? ? ? String dir = MODS_DIR.toString(); > +? ? ? ? String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > +? ? ? ? // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS > +? ? ? ? // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be > +? ? ? ? // deemed as application arguments > +? ? ? ? OutputAnalyzer output = ProcessTools.executeProcess( > +? ? ? ? ? ? createProcessWithLauncherDebugging( > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid, > +? ? ? ? ? ? ? ? "--module-path=" + dir, > +? ? ? ? ? ? ? ? "--module=" + mid)) > +? ? ? ? ? ? .outputTo(System.out) > +? ? ? ? ? ? .errorTo(System.out) > +? ? ? ? ? ? .shouldContain("argv[ 0] = '--module-path=" + dir) > +? ? ? ? ? ? .shouldContain("argv[ 1] = '--module=" + mid); > + > +? ? ? ? if (IS_WINDOWS) { > +? ? ? ? ? ? output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); > +? ? ? ? } > + > +? ? ? ? // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > +? ? ? ? // This command line will not work as --module= is terminating and the module will be not found > +? ? ? ? int exitValue = exec("--module=" + mid, "--module-path" + dir); > +? ? ? ? assertTrue(exitValue != 0); > +? ? } > } > > > -----Original Message----- > From: Henry Jen > Sent: December 6, 2019 12:03 AM > To: Nikola Grcevski > Cc: Kumar Srinivasan ; Alan Bateman ; mailto:mailto:core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > >> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: >> >> Hello all again! >> >> Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: >> >> --- a/src/java.base/share/native/libjli/args.c >> +++ b/src/java.base/share/native/libjli/args.c >> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { >>? ? ? ? ? ? } >>? ? ? ? } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>? ? ? ? ? ? stopExpansion = JNI_TRUE; >> +? ? ? ? } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { > > I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. > > BTW, we need the patch to be hosted on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=iuIbGg8zzbN7EPOUkKuXfzAUknZDXckOdwBX2XhwGrE%3D&reserved=0 or you can attach the patch to the review thread if you are not yet an author. > > Cheers, > Henry > > >> +? ? ? ? ? ? idx = argsCount; >>? ? ? ? } >>? ? } else { >>? ? ? ? if (!expectingNoDashArg) { >> >> The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. >> >> I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. >> >> I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). >> >> I ran all the launcher tests on both Windows and Linux and all tests pass. >> >> Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. >> >> Thank you, >> Nikola >> >> -----Original Message----- >> From: Henry Jen >> Sent: December 4, 2019 8:26 PM >> To: Kumar Srinivasan ; Alan Bateman >> ; Nikola Grcevski >> >> Cc: mailto:mailto:core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >>> >>> Hi Nikola, >>> >>> It looks ok to me, I will leave it to Henry and Alan to bless this. >>> >>> IMHO: I think we should fix it correctly now than later, I don't >>> think it is all that difficult AFAICT all the launcher has? to do is >>> identify "--module==", then the next argument is the first index. >>> >> >> I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. >> >> If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. >> >> FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. >> >> I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. >> >> I?ll let Alan to comment about the ?module option usage. >> >> The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs >> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=362LaE5nipNO0eVmKa%2BmTTwhhBCFfAGdFMFHd%2Bumx4A%3D&reserved=0 >> &data=02%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 >> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY >> %3D&reserved=0 >> >>> Kumar >>> >>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >>> Hi Henry and Kumar, >>> >>> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >>> >>> Please find my updated webrev here for your review: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc >>> e >>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=WMlvgPM2Ixt0WaZiD61ZLjRmSgRL3UDmrNITh7H%2Ft38%3D&reserved=0 >>> c >>> evski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >>> f >>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ >>> % >>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>> >>> Cheers, >>> >>> Nikola >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 3, 2019 11:39 AM >>> To: Kumar Srinivasan >>> Cc: Nikola Grcevski ; Alan Bateman >>> ; mailto:mailto:core-libs-dev at openjdk.java.net >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>> >>> Kumar, >>> >>> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >>> >>> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >>> >>> Cheers, >>> Henry >>> >>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>>> >>>> Hi, >>>> >>>> Sorry for chiming in? late in the review process, for what it's worth.... >>>> >>>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>>>? ?and subsequent crash,? but it does not address? wildcard arguments expansion. >>>> >>>>? ?What if we have >>>>? ?% java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>>>? ?Where jdk.compiler is a java compiler implementation (javac). >>>>? ?The user would expect the above compiler module to build all the .java files in that directory, >>>>? ?and this fix will not address that. >>>> >>>> Some background: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=QyeJDvywLhjIe02uwSYhV2mI2ERcgOhObjk2lDWF8oQ%3D&reserved=0 >>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=mH19URBhYu0rW%2Bpsl91V9e3TcwPD%2BDX0YSNbXao5H8o%3D&reserved=0 >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>>> Please see all the related bugs in the above JIRA issue. >>>> >>>> Paragraph #6 in this interview surmises the wild card behavior on? Windows: >>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=K1mAbE9L7km1jXGixjKlWpUFsEpSKxwpsi%2Bqby35nlo%3D&reserved=0 >>>> 2%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=%2FUxEEDQrTgIk2Y%2Bd%2FPz67ocYVqRXncW%2FsITD%2BWpemSY%3D&reserved=0 >>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>>> ;reserved=0 >>>> >>>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>>> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=ED1VtZLjyMmo3uRMRQ02rMCeeHrk0HIlQO8mv2tnPKA%3D&reserved=0 >>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>>> ki%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=HvTbDg9uHe5WDu0OVcH%2BPF5mgYHWv2OUHYAWY2EheFo%3D&reserved=0 >>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>>> Using the modules test framework may make the test simpler. >>>> >>>> Kumar Srinivasan >>>> >>>> >>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>>> Hi Alan and Henry, >>>> >>>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>>> >>>> I created a webrev here for the change, including a new test in Arrrghs.java: >>>> >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=fi870VNLFmOgySkWY1LJJ2qBSKZkdTaIEW6ytg%2FMHDA%3D&reserved=0 >>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=XX0qBV1e5ucqPSL%2B4YciHNXR29evREuIRDFwTSxaqHU%3D&reserved=0 >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>> >>>> I copied the test validation and assertion style of other code inside the test class. >>>> >>>> Please let me know if you have any comments or suggestions. >>>> >>>> Thanks again! >>>> >>>> -----Original Message----- >>>> From: Henry Jen >>>> Sent: December 2, 2019 12:26 PM >>>> To: Alan Bateman >>>> Cc: Nikola Grcevski ; >>>> mailto:mailto:core-libs-dev at openjdk.java.net >>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>>> >>>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>>> >>>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>>> >>>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>>> >>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>>> : >>>>>> >>>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>>> >>>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>>> >>>>> -Alan From alexey.semenyuk at oracle.com Wed Dec 11 18:46:14 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Dec 2019 13:46:14 -0500 Subject: RFR: JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path In-Reply-To: References: Message-ID: Please review fix [2] for jpackage bug [1]. - adds $(X_CFLAGS) to compiler command line. Patch contributed by Arthur Eubanks (aeubanks at google.com). - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8235728 [2] http://cr.openjdk.java.net/~asemenyuk/8235728/webrev.00 From philip.race at oracle.com Wed Dec 11 18:48:38 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Dec 2019 10:48:38 -0800 Subject: RFR: JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path In-Reply-To: References: Message-ID: <9caf056e-34b5-8e58-dbff-5547ba7b645c@oracle.com> Looks OK. I presume you did a test build in our build system ? -phil On 12/11/19 10:46 AM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > - adds $(X_CFLAGS) to compiler command line. > > Patch contributed by Arthur Eubanks (aeubanks at google.com). > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8235728 > > [2] http://cr.openjdk.java.net/~asemenyuk/8235728/webrev.00 > From erik.joelsson at oracle.com Wed Dec 11 18:54:53 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Dec 2019 10:54:53 -0800 Subject: RFR: JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path In-Reply-To: References: Message-ID: Looks good. /Erik On 2019-12-11 10:46, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > - adds $(X_CFLAGS) to compiler command line. > > Patch contributed by Arthur Eubanks (aeubanks at google.com). > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8235728 > > [2] http://cr.openjdk.java.net/~asemenyuk/8235728/webrev.00 > From aeubanks at google.com Wed Dec 11 19:09:15 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Wed, 11 Dec 2019 11:09:15 -0800 Subject: RFR: JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path In-Reply-To: References: Message-ID: Looks good, thanks for fixing this! On Wed, Dec 11, 2019 at 10:55 AM Erik Joelsson wrote: > Looks good. > > /Erik > > On 2019-12-11 10:46, Alexey Semenyuk wrote: > > Please review fix [2] for jpackage bug [1]. > > > > - adds $(X_CFLAGS) to compiler command line. > > > > Patch contributed by Arthur Eubanks (aeubanks at google.com). > > > > - Alexey > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8235728 > > > > [2] http://cr.openjdk.java.net/~asemenyuk/8235728/webrev.00 > > > From andy.herrick at oracle.com Wed Dec 11 19:11:27 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 14:11:27 -0500 Subject: RFR: JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path In-Reply-To: References: Message-ID: looks good /Andy On 12/11/2019 1:46 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > - adds $(X_CFLAGS) to compiler command line. > > Patch contributed by Arthur Eubanks (aeubanks at google.com). > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8235728 > > [2] http://cr.openjdk.java.net/~asemenyuk/8235728/webrev.00 > From andy.herrick at oracle.com Wed Dec 11 19:42:01 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 14:42:01 -0500 Subject: RFR: 8235788: Changeset for JDK-8235252 pushed with wrong bug ID Message-ID: Please review fix [1] for issue [2] This is backing out the fix to JDK-8235252 so I can re-push it with the right comment [1] 8235788 Changeset for JDK-8235252 pushed with wrong bug ID [2] https://bugs.openjdk.java.net/browse/JDK-8235788 /Andy From andy.herrick at oracle.com Wed Dec 11 19:43:36 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 14:43:36 -0500 Subject: RFR: 8235788: Changeset for JDK-8235252 pushed with wrong bug ID In-Reply-To: References: Message-ID: sorry - fix is at: [3] http://cr.openjdk.java.net/~herrick/8235788/webrev.01/ /Andy On 12/11/2019 2:42 PM, Andy Herrick wrote: > Please review fix [1] for issue [2] > > This is backing out the fix to JDK-8235252 so I can re-push it with > the right comment > > [1] 8235788 > Changeset for JDK-8235252 pushed with wrong bug ID > > [2] https://bugs.openjdk.java.net/browse/JDK-8235788 > > /Andy > From philip.race at oracle.com Wed Dec 11 19:57:43 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Dec 2019 11:57:43 -0800 Subject: RFR: 8235788: Changeset for JDK-8235252 pushed with wrong bug ID In-Reply-To: References: Message-ID: <9dbadaf3-22c7-5018-c7ee-d187b54ece19@oracle.com> +1 -phil On 12/11/19 11:43 AM, Andy Herrick wrote: > sorry - fix is at: > > [3] http://cr.openjdk.java.net/~herrick/8235788/webrev.01/ > > /Andy > > On 12/11/2019 2:42 PM, Andy Herrick wrote: >> Please review fix [1] for issue [2] >> >> This is backing out the fix to JDK-8235252 so I can re-push it with >> the right comment >> >> [1] 8235788 >> Changeset for JDK-8235252 pushed with wrong bug ID >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8235788 >> >> /Andy >> From alexey.semenyuk at oracle.com Wed Dec 11 20:14:05 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Dec 2019 15:14:05 -0500 Subject: RFR: JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path In-Reply-To: <9caf056e-34b5-8e58-dbff-5547ba7b645c@oracle.com> References: <9caf056e-34b5-8e58-dbff-5547ba7b645c@oracle.com> Message-ID: Yes, I did a test build. - Alexey On 12/11/2019 1:48 PM, Phil Race wrote: > Looks OK. I presume you did a test build in our build system ? > > -phil > > On 12/11/19 10:46 AM, Alexey Semenyuk wrote: >> Please review fix [2] for jpackage bug [1]. >> >> - adds $(X_CFLAGS) to compiler command line. >> >> Patch contributed by Arthur Eubanks (aeubanks at google.com). >> >> - Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235728 >> >> [2] http://cr.openjdk.java.net/~asemenyuk/8235728/webrev.00 >> > From alexey.semenyuk at oracle.com Wed Dec 11 20:16:43 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 11 Dec 2019 15:16:43 -0500 Subject: RFR: 8235788: Changeset for JDK-8235252 pushed with wrong bug ID In-Reply-To: <9dbadaf3-22c7-5018-c7ee-d187b54ece19@oracle.com> References: <9dbadaf3-22c7-5018-c7ee-d187b54ece19@oracle.com> Message-ID: <1091b735-f3df-7e13-443a-f8d10ba293c7@oracle.com> Looks good. - Alexey On 12/11/2019 2:57 PM, Phil Race wrote: > +1 > > -phil > > On 12/11/19 11:43 AM, Andy Herrick wrote: >> sorry - fix is at: >> >> [3] http://cr.openjdk.java.net/~herrick/8235788/webrev.01/ >> >> /Andy >> >> On 12/11/2019 2:42 PM, Andy Herrick wrote: >>> Please review fix [1] for issue [2] >>> >>> This is backing out the fix to JDK-8235252 so I can re-push it with >>> the right comment >>> >>> [1] 8235788 >>> Changeset for JDK-8235252 pushed with wrong bug ID >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8235788 >>> >>> /Andy >>> > From philip.race at oracle.com Wed Dec 11 20:22:13 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Dec 2019 12:22:13 -0800 Subject: RFR: JDK-8235728: JDK-8212780 breaks builds with a custom X11 include path In-Reply-To: References: <9caf056e-34b5-8e58-dbff-5547ba7b645c@oracle.com> Message-ID: ok. all good. -phil On 12/11/19 12:14 PM, Alexey Semenyuk wrote: > Yes, I did a test build. > > - Alexey > > On 12/11/2019 1:48 PM, Phil Race wrote: >> Looks OK. I presume you did a test build in our build system ? >> >> -phil >> >> On 12/11/19 10:46 AM, Alexey Semenyuk wrote: >>> Please review fix [2] for jpackage bug [1]. >>> >>> - adds $(X_CFLAGS) to compiler command line. >>> >>> Patch contributed by Arthur Eubanks (aeubanks at google.com). >>> >>> - Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235728 >>> >>> [2] http://cr.openjdk.java.net/~asemenyuk/8235728/webrev.00 >>> >> > From alexander.matveev at oracle.com Wed Dec 11 20:59:56 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 11 Dec 2019 12:59:56 -0800 Subject: RFR: JDK-8235252: Repair run_tests.sh by locating jtreg locally In-Reply-To: <8a0c2957-71e0-18cc-96b7-6d651919e0f6@oracle.com> References: <35a28018-d1d0-f077-d143-6500877e6856@oracle.com> <2b553034-66cc-7615-1f1c-951b0b441e94@oracle.com> <8a0c2957-71e0-18cc-96b7-6d651919e0f6@oracle.com> Message-ID: <648b1c66-b642-93b1-dc78-1ff5981d0c62@oracle.com> webrev.01 is incorrect, since it uses JTREG_ prefix for variables name. Correct webrev is http://cr.openjdk.java.net/~almatvee/8235252/webrev.02/ It is identical to webrev.01, except prefix of variable names changed to JT_. Thanks, Alexander On 12/10/19 3:54 PM, Alexander Matveev wrote: > http://cr.openjdk.java.net/~almatvee/8235252/webrev.01/ > - Updated script to use JT_HOME first if set, then use JT_BUNDLE_URL > if set. > - Also, renamed JTREG_ to JT_ in variables names to align with rest of > JDK. > > Not sure why we did not use jtreg used by all the other tests. > run_tests.sh used for convenience to generate and verify packages > generated by jpackage. This process done in 5 stages: generating > packages (jtreg test), installation (requires user input), verify > installation, uninstall (requires user input) and verify uninstall. > This is why we using helper script to simplify this process. > > Thanks, > Alexander > > On 12/10/2019 3:32 PM, Alexey Semenyuk wrote: >> http://cr.openjdk.java.net/~almatvee/8235252/webrev.01/ looks good. >> >> - Alexey >> >> On 12/10/2019 4:49 PM, Jonathan Gibbons wrote: >>> This seems ... surprising. >>> >>> Why is the instance of jtreg used for all the other tests not good >>> enough here? >>> >>> -- Jon >>> >>> On 12/10/19 1:35 PM, Alexander Matveev wrote: >>>> Please review simple script fix [2] for jpackage bug [1]. >>>> >>>> ?- Modified script to download jtreg bundle from URL provided by >>>> environment variable JTREG_BUNDLE_URL. >>>> >>>> Thanks, >>>> Alexander >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235252 >>>> >>>> [2] http://cr.openjdk.java.net/~almatvee/8235252/webrev.00/ >> > From andy.herrick at oracle.com Wed Dec 11 21:18:38 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 11 Dec 2019 16:18:38 -0500 Subject: RFR: JDK-8235252: Repair run_tests.sh by locating jtreg locally In-Reply-To: <648b1c66-b642-93b1-dc78-1ff5981d0c62@oracle.com> References: <35a28018-d1d0-f077-d143-6500877e6856@oracle.com> <2b553034-66cc-7615-1f1c-951b0b441e94@oracle.com> <8a0c2957-71e0-18cc-96b7-6d651919e0f6@oracle.com> <648b1c66-b642-93b1-dc78-1ff5981d0c62@oracle.com> Message-ID: looks good /Andy On 12/11/2019 3:59 PM, Alexander Matveev wrote: > webrev.01 is incorrect, since it uses JTREG_ prefix for variables name. > > Correct webrev is http://cr.openjdk.java.net/~almatvee/8235252/webrev.02/ > It is identical to webrev.01, except prefix of variable names changed > to JT_. > > Thanks, > Alexander > > On 12/10/19 3:54 PM, Alexander Matveev wrote: >> http://cr.openjdk.java.net/~almatvee/8235252/webrev.01/ >> - Updated script to use JT_HOME first if set, then use JT_BUNDLE_URL >> if set. >> - Also, renamed JTREG_ to JT_ in variables names to align with rest >> of JDK. >> >> Not sure why we did not use jtreg used by all the other tests. >> run_tests.sh used for convenience to generate and verify packages >> generated by jpackage. This process done in 5 stages: generating >> packages (jtreg test), installation (requires user input), verify >> installation, uninstall (requires user input) and verify uninstall. >> This is why we using helper script to simplify this process. >> >> Thanks, >> Alexander >> >> On 12/10/2019 3:32 PM, Alexey Semenyuk wrote: >>> http://cr.openjdk.java.net/~almatvee/8235252/webrev.01/ looks good. >>> >>> - Alexey >>> >>> On 12/10/2019 4:49 PM, Jonathan Gibbons wrote: >>>> This seems ... surprising. >>>> >>>> Why is the instance of jtreg used for all the other tests not good >>>> enough here? >>>> >>>> -- Jon >>>> >>>> On 12/10/19 1:35 PM, Alexander Matveev wrote: >>>>> Please review simple script fix [2] for jpackage bug [1]. >>>>> >>>>> ?- Modified script to download jtreg bundle from URL provided by >>>>> environment variable JTREG_BUNDLE_URL. >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235252 >>>>> >>>>> [2] http://cr.openjdk.java.net/~almatvee/8235252/webrev.00/ >>> >> > From naoto.sato at oracle.com Wed Dec 11 21:21:17 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 11 Dec 2019 13:21:17 -0800 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider Message-ID: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> Hi, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8235238 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ The fix will retrieve the custom zone names from the time zone name provider, for the custom ZoneRulesProvider implementations. Naoto From ksrinifmt at gmail.com Wed Dec 11 22:26:39 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Wed, 11 Dec 2019 14:26:39 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> Message-ID: Hi Nikola, Thank you for making the changes. Looks good to me. Kumar Srinivasan PS: my new and official email address: kusrinivasan at vmware.com On Wed, Dec 11, 2019 at 10:04 AM Nikola Grcevski < Nikola.Grcevski at microsoft.com> wrote: > Thank you again for reviewing my code Kumar! > > I have applied your refactoring suggestions. Using the array approach as > you suggested made the test code a lot more tidier. I?m attaching the > updated patch after my signature and the external webrev is here for > reference: > > https://grcevski.github.io/JDK-8234076/webrev/ > > Cheers, > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 > +0800 > +++ b/src/java.base/share/native/libjli/args.c Wed Dec 11 12:09:29 2019 > -0500 > @@ -130,6 +130,8 @@ > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > @@ -449,6 +451,7 @@ > return JLI_StrCmp(arg, "-jar") == 0 || > JLI_StrCmp(arg, "-m") == 0 || > JLI_StrCmp(arg, "--module") == 0 || > + JLI_StrCCmp(arg, "--module=") == 0 || > JLI_StrCmp(arg, "--dry-run") == 0 || > JLI_StrCmp(arg, "-h") == 0 || > JLI_StrCmp(arg, "-?") == 0 || > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c Wed Dec 11 > 12:09:29 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > > // sanity check, match the args we have, to the holy grail > idx = JLI_GetAppArgIndex(); > + > + // First arg index is NOT_FOUND > + if (idx < 0) { > + // The only allowed value should be NOT_FOUND (-1) unless another > change introduces > + // a different negative index > + assert (idx == -1); > + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", > idx); > + JLI_TraceLauncher("passing arguments as-is.\n"); > + return NewPlatformStringArray(env, strv, argc); > + } > + > isTool = (idx == 0); > if (isTool) { idx++; } // skip tool name > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, > stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java > --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 > +0800 > +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Wed Dec 11 12:09:29 2019 > -0500 > @@ -37,6 +37,8 @@ > import java.util.List; > import java.util.Map; > import java.util.regex.Pattern; > +import java.nio.file.Paths; > +import java.nio.file.Path; > > public class ArgsEnvVar extends TestHelper { > private static File testJar = null; > @@ -153,6 +155,7 @@ > List.of("-jar", "test.jar"), > List.of("-m", "test/Foo"), > List.of("--module", "test/Foo"), > + List.of("--module=test/Foo"), > List.of("--dry-run"), > List.of("-h"), > List.of("-?"), > @@ -241,6 +244,69 @@ > verifyOptions(List.of("--add-exports", > "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); > } > > + > + @Test > + // That that we can correctly handle the module longform argument > option > + // when supplied in an argument file > + public void modulesInArgsFile() throws IOException { > + File cwd = new File("."); > + File testModuleDir = new File(cwd, "modules_test"); > + > + createEchoArgumentsModule(testModuleDir); > + > + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); > + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), > "mods"); > + > + // test module / main class > + String MODULE_OPTION = "--module=test/launcher.Main"; > + String TEST_MODULE = "test"; > + > + // javac -d mods/test src/test/** > + TestResult tr = doExec( > + javacCmd, > + "-d", MODS_DIR.toString(), > + "--module-source-path", SRC_DIR.toString(), > + "--module", TEST_MODULE); > + > + if (!tr.isOK()) { > + System.out.println("test did not compile"); > + throw new RuntimeException("Error: modules test did not > compile"); > + } > + > + // verify the terminating ability of --module= through > environment variables > + File argFile = createArgFile("cmdargs", List.of("--module-path", > MODS_DIR.toString(), MODULE_OPTION, "--hello")); > + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); > + tr = doExec(env, javaCmd); > + tr.checkNegative(); > + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is > not allowed in environment variable JDK_JAVA_OPTIONS"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check that specifying --module and --module-path with file > works > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); > + tr.contains("[--hello]"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check with reversed --module-path and --module in the > arguments file, this will fail, --module= is terminating > + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, > "--module-path", MODS_DIR.toString(), "--hello")); > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); > + tr.checkNegative(); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // clean-up > + argFile.delete(); > + argFile1.delete(); > + recursiveDelete(testModuleDir); > + } > + > public static void main(String... args) throws Exception { > init(); > ArgsEnvVar a = new ArgsEnvVar(); > diff -r bd436284147d test/jdk/tools/launcher/TestHelper.java > --- a/test/jdk/tools/launcher/TestHelper.java Wed Nov 20 08:12:14 2019 > +0800 > +++ b/test/jdk/tools/launcher/TestHelper.java Wed Dec 11 12:09:29 2019 > -0500 > @@ -500,6 +500,40 @@ > return Locale.getDefault().getLanguage().equals("en"); > } > > + /** > + * Helper method to initialize a simple module that just prints the > passed in arguments > + */ > + static void createEchoArgumentsModule(File modulesDir) throws > IOException { > + if (modulesDir.exists()) { > + recursiveDelete(modulesDir); > + } > + > + modulesDir.mkdirs(); > + > + File srcDir = new File(modulesDir, "src"); > + File modsDir = new File(modulesDir, "mods"); > + File testDir = new File(srcDir, "test"); > + File launcherTestDir = new File(testDir, "launcher"); > + srcDir.mkdir(); > + modsDir.mkdir(); > + testDir.mkdir(); > + launcherTestDir.mkdir(); > + > + String[] moduleInfoCode = { "module test {}" }; > + createFile(new File(testDir, "module-info.java"), > Arrays.asList(moduleInfoCode)); > + > + String[] moduleCode = { > + "package launcher;", > + "import java.util.Arrays;", > + "public class Main {", > + "public static void main(String[] args) {", > + "System.out.println(Arrays.toString(args));", > + "}", > + "}" > + }; > + createFile(new File(launcherTestDir, "Main.java"), > Arrays.asList(moduleCode)); > + } > + > /* > * A class to encapsulate the test results and stuff, with some ease > * of use methods to check the test results. > diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java > --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Wed Dec 11 > 12:09:29 2019 -0500 > @@ -246,6 +246,10 @@ > if (!tr.contains("Error: Could not find or load main class > AbsentClass")) { > throw new RuntimeException("Test Fails"); > } > + > + // Make sure we handle correctly the module long form (--module=) > + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", > "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); > + ensureNoWarnings(tr); > } > > void ensureNoWarnings(TestResult tr) { > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Dec 11 > 12:09:29 2019 -0500 > @@ -29,6 +29,7 @@ > * jdk.jlink > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > * @run testng BasicTest > + * @bug 8234076 > * @summary Basic test of starting an application as a module > */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ > // the module main class > private static final String MAIN_CLASS = "jdk.test.Main"; > > + // for Windows specific launcher tests > + static final boolean IS_WINDOWS = System.getProperty("os.name", > "unknown").startsWith("Windows"); > > @BeforeTest > public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ > assertTrue(exitValue != 0); > } > > + > + /** > + * Helper method that creates a ProcessBuilder with command line > arguments > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > + */ > + private ProcessBuilder createProcessWithLauncherDebugging(String... > cmds) { > + ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > + return pb; > + } > + > + /** > + * Test the ability for the Windows launcher to do proper application > argument > + * detection and expansion, when using the long form module option > and all passed in > + * command line arguments are prefixed with a dash. > + * > + * These tests are not expected to work on *nixes, and are ignored. > + */ > + public void testWindowsWithLongFormModuleOption() throws Exception { > + if (!IS_WINDOWS) { > + return; > + } > + > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > + // We should be able to find the argument --help as an > application argument > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help"); > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > <...src/test>/*.java --help > + // We should be able to see argument expansion happen > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help") > + .shouldContain("module-info.java"); > + } > + > + > + /** > + * Test that --module= is terminating for VM argument processing just > like --module > + */ > + public void testLongFormModuleOptionTermination() throws Exception { > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --module-path=mods --module=$TESTMODULE/$MAINCLASS > + // The first --module= will terminate the VM arguments > processing. The second pair of module-path and module will be > + // deemed as application arguments > + OutputAnalyzer output = ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--module-path=" + dir, > + "--module=" + mid)) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("argv[ 0] = '--module-path=" + dir) > + .shouldContain("argv[ 1] = '--module=" + mid); > + > + if (IS_WINDOWS) { > + output.shouldContain("F--module-path=" + > dir).shouldContain("F--module=" + mid); > + } > + > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > + // This command line will not work as --module= is terminating > and the module will be not found > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > + assertTrue(exitValue != 0); > + } > } > > From: Kumar Srinivasan > Sent: December 10, 2019 8:43 PM > To: Nikola Grcevski > Cc: Henry Jen ; Alan Bateman < > Alan.Bateman at oracle.com>; core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > [Resend; cc'ing the group] > > Hi Nikola, > > Generally looks great to me. I would have moved initModulesDir to > TestHelper.createSimpleModule(File dir). > TestHelper.java contains a collection of test related utilities needed by > the launcher, it will help someone > else use it to create a simple module. > > I would have rewritten this > + ArrayList scratchpad = new ArrayList<>(); > + scratchpad.add("module test {}"); > + createFile(new File(testDir, "module-info.java"), scratchpad); > + scratchpad.clear(); > + scratchpad.add("package launcher;"); > + scratchpad.add("import java.util.Arrays;"); > + scratchpad.add("public class Main {"); > + scratchpad.add("public static void main(String[] args) {"); > + scratchpad.add("System.out.println(Arrays.toString(args));"); > + scratchpad.add("}"); > + scratchpad.add("}"); > + createFile(new File(launcherTestDir, "Main.java"), scratchpad); > > as follows: > String a1[] = {"module test{}"}; > createFile(new File(testDir, "module-info.java", Arrays.asList(a1)); > > String a2[] = { > "package launcher;", > .... > .... > } > createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(a2)); > > This might make the code neater. > > Besides that, looks very good. > > Thanks > Kumar > > > On Mon, Dec 9, 2019 at 1:58 PM Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > Hi Henry and Kumar, > > Thank you again for the review! I have added the fix to isTerminalOpt and > used both of your suggestions to make new tests. > With native memory tracking enabled, I could actually see a crash on both > Linux and Windows without the suggested fix. > > I tested the changes again on both Linux and Windows, and the new unit > tests fail if isTerminalOpt doesn?t check for ?module= > as per Henry's suggestion. > > I'm attaching the new patch (my apologies for the size) at the bottom of > this email after my signature. If I haven't covered > certain aspects in the new tests please let me know, I'm more than happy > to extend them further. I've updated the webrev > to reflect the latest patch if it's easier to read: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=XcriPrQ%2B9rypJN6IShAKU2%2Fz5sZE%2BMCWT3gHyVg3Y3s%3D&reserved=0 > > Thanks again! > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 > +0800 > +++ b/src/java.base/share/native/libjli/args.c Mon Dec 09 16:08:54 2019 > -0500 > @@ -130,6 +130,8 @@ > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > @@ -449,6 +451,7 @@ > return JLI_StrCmp(arg, "-jar") == 0 || > JLI_StrCmp(arg, "-m") == 0 || > JLI_StrCmp(arg, "--module") == 0 || > + JLI_StrCCmp(arg, "--module=") == 0 || > JLI_StrCmp(arg, "--dry-run") == 0 || > JLI_StrCmp(arg, "-h") == 0 || > JLI_StrCmp(arg, "-?") == 0 || > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c Mon Dec 09 > 16:08:54 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > > // sanity check, match the args we have, to the holy grail > idx = JLI_GetAppArgIndex(); > + > + // First arg index is NOT_FOUND > + if (idx < 0) { > + // The only allowed value should be NOT_FOUND (-1) unless another > change introduces > + // a different negative index > + assert (idx == -1); > + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", > idx); > + JLI_TraceLauncher("passing arguments as-is.\n"); > + return NewPlatformStringArray(env, strv, argc); > + } > + > isTool = (idx == 0); > if (isTool) { idx++; } // skip tool name > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, > stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java > --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 > +0800 > +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Mon Dec 09 16:08:54 2019 > -0500 > @@ -37,6 +37,8 @@ > import java.util.List; > import java.util.Map; > import java.util.regex.Pattern; > +import java.nio.file.Paths; > +import java.nio.file.Path; > > public class ArgsEnvVar extends TestHelper { > private static File testJar = null; > @@ -153,6 +155,7 @@ > List.of("-jar", "test.jar"), > List.of("-m", "test/Foo"), > List.of("--module", "test/Foo"), > + List.of("--module=test/Foo"), > List.of("--dry-run"), > List.of("-h"), > List.of("-?"), > @@ -241,6 +244,101 @@ > verifyOptions(List.of("--add-exports", > "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); > } > > + /** > + * Helper method to initialize a simple module that just prints the > passed in arguments > + */ > + private void initModulesDir(File modulesDir) throws IOException { > + if (modulesDir.exists()) { > + recursiveDelete(modulesDir); > + } > + > + modulesDir.mkdirs(); > + > + File srcDir = new File(modulesDir, "src"); > + File modsDir = new File(modulesDir, "mods"); > + File testDir = new File(srcDir, "test"); > + File launcherTestDir = new File(testDir, "launcher"); > + srcDir.mkdir(); > + modsDir.mkdir(); > + testDir.mkdir(); > + launcherTestDir.mkdir(); > + > + ArrayList scratchpad = new ArrayList<>(); > + scratchpad.add("module test {}"); > + createFile(new File(testDir, "module-info.java"), scratchpad); > + scratchpad.clear(); > + scratchpad.add("package launcher;"); > + scratchpad.add("import java.util.Arrays;"); > + scratchpad.add("public class Main {"); > + scratchpad.add("public static void main(String[] args) {"); > + scratchpad.add("System.out.println(Arrays.toString(args));"); > + scratchpad.add("}"); > + scratchpad.add("}"); > + createFile(new File(launcherTestDir, "Main.java"), scratchpad); > + } > + > + @Test > + // That that we can correctly handle the module longform argument > option > + // when supplied in an argument file > + public void modulesInArgsFile() throws IOException { > + File cwd = new File("."); > + File testModuleDir = new File(cwd, "modules_test"); > + > + initModulesDir(testModuleDir); > + > + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); > + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), > "mods"); > + > + // test module / main class > + String MODULE_OPTION = "--module=test/launcher.Main"; > + String TEST_MODULE = "test"; > + > + // javac -d mods/test src/test/** > + TestResult tr = doExec( > + javacCmd, > + "-d", MODS_DIR.toString(), > + "--module-source-path", SRC_DIR.toString(), > + "--module", TEST_MODULE); > + > + if (!tr.isOK()) { > + System.out.println("test did not compile"); > + throw new RuntimeException("Error: modules test did not > compile"); > + } > + > + // verify the terminating ability of --module= through > environment variables > + File argFile = createArgFile("cmdargs", List.of("--module-path", > MODS_DIR.toString(), MODULE_OPTION, "--hello")); > + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); > + tr = doExec(env, javaCmd); > + tr.checkNegative(); > + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is > not allowed in environment variable JDK_JAVA_OPTIONS"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check that specifying --module and --module-path with file > works > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); > + tr.contains("[--hello]"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check with reversed --module-path and --module in the > arguments file, this will fail, --module= is terminating > + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, > "--module-path", MODS_DIR.toString(), "--hello")); > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); > + tr.checkNegative(); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // clean-up > + argFile.delete(); > + argFile1.delete(); > + recursiveDelete(testModuleDir); > + } > + > public static void main(String... args) throws Exception { > init(); > ArgsEnvVar a = new ArgsEnvVar(); > diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java > --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Mon Dec 09 > 16:08:54 2019 -0500 > @@ -246,6 +246,10 @@ > if (!tr.contains("Error: Could not find or load main class > AbsentClass")) { > throw new RuntimeException("Test Fails"); > } > + > + // Make sure we handle correctly the module long form (--module=) > + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", > "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); > + ensureNoWarnings(tr); > } > > void ensureNoWarnings(TestResult tr) { > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 > 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Mon Dec 09 > 16:08:54 2019 -0500 > @@ -29,6 +29,7 @@ > * jdk.jlink > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > * @run testng BasicTest > + * @bug 8234076 > * @summary Basic test of starting an application as a module > */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ > // the module main class > private static final String MAIN_CLASS = "jdk.test.Main"; > > + // for Windows specific launcher tests > + static final boolean IS_WINDOWS = System.getProperty(" > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=kgi%2B5Ob%2FqX45oTtLSTalwXeQqIct1EUD1k30KOddm5c%3D&reserved=0", > "unknown").startsWith("Windows"); > > @BeforeTest > public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ > assertTrue(exitValue != 0); > } > > + > + /** > + * Helper method that creates a ProcessBuilder with command line > arguments > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > + */ > + private ProcessBuilder createProcessWithLauncherDebugging(String... > cmds) { > + ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > + return pb; > + } > + > + /** > + * Test the ability for the Windows launcher to do proper application > argument > + * detection and expansion, when using the long form module option > and all passed in > + * command line arguments are prefixed with a dash. > + * > + * These tests are not expected to work on *nixes, and are ignored. > + */ > + public void testWindowsWithLongFormModuleOption() throws Exception { > + if (!IS_WINDOWS) { > + return; > + } > + > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > + // We should be able to find the argument --help as an > application argument > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help"); > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > <...src/test>/*.java --help > + // We should be able to see argument expansion happen > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help") > + .shouldContain("module-info.java"); > + } > + > + > + /** > + * Test that --module= is terminating for VM argument processing just > like --module > + */ > + public void testLongFormModuleOptionTermination() throws Exception { > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --module-path=mods --module=$TESTMODULE/$MAINCLASS > + // The first --module= will terminate the VM arguments > processing. The second pair of module-path and module will be > + // deemed as application arguments > + OutputAnalyzer output = ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--module-path=" + dir, > + "--module=" + mid)) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("argv[ 0] = '--module-path=" + dir) > + .shouldContain("argv[ 1] = '--module=" + mid); > + > + if (IS_WINDOWS) { > + output.shouldContain("F--module-path=" + > dir).shouldContain("F--module=" + mid); > + } > + > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > + // This command line will not work as --module= is terminating > and the module will be not found > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > + assertTrue(exitValue != 0); > + } > } > > > From: Kumar Srinivasan > Sent: December 7, 2019 10:28 PM > To: Henry Jen > Cc: Nikola Grcevski ; Alan Bateman > ; mailto:core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > Hi, > > The launcher fix looks good, despite the launcher fix being simple, please > note, > it sometimes requires a lot more effort to write a test for it, please > read on.... > > Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my > memory and I recalled > this change for VM's native memory tracking. > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=P3l7Y932pcZ14WwbszC0%2BIN%2BUcS2QrAizwT0Idqa6yQ%3D&reserved=0 > Inspecting the above changeset, we might have to add another test for JVM > native memory tracking, > since this is a terminal argument. > > Maybe TestHelper could create a simple module, which prints its args, > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=iaKDsz3aVTdEumV4eOMj5SbA9WtSHT6ADA4KEMoqwgw%3D&reserved=0 > > Kumar Srinivasan > > On Fri, Dec 6, 2019 at 2:44 PM Henry Jen henry.jen at oracle.com> wrote: > Thanks for the work, the test case covers that when ?module= is used > before other options, which is good. > > But we need another to make sure that when ?module= is put in an argument > file or environment variable, that should not be allowed. The fix is > simple, we need to add that to isTerminalOp() method. > > Cheers, > Henry > > > On Dec 6, 2019, at 12:28 PM, Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > > > > Thank you Henry! > > > > I have modified the fix in checkArg to use JLI_StrCCmp as suggested > below and I have extended the BasicTest.java (in > test/jdk/tools/launcher/modules/basic) with few additional tests. > > > > I don't have author status yet, therefore I'm attaching the patch right > after my signature. I also updated my external webrev if that's easier to > review ( > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=KrUiucM4CY4G1aADtTMhHwJxr3e7ATJDMMxX5uG3b14%3D&reserved=0 > ) > > > > Thanks again to everyone for your help with this bug. If there are any > additional comments or suggestions please let me know. > > Nikola > > > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -130,6 +130,8 @@ > > } > > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > > stopExpansion = JNI_TRUE; > > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > > + idx = argsCount; > > } > > } else { > > if (!expectingNoDashArg) { > > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -34,6 +34,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include "java.h" > > @@ -1015,6 +1016,17 @@ > > > > // sanity check, match the args we have, to the holy grail > > idx = JLI_GetAppArgIndex(); > > + > > + // First arg index is NOT_FOUND > > + if (idx < 0) { > > + // The only allowed value should be NOT_FOUND (-1) unless > another change introduces > > + // a different negative index > > + assert (idx == -1); > > + JLI_TraceLauncher("Warning: first app arg index not found, > %d\n", idx); > > + JLI_TraceLauncher("passing arguments as-is.\n"); > > + return NewPlatformStringArray(env, strv, argc); > > + } > > + > > isTool = (idx == 0); > > if (isTool) { idx++; } // skip tool name > > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, > stdargs[idx].arg); > > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 > 08:12:14 2019 +0800 > > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 > 15:11:36 2019 -0500 > > @@ -29,6 +29,7 @@ > > * jdk.jlink > > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > > * @run testng BasicTest > > + * @bug 8234076 > > * @summary Basic test of starting an application as a module > > */ > > > > @@ -40,6 +41,8 @@ > > > > import jdk.test.lib.compiler.CompilerUtils; > > import jdk.test.lib.process.ProcessTools; > > +import jdk.test.lib.process.OutputAnalyzer; > > +import jdk.test.lib.Utils; > > > > import org.testng.annotations.BeforeTest; > > import org.testng.annotations.Test; > > @@ -70,6 +73,8 @@ > > // the module main class > > private static final String MAIN_CLASS = "jdk.test.Main"; > > > > + // for Windows specific launcher tests > > + static final boolean IS_WINDOWS = System.getProperty(" > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=3FmeinWv8eFAn8IWUozJWE2OKKaOP9QUFV75TIpu%2Bjk%3D&reserved=0", > "unknown").startsWith("Windows"); > > > > @BeforeTest > > public void compileTestModule() throws Exception { > > @@ -259,4 +264,87 @@ > > assertTrue(exitValue != 0); > > } > > > > + > > + /** > > + * Helper method that creates a ProcessBuilder with command line > arguments > > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > > + */ > > + private ProcessBuilder createProcessWithLauncherDebugging(String... > cmds) { > > + ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > > + > > + return pb; > > + } > > + > > + /** > > + * Test the ability for the Windows launcher to do proper > application argument > > + * detection and expansion, when using the long form module option > and all passed in > > + * command line arguments are prefixed with a dash. > > + * > > + * These tests are not expected to work on *nixes, and are ignored. > > + */ > > + public void testWindowsWithLongFormModuleOption() throws Exception { > > + if (!IS_WINDOWS) { > > + return; > > + } > > + > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --help > > + // We should be able to find the argument --help as an > application argument > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help"); > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > <...src/test>/*.java --help > > + // We should be able to see argument expansion happen > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + SRC_DIR.resolve(TEST_MODULE).toString() + > "file://*.java", > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help") > > + .shouldContain("module-info.java"); > > + } > > + > > + > > + /** > > + * Test that --module= is terminating for VM argument processing > just like --module > > + */ > > + public void testLongFormModuleOptionTermination() throws Exception { > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS > --module-path=mods --module=$TESTMODULE/$MAINCLASS > > + // The first --module= will terminate the VM arguments > processing. The second pair of module-path and module will be > > + // deemed as application arguments > > + OutputAnalyzer output = ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--module-path=" + dir, > > + "--module=" + mid)) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("argv[ 0] = '--module-path=" + dir) > > + .shouldContain("argv[ 1] = '--module=" + mid); > > + > > + if (IS_WINDOWS) { > > + output.shouldContain("F--module-path=" + > dir).shouldContain("F--module=" + mid); > > + } > > + > > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > > + // This command line will not work as --module= is terminating > and the module will be not found > > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > > + assertTrue(exitValue != 0); > > + } > > } > > > > > > -----Original Message----- > > From: Henry Jen > > Sent: December 6, 2019 12:03 AM > > To: Nikola Grcevski > > Cc: Kumar Srinivasan ; Alan Bateman > ; mailto:mailto: > core-libs-dev at openjdk.java.net > > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > > > > >> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > >> > >> Hello all again! > >> > >> Based on the suggestion by Kumar I made the following small patch to > checkArg src/java.base/share/native/libjli/args.c: > >> > >> --- a/src/java.base/share/native/libjli/args.c > >> +++ b/src/java.base/share/native/libjli/args.c > >> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { > >> } > >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > >> stopExpansion = JNI_TRUE; > >> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { > > > > I would suggest use JLI_StrCCmp as in java.c. I think combine this fix > with origin crash prevention for -1 is a safe approach and most compatible > to current behavior. > > > > BTW, we need the patch to be hosted on > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=iuIbGg8zzbN7EPOUkKuXfzAUknZDXckOdwBX2XhwGrE%3D&reserved=0 > or you can attach the patch to the review thread if you are not yet an > author. > > > > Cheers, > > Henry > > > > > >> + idx = argsCount; > >> } > >> } else { > >> if (!expectingNoDashArg) { > >> > >> The change is in common code and simply checks for the usage of > --module= and deems the next argument as the start of the application > arguments. I can confirm that using -m instead of --module doesn't allow > for the = separator to be used, so we only need to check for --module= if > this is a desired change. > >> > >> I tested with various combinations on the command line and I couldn't > find a set of arguments ordering that breaks the terminating quality of > --module. > >> > >> I also performed series of tests to try to break the argument expansion > on Windows with this change, but it worked in all instances. The testcase > is working correctly with this change, as well as the javac launcher > command as proposed by Kumar (java --module-path=mods > --module=jdk.compiler/com.sun.tools.javac.Main *.java). > >> > >> I ran all the launcher tests on both Windows and Linux and all tests > pass. > >> > >> Please let me know if this is a preferred approach to address this bug > or if you think there's a potential problem with the change. If this is an > acceptable fix I can create new webrev with set of tests for the various > edge cases I tried, and new launcher specific tests that ensure argument > expansion is performed on Windows with this module usage. > >> > >> Thank you, > >> Nikola > >> > >> -----Original Message----- > >> From: Henry Jen > >> Sent: December 4, 2019 8:26 PM > >> To: Kumar Srinivasan ; Alan Bateman > >> ; Nikola Grcevski > >> > >> Cc: mailto:mailto:core-libs-dev at openjdk.java.net > >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >> > >>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan ksrinifmt at gmail.com> wrote: > >>> > >>> Hi Nikola, > >>> > >>> It looks ok to me, I will leave it to Henry and Alan to bless this. > >>> > >>> IMHO: I think we should fix it correctly now than later, I don't > >>> think it is all that difficult AFAICT all the launcher has to do is > >>> identify "--module==", then the next argument is the first index. > >>> > >> > >> I don?t disagree, if we can decide whether ?module= is allowed. Based > on my understanding and the document for java[1], the ?module= is not > necessarily correct. > >> > >> If we decided to accept it, the fix would be make sure the index set > correctly as Kumar suggested, and the fix can be relatively simple. > >> > >> FWIW, it?s still possible the index is NOT_FOUND if there is no main > class specified, but that should never cause crash as if no main class is > found, the launcher should either execute other terminal argument or > display help. > >> > >> I agree the fix is not complete as it only make sure no crash can > happen. It doesn?t actually make ?module= illegal and show help in case of > that. At this point, there is a discrepancy in launcher code regard ?module > usage, and we need to fix that. > >> > >> I?ll let Alan to comment about the ?module option usage. > >> > >> The webrev looks good to me, although I would like to see the test be > more close to other arguments processing test, but since this can only be > reproduced with ?module= usage, I assume this is not bad. > >> > >> [1] > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > >> . > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=362LaE5nipNO0eVmKa%2BmTTwhhBCFfAGdFMFHd%2Bumx4A%3D&reserved=0 > >> &data=02%7C01%7CNikola.Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 > >> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 > >> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY > >> %3D&reserved=0 > >> > >>> Kumar > >>> > >>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > >>> Hi Henry and Kumar, > >>> > >>> Thanks again for your comments! I have updated the test to be part of > test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve > the same amount of testing. I added a new test method inside BasicTest.java > and tested on both Windows and Linux. > >>> > >>> Please find my updated webrev here for your review: > >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc > >>> e > >>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=WMlvgPM2Ixt0WaZiD61ZLjRmSgRL3UDmrNITh7H%2Ft38%3D&reserved=0 > >>> c > >>> evski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 > >>> f > >>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ > >>> % > >>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>> > >>> Cheers, > >>> > >>> Nikola > >>> > >>> -----Original Message----- > >>> From: Henry Jen > >>> Sent: December 3, 2019 11:39 AM > >>> To: Kumar Srinivasan > >>> Cc: Nikola Grcevski ; > Alan Bateman > >>> ; mailto:mailto: > core-libs-dev at openjdk.java.net > >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >>> > >>> Kumar, > >>> > >>> Great to have you look at this, you are correct, this patch doesn?t > address the wildcard expansion issue, but only to address the potential > crash if a main class is not specified as Nikola pointed out. > >>> > >>> We definitely need a follow up to fix wildcard expansion. The pointer > to simplify the test is helpful, it would make the test more obvious. > >>> > >>> Cheers, > >>> Henry > >>> > >>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan ksrinifmt at gmail.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Sorry for chiming in late in the review process, for what it's > worth.... > >>>> > >>>> 1. It is not at all clear to me if this solution is correct, yes it > averts the problem of not finding the main-class > >>>> and subsequent crash, but it does not address wildcard arguments > expansion. > >>>> > >>>> What if we have > >>>> % java --module-path=mods > --module=jdk.compiler/com.sun.tools.javac.Main *.java > >>>> Where jdk.compiler is a java compiler implementation (javac). > >>>> The user would expect the above compiler module to build all the > .java files in that directory, > >>>> and this fix will not address that. > >>>> > >>>> Some background: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > >>>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=QyeJDvywLhjIe02uwSYhV2mI2ERcgOhObjk2lDWF8oQ%3D&reserved=0 > >>>> .Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=mH19URBhYu0rW%2Bpsl91V9e3TcwPD%2BDX0YSNbXao5H8o%3D&reserved=0 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b > >>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 > >>>> Please see all the related bugs in the above JIRA issue. > >>>> > >>>> Paragraph #6 in this interview surmises the wild card behavior on > Windows: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. > >>>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=K1mAbE9L7km1jXGixjKlWpUFsEpSKxwpsi%2Bqby35nlo%3D&reserved=0 > >>>> 2%7C01%7CNikola.Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=%2FUxEEDQrTgIk2Y%2Bd%2FPz67ocYVqRXncW%2FsITD%2BWpemSY%3D&reserved=0 > >>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 > >>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& > >>>> ;reserved=0 > >>>> > >>>> 2. Though the arguments related tests are in Aaarghs.java the modules > related tests for the launcher are at: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg > >>>> . > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=ED1VtZLjyMmo3uRMRQ02rMCeeHrk0HIlQO8mv2tnPKA%3D&reserved=0 > >>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs > >>>> ki% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=HvTbDg9uHe5WDu0OVcH%2BPF5mgYHWv2OUHYAWY2EheFo%3D&reserved=0 > >>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE > >>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 > >>>> Using the modules test framework may make the test simpler. > >>>> > >>>> Kumar Srinivasan > >>>> > >>>> > >>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski Nikola.Grcevski at microsoft.com> wrote: > >>>> Hi Alan and Henry, > >>>> > >>>> Thank you for reviewing my email! Henry's observation matches mine, > the shared common code for all platforms in checkArg > (src/java.base/share/native/libjli/args.c) can potentially leave the > firstAppArgIndex static set to -1, if all passed command line arguments are > prefixed with a dash. Later on the arguments are validated, however we > might crash before then on Windows because of the negative index access. In > this case, the customer command was valid (modules usage) and the program > runs successfully. > >>>> > >>>> I created a webrev here for the change, including a new test in > Arrrghs.java: > >>>> > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr > >>>> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=fi870VNLFmOgySkWY1LJJ2qBSKZkdTaIEW6ytg%2FMHDA%3D&reserved=0 > >>>> .Grcevski% > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=XX0qBV1e5ucqPSL%2B4YciHNXR29evREuIRDFwTSxaqHU%3D&reserved=0 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e > >>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>>> > >>>> I copied the test validation and assertion style of other code inside > the test class. > >>>> > >>>> Please let me know if you have any comments or suggestions. > >>>> > >>>> Thanks again! > >>>> > >>>> -----Original Message----- > >>>> From: Henry Jen > >>>> Sent: December 2, 2019 12:26 PM > >>>> To: Alan Bateman > >>>> Cc: Nikola Grcevski ; > >>>> mailto:mailto:core-libs-dev at openjdk.java.net > >>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > >>>> > >>>> The fix looks reasonable to me, basically, if the command argument > format is not legal, it?s possible we won?t find the main class when doing > argument file expansion, and the index is -1 which could cause crash on > Windows platform for the wildcard processing. > >>>> > >>>> I think we should add a test case for this, probably in > test/jdk/tools/launcher/Arrrghs.java. > >>>> > >>>> As I understand it, the argument validation is done in a later stage > after calling JLI_Launch. > >>>> > >>>> Cheers, > >>>> Henry > >>>> > >>>> > >>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman Alan.Bateman at oracle.com> wrote: > >>>>> > >>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: > >>>>>> : > >>>>>> > >>>>>> Please let me know if this approach is acceptable for the current > bug report and I'll make a webrev and include appropriate launcher tests. I > was thinking the tests should do extra validation on the output from > _JAVA_LAUNCHER_DEBUG on Windows. > >>>>>> > >>>>> I think you're in the right area but I would have expected the arg > index to 0 here. Henry Jen (cc'ed) might have some comments on this. > >>>>> > >>>>> -Alan > From brian.burkhalter at oracle.com Thu Dec 12 00:08:25 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 11 Dec 2019 16:08:25 -0800 Subject: 8235668: LineNumberReader#getLineNumber() returns wrong line number (one fewer) in Lucene test Message-ID: <0B1EABC7-4962-430D-B6F1-0C72516EA22F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8235668 http://cr.openjdk.java.net/~bpb/8235668/webrev.00/ Due to the problems reported in [1], in the interest of not changing longstanding behavior, we would like to revert the fix for [2], despite the fact that it makes the behavior of LineNumberReader more consistent with its specification. An issue [3] was filed to revisit this situation in the future. The changes made to revert BufferedReader were done manually but the other two files were straight reversions to the previous delta. Note that the copyright date ?2019? is removed from the test. Is that correct? Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8235668 [2] https://bugs.openjdk.java.net/browse/JDK-8230342 [3] https://bugs.openjdk.java.net/browse/JDK-8235792 From fujie at loongson.cn Thu Dec 12 01:41:29 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 12 Dec 2019 09:41:29 +0800 Subject: RFR: 8235625: [TESTBUG] tools/jpackage/share/JavaOptionsEqualsTest.java fails with debug VMs In-Reply-To: References: Message-ID: <23cf8e27-e423-8db4-71d8-8bca5888f9ea@loongson.cn> Thanks Andy for your review. Done. Best regards, Jie From igor.ignatyev at oracle.com Thu Dec 12 03:29:17 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 11 Dec 2019 19:29:17 -0800 Subject: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS In-Reply-To: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> References: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> Message-ID: Hi Sergey, overall looks good to me. a question about linux, is there an alternative to gnome-screenshot for DEs other than GNOME? -- Igor > On Dec 11, 2019, at 1:00 AM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 > Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 > > This change adds the "screen capture on the test failure" feature on macOS and Linux. > - On Linux, it is implemented by the "gnome-screenshot" command(in case of > multiscreen+xinerama the whole big screen will be saved to the "screen.png" file). > - On macOS it is implemented by the "screencapture" command, note that I have > used 1 file per screen, if the number of screens less than 5, other files will be ignored. > > -- > Best regards, Sergey. From henry.jen at oracle.com Thu Dec 12 06:29:50 2019 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 11 Dec 2019 22:29:50 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> Message-ID: <5BF0FE41-15AE-4133-9758-941BA063EA1F@oracle.com> Nikola, The change looks fine to me as well, I?ll run the test and push it before RDP1 if everything is good with Kumar as reviewer. Cheers, Henry > On Dec 11, 2019, at 2:26 PM, Kumar Srinivasan wrote: > > Hi Nikola, > > Thank you for making the changes. Looks good to me. > > Kumar Srinivasan > PS: my new and official email address: kusrinivasan at vmware.com > > > On Wed, Dec 11, 2019 at 10:04 AM Nikola Grcevski wrote: > Thank you again for reviewing my code Kumar! > > I have applied your refactoring suggestions. Using the array approach as you suggested made the test code a lot more tidier. I?m attaching the updated patch after my signature and the external webrev is here for reference: > > https://grcevski.github.io/JDK-8234076/webrev/ > > Cheers, > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/share/native/libjli/args.c Wed Dec 11 12:09:29 2019 -0500 > @@ -130,6 +130,8 @@ > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > @@ -449,6 +451,7 @@ > return JLI_StrCmp(arg, "-jar") == 0 || > JLI_StrCmp(arg, "-m") == 0 || > JLI_StrCmp(arg, "--module") == 0 || > + JLI_StrCCmp(arg, "--module=") == 0 || > JLI_StrCmp(arg, "--dry-run") == 0 || > JLI_StrCmp(arg, "-h") == 0 || > JLI_StrCmp(arg, "-?") == 0 || > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c Wed Dec 11 12:09:29 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > > // sanity check, match the args we have, to the holy grail > idx = JLI_GetAppArgIndex(); > + > + // First arg index is NOT_FOUND > + if (idx < 0) { > + // The only allowed value should be NOT_FOUND (-1) unless another change introduces > + // a different negative index > + assert (idx == -1); > + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); > + JLI_TraceLauncher("passing arguments as-is.\n"); > + return NewPlatformStringArray(env, strv, argc); > + } > + > isTool = (idx == 0); > if (isTool) { idx++; } // skip tool name > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java > --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Wed Dec 11 12:09:29 2019 -0500 > @@ -37,6 +37,8 @@ > import java.util.List; > import java.util.Map; > import java.util.regex.Pattern; > +import java.nio.file.Paths; > +import java.nio.file.Path; > > public class ArgsEnvVar extends TestHelper { > private static File testJar = null; > @@ -153,6 +155,7 @@ > List.of("-jar", "test.jar"), > List.of("-m", "test/Foo"), > List.of("--module", "test/Foo"), > + List.of("--module=test/Foo"), > List.of("--dry-run"), > List.of("-h"), > List.of("-?"), > @@ -241,6 +244,69 @@ > verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); > } > > + > + @Test > + // That that we can correctly handle the module longform argument option > + // when supplied in an argument file > + public void modulesInArgsFile() throws IOException { > + File cwd = new File("."); > + File testModuleDir = new File(cwd, "modules_test"); > + > + createEchoArgumentsModule(testModuleDir); > + > + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); > + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); > + > + // test module / main class > + String MODULE_OPTION = "--module=test/launcher.Main"; > + String TEST_MODULE = "test"; > + > + // javac -d mods/test src/test/** > + TestResult tr = doExec( > + javacCmd, > + "-d", MODS_DIR.toString(), > + "--module-source-path", SRC_DIR.toString(), > + "--module", TEST_MODULE); > + > + if (!tr.isOK()) { > + System.out.println("test did not compile"); > + throw new RuntimeException("Error: modules test did not compile"); > + } > + > + // verify the terminating ability of --module= through environment variables > + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); > + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); > + tr = doExec(env, javaCmd); > + tr.checkNegative(); > + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check that specifying --module and --module-path with file works > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); > + tr.contains("[--hello]"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating > + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); > + tr.checkNegative(); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // clean-up > + argFile.delete(); > + argFile1.delete(); > + recursiveDelete(testModuleDir); > + } > + > public static void main(String... args) throws Exception { > init(); > ArgsEnvVar a = new ArgsEnvVar(); > diff -r bd436284147d test/jdk/tools/launcher/TestHelper.java > --- a/test/jdk/tools/launcher/TestHelper.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/TestHelper.java Wed Dec 11 12:09:29 2019 -0500 > @@ -500,6 +500,40 @@ > return Locale.getDefault().getLanguage().equals("en"); > } > > + /** > + * Helper method to initialize a simple module that just prints the passed in arguments > + */ > + static void createEchoArgumentsModule(File modulesDir) throws IOException { > + if (modulesDir.exists()) { > + recursiveDelete(modulesDir); > + } > + > + modulesDir.mkdirs(); > + > + File srcDir = new File(modulesDir, "src"); > + File modsDir = new File(modulesDir, "mods"); > + File testDir = new File(srcDir, "test"); > + File launcherTestDir = new File(testDir, "launcher"); > + srcDir.mkdir(); > + modsDir.mkdir(); > + testDir.mkdir(); > + launcherTestDir.mkdir(); > + > + String[] moduleInfoCode = { "module test {}" }; > + createFile(new File(testDir, "module-info.java"), Arrays.asList(moduleInfoCode)); > + > + String[] moduleCode = { > + "package launcher;", > + "import java.util.Arrays;", > + "public class Main {", > + "public static void main(String[] args) {", > + "System.out.println(Arrays.toString(args));", > + "}", > + "}" > + }; > + createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(moduleCode)); > + } > + > /* > * A class to encapsulate the test results and stuff, with some ease > * of use methods to check the test results. > diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java > --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Wed Dec 11 12:09:29 2019 -0500 > @@ -246,6 +246,10 @@ > if (!tr.contains("Error: Could not find or load main class AbsentClass")) { > throw new RuntimeException("Test Fails"); > } > + > + // Make sure we handle correctly the module long form (--module=) > + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); > + ensureNoWarnings(tr); > } > > void ensureNoWarnings(TestResult tr) { > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Dec 11 12:09:29 2019 -0500 > @@ -29,6 +29,7 @@ > * jdk.jlink > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > * @run testng BasicTest > + * @bug 8234076 > * @summary Basic test of starting an application as a module > */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ > // the module main class > private static final String MAIN_CLASS = "jdk.test.Main"; > > + // for Windows specific launcher tests > + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); > > @BeforeTest > public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ > assertTrue(exitValue != 0); > } > > + > + /** > + * Helper method that creates a ProcessBuilder with command line arguments > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > + */ > + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { > + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > + return pb; > + } > + > + /** > + * Test the ability for the Windows launcher to do proper application argument > + * detection and expansion, when using the long form module option and all passed in > + * command line arguments are prefixed with a dash. > + * > + * These tests are not expected to work on *nixes, and are ignored. > + */ > + public void testWindowsWithLongFormModuleOption() throws Exception { > + if (!IS_WINDOWS) { > + return; > + } > + > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > + // We should be able to find the argument --help as an application argument > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help"); > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help > + // We should be able to see argument expansion happen > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help") > + .shouldContain("module-info.java"); > + } > + > + > + /** > + * Test that --module= is terminating for VM argument processing just like --module > + */ > + public void testLongFormModuleOptionTermination() throws Exception { > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS > + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be > + // deemed as application arguments > + OutputAnalyzer output = ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--module-path=" + dir, > + "--module=" + mid)) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("argv[ 0] = '--module-path=" + dir) > + .shouldContain("argv[ 1] = '--module=" + mid); > + > + if (IS_WINDOWS) { > + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); > + } > + > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > + // This command line will not work as --module= is terminating and the module will be not found > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > + assertTrue(exitValue != 0); > + } > } > > From: Kumar Srinivasan > Sent: December 10, 2019 8:43 PM > To: Nikola Grcevski > Cc: Henry Jen ; Alan Bateman ; core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > [Resend; cc'ing the group] > > Hi Nikola, > > Generally looks great to me. I would have moved initModulesDir to TestHelper.createSimpleModule(File dir). > TestHelper.java contains a collection of test related utilities needed by the launcher, it will help someone > else use it to create a simple module. > > I would have rewritten this > + ArrayList scratchpad = new ArrayList<>(); > + scratchpad.add("module test {}"); > + createFile(new File(testDir, "module-info.java"), scratchpad); > + scratchpad.clear(); > + scratchpad.add("package launcher;"); > + scratchpad.add("import java.util.Arrays;"); > + scratchpad.add("public class Main {"); > + scratchpad.add("public static void main(String[] args) {"); > + scratchpad.add("System.out.println(Arrays.toString(args));"); > + scratchpad.add("}"); > + scratchpad.add("}"); > + createFile(new File(launcherTestDir, "Main.java"), scratchpad); > > as follows: > String a1[] = {"module test{}"}; > createFile(new File(testDir, "module-info.java", Arrays.asList(a1)); > > String a2[] = { > "package launcher;", > .... > .... > } > createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(a2)); > > This might make the code neater. > > Besides that, looks very good. > > Thanks > Kumar > > > On Mon, Dec 9, 2019 at 1:58 PM Nikola Grcevski wrote: > Hi Henry and Kumar, > > Thank you again for the review! I have added the fix to isTerminalOpt and used both of your suggestions to make new tests. > With native memory tracking enabled, I could actually see a crash on both Linux and Windows without the suggested fix. > > I tested the changes again on both Linux and Windows, and the new unit tests fail if isTerminalOpt doesn?t check for ?module= > as per Henry's suggestion. > > I'm attaching the new patch (my apologies for the size) at the bottom of this email after my signature. If I haven't covered > certain aspects in the new tests please let me know, I'm more than happy to extend them further. I've updated the webrev > to reflect the latest patch if it's easier to read: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=XcriPrQ%2B9rypJN6IShAKU2%2Fz5sZE%2BMCWT3gHyVg3Y3s%3D&reserved=0 > > Thanks again! > Nikola > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/share/native/libjli/args.c Mon Dec 09 16:08:54 2019 -0500 > @@ -130,6 +130,8 @@ > } > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > stopExpansion = JNI_TRUE; > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > + idx = argsCount; > } > } else { > if (!expectingNoDashArg) { > @@ -449,6 +451,7 @@ > return JLI_StrCmp(arg, "-jar") == 0 || > JLI_StrCmp(arg, "-m") == 0 || > JLI_StrCmp(arg, "--module") == 0 || > + JLI_StrCCmp(arg, "--module=") == 0 || > JLI_StrCmp(arg, "--dry-run") == 0 || > JLI_StrCmp(arg, "-h") == 0 || > JLI_StrCmp(arg, "-?") == 0 || > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 > +++ b/src/java.base/windows/native/libjli/java_md.c Mon Dec 09 16:08:54 2019 -0500 > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include "java.h" > @@ -1015,6 +1016,17 @@ > > // sanity check, match the args we have, to the holy grail > idx = JLI_GetAppArgIndex(); > + > + // First arg index is NOT_FOUND > + if (idx < 0) { > + // The only allowed value should be NOT_FOUND (-1) unless another change introduces > + // a different negative index > + assert (idx == -1); > + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); > + JLI_TraceLauncher("passing arguments as-is.\n"); > + return NewPlatformStringArray(env, strv, argc); > + } > + > isTool = (idx == 0); > if (isTool) { idx++; } // skip tool name > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); > diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java > --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Mon Dec 09 16:08:54 2019 -0500 > @@ -37,6 +37,8 @@ > import java.util.List; > import java.util.Map; > import java.util.regex.Pattern; > +import java.nio.file.Paths; > +import java.nio.file.Path; > > public class ArgsEnvVar extends TestHelper { > private static File testJar = null; > @@ -153,6 +155,7 @@ > List.of("-jar", "test.jar"), > List.of("-m", "test/Foo"), > List.of("--module", "test/Foo"), > + List.of("--module=test/Foo"), > List.of("--dry-run"), > List.of("-h"), > List.of("-?"), > @@ -241,6 +244,101 @@ > verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); > } > > + /** > + * Helper method to initialize a simple module that just prints the passed in arguments > + */ > + private void initModulesDir(File modulesDir) throws IOException { > + if (modulesDir.exists()) { > + recursiveDelete(modulesDir); > + } > + > + modulesDir.mkdirs(); > + > + File srcDir = new File(modulesDir, "src"); > + File modsDir = new File(modulesDir, "mods"); > + File testDir = new File(srcDir, "test"); > + File launcherTestDir = new File(testDir, "launcher"); > + srcDir.mkdir(); > + modsDir.mkdir(); > + testDir.mkdir(); > + launcherTestDir.mkdir(); > + > + ArrayList scratchpad = new ArrayList<>(); > + scratchpad.add("module test {}"); > + createFile(new File(testDir, "module-info.java"), scratchpad); > + scratchpad.clear(); > + scratchpad.add("package launcher;"); > + scratchpad.add("import java.util.Arrays;"); > + scratchpad.add("public class Main {"); > + scratchpad.add("public static void main(String[] args) {"); > + scratchpad.add("System.out.println(Arrays.toString(args));"); > + scratchpad.add("}"); > + scratchpad.add("}"); > + createFile(new File(launcherTestDir, "Main.java"), scratchpad); > + } > + > + @Test > + // That that we can correctly handle the module longform argument option > + // when supplied in an argument file > + public void modulesInArgsFile() throws IOException { > + File cwd = new File("."); > + File testModuleDir = new File(cwd, "modules_test"); > + > + initModulesDir(testModuleDir); > + > + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); > + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); > + > + // test module / main class > + String MODULE_OPTION = "--module=test/launcher.Main"; > + String TEST_MODULE = "test"; > + > + // javac -d mods/test src/test/** > + TestResult tr = doExec( > + javacCmd, > + "-d", MODS_DIR.toString(), > + "--module-source-path", SRC_DIR.toString(), > + "--module", TEST_MODULE); > + > + if (!tr.isOK()) { > + System.out.println("test did not compile"); > + throw new RuntimeException("Error: modules test did not compile"); > + } > + > + // verify the terminating ability of --module= through environment variables > + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); > + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); > + tr = doExec(env, javaCmd); > + tr.checkNegative(); > + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check that specifying --module and --module-path with file works > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); > + tr.contains("[--hello]"); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating > + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); > + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); > + tr.checkNegative(); > + if (!tr.testStatus) { > + System.out.println(tr); > + throw new RuntimeException("test fails"); > + } > + > + // clean-up > + argFile.delete(); > + argFile1.delete(); > + recursiveDelete(testModuleDir); > + } > + > public static void main(String... args) throws Exception { > init(); > ArgsEnvVar a = new ArgsEnvVar(); > diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java > --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Mon Dec 09 16:08:54 2019 -0500 > @@ -246,6 +246,10 @@ > if (!tr.contains("Error: Could not find or load main class AbsentClass")) { > throw new RuntimeException("Test Fails"); > } > + > + // Make sure we handle correctly the module long form (--module=) > + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); > + ensureNoWarnings(tr); > } > > void ensureNoWarnings(TestResult tr) { > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Mon Dec 09 16:08:54 2019 -0500 > @@ -29,6 +29,7 @@ > * jdk.jlink > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > * @run testng BasicTest > + * @bug 8234076 > * @summary Basic test of starting an application as a module > */ > > @@ -40,6 +41,8 @@ > > import jdk.test.lib.compiler.CompilerUtils; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.process.OutputAnalyzer; > +import jdk.test.lib.Utils; > > import org.testng.annotations.BeforeTest; > import org.testng.annotations.Test; > @@ -70,6 +73,8 @@ > // the module main class > private static final String MAIN_CLASS = "jdk.test.Main"; > > + // for Windows specific launcher tests > + static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=kgi%2B5Ob%2FqX45oTtLSTalwXeQqIct1EUD1k30KOddm5c%3D&reserved=0", "unknown").startsWith("Windows"); > > @BeforeTest > public void compileTestModule() throws Exception { > @@ -259,4 +264,87 @@ > assertTrue(exitValue != 0); > } > > + > + /** > + * Helper method that creates a ProcessBuilder with command line arguments > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > + */ > + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { > + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > + > + return pb; > + } > + > + /** > + * Test the ability for the Windows launcher to do proper application argument > + * detection and expansion, when using the long form module option and all passed in > + * command line arguments are prefixed with a dash. > + * > + * These tests are not expected to work on *nixes, and are ignored. > + */ > + public void testWindowsWithLongFormModuleOption() throws Exception { > + if (!IS_WINDOWS) { > + return; > + } > + > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > + // We should be able to find the argument --help as an application argument > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help"); > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help > + // We should be able to see argument expansion happen > + ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", > + "--help")) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("F--help") > + .shouldContain("module-info.java"); > + } > + > + > + /** > + * Test that --module= is terminating for VM argument processing just like --module > + */ > + public void testLongFormModuleOptionTermination() throws Exception { > + String dir = MODS_DIR.toString(); > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > + > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS > + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be > + // deemed as application arguments > + OutputAnalyzer output = ProcessTools.executeProcess( > + createProcessWithLauncherDebugging( > + "--module-path=" + dir, > + "--module=" + mid, > + "--module-path=" + dir, > + "--module=" + mid)) > + .outputTo(System.out) > + .errorTo(System.out) > + .shouldContain("argv[ 0] = '--module-path=" + dir) > + .shouldContain("argv[ 1] = '--module=" + mid); > + > + if (IS_WINDOWS) { > + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); > + } > + > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > + // This command line will not work as --module= is terminating and the module will be not found > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > + assertTrue(exitValue != 0); > + } > } > > > From: Kumar Srinivasan > Sent: December 7, 2019 10:28 PM > To: Henry Jen > Cc: Nikola Grcevski ; Alan Bateman ; mailto:core-libs-dev at openjdk.java.net > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > Hi, > > The launcher fix looks good, despite the launcher fix being simple, please note, > it sometimes requires a lot more effort to write a test for it, please read on.... > > Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my memory and I recalled > this change for VM's native memory tracking. > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=P3l7Y932pcZ14WwbszC0%2BIN%2BUcS2QrAizwT0Idqa6yQ%3D&reserved=0 > Inspecting the above changeset, we might have to add another test for JVM native memory tracking, > since this is a terminal argument. > > Maybe TestHelper could create a simple module, which prints its args, > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=iaKDsz3aVTdEumV4eOMj5SbA9WtSHT6ADA4KEMoqwgw%3D&reserved=0 > > Kumar Srinivasan > > On Fri, Dec 6, 2019 at 2:44 PM Henry Jen wrote: > Thanks for the work, the test case covers that when ?module= is used before other options, which is good. > > But we need another to make sure that when ?module= is put in an argument file or environment variable, that should not be allowed. The fix is simple, we need to add that to isTerminalOp() method. > > Cheers, > Henry > > > On Dec 6, 2019, at 12:28 PM, Nikola Grcevski wrote: > > > > Thank you Henry! > > > > I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. > > > > I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=KrUiucM4CY4G1aADtTMhHwJxr3e7ATJDMMxX5uG3b14%3D&reserved=0) > > > > Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. > > Nikola > > > > diff -r bd436284147d src/java.base/share/native/libjli/args.c > > --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 > > +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 15:11:36 2019 -0500 > > @@ -130,6 +130,8 @@ > > } > > } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > > stopExpansion = JNI_TRUE; > > + } else if (JLI_StrCCmp(arg, "--module=") == 0) { > > + idx = argsCount; > > } > > } else { > > if (!expectingNoDashArg) { > > diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c > > --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 > > +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 15:11:36 2019 -0500 > > @@ -34,6 +34,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include "java.h" > > @@ -1015,6 +1016,17 @@ > > > > // sanity check, match the args we have, to the holy grail > > idx = JLI_GetAppArgIndex(); > > + > > + // First arg index is NOT_FOUND > > + if (idx < 0) { > > + // The only allowed value should be NOT_FOUND (-1) unless another change introduces > > + // a different negative index > > + assert (idx == -1); > > + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); > > + JLI_TraceLauncher("passing arguments as-is.\n"); > > + return NewPlatformStringArray(env, strv, argc); > > + } > > + > > isTool = (idx == 0); > > if (isTool) { idx++; } // skip tool name > > JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); > > diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java > > --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 > > +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 15:11:36 2019 -0500 > > @@ -29,6 +29,7 @@ > > * jdk.jlink > > * @build BasicTest jdk.test.lib.compiler.CompilerUtils > > * @run testng BasicTest > > + * @bug 8234076 > > * @summary Basic test of starting an application as a module > > */ > > > > @@ -40,6 +41,8 @@ > > > > import jdk.test.lib.compiler.CompilerUtils; > > import jdk.test.lib.process.ProcessTools; > > +import jdk.test.lib.process.OutputAnalyzer; > > +import jdk.test.lib.Utils; > > > > import org.testng.annotations.BeforeTest; > > import org.testng.annotations.Test; > > @@ -70,6 +73,8 @@ > > // the module main class > > private static final String MAIN_CLASS = "jdk.test.Main"; > > > > + // for Windows specific launcher tests > > + static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=3FmeinWv8eFAn8IWUozJWE2OKKaOP9QUFV75TIpu%2Bjk%3D&reserved=0", "unknown").startsWith("Windows"); > > > > @BeforeTest > > public void compileTestModule() throws Exception { > > @@ -259,4 +264,87 @@ > > assertTrue(exitValue != 0); > > } > > > > + > > + /** > > + * Helper method that creates a ProcessBuilder with command line arguments > > + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. > > + */ > > + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { > > + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); > > + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); > > + > > + return pb; > > + } > > + > > + /** > > + * Test the ability for the Windows launcher to do proper application argument > > + * detection and expansion, when using the long form module option and all passed in > > + * command line arguments are prefixed with a dash. > > + * > > + * These tests are not expected to work on *nixes, and are ignored. > > + */ > > + public void testWindowsWithLongFormModuleOption() throws Exception { > > + if (!IS_WINDOWS) { > > + return; > > + } > > + > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help > > + // We should be able to find the argument --help as an application argument > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help"); > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help > > + // We should be able to see argument expansion happen > > + ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", > > + "--help")) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("F--help") > > + .shouldContain("module-info.java"); > > + } > > + > > + > > + /** > > + * Test that --module= is terminating for VM argument processing just like --module > > + */ > > + public void testLongFormModuleOptionTermination() throws Exception { > > + String dir = MODS_DIR.toString(); > > + String mid = TEST_MODULE + "/" + MAIN_CLASS; > > + > > + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS > > + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be > > + // deemed as application arguments > > + OutputAnalyzer output = ProcessTools.executeProcess( > > + createProcessWithLauncherDebugging( > > + "--module-path=" + dir, > > + "--module=" + mid, > > + "--module-path=" + dir, > > + "--module=" + mid)) > > + .outputTo(System.out) > > + .errorTo(System.out) > > + .shouldContain("argv[ 0] = '--module-path=" + dir) > > + .shouldContain("argv[ 1] = '--module=" + mid); > > + > > + if (IS_WINDOWS) { > > + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); > > + } > > + > > + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods > > + // This command line will not work as --module= is terminating and the module will be not found > > + int exitValue = exec("--module=" + mid, "--module-path" + dir); > > + assertTrue(exitValue != 0); > > + } > > } > > > > > > -----Original Message----- > > From: Henry Jen > > Sent: December 6, 2019 12:03 AM > > To: Nikola Grcevski > > Cc: Kumar Srinivasan ; Alan Bateman ; mailto:mailto:core-libs-dev at openjdk.java.net > > Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > > > > > >> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: > >> > >> Hello all again! > >> > >> Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: > >> > >> --- a/src/java.base/share/native/libjli/args.c > >> +++ b/src/java.base/share/native/libjli/args.c > >> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { > >> } > >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { > >> stopExpansion = JNI_TRUE; > >> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { > > > > I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. > > > > BTW, we need the patch to be hosted on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=iuIbGg8zzbN7EPOUkKuXfzAUknZDXckOdwBX2XhwGrE%3D&reserved=0 or you can attach the patch to the review thread if you are not yet an author. > > > > Cheers, > > Henry > > > > > >> + idx = argsCount; > >> } > >> } else { > >> if (!expectingNoDashArg) { > >> > >> The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. > >> > >> I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. > >> > >> I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). > >> > >> I ran all the launcher tests on both Windows and Linux and all tests pass. > >> > >> Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. > >> > >> Thank you, > >> Nikola > >> > >> -----Original Message----- > >> From: Henry Jen > >> Sent: December 4, 2019 8:26 PM > >> To: Kumar Srinivasan ; Alan Bateman > >> ; Nikola Grcevski > >> > >> Cc: mailto:mailto:core-libs-dev at openjdk.java.net > >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >> > >>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: > >>> > >>> Hi Nikola, > >>> > >>> It looks ok to me, I will leave it to Henry and Alan to bless this. > >>> > >>> IMHO: I think we should fix it correctly now than later, I don't > >>> think it is all that difficult AFAICT all the launcher has to do is > >>> identify "--module==", then the next argument is the first index. > >>> > >> > >> I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. > >> > >> If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. > >> > >> FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. > >> > >> I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. > >> > >> I?ll let Alan to comment about the ?module option usage. > >> > >> The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. > >> > >> [1] > >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > >> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=362LaE5nipNO0eVmKa%2BmTTwhhBCFfAGdFMFHd%2Bumx4A%3D&reserved=0 > >> &data=02%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 > >> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 > >> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY > >> %3D&reserved=0 > >> > >>> Kumar > >>> > >>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: > >>> Hi Henry and Kumar, > >>> > >>> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. > >>> > >>> Please find my updated webrev here for your review: > >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc > >>> e > >>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=WMlvgPM2Ixt0WaZiD61ZLjRmSgRL3UDmrNITh7H%2Ft38%3D&reserved=0 > >>> c > >>> evski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 > >>> f > >>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ > >>> % > >>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>> > >>> Cheers, > >>> > >>> Nikola > >>> > >>> -----Original Message----- > >>> From: Henry Jen > >>> Sent: December 3, 2019 11:39 AM > >>> To: Kumar Srinivasan > >>> Cc: Nikola Grcevski ; Alan Bateman > >>> ; mailto:mailto:core-libs-dev at openjdk.java.net > >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate > >>> > >>> Kumar, > >>> > >>> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. > >>> > >>> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. > >>> > >>> Cheers, > >>> Henry > >>> > >>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: > >>>> > >>>> Hi, > >>>> > >>>> Sorry for chiming in late in the review process, for what it's worth.... > >>>> > >>>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class > >>>> and subsequent crash, but it does not address wildcard arguments expansion. > >>>> > >>>> What if we have > >>>> % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java > >>>> Where jdk.compiler is a java compiler implementation (javac). > >>>> The user would expect the above compiler module to build all the .java files in that directory, > >>>> and this fix will not address that. > >>>> > >>>> Some background: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu > >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=QyeJDvywLhjIe02uwSYhV2mI2ERcgOhObjk2lDWF8oQ%3D&reserved=0 > >>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=mH19URBhYu0rW%2Bpsl91V9e3TcwPD%2BDX0YSNbXao5H8o%3D&reserved=0 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b > >>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 > >>>> Please see all the related bugs in the above JIRA issue. > >>>> > >>>> Paragraph #6 in this interview surmises the wild card behavior on Windows: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. > >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=K1mAbE9L7km1jXGixjKlWpUFsEpSKxwpsi%2Bqby35nlo%3D&reserved=0 > >>>> 2%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=%2FUxEEDQrTgIk2Y%2Bd%2FPz67ocYVqRXncW%2FsITD%2BWpemSY%3D&reserved=0 > >>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 > >>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& > >>>> ;reserved=0 > >>>> > >>>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg > >>>> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=ED1VtZLjyMmo3uRMRQ02rMCeeHrk0HIlQO8mv2tnPKA%3D&reserved=0 > >>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs > >>>> ki%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=HvTbDg9uHe5WDu0OVcH%2BPF5mgYHWv2OUHYAWY2EheFo%3D&reserved=0 > >>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE > >>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 > >>>> Using the modules test framework may make the test simpler. > >>>> > >>>> Kumar Srinivasan > >>>> > >>>> > >>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: > >>>> Hi Alan and Henry, > >>>> > >>>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. > >>>> > >>>> I created a webrev here for the change, including a new test in Arrrghs.java: > >>>> > >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr > >>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=fi870VNLFmOgySkWY1LJJ2qBSKZkdTaIEW6ytg%2FMHDA%3D&reserved=0 > >>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=XX0qBV1e5ucqPSL%2B4YciHNXR29evREuIRDFwTSxaqHU%3D&reserved=0 > >>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e > >>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 > >>>> > >>>> I copied the test validation and assertion style of other code inside the test class. > >>>> > >>>> Please let me know if you have any comments or suggestions. > >>>> > >>>> Thanks again! > >>>> > >>>> -----Original Message----- > >>>> From: Henry Jen > >>>> Sent: December 2, 2019 12:26 PM > >>>> To: Alan Bateman > >>>> Cc: Nikola Grcevski ; > >>>> mailto:mailto:core-libs-dev at openjdk.java.net > >>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate > >>>> > >>>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. > >>>> > >>>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. > >>>> > >>>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. > >>>> > >>>> Cheers, > >>>> Henry > >>>> > >>>> > >>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: > >>>>> > >>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: > >>>>>> : > >>>>>> > >>>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. > >>>>>> > >>>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. > >>>>> > >>>>> -Alan From henry.jen at oracle.com Thu Dec 12 08:03:55 2019 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 12 Dec 2019 00:03:55 -0800 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: <5BF0FE41-15AE-4133-9758-941BA063EA1F@oracle.com> References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> <5BF0FE41-15AE-4133-9758-941BA063EA1F@oracle.com> Message-ID: <9C342309-FCEA-4446-AE14-C619C811D2C1@oracle.com> The quote is causing test failure on Mac, I?ll apply following fix diff --git a/test/jdk/tools/launcher/ArgsEnvVar.java b/test/jdk/tools/launcher/ArgsEnvVar.java --- a/test/jdk/tools/launcher/ArgsEnvVar.java +++ b/test/jdk/tools/launcher/ArgsEnvVar.java @@ -285,7 +285,7 @@ } // check that specifying --module and --module-path with file works - tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "@cmdargs"); tr.contains("[--hello]"); if (!tr.testStatus) { System.out.println(tr); @@ -294,7 +294,7 @@ // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); - tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "@cmdargs1"); tr.checkNegative(); if (!tr.testStatus) { System.out.println(tr); Cheers, Henry > On Dec 11, 2019, at 10:29 PM, Henry Jen wrote: > > Nikola, > > The change looks fine to me as well, I?ll run the test and push it before RDP1 if everything is good with Kumar as reviewer. > > Cheers, > Henry > > >> On Dec 11, 2019, at 2:26 PM, Kumar Srinivasan wrote: >> >> Hi Nikola, >> >> Thank you for making the changes. Looks good to me. >> >> Kumar Srinivasan >> PS: my new and official email address: kusrinivasan at vmware.com >> >> >> On Wed, Dec 11, 2019 at 10:04 AM Nikola Grcevski wrote: >> Thank you again for reviewing my code Kumar! >> >> I have applied your refactoring suggestions. Using the array approach as you suggested made the test code a lot more tidier. I?m attaching the updated patch after my signature and the external webrev is here for reference: >> >> https://grcevski.github.io/JDK-8234076/webrev/ >> >> Cheers, >> Nikola >> >> diff -r bd436284147d src/java.base/share/native/libjli/args.c >> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/share/native/libjli/args.c Wed Dec 11 12:09:29 2019 -0500 >> @@ -130,6 +130,8 @@ >> } >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >> stopExpansion = JNI_TRUE; >> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >> + idx = argsCount; >> } >> } else { >> if (!expectingNoDashArg) { >> @@ -449,6 +451,7 @@ >> return JLI_StrCmp(arg, "-jar") == 0 || >> JLI_StrCmp(arg, "-m") == 0 || >> JLI_StrCmp(arg, "--module") == 0 || >> + JLI_StrCCmp(arg, "--module=") == 0 || >> JLI_StrCmp(arg, "--dry-run") == 0 || >> JLI_StrCmp(arg, "-h") == 0 || >> JLI_StrCmp(arg, "-?") == 0 || >> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/windows/native/libjli/java_md.c Wed Dec 11 12:09:29 2019 -0500 >> @@ -34,6 +34,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include "java.h" >> @@ -1015,6 +1016,17 @@ >> >> // sanity check, match the args we have, to the holy grail >> idx = JLI_GetAppArgIndex(); >> + >> + // First arg index is NOT_FOUND >> + if (idx < 0) { >> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >> + // a different negative index >> + assert (idx == -1); >> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >> + JLI_TraceLauncher("passing arguments as-is.\n"); >> + return NewPlatformStringArray(env, strv, argc); >> + } >> + >> isTool = (idx == 0); >> if (isTool) { idx++; } // skip tool name >> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >> diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java >> --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -37,6 +37,8 @@ >> import java.util.List; >> import java.util.Map; >> import java.util.regex.Pattern; >> +import java.nio.file.Paths; >> +import java.nio.file.Path; >> >> public class ArgsEnvVar extends TestHelper { >> private static File testJar = null; >> @@ -153,6 +155,7 @@ >> List.of("-jar", "test.jar"), >> List.of("-m", "test/Foo"), >> List.of("--module", "test/Foo"), >> + List.of("--module=test/Foo"), >> List.of("--dry-run"), >> List.of("-h"), >> List.of("-?"), >> @@ -241,6 +244,69 @@ >> verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); >> } >> >> + >> + @Test >> + // That that we can correctly handle the module longform argument option >> + // when supplied in an argument file >> + public void modulesInArgsFile() throws IOException { >> + File cwd = new File("."); >> + File testModuleDir = new File(cwd, "modules_test"); >> + >> + createEchoArgumentsModule(testModuleDir); >> + >> + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); >> + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); >> + >> + // test module / main class >> + String MODULE_OPTION = "--module=test/launcher.Main"; >> + String TEST_MODULE = "test"; >> + >> + // javac -d mods/test src/test/** >> + TestResult tr = doExec( >> + javacCmd, >> + "-d", MODS_DIR.toString(), >> + "--module-source-path", SRC_DIR.toString(), >> + "--module", TEST_MODULE); >> + >> + if (!tr.isOK()) { >> + System.out.println("test did not compile"); >> + throw new RuntimeException("Error: modules test did not compile"); >> + } >> + >> + // verify the terminating ability of --module= through environment variables >> + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); >> + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); >> + tr = doExec(env, javaCmd); >> + tr.checkNegative(); >> + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check that specifying --module and --module-path with file works >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); >> + tr.contains("[--hello]"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating >> + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); >> + tr.checkNegative(); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // clean-up >> + argFile.delete(); >> + argFile1.delete(); >> + recursiveDelete(testModuleDir); >> + } >> + >> public static void main(String... args) throws Exception { >> init(); >> ArgsEnvVar a = new ArgsEnvVar(); >> diff -r bd436284147d test/jdk/tools/launcher/TestHelper.java >> --- a/test/jdk/tools/launcher/TestHelper.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestHelper.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -500,6 +500,40 @@ >> return Locale.getDefault().getLanguage().equals("en"); >> } >> >> + /** >> + * Helper method to initialize a simple module that just prints the passed in arguments >> + */ >> + static void createEchoArgumentsModule(File modulesDir) throws IOException { >> + if (modulesDir.exists()) { >> + recursiveDelete(modulesDir); >> + } >> + >> + modulesDir.mkdirs(); >> + >> + File srcDir = new File(modulesDir, "src"); >> + File modsDir = new File(modulesDir, "mods"); >> + File testDir = new File(srcDir, "test"); >> + File launcherTestDir = new File(testDir, "launcher"); >> + srcDir.mkdir(); >> + modsDir.mkdir(); >> + testDir.mkdir(); >> + launcherTestDir.mkdir(); >> + >> + String[] moduleInfoCode = { "module test {}" }; >> + createFile(new File(testDir, "module-info.java"), Arrays.asList(moduleInfoCode)); >> + >> + String[] moduleCode = { >> + "package launcher;", >> + "import java.util.Arrays;", >> + "public class Main {", >> + "public static void main(String[] args) {", >> + "System.out.println(Arrays.toString(args));", >> + "}", >> + "}" >> + }; >> + createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(moduleCode)); >> + } >> + >> /* >> * A class to encapsulate the test results and stuff, with some ease >> * of use methods to check the test results. >> diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java >> --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -246,6 +246,10 @@ >> if (!tr.contains("Error: Could not find or load main class AbsentClass")) { >> throw new RuntimeException("Test Fails"); >> } >> + >> + // Make sure we handle correctly the module long form (--module=) >> + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); >> + ensureNoWarnings(tr); >> } >> >> void ensureNoWarnings(TestResult tr) { >> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -29,6 +29,7 @@ >> * jdk.jlink >> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >> * @run testng BasicTest >> + * @bug 8234076 >> * @summary Basic test of starting an application as a module >> */ >> >> @@ -40,6 +41,8 @@ >> >> import jdk.test.lib.compiler.CompilerUtils; >> import jdk.test.lib.process.ProcessTools; >> +import jdk.test.lib.process.OutputAnalyzer; >> +import jdk.test.lib.Utils; >> >> import org.testng.annotations.BeforeTest; >> import org.testng.annotations.Test; >> @@ -70,6 +73,8 @@ >> // the module main class >> private static final String MAIN_CLASS = "jdk.test.Main"; >> >> + // for Windows specific launcher tests >> + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); >> >> @BeforeTest >> public void compileTestModule() throws Exception { >> @@ -259,4 +264,87 @@ >> assertTrue(exitValue != 0); >> } >> >> + >> + /** >> + * Helper method that creates a ProcessBuilder with command line arguments >> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >> + */ >> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >> + >> + return pb; >> + } >> + >> + /** >> + * Test the ability for the Windows launcher to do proper application argument >> + * detection and expansion, when using the long form module option and all passed in >> + * command line arguments are prefixed with a dash. >> + * >> + * These tests are not expected to work on *nixes, and are ignored. >> + */ >> + public void testWindowsWithLongFormModuleOption() throws Exception { >> + if (!IS_WINDOWS) { >> + return; >> + } >> + >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >> + // We should be able to find the argument --help as an application argument >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help"); >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >> + // We should be able to see argument expansion happen >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help") >> + .shouldContain("module-info.java"); >> + } >> + >> + >> + /** >> + * Test that --module= is terminating for VM argument processing just like --module >> + */ >> + public void testLongFormModuleOptionTermination() throws Exception { >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >> + // deemed as application arguments >> + OutputAnalyzer output = ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--module-path=" + dir, >> + "--module=" + mid)) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("argv[ 0] = '--module-path=" + dir) >> + .shouldContain("argv[ 1] = '--module=" + mid); >> + >> + if (IS_WINDOWS) { >> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >> + } >> + >> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >> + // This command line will not work as --module= is terminating and the module will be not found >> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >> + assertTrue(exitValue != 0); >> + } >> } >> >> From: Kumar Srinivasan >> Sent: December 10, 2019 8:43 PM >> To: Nikola Grcevski >> Cc: Henry Jen ; Alan Bateman ; core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> [Resend; cc'ing the group] >> >> Hi Nikola, >> >> Generally looks great to me. I would have moved initModulesDir to TestHelper.createSimpleModule(File dir). >> TestHelper.java contains a collection of test related utilities needed by the launcher, it will help someone >> else use it to create a simple module. >> >> I would have rewritten this >> + ArrayList scratchpad = new ArrayList<>(); >> + scratchpad.add("module test {}"); >> + createFile(new File(testDir, "module-info.java"), scratchpad); >> + scratchpad.clear(); >> + scratchpad.add("package launcher;"); >> + scratchpad.add("import java.util.Arrays;"); >> + scratchpad.add("public class Main {"); >> + scratchpad.add("public static void main(String[] args) {"); >> + scratchpad.add("System.out.println(Arrays.toString(args));"); >> + scratchpad.add("}"); >> + scratchpad.add("}"); >> + createFile(new File(launcherTestDir, "Main.java"), scratchpad); >> >> as follows: >> String a1[] = {"module test{}"}; >> createFile(new File(testDir, "module-info.java", Arrays.asList(a1)); >> >> String a2[] = { >> "package launcher;", >> .... >> .... >> } >> createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(a2)); >> >> This might make the code neater. >> >> Besides that, looks very good. >> >> Thanks >> Kumar >> >> >> On Mon, Dec 9, 2019 at 1:58 PM Nikola Grcevski wrote: >> Hi Henry and Kumar, >> >> Thank you again for the review! I have added the fix to isTerminalOpt and used both of your suggestions to make new tests. >> With native memory tracking enabled, I could actually see a crash on both Linux and Windows without the suggested fix. >> >> I tested the changes again on both Linux and Windows, and the new unit tests fail if isTerminalOpt doesn?t check for ?module= >> as per Henry's suggestion. >> >> I'm attaching the new patch (my apologies for the size) at the bottom of this email after my signature. If I haven't covered >> certain aspects in the new tests please let me know, I'm more than happy to extend them further. I've updated the webrev >> to reflect the latest patch if it's easier to read: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=XcriPrQ%2B9rypJN6IShAKU2%2Fz5sZE%2BMCWT3gHyVg3Y3s%3D&reserved=0 >> >> Thanks again! >> Nikola >> >> diff -r bd436284147d src/java.base/share/native/libjli/args.c >> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/share/native/libjli/args.c Mon Dec 09 16:08:54 2019 -0500 >> @@ -130,6 +130,8 @@ >> } >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >> stopExpansion = JNI_TRUE; >> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >> + idx = argsCount; >> } >> } else { >> if (!expectingNoDashArg) { >> @@ -449,6 +451,7 @@ >> return JLI_StrCmp(arg, "-jar") == 0 || >> JLI_StrCmp(arg, "-m") == 0 || >> JLI_StrCmp(arg, "--module") == 0 || >> + JLI_StrCCmp(arg, "--module=") == 0 || >> JLI_StrCmp(arg, "--dry-run") == 0 || >> JLI_StrCmp(arg, "-h") == 0 || >> JLI_StrCmp(arg, "-?") == 0 || >> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/windows/native/libjli/java_md.c Mon Dec 09 16:08:54 2019 -0500 >> @@ -34,6 +34,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include "java.h" >> @@ -1015,6 +1016,17 @@ >> >> // sanity check, match the args we have, to the holy grail >> idx = JLI_GetAppArgIndex(); >> + >> + // First arg index is NOT_FOUND >> + if (idx < 0) { >> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >> + // a different negative index >> + assert (idx == -1); >> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >> + JLI_TraceLauncher("passing arguments as-is.\n"); >> + return NewPlatformStringArray(env, strv, argc); >> + } >> + >> isTool = (idx == 0); >> if (isTool) { idx++; } // skip tool name >> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >> diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java >> --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -37,6 +37,8 @@ >> import java.util.List; >> import java.util.Map; >> import java.util.regex.Pattern; >> +import java.nio.file.Paths; >> +import java.nio.file.Path; >> >> public class ArgsEnvVar extends TestHelper { >> private static File testJar = null; >> @@ -153,6 +155,7 @@ >> List.of("-jar", "test.jar"), >> List.of("-m", "test/Foo"), >> List.of("--module", "test/Foo"), >> + List.of("--module=test/Foo"), >> List.of("--dry-run"), >> List.of("-h"), >> List.of("-?"), >> @@ -241,6 +244,101 @@ >> verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); >> } >> >> + /** >> + * Helper method to initialize a simple module that just prints the passed in arguments >> + */ >> + private void initModulesDir(File modulesDir) throws IOException { >> + if (modulesDir.exists()) { >> + recursiveDelete(modulesDir); >> + } >> + >> + modulesDir.mkdirs(); >> + >> + File srcDir = new File(modulesDir, "src"); >> + File modsDir = new File(modulesDir, "mods"); >> + File testDir = new File(srcDir, "test"); >> + File launcherTestDir = new File(testDir, "launcher"); >> + srcDir.mkdir(); >> + modsDir.mkdir(); >> + testDir.mkdir(); >> + launcherTestDir.mkdir(); >> + >> + ArrayList scratchpad = new ArrayList<>(); >> + scratchpad.add("module test {}"); >> + createFile(new File(testDir, "module-info.java"), scratchpad); >> + scratchpad.clear(); >> + scratchpad.add("package launcher;"); >> + scratchpad.add("import java.util.Arrays;"); >> + scratchpad.add("public class Main {"); >> + scratchpad.add("public static void main(String[] args) {"); >> + scratchpad.add("System.out.println(Arrays.toString(args));"); >> + scratchpad.add("}"); >> + scratchpad.add("}"); >> + createFile(new File(launcherTestDir, "Main.java"), scratchpad); >> + } >> + >> + @Test >> + // That that we can correctly handle the module longform argument option >> + // when supplied in an argument file >> + public void modulesInArgsFile() throws IOException { >> + File cwd = new File("."); >> + File testModuleDir = new File(cwd, "modules_test"); >> + >> + initModulesDir(testModuleDir); >> + >> + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); >> + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); >> + >> + // test module / main class >> + String MODULE_OPTION = "--module=test/launcher.Main"; >> + String TEST_MODULE = "test"; >> + >> + // javac -d mods/test src/test/** >> + TestResult tr = doExec( >> + javacCmd, >> + "-d", MODS_DIR.toString(), >> + "--module-source-path", SRC_DIR.toString(), >> + "--module", TEST_MODULE); >> + >> + if (!tr.isOK()) { >> + System.out.println("test did not compile"); >> + throw new RuntimeException("Error: modules test did not compile"); >> + } >> + >> + // verify the terminating ability of --module= through environment variables >> + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); >> + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); >> + tr = doExec(env, javaCmd); >> + tr.checkNegative(); >> + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check that specifying --module and --module-path with file works >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); >> + tr.contains("[--hello]"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating >> + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); >> + tr.checkNegative(); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // clean-up >> + argFile.delete(); >> + argFile1.delete(); >> + recursiveDelete(testModuleDir); >> + } >> + >> public static void main(String... args) throws Exception { >> init(); >> ArgsEnvVar a = new ArgsEnvVar(); >> diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java >> --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -246,6 +246,10 @@ >> if (!tr.contains("Error: Could not find or load main class AbsentClass")) { >> throw new RuntimeException("Test Fails"); >> } >> + >> + // Make sure we handle correctly the module long form (--module=) >> + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); >> + ensureNoWarnings(tr); >> } >> >> void ensureNoWarnings(TestResult tr) { >> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -29,6 +29,7 @@ >> * jdk.jlink >> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >> * @run testng BasicTest >> + * @bug 8234076 >> * @summary Basic test of starting an application as a module >> */ >> >> @@ -40,6 +41,8 @@ >> >> import jdk.test.lib.compiler.CompilerUtils; >> import jdk.test.lib.process.ProcessTools; >> +import jdk.test.lib.process.OutputAnalyzer; >> +import jdk.test.lib.Utils; >> >> import org.testng.annotations.BeforeTest; >> import org.testng.annotations.Test; >> @@ -70,6 +73,8 @@ >> // the module main class >> private static final String MAIN_CLASS = "jdk.test.Main"; >> >> + // for Windows specific launcher tests >> + static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824589979&sdata=kgi%2B5Ob%2FqX45oTtLSTalwXeQqIct1EUD1k30KOddm5c%3D&reserved=0", "unknown").startsWith("Windows"); >> >> @BeforeTest >> public void compileTestModule() throws Exception { >> @@ -259,4 +264,87 @@ >> assertTrue(exitValue != 0); >> } >> >> + >> + /** >> + * Helper method that creates a ProcessBuilder with command line arguments >> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >> + */ >> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >> + >> + return pb; >> + } >> + >> + /** >> + * Test the ability for the Windows launcher to do proper application argument >> + * detection and expansion, when using the long form module option and all passed in >> + * command line arguments are prefixed with a dash. >> + * >> + * These tests are not expected to work on *nixes, and are ignored. >> + */ >> + public void testWindowsWithLongFormModuleOption() throws Exception { >> + if (!IS_WINDOWS) { >> + return; >> + } >> + >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >> + // We should be able to find the argument --help as an application argument >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help"); >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >> + // We should be able to see argument expansion happen >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help") >> + .shouldContain("module-info.java"); >> + } >> + >> + >> + /** >> + * Test that --module= is terminating for VM argument processing just like --module >> + */ >> + public void testLongFormModuleOptionTermination() throws Exception { >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >> + // deemed as application arguments >> + OutputAnalyzer output = ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--module-path=" + dir, >> + "--module=" + mid)) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("argv[ 0] = '--module-path=" + dir) >> + .shouldContain("argv[ 1] = '--module=" + mid); >> + >> + if (IS_WINDOWS) { >> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >> + } >> + >> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >> + // This command line will not work as --module= is terminating and the module will be not found >> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >> + assertTrue(exitValue != 0); >> + } >> } >> >> >> From: Kumar Srinivasan >> Sent: December 7, 2019 10:28 PM >> To: Henry Jen >> Cc: Nikola Grcevski ; Alan Bateman ; mailto:core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> Hi, >> >> The launcher fix looks good, despite the launcher fix being simple, please note, >> it sometimes requires a lot more effort to write a test for it, please read on.... >> >> Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my memory and I recalled >> this change for VM's native memory tracking. >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=P3l7Y932pcZ14WwbszC0%2BIN%2BUcS2QrAizwT0Idqa6yQ%3D&reserved=0 >> Inspecting the above changeset, we might have to add another test for JVM native memory tracking, >> since this is a terminal argument. >> >> Maybe TestHelper could create a simple module, which prints its args, >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824599960&sdata=iaKDsz3aVTdEumV4eOMj5SbA9WtSHT6ADA4KEMoqwgw%3D&reserved=0 >> >> Kumar Srinivasan >> >> On Fri, Dec 6, 2019 at 2:44 PM Henry Jen wrote: >> Thanks for the work, the test case covers that when ?module= is used before other options, which is good. >> >> But we need another to make sure that when ?module= is put in an argument file or environment variable, that should not be allowed. The fix is simple, we need to add that to isTerminalOp() method. >> >> Cheers, >> Henry >> >>> On Dec 6, 2019, at 12:28 PM, Nikola Grcevski wrote: >>> >>> Thank you Henry! >>> >>> I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. >>> >>> I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=KrUiucM4CY4G1aADtTMhHwJxr3e7ATJDMMxX5uG3b14%3D&reserved=0) >>> >>> Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. >>> Nikola >>> >>> diff -r bd436284147d src/java.base/share/native/libjli/args.c >>> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 15:11:36 2019 -0500 >>> @@ -130,6 +130,8 @@ >>> } >>> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>> stopExpansion = JNI_TRUE; >>> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >>> + idx = argsCount; >>> } >>> } else { >>> if (!expectingNoDashArg) { >>> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >>> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 15:11:36 2019 -0500 >>> @@ -34,6 +34,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #include >>> #include "java.h" >>> @@ -1015,6 +1016,17 @@ >>> >>> // sanity check, match the args we have, to the holy grail >>> idx = JLI_GetAppArgIndex(); >>> + >>> + // First arg index is NOT_FOUND >>> + if (idx < 0) { >>> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >>> + // a different negative index >>> + assert (idx == -1); >>> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >>> + JLI_TraceLauncher("passing arguments as-is.\n"); >>> + return NewPlatformStringArray(env, strv, argc); >>> + } >>> + >>> isTool = (idx == 0); >>> if (isTool) { idx++; } // skip tool name >>> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >>> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >>> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 15:11:36 2019 -0500 >>> @@ -29,6 +29,7 @@ >>> * jdk.jlink >>> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >>> * @run testng BasicTest >>> + * @bug 8234076 >>> * @summary Basic test of starting an application as a module >>> */ >>> >>> @@ -40,6 +41,8 @@ >>> >>> import jdk.test.lib.compiler.CompilerUtils; >>> import jdk.test.lib.process.ProcessTools; >>> +import jdk.test.lib.process.OutputAnalyzer; >>> +import jdk.test.lib.Utils; >>> >>> import org.testng.annotations.BeforeTest; >>> import org.testng.annotations.Test; >>> @@ -70,6 +73,8 @@ >>> // the module main class >>> private static final String MAIN_CLASS = "jdk.test.Main"; >>> >>> + // for Windows specific launcher tests >>> + static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824609890&sdata=3FmeinWv8eFAn8IWUozJWE2OKKaOP9QUFV75TIpu%2Bjk%3D&reserved=0", "unknown").startsWith("Windows"); >>> >>> @BeforeTest >>> public void compileTestModule() throws Exception { >>> @@ -259,4 +264,87 @@ >>> assertTrue(exitValue != 0); >>> } >>> >>> + >>> + /** >>> + * Helper method that creates a ProcessBuilder with command line arguments >>> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >>> + */ >>> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >>> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >>> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >>> + >>> + return pb; >>> + } >>> + >>> + /** >>> + * Test the ability for the Windows launcher to do proper application argument >>> + * detection and expansion, when using the long form module option and all passed in >>> + * command line arguments are prefixed with a dash. >>> + * >>> + * These tests are not expected to work on *nixes, and are ignored. >>> + */ >>> + public void testWindowsWithLongFormModuleOption() throws Exception { >>> + if (!IS_WINDOWS) { >>> + return; >>> + } >>> + >>> + String dir = MODS_DIR.toString(); >>> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >>> + // We should be able to find the argument --help as an application argument >>> + ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + "--help")) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("F--help"); >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >>> + // We should be able to see argument expansion happen >>> + ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", >>> + "--help")) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("F--help") >>> + .shouldContain("module-info.java"); >>> + } >>> + >>> + >>> + /** >>> + * Test that --module= is terminating for VM argument processing just like --module >>> + */ >>> + public void testLongFormModuleOptionTermination() throws Exception { >>> + String dir = MODS_DIR.toString(); >>> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >>> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >>> + // deemed as application arguments >>> + OutputAnalyzer output = ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + "--module-path=" + dir, >>> + "--module=" + mid)) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("argv[ 0] = '--module-path=" + dir) >>> + .shouldContain("argv[ 1] = '--module=" + mid); >>> + >>> + if (IS_WINDOWS) { >>> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >>> + } >>> + >>> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >>> + // This command line will not work as --module= is terminating and the module will be not found >>> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >>> + assertTrue(exitValue != 0); >>> + } >>> } >>> >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 6, 2019 12:03 AM >>> To: Nikola Grcevski >>> Cc: Kumar Srinivasan ; Alan Bateman ; mailto:mailto:core-libs-dev at openjdk.java.net >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>> >>> >>>> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: >>>> >>>> Hello all again! >>>> >>>> Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: >>>> >>>> --- a/src/java.base/share/native/libjli/args.c >>>> +++ b/src/java.base/share/native/libjli/args.c >>>> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { >>>> } >>>> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>>> stopExpansion = JNI_TRUE; >>>> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { >>> >>> I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. >>> >>> BTW, we need the patch to be hosted on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=iuIbGg8zzbN7EPOUkKuXfzAUknZDXckOdwBX2XhwGrE%3D&reserved=0 or you can attach the patch to the review thread if you are not yet an author. >>> >>> Cheers, >>> Henry >>> >>> >>>> + idx = argsCount; >>>> } >>>> } else { >>>> if (!expectingNoDashArg) { >>>> >>>> The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. >>>> >>>> I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. >>>> >>>> I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). >>>> >>>> I ran all the launcher tests on both Windows and Linux and all tests pass. >>>> >>>> Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. >>>> >>>> Thank you, >>>> Nikola >>>> >>>> -----Original Message----- >>>> From: Henry Jen >>>> Sent: December 4, 2019 8:26 PM >>>> To: Kumar Srinivasan ; Alan Bateman >>>> ; Nikola Grcevski >>>> >>>> Cc: mailto:mailto:core-libs-dev at openjdk.java.net >>>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>>> >>>>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >>>>> >>>>> Hi Nikola, >>>>> >>>>> It looks ok to me, I will leave it to Henry and Alan to bless this. >>>>> >>>>> IMHO: I think we should fix it correctly now than later, I don't >>>>> think it is all that difficult AFAICT all the launcher has to do is >>>>> identify "--module==", then the next argument is the first index. >>>>> >>>> >>>> I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. >>>> >>>> If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. >>>> >>>> FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. >>>> >>>> I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. >>>> >>>> I?ll let Alan to comment about the ?module option usage. >>>> >>>> The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. >>>> >>>> [1] >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs >>>> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824619848&sdata=362LaE5nipNO0eVmKa%2BmTTwhhBCFfAGdFMFHd%2Bumx4A%3D&reserved=0 >>>> &data=02%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >>>> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 >>>> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY >>>> %3D&reserved=0 >>>> >>>>> Kumar >>>>> >>>>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >>>>> Hi Henry and Kumar, >>>>> >>>>> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >>>>> >>>>> Please find my updated webrev here for your review: >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc >>>>> e >>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=WMlvgPM2Ixt0WaZiD61ZLjRmSgRL3UDmrNITh7H%2Ft38%3D&reserved=0 >>>>> c >>>>> evski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >>>>> f >>>>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ >>>>> % >>>>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>>> >>>>> Cheers, >>>>> >>>>> Nikola >>>>> >>>>> -----Original Message----- >>>>> From: Henry Jen >>>>> Sent: December 3, 2019 11:39 AM >>>>> To: Kumar Srinivasan >>>>> Cc: Nikola Grcevski ; Alan Bateman >>>>> ; mailto:mailto:core-libs-dev at openjdk.java.net >>>>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>>>> >>>>> Kumar, >>>>> >>>>> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >>>>> >>>>> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Sorry for chiming in late in the review process, for what it's worth.... >>>>>> >>>>>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>>>>> and subsequent crash, but it does not address wildcard arguments expansion. >>>>>> >>>>>> What if we have >>>>>> % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>>>>> Where jdk.compiler is a java compiler implementation (javac). >>>>>> The user would expect the above compiler module to build all the .java files in that directory, >>>>>> and this fix will not address that. >>>>>> >>>>>> Some background: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=QyeJDvywLhjIe02uwSYhV2mI2ERcgOhObjk2lDWF8oQ%3D&reserved=0 >>>>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=mH19URBhYu0rW%2Bpsl91V9e3TcwPD%2BDX0YSNbXao5H8o%3D&reserved=0 >>>>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>>>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>>>>> Please see all the related bugs in the above JIRA issue. >>>>>> >>>>>> Paragraph #6 in this interview surmises the wild card behavior on Windows: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=K1mAbE9L7km1jXGixjKlWpUFsEpSKxwpsi%2Bqby35nlo%3D&reserved=0 >>>>>> 2%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=%2FUxEEDQrTgIk2Y%2Bd%2FPz67ocYVqRXncW%2FsITD%2BWpemSY%3D&reserved=0 >>>>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>>>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>>>>> ;reserved=0 >>>>>> >>>>>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>>>>> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=ED1VtZLjyMmo3uRMRQ02rMCeeHrk0HIlQO8mv2tnPKA%3D&reserved=0 >>>>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>>>>> ki%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=HvTbDg9uHe5WDu0OVcH%2BPF5mgYHWv2OUHYAWY2EheFo%3D&reserved=0 >>>>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>>>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>>>>> Using the modules test framework may make the test simpler. >>>>>> >>>>>> Kumar Srinivasan >>>>>> >>>>>> >>>>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>>>>> Hi Alan and Henry, >>>>>> >>>>>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>>>>> >>>>>> I created a webrev here for the change, including a new test in Arrrghs.java: >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=fi870VNLFmOgySkWY1LJJ2qBSKZkdTaIEW6ytg%2FMHDA%3D&reserved=0 >>>>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=XX0qBV1e5ucqPSL%2B4YciHNXR29evREuIRDFwTSxaqHU%3D&reserved=0 >>>>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>>>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>>>> >>>>>> I copied the test validation and assertion style of other code inside the test class. >>>>>> >>>>>> Please let me know if you have any comments or suggestions. >>>>>> >>>>>> Thanks again! >>>>>> >>>>>> -----Original Message----- >>>>>> From: Henry Jen >>>>>> Sent: December 2, 2019 12:26 PM >>>>>> To: Alan Bateman >>>>>> Cc: Nikola Grcevski ; >>>>>> mailto:mailto:core-libs-dev at openjdk.java.net >>>>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>>>>> >>>>>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>>>>> >>>>>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>>>>> >>>>>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> >>>>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>>>>> >>>>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>>>>> : >>>>>>>> >>>>>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>>>>> >>>>>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>>>>> >>>>>>> -Alan > From christoph.langer at sap.com Thu Dec 12 08:54:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Dec 2019 08:54:11 +0000 Subject: RFR (S): 8235750: [jpackage] Cleanup imports in WinMsiBundler.java In-Reply-To: References: Message-ID: Thanks, Andy and Alexey for the reviews. I've pushed it. Cheers Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Andy Herrick > Sent: Mittwoch, 11. Dezember 2019 15:25 > To: core-libs-dev at openjdk.java.net > Subject: Re: RFR (S): 8235750: [jpackage] Cleanup imports in > WinMsiBundler.java > > looks good - thank you. > > /Andy > > On 12/11/2019 5:02 AM, Langer, Christoph wrote: > > Hi, > > > > please review this import statements cleanup for > src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/interna > l/WinMsiBundler.java. I stumbled over an issue when I imported the > jpackage project into Eclipse. > > > > Due to importing both, static > jdk.incubator.jpackage.internal.StandardBundlerParam.* and static > jdk.incubator.jpackage.internal.WindowsBundlerParam.*, Eclipse thinks > some symbols are ambiguous. > > > > I would also remove an unused list object. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235750.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235750 > > > > Thanks > > Christoph > > From suenaga at oss.nttdata.com Thu Dec 12 09:31:21 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 12 Dec 2019 18:31:21 +0900 Subject: Build warning in jpackage Message-ID: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> Hi all, I tried to build jdk/jdk on Fedora 31 x64, but I saw C++ compiler error as below: ``` In file included from /home/ysuenaga/OpenJDK/jdk/src/jdk.incubator.jpackage/unix/native/libapplauncher/PosixPlatform.cpp:36: /usr/include/sys/sysctl.h:21:2: error: #warning "The header is deprecated and will be removed." [-Werror=cpp] 21 | #warning "The header is deprecated and will be removed." | ``` AFAICS sysctl.h provides `sysctl()` and some macros, but they are not used in PosixPlatform.cpp . In fact, I did not see any error when I remove `#include ` from it. Is it bug? If so, I will file it to JBS and will send review request. Thanks, Yasumasa From Sergey.Bylokhov at oracle.com Thu Dec 12 09:43:36 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Dec 2019 01:43:36 -0800 Subject: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS In-Reply-To: References: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> Message-ID: <5c64d3e4-fe2e-b278-8a45-4d4c65dac8eb@oracle.com> On 12/11/19 7:29 pm, Igor Ignatyev wrote: > Hi Sergey, > > overall looks good to me. a question about linux, is there an alternative to gnome-screenshot for DEs other than GNOME? There are some alternatives like spectacle, mate-screenshot, xwd, imagemagick/import and some others, but non of them are preinstalled in all cases and some of them does not work properly if transparent/visual effects are enabled(kde/gnome/etc). > > -- Igor > >> On Dec 11, 2019, at 1:00 AM, Sergey Bylokhov wrote: >> >> Hello. >> Please review the fix for JDK 14. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 >> Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 >> >> This change adds the "screen capture on the test failure" feature on macOS and Linux. >> - On Linux, it is implemented by the "gnome-screenshot" command(in case of >> multiscreen+xinerama the whole big screen will be saved to the "screen.png" file). >> - On macOS it is implemented by the "screencapture" command, note that I have >> used 1 file per screen, if the number of screens less than 5, other files will be ignored. >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From aph at redhat.com Thu Dec 12 10:25:01 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Dec 2019 10:25:01 +0000 Subject: Build warning in jpackage In-Reply-To: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> References: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> Message-ID: On 12/12/19 9:31 AM, Yasumasa Suenaga wrote: > AFAICS sysctl.h provides `sysctl()` and some macros, but they are not used in PosixPlatform.cpp . > In fact, I did not see any error when I remove `#include ` from it. You probably won't see an error unless you configure with --disable-precompiled-headers. Please try that, and we can then consider removing that #include. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From suenaga at oss.nttdata.com Thu Dec 12 13:23:41 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 12 Dec 2019 22:23:41 +0900 Subject: RFR (trivial): 8235833: PosixPlatform.cpp should not include sysctl.h In-Reply-To: References: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> Message-ID: <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> Hi Andrew, I can see same error whether --disable-precompiled-headers or not. So I filed it to JBS and uploaded webrev. Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8235833 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235833/webrev.00/ It works fine on Fedora 31. I've pushed it to submit repo. I believe it passes all tests. Thanks, Yasumasa On 2019/12/12 19:25, Andrew Haley wrote: > On 12/12/19 9:31 AM, Yasumasa Suenaga wrote: >> AFAICS sysctl.h provides `sysctl()` and some macros, but they are not used in PosixPlatform.cpp . >> In fact, I did not see any error when I remove `#include ` from it. > > You probably won't see an error unless you configure with > --disable-precompiled-headers. Please try that, and we can then > consider removing that #include. > From kusrinivasan at vmware.com Thu Dec 12 13:31:44 2019 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Thu, 12 Dec 2019 13:31:44 +0000 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: <5BF0FE41-15AE-4133-9758-941BA063EA1F@oracle.com> References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> <5BF0FE41-15AE-4133-9758-941BA063EA1F@oracle.com> Message-ID: Hi Henry, I approve this. Appreciate you pushing it, as usual *all* possible tests need to be run. ;) Nikola, welcome to the OpenJDK community. Thanks Kumar > On Dec 11, 2019, at 10:29 PM, Henry Jen wrote: > > Nikola, > > The change looks fine to me as well, I?ll run the test and push it before RDP1 if everything is good with Kumar as reviewer. > > Cheers, > Henry > > >> On Dec 11, 2019, at 2:26 PM, Kumar Srinivasan wrote: >> >> Hi Nikola, >> >> Thank you for making the changes. Looks good to me. >> >> Kumar Srinivasan >> PS: my new and official email address: kusrinivasan at vmware.com >> >> >> On Wed, Dec 11, 2019 at 10:04 AM Nikola Grcevski wrote: >> Thank you again for reviewing my code Kumar! >> >> I have applied your refactoring suggestions. Using the array approach as you suggested made the test code a lot more tidier. I?m attaching the updated patch after my signature and the external webrev is here for reference: >> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=UDtNAMKCQ3ILrmrN0JQwLbO5rpiZ%2BOEh1ojBUIeWzuo%3D&reserved=0 >> >> Cheers, >> Nikola >> >> diff -r bd436284147d src/java.base/share/native/libjli/args.c >> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/share/native/libjli/args.c Wed Dec 11 12:09:29 2019 -0500 >> @@ -130,6 +130,8 @@ >> } >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >> stopExpansion = JNI_TRUE; >> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >> + idx = argsCount; >> } >> } else { >> if (!expectingNoDashArg) { >> @@ -449,6 +451,7 @@ >> return JLI_StrCmp(arg, "-jar") == 0 || >> JLI_StrCmp(arg, "-m") == 0 || >> JLI_StrCmp(arg, "--module") == 0 || >> + JLI_StrCCmp(arg, "--module=") == 0 || >> JLI_StrCmp(arg, "--dry-run") == 0 || >> JLI_StrCmp(arg, "-h") == 0 || >> JLI_StrCmp(arg, "-?") == 0 || >> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/windows/native/libjli/java_md.c Wed Dec 11 12:09:29 2019 -0500 >> @@ -34,6 +34,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include "java.h" >> @@ -1015,6 +1016,17 @@ >> >> // sanity check, match the args we have, to the holy grail >> idx = JLI_GetAppArgIndex(); >> + >> + // First arg index is NOT_FOUND >> + if (idx < 0) { >> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >> + // a different negative index >> + assert (idx == -1); >> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >> + JLI_TraceLauncher("passing arguments as-is.\n"); >> + return NewPlatformStringArray(env, strv, argc); >> + } >> + >> isTool = (idx == 0); >> if (isTool) { idx++; } // skip tool name >> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >> diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java >> --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -37,6 +37,8 @@ >> import java.util.List; >> import java.util.Map; >> import java.util.regex.Pattern; >> +import java.nio.file.Paths; >> +import java.nio.file.Path; >> >> public class ArgsEnvVar extends TestHelper { >> private static File testJar = null; >> @@ -153,6 +155,7 @@ >> List.of("-jar", "test.jar"), >> List.of("-m", "test/Foo"), >> List.of("--module", "test/Foo"), >> + List.of("--module=test/Foo"), >> List.of("--dry-run"), >> List.of("-h"), >> List.of("-?"), >> @@ -241,6 +244,69 @@ >> verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); >> } >> >> + >> + @Test >> + // That that we can correctly handle the module longform argument option >> + // when supplied in an argument file >> + public void modulesInArgsFile() throws IOException { >> + File cwd = new File("."); >> + File testModuleDir = new File(cwd, "modules_test"); >> + >> + createEchoArgumentsModule(testModuleDir); >> + >> + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); >> + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); >> + >> + // test module / main class >> + String MODULE_OPTION = "--module=test/launcher.Main"; >> + String TEST_MODULE = "test"; >> + >> + // javac -d mods/test src/test/** >> + TestResult tr = doExec( >> + javacCmd, >> + "-d", MODS_DIR.toString(), >> + "--module-source-path", SRC_DIR.toString(), >> + "--module", TEST_MODULE); >> + >> + if (!tr.isOK()) { >> + System.out.println("test did not compile"); >> + throw new RuntimeException("Error: modules test did not compile"); >> + } >> + >> + // verify the terminating ability of --module= through environment variables >> + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); >> + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); >> + tr = doExec(env, javaCmd); >> + tr.checkNegative(); >> + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check that specifying --module and --module-path with file works >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); >> + tr.contains("[--hello]"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating >> + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); >> + tr.checkNegative(); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // clean-up >> + argFile.delete(); >> + argFile1.delete(); >> + recursiveDelete(testModuleDir); >> + } >> + >> public static void main(String... args) throws Exception { >> init(); >> ArgsEnvVar a = new ArgsEnvVar(); >> diff -r bd436284147d test/jdk/tools/launcher/TestHelper.java >> --- a/test/jdk/tools/launcher/TestHelper.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestHelper.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -500,6 +500,40 @@ >> return Locale.getDefault().getLanguage().equals("en"); >> } >> >> + /** >> + * Helper method to initialize a simple module that just prints the passed in arguments >> + */ >> + static void createEchoArgumentsModule(File modulesDir) throws IOException { >> + if (modulesDir.exists()) { >> + recursiveDelete(modulesDir); >> + } >> + >> + modulesDir.mkdirs(); >> + >> + File srcDir = new File(modulesDir, "src"); >> + File modsDir = new File(modulesDir, "mods"); >> + File testDir = new File(srcDir, "test"); >> + File launcherTestDir = new File(testDir, "launcher"); >> + srcDir.mkdir(); >> + modsDir.mkdir(); >> + testDir.mkdir(); >> + launcherTestDir.mkdir(); >> + >> + String[] moduleInfoCode = { "module test {}" }; >> + createFile(new File(testDir, "module-info.java"), Arrays.asList(moduleInfoCode)); >> + >> + String[] moduleCode = { >> + "package launcher;", >> + "import java.util.Arrays;", >> + "public class Main {", >> + "public static void main(String[] args) {", >> + "System.out.println(Arrays.toString(args));", >> + "}", >> + "}" >> + }; >> + createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(moduleCode)); >> + } >> + >> /* >> * A class to encapsulate the test results and stuff, with some ease >> * of use methods to check the test results. >> diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java >> --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -246,6 +246,10 @@ >> if (!tr.contains("Error: Could not find or load main class AbsentClass")) { >> throw new RuntimeException("Test Fails"); >> } >> + >> + // Make sure we handle correctly the module long form (--module=) >> + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); >> + ensureNoWarnings(tr); >> } >> >> void ensureNoWarnings(TestResult tr) { >> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -29,6 +29,7 @@ >> * jdk.jlink >> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >> * @run testng BasicTest >> + * @bug 8234076 >> * @summary Basic test of starting an application as a module >> */ >> >> @@ -40,6 +41,8 @@ >> >> import jdk.test.lib.compiler.CompilerUtils; >> import jdk.test.lib.process.ProcessTools; >> +import jdk.test.lib.process.OutputAnalyzer; >> +import jdk.test.lib.Utils; >> >> import org.testng.annotations.BeforeTest; >> import org.testng.annotations.Test; >> @@ -70,6 +73,8 @@ >> // the module main class >> private static final String MAIN_CLASS = "jdk.test.Main"; >> >> + // for Windows specific launcher tests >> + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); >> >> @BeforeTest >> public void compileTestModule() throws Exception { >> @@ -259,4 +264,87 @@ >> assertTrue(exitValue != 0); >> } >> >> + >> + /** >> + * Helper method that creates a ProcessBuilder with command line arguments >> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >> + */ >> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >> + >> + return pb; >> + } >> + >> + /** >> + * Test the ability for the Windows launcher to do proper application argument >> + * detection and expansion, when using the long form module option and all passed in >> + * command line arguments are prefixed with a dash. >> + * >> + * These tests are not expected to work on *nixes, and are ignored. >> + */ >> + public void testWindowsWithLongFormModuleOption() throws Exception { >> + if (!IS_WINDOWS) { >> + return; >> + } >> + >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >> + // We should be able to find the argument --help as an application argument >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help"); >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >> + // We should be able to see argument expansion happen >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help") >> + .shouldContain("module-info.java"); >> + } >> + >> + >> + /** >> + * Test that --module= is terminating for VM argument processing just like --module >> + */ >> + public void testLongFormModuleOptionTermination() throws Exception { >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >> + // deemed as application arguments >> + OutputAnalyzer output = ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--module-path=" + dir, >> + "--module=" + mid)) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("argv[ 0] = '--module-path=" + dir) >> + .shouldContain("argv[ 1] = '--module=" + mid); >> + >> + if (IS_WINDOWS) { >> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >> + } >> + >> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >> + // This command line will not work as --module= is terminating and the module will be not found >> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >> + assertTrue(exitValue != 0); >> + } >> } >> >> From: Kumar Srinivasan >> Sent: December 10, 2019 8:43 PM >> To: Nikola Grcevski >> Cc: Henry Jen ; Alan Bateman ; core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> [Resend; cc'ing the group] >> >> Hi Nikola, >> >> Generally looks great to me. I would have moved initModulesDir to TestHelper.createSimpleModule(File dir). >> TestHelper.java contains a collection of test related utilities needed by the launcher, it will help someone >> else use it to create a simple module. >> >> I would have rewritten this >> + ArrayList scratchpad = new ArrayList<>(); >> + scratchpad.add("module test {}"); >> + createFile(new File(testDir, "module-info.java"), scratchpad); >> + scratchpad.clear(); >> + scratchpad.add("package launcher;"); >> + scratchpad.add("import java.util.Arrays;"); >> + scratchpad.add("public class Main {"); >> + scratchpad.add("public static void main(String[] args) {"); >> + scratchpad.add("System.out.println(Arrays.toString(args));"); >> + scratchpad.add("}"); >> + scratchpad.add("}"); >> + createFile(new File(launcherTestDir, "Main.java"), scratchpad); >> >> as follows: >> String a1[] = {"module test{}"}; >> createFile(new File(testDir, "module-info.java", Arrays.asList(a1)); >> >> String a2[] = { >> "package launcher;", >> .... >> .... >> } >> createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(a2)); >> >> This might make the code neater. >> >> Besides that, looks very good. >> >> Thanks >> Kumar >> >> >> On Mon, Dec 9, 2019 at 1:58 PM Nikola Grcevski wrote: >> Hi Henry and Kumar, >> >> Thank you again for the review! I have added the fix to isTerminalOpt and used both of your suggestions to make new tests. >> With native memory tracking enabled, I could actually see a crash on both Linux and Windows without the suggested fix. >> >> I tested the changes again on both Linux and Windows, and the new unit tests fail if isTerminalOpt doesn?t check for ?module= >> as per Henry's suggestion. >> >> I'm attaching the new patch (my apologies for the size) at the bottom of this email after my signature. If I haven't covered >> certain aspects in the new tests please let me know, I'm more than happy to extend them further. I've updated the webrev >> to reflect the latest patch if it's easier to read: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=UDtNAMKCQ3ILrmrN0JQwLbO5rpiZ%2BOEh1ojBUIeWzuo%3D&reserved=0 >> >> Thanks again! >> Nikola >> >> diff -r bd436284147d src/java.base/share/native/libjli/args.c >> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/share/native/libjli/args.c Mon Dec 09 16:08:54 2019 -0500 >> @@ -130,6 +130,8 @@ >> } >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >> stopExpansion = JNI_TRUE; >> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >> + idx = argsCount; >> } >> } else { >> if (!expectingNoDashArg) { >> @@ -449,6 +451,7 @@ >> return JLI_StrCmp(arg, "-jar") == 0 || >> JLI_StrCmp(arg, "-m") == 0 || >> JLI_StrCmp(arg, "--module") == 0 || >> + JLI_StrCCmp(arg, "--module=") == 0 || >> JLI_StrCmp(arg, "--dry-run") == 0 || >> JLI_StrCmp(arg, "-h") == 0 || >> JLI_StrCmp(arg, "-?") == 0 || >> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/windows/native/libjli/java_md.c Mon Dec 09 16:08:54 2019 -0500 >> @@ -34,6 +34,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include "java.h" >> @@ -1015,6 +1016,17 @@ >> >> // sanity check, match the args we have, to the holy grail >> idx = JLI_GetAppArgIndex(); >> + >> + // First arg index is NOT_FOUND >> + if (idx < 0) { >> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >> + // a different negative index >> + assert (idx == -1); >> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >> + JLI_TraceLauncher("passing arguments as-is.\n"); >> + return NewPlatformStringArray(env, strv, argc); >> + } >> + >> isTool = (idx == 0); >> if (isTool) { idx++; } // skip tool name >> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >> diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java >> --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -37,6 +37,8 @@ >> import java.util.List; >> import java.util.Map; >> import java.util.regex.Pattern; >> +import java.nio.file.Paths; >> +import java.nio.file.Path; >> >> public class ArgsEnvVar extends TestHelper { >> private static File testJar = null; >> @@ -153,6 +155,7 @@ >> List.of("-jar", "test.jar"), >> List.of("-m", "test/Foo"), >> List.of("--module", "test/Foo"), >> + List.of("--module=test/Foo"), >> List.of("--dry-run"), >> List.of("-h"), >> List.of("-?"), >> @@ -241,6 +244,101 @@ >> verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); >> } >> >> + /** >> + * Helper method to initialize a simple module that just prints the passed in arguments >> + */ >> + private void initModulesDir(File modulesDir) throws IOException { >> + if (modulesDir.exists()) { >> + recursiveDelete(modulesDir); >> + } >> + >> + modulesDir.mkdirs(); >> + >> + File srcDir = new File(modulesDir, "src"); >> + File modsDir = new File(modulesDir, "mods"); >> + File testDir = new File(srcDir, "test"); >> + File launcherTestDir = new File(testDir, "launcher"); >> + srcDir.mkdir(); >> + modsDir.mkdir(); >> + testDir.mkdir(); >> + launcherTestDir.mkdir(); >> + >> + ArrayList scratchpad = new ArrayList<>(); >> + scratchpad.add("module test {}"); >> + createFile(new File(testDir, "module-info.java"), scratchpad); >> + scratchpad.clear(); >> + scratchpad.add("package launcher;"); >> + scratchpad.add("import java.util.Arrays;"); >> + scratchpad.add("public class Main {"); >> + scratchpad.add("public static void main(String[] args) {"); >> + scratchpad.add("System.out.println(Arrays.toString(args));"); >> + scratchpad.add("}"); >> + scratchpad.add("}"); >> + createFile(new File(launcherTestDir, "Main.java"), scratchpad); >> + } >> + >> + @Test >> + // That that we can correctly handle the module longform argument option >> + // when supplied in an argument file >> + public void modulesInArgsFile() throws IOException { >> + File cwd = new File("."); >> + File testModuleDir = new File(cwd, "modules_test"); >> + >> + initModulesDir(testModuleDir); >> + >> + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); >> + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); >> + >> + // test module / main class >> + String MODULE_OPTION = "--module=test/launcher.Main"; >> + String TEST_MODULE = "test"; >> + >> + // javac -d mods/test src/test/** >> + TestResult tr = doExec( >> + javacCmd, >> + "-d", MODS_DIR.toString(), >> + "--module-source-path", SRC_DIR.toString(), >> + "--module", TEST_MODULE); >> + >> + if (!tr.isOK()) { >> + System.out.println("test did not compile"); >> + throw new RuntimeException("Error: modules test did not compile"); >> + } >> + >> + // verify the terminating ability of --module= through environment variables >> + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); >> + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); >> + tr = doExec(env, javaCmd); >> + tr.checkNegative(); >> + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check that specifying --module and --module-path with file works >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); >> + tr.contains("[--hello]"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating >> + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); >> + tr.checkNegative(); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // clean-up >> + argFile.delete(); >> + argFile1.delete(); >> + recursiveDelete(testModuleDir); >> + } >> + >> public static void main(String... args) throws Exception { >> init(); >> ArgsEnvVar a = new ArgsEnvVar(); >> diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java >> --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -246,6 +246,10 @@ >> if (!tr.contains("Error: Could not find or load main class AbsentClass")) { >> throw new RuntimeException("Test Fails"); >> } >> + >> + // Make sure we handle correctly the module long form (--module=) >> + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); >> + ensureNoWarnings(tr); >> } >> >> void ensureNoWarnings(TestResult tr) { >> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -29,6 +29,7 @@ >> * jdk.jlink >> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >> * @run testng BasicTest >> + * @bug 8234076 >> * @summary Basic test of starting an application as a module >> */ >> >> @@ -40,6 +41,8 @@ >> >> import jdk.test.lib.compiler.CompilerUtils; >> import jdk.test.lib.process.ProcessTools; >> +import jdk.test.lib.process.OutputAnalyzer; >> +import jdk.test.lib.Utils; >> >> import org.testng.annotations.BeforeTest; >> import org.testng.annotations.Test; >> @@ -70,6 +73,8 @@ >> // the module main class >> private static final String MAIN_CLASS = "jdk.test.Main"; >> >> + // for Windows specific launcher tests >> + static final boolean IS_WINDOWS = System.getProperty("https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=n75hStNtM66vkRxc380wOIM9SHfb%2BSUmjR7vOqbNvrc%3D&reserved=0", "unknown").startsWith("Windows"); >> >> @BeforeTest >> public void compileTestModule() throws Exception { >> @@ -259,4 +264,87 @@ >> assertTrue(exitValue != 0); >> } >> >> + >> + /** >> + * Helper method that creates a ProcessBuilder with command line arguments >> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >> + */ >> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >> + >> + return pb; >> + } >> + >> + /** >> + * Test the ability for the Windows launcher to do proper application argument >> + * detection and expansion, when using the long form module option and all passed in >> + * command line arguments are prefixed with a dash. >> + * >> + * These tests are not expected to work on *nixes, and are ignored. >> + */ >> + public void testWindowsWithLongFormModuleOption() throws Exception { >> + if (!IS_WINDOWS) { >> + return; >> + } >> + >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >> + // We should be able to find the argument --help as an application argument >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help"); >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >> + // We should be able to see argument expansion happen >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help") >> + .shouldContain("module-info.java"); >> + } >> + >> + >> + /** >> + * Test that --module= is terminating for VM argument processing just like --module >> + */ >> + public void testLongFormModuleOptionTermination() throws Exception { >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >> + // deemed as application arguments >> + OutputAnalyzer output = ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--module-path=" + dir, >> + "--module=" + mid)) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("argv[ 0] = '--module-path=" + dir) >> + .shouldContain("argv[ 1] = '--module=" + mid); >> + >> + if (IS_WINDOWS) { >> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >> + } >> + >> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >> + // This command line will not work as --module= is terminating and the module will be not found >> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >> + assertTrue(exitValue != 0); >> + } >> } >> >> >> From: Kumar Srinivasan >> Sent: December 7, 2019 10:28 PM >> To: Henry Jen >> Cc: Nikola Grcevski ; Alan Bateman ; mailto:core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> Hi, >> >> The launcher fix looks good, despite the launcher fix being simple, please note, >> it sometimes requires a lot more effort to write a test for it, please read on.... >> >> Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my memory and I recalled >> this change for VM's native memory tracking. >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=kBxw2xaMCtFVzE5CkkazmXisai6aO00Ml3ocA%2BkPWwM%3D&reserved=0 >> Inspecting the above changeset, we might have to add another test for JVM native memory tracking, >> since this is a terminal argument. >> >> Maybe TestHelper could create a simple module, which prints its args, >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=SgnSQdJLZOT7hrvBKV5N%2Bgy%2BMVYeGX4Z8dX3ed4dJlw%3D&reserved=0 >> >> Kumar Srinivasan >> >> On Fri, Dec 6, 2019 at 2:44 PM Henry Jen wrote: >> Thanks for the work, the test case covers that when ?module= is used before other options, which is good. >> >> But we need another to make sure that when ?module= is put in an argument file or environment variable, that should not be allowed. The fix is simple, we need to add that to isTerminalOp() method. >> >> Cheers, >> Henry >> >>> On Dec 6, 2019, at 12:28 PM, Nikola Grcevski wrote: >>> >>> Thank you Henry! >>> >>> I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. >>> >>> I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=UDtNAMKCQ3ILrmrN0JQwLbO5rpiZ%2BOEh1ojBUIeWzuo%3D&reserved=0) >>> >>> Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. >>> Nikola >>> >>> diff -r bd436284147d src/java.base/share/native/libjli/args.c >>> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 15:11:36 2019 -0500 >>> @@ -130,6 +130,8 @@ >>> } >>> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>> stopExpansion = JNI_TRUE; >>> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >>> + idx = argsCount; >>> } >>> } else { >>> if (!expectingNoDashArg) { >>> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >>> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 15:11:36 2019 -0500 >>> @@ -34,6 +34,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #include >>> #include "java.h" >>> @@ -1015,6 +1016,17 @@ >>> >>> // sanity check, match the args we have, to the holy grail >>> idx = JLI_GetAppArgIndex(); >>> + >>> + // First arg index is NOT_FOUND >>> + if (idx < 0) { >>> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >>> + // a different negative index >>> + assert (idx == -1); >>> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >>> + JLI_TraceLauncher("passing arguments as-is.\n"); >>> + return NewPlatformStringArray(env, strv, argc); >>> + } >>> + >>> isTool = (idx == 0); >>> if (isTool) { idx++; } // skip tool name >>> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >>> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >>> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 15:11:36 2019 -0500 >>> @@ -29,6 +29,7 @@ >>> * jdk.jlink >>> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >>> * @run testng BasicTest >>> + * @bug 8234076 >>> * @summary Basic test of starting an application as a module >>> */ >>> >>> @@ -40,6 +41,8 @@ >>> >>> import jdk.test.lib.compiler.CompilerUtils; >>> import jdk.test.lib.process.ProcessTools; >>> +import jdk.test.lib.process.OutputAnalyzer; >>> +import jdk.test.lib.Utils; >>> >>> import org.testng.annotations.BeforeTest; >>> import org.testng.annotations.Test; >>> @@ -70,6 +73,8 @@ >>> // the module main class >>> private static final String MAIN_CLASS = "jdk.test.Main"; >>> >>> + // for Windows specific launcher tests >>> + static final boolean IS_WINDOWS = System.getProperty("https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=n75hStNtM66vkRxc380wOIM9SHfb%2BSUmjR7vOqbNvrc%3D&reserved=0", "unknown").startsWith("Windows"); >>> >>> @BeforeTest >>> public void compileTestModule() throws Exception { >>> @@ -259,4 +264,87 @@ >>> assertTrue(exitValue != 0); >>> } >>> >>> + >>> + /** >>> + * Helper method that creates a ProcessBuilder with command line arguments >>> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >>> + */ >>> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >>> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >>> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >>> + >>> + return pb; >>> + } >>> + >>> + /** >>> + * Test the ability for the Windows launcher to do proper application argument >>> + * detection and expansion, when using the long form module option and all passed in >>> + * command line arguments are prefixed with a dash. >>> + * >>> + * These tests are not expected to work on *nixes, and are ignored. >>> + */ >>> + public void testWindowsWithLongFormModuleOption() throws Exception { >>> + if (!IS_WINDOWS) { >>> + return; >>> + } >>> + >>> + String dir = MODS_DIR.toString(); >>> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >>> + // We should be able to find the argument --help as an application argument >>> + ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + "--help")) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("F--help"); >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >>> + // We should be able to see argument expansion happen >>> + ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", >>> + "--help")) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("F--help") >>> + .shouldContain("module-info.java"); >>> + } >>> + >>> + >>> + /** >>> + * Test that --module= is terminating for VM argument processing just like --module >>> + */ >>> + public void testLongFormModuleOptionTermination() throws Exception { >>> + String dir = MODS_DIR.toString(); >>> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >>> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >>> + // deemed as application arguments >>> + OutputAnalyzer output = ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + "--module-path=" + dir, >>> + "--module=" + mid)) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("argv[ 0] = '--module-path=" + dir) >>> + .shouldContain("argv[ 1] = '--module=" + mid); >>> + >>> + if (IS_WINDOWS) { >>> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >>> + } >>> + >>> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >>> + // This command line will not work as --module= is terminating and the module will be not found >>> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >>> + assertTrue(exitValue != 0); >>> + } >>> } >>> >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 6, 2019 12:03 AM >>> To: Nikola Grcevski >>> Cc: Kumar Srinivasan ; Alan Bateman ; mailto:mailto:core-libs-dev at openjdk.java.net >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>> >>> >>>> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: >>>> >>>> Hello all again! >>>> >>>> Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: >>>> >>>> --- a/src/java.base/share/native/libjli/args.c >>>> +++ b/src/java.base/share/native/libjli/args.c >>>> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { >>>> } >>>> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>>> stopExpansion = JNI_TRUE; >>>> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { >>> >>> I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. >>> >>> BTW, we need the patch to be hosted on https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=Nhivs6S9cWvz%2BXotBnEdL8L%2FeqsEDNbk%2BRiASG5psPU%3D&reserved=0 or you can attach the patch to the review thread if you are not yet an author. >>> >>> Cheers, >>> Henry >>> >>> >>>> + idx = argsCount; >>>> } >>>> } else { >>>> if (!expectingNoDashArg) { >>>> >>>> The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. >>>> >>>> I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. >>>> >>>> I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). >>>> >>>> I ran all the launcher tests on both Windows and Linux and all tests pass. >>>> >>>> Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. >>>> >>>> Thank you, >>>> Nikola >>>> >>>> -----Original Message----- >>>> From: Henry Jen >>>> Sent: December 4, 2019 8:26 PM >>>> To: Kumar Srinivasan ; Alan Bateman >>>> ; Nikola Grcevski >>>> >>>> Cc: mailto:mailto:core-libs-dev at openjdk.java.net >>>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>>> >>>>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >>>>> >>>>> Hi Nikola, >>>>> >>>>> It looks ok to me, I will leave it to Henry and Alan to bless this. >>>>> >>>>> IMHO: I think we should fix it correctly now than later, I don't >>>>> think it is all that difficult AFAICT all the launcher has to do is >>>>> identify "--module==", then the next argument is the first index. >>>>> >>>> >>>> I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. >>>> >>>> If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. >>>> >>>> FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. >>>> >>>> I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. >>>> >>>> I?ll let Alan to comment about the ?module option usage. >>>> >>>> The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. >>>> >>>> [1] >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs >>>> .https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834188430&sdata=lyeNhD4KG4gHGGoyxboQ2fnyLhXqTdEd2Zo1yKFYpKg%3D&reserved=0 >>>> &data=02%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >>>> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 >>>> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY >>>> %3D&reserved=0 >>>> >>>>> Kumar >>>>> >>>>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >>>>> Hi Henry and Kumar, >>>>> >>>>> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >>>>> >>>>> Please find my updated webrev here for your review: >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc >>>>> e >>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834198420&sdata=%2BjbBozHCntcBnElAD1%2F1AXBDV5hRmFCNjdXh4GYiG4E%3D&reserved=0 >>>>> c >>>>> evski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >>>>> f >>>>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ >>>>> % >>>>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>>> >>>>> Cheers, >>>>> >>>>> Nikola >>>>> >>>>> -----Original Message----- >>>>> From: Henry Jen >>>>> Sent: December 3, 2019 11:39 AM >>>>> To: Kumar Srinivasan >>>>> Cc: Nikola Grcevski ; Alan Bateman >>>>> ; mailto:mailto:core-libs-dev at openjdk.java.net >>>>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>>>> >>>>> Kumar, >>>>> >>>>> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >>>>> >>>>> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Sorry for chiming in late in the review process, for what it's worth.... >>>>>> >>>>>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>>>>> and subsequent crash, but it does not address wildcard arguments expansion. >>>>>> >>>>>> What if we have >>>>>> % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>>>>> Where jdk.compiler is a java compiler implementation (javac). >>>>>> The user would expect the above compiler module to build all the .java files in that directory, >>>>>> and this fix will not address that. >>>>>> >>>>>> Some background: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834198420&sdata=5A3SGgptAOtYxypX4D8j6JqIZS5mN8q0TKDa0%2BvJI5U%3D&reserved=0 >>>>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=mH19URBhYu0rW%2Bpsl91V9e3TcwPD%2BDX0YSNbXao5H8o%3D&reserved=0 >>>>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>>>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>>>>> Please see all the related bugs in the above JIRA issue. >>>>>> >>>>>> Paragraph #6 in this interview surmises the wild card behavior on Windows: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834198420&sdata=YpDEqU5h%2BsTKPbR9gHKMsTonj0V8tgfvFXPtslAHUXc%3D&reserved=0 >>>>>> 2%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=%2FUxEEDQrTgIk2Y%2Bd%2FPz67ocYVqRXncW%2FsITD%2BWpemSY%3D&reserved=0 >>>>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>>>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>>>>> ;reserved=0 >>>>>> >>>>>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>>>>> .https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834198420&sdata=YJgeu27IeTF2uEBxv9GaWhQwEEoo2O9fNIh%2BmimtpP4%3D&reserved=0 >>>>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>>>>> ki%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=HvTbDg9uHe5WDu0OVcH%2BPF5mgYHWv2OUHYAWY2EheFo%3D&reserved=0 >>>>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>>>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>>>>> Using the modules test framework may make the test simpler. >>>>>> >>>>>> Kumar Srinivasan >>>>>> >>>>>> >>>>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>>>>> Hi Alan and Henry, >>>>>> >>>>>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>>>>> >>>>>> I created a webrev here for the change, including a new test in Arrrghs.java: >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce5d5287371254e269f6508d77ecce750%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637117290834198420&sdata=MwmU3OzbpRwCdyF0oW9A72J38tI5OFWMoqNADj1HEFY%3D&reserved=0 >>>>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=XX0qBV1e5ucqPSL%2B4YciHNXR29evREuIRDFwTSxaqHU%3D&reserved=0 >>>>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>>>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>>>> >>>>>> I copied the test validation and assertion style of other code inside the test class. >>>>>> >>>>>> Please let me know if you have any comments or suggestions. >>>>>> >>>>>> Thanks again! >>>>>> >>>>>> -----Original Message----- >>>>>> From: Henry Jen >>>>>> Sent: December 2, 2019 12:26 PM >>>>>> To: Alan Bateman >>>>>> Cc: Nikola Grcevski ; >>>>>> mailto:mailto:core-libs-dev at openjdk.java.net >>>>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>>>>> >>>>>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>>>>> >>>>>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>>>>> >>>>>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> >>>>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>>>>> >>>>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>>>>> : >>>>>>>> >>>>>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>>>>> >>>>>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>>>>> >>>>>>> -Alan > From Nikola.Grcevski at microsoft.com Thu Dec 12 15:44:22 2019 From: Nikola.Grcevski at microsoft.com (Nikola Grcevski) Date: Thu, 12 Dec 2019 15:44:22 +0000 Subject: [EXTERNAL] JDK-8234076 bug fix candidate In-Reply-To: References: <74271748-E9EF-4CDC-81C3-C1A4C874AC3E@oracle.com> <7B914176-2900-4508-8D98-F254924C94B6@oracle.com> <64B628EF-FFED-411A-B431-253C39635C06@oracle.com> <5BF0FE41-15AE-4133-9758-941BA063EA1F@oracle.com> Message-ID: Thank you Henry for fixing the test issue, and thank you Kumar for the prompt review! In hindsight I should've run the tests on MacOS too, I'll make sure I do that for future work. I truly appreciate the help you've given me in making this bug fix. Cheers, Nikola -----Original Message----- From: Kumar Srinivasan Sent: December 12, 2019 8:32 AM To: Henry Jen Cc: core-libs-dev at openjdk.java.net; Nikola Grcevski Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate Hi Henry, I approve this. Appreciate you pushing it, as usual *all* possible tests need to be run. ;) Nikola, welcome to the OpenJDK community. Thanks Kumar > On Dec 11, 2019, at 10:29 PM, Henry Jen wrote: > > Nikola, > > The change looks fine to me as well, I?ll run the test and push it before RDP1 if everything is good with Kumar as reviewer. > > Cheers, > Henry > > >> On Dec 11, 2019, at 2:26 PM, Kumar Srinivasan wrote: >> >> Hi Nikola, >> >> Thank you for making the changes. Looks good to me. >> >> Kumar Srinivasan >> PS: my new and official email address: kusrinivasan at vmware.com >> >> >> On Wed, Dec 11, 2019 at 10:04 AM Nikola Grcevski wrote: >> Thank you again for reviewing my code Kumar! >> >> I have applied your refactoring suggestions. Using the array approach as you suggested made the test code a lot more tidier. I?m attaching the updated patch after my signature and the external webrev is here for reference: >> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086603237&sdata=i9pxLqzp2zCmsMbFDB56Aimdq1VVbYxjeaP%2ByBtNA3w%3D&reserved=0 >> >> Cheers, >> Nikola >> >> diff -r bd436284147d src/java.base/share/native/libjli/args.c >> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/share/native/libjli/args.c Wed Dec 11 12:09:29 2019 -0500 >> @@ -130,6 +130,8 @@ >> } >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >> stopExpansion = JNI_TRUE; >> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >> + idx = argsCount; >> } >> } else { >> if (!expectingNoDashArg) { >> @@ -449,6 +451,7 @@ >> return JLI_StrCmp(arg, "-jar") == 0 || >> JLI_StrCmp(arg, "-m") == 0 || >> JLI_StrCmp(arg, "--module") == 0 || >> + JLI_StrCCmp(arg, "--module=") == 0 || >> JLI_StrCmp(arg, "--dry-run") == 0 || >> JLI_StrCmp(arg, "-h") == 0 || >> JLI_StrCmp(arg, "-?") == 0 || >> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/windows/native/libjli/java_md.c Wed Dec 11 12:09:29 2019 -0500 >> @@ -34,6 +34,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include "java.h" >> @@ -1015,6 +1016,17 @@ >> >> // sanity check, match the args we have, to the holy grail >> idx = JLI_GetAppArgIndex(); >> + >> + // First arg index is NOT_FOUND >> + if (idx < 0) { >> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >> + // a different negative index >> + assert (idx == -1); >> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >> + JLI_TraceLauncher("passing arguments as-is.\n"); >> + return NewPlatformStringArray(env, strv, argc); >> + } >> + >> isTool = (idx == 0); >> if (isTool) { idx++; } // skip tool name >> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >> diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java >> --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -37,6 +37,8 @@ >> import java.util.List; >> import java.util.Map; >> import java.util.regex.Pattern; >> +import java.nio.file.Paths; >> +import java.nio.file.Path; >> >> public class ArgsEnvVar extends TestHelper { >> private static File testJar = null; >> @@ -153,6 +155,7 @@ >> List.of("-jar", "test.jar"), >> List.of("-m", "test/Foo"), >> List.of("--module", "test/Foo"), >> + List.of("--module=test/Foo"), >> List.of("--dry-run"), >> List.of("-h"), >> List.of("-?"), >> @@ -241,6 +244,69 @@ >> verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); >> } >> >> + >> + @Test >> + // That that we can correctly handle the module longform argument option >> + // when supplied in an argument file >> + public void modulesInArgsFile() throws IOException { >> + File cwd = new File("."); >> + File testModuleDir = new File(cwd, "modules_test"); >> + >> + createEchoArgumentsModule(testModuleDir); >> + >> + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); >> + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); >> + >> + // test module / main class >> + String MODULE_OPTION = "--module=test/launcher.Main"; >> + String TEST_MODULE = "test"; >> + >> + // javac -d mods/test src/test/** >> + TestResult tr = doExec( >> + javacCmd, >> + "-d", MODS_DIR.toString(), >> + "--module-source-path", SRC_DIR.toString(), >> + "--module", TEST_MODULE); >> + >> + if (!tr.isOK()) { >> + System.out.println("test did not compile"); >> + throw new RuntimeException("Error: modules test did not compile"); >> + } >> + >> + // verify the terminating ability of --module= through environment variables >> + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); >> + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); >> + tr = doExec(env, javaCmd); >> + tr.checkNegative(); >> + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check that specifying --module and --module-path with file works >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); >> + tr.contains("[--hello]"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating >> + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); >> + tr.checkNegative(); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // clean-up >> + argFile.delete(); >> + argFile1.delete(); >> + recursiveDelete(testModuleDir); >> + } >> + >> public static void main(String... args) throws Exception { >> init(); >> ArgsEnvVar a = new ArgsEnvVar(); >> diff -r bd436284147d test/jdk/tools/launcher/TestHelper.java >> --- a/test/jdk/tools/launcher/TestHelper.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestHelper.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -500,6 +500,40 @@ >> return Locale.getDefault().getLanguage().equals("en"); >> } >> >> + /** >> + * Helper method to initialize a simple module that just prints the passed in arguments >> + */ >> + static void createEchoArgumentsModule(File modulesDir) throws IOException { >> + if (modulesDir.exists()) { >> + recursiveDelete(modulesDir); >> + } >> + >> + modulesDir.mkdirs(); >> + >> + File srcDir = new File(modulesDir, "src"); >> + File modsDir = new File(modulesDir, "mods"); >> + File testDir = new File(srcDir, "test"); >> + File launcherTestDir = new File(testDir, "launcher"); >> + srcDir.mkdir(); >> + modsDir.mkdir(); >> + testDir.mkdir(); >> + launcherTestDir.mkdir(); >> + >> + String[] moduleInfoCode = { "module test {}" }; >> + createFile(new File(testDir, "module-info.java"), Arrays.asList(moduleInfoCode)); >> + >> + String[] moduleCode = { >> + "package launcher;", >> + "import java.util.Arrays;", >> + "public class Main {", >> + "public static void main(String[] args) {", >> + "System.out.println(Arrays.toString(args));", >> + "}", >> + "}" >> + }; >> + createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(moduleCode)); >> + } >> + >> /* >> * A class to encapsulate the test results and stuff, with some ease >> * of use methods to check the test results. >> diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java >> --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -246,6 +246,10 @@ >> if (!tr.contains("Error: Could not find or load main class AbsentClass")) { >> throw new RuntimeException("Test Fails"); >> } >> + >> + // Make sure we handle correctly the module long form (--module=) >> + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); >> + ensureNoWarnings(tr); >> } >> >> void ensureNoWarnings(TestResult tr) { >> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Dec 11 12:09:29 2019 -0500 >> @@ -29,6 +29,7 @@ >> * jdk.jlink >> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >> * @run testng BasicTest >> + * @bug 8234076 >> * @summary Basic test of starting an application as a module >> */ >> >> @@ -40,6 +41,8 @@ >> >> import jdk.test.lib.compiler.CompilerUtils; >> import jdk.test.lib.process.ProcessTools; >> +import jdk.test.lib.process.OutputAnalyzer; >> +import jdk.test.lib.Utils; >> >> import org.testng.annotations.BeforeTest; >> import org.testng.annotations.Test; >> @@ -70,6 +73,8 @@ >> // the module main class >> private static final String MAIN_CLASS = "jdk.test.Main"; >> >> + // for Windows specific launcher tests >> + static final boolean IS_WINDOWS = System.getProperty("os.name", "unknown").startsWith("Windows"); >> >> @BeforeTest >> public void compileTestModule() throws Exception { >> @@ -259,4 +264,87 @@ >> assertTrue(exitValue != 0); >> } >> >> + >> + /** >> + * Helper method that creates a ProcessBuilder with command line arguments >> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >> + */ >> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >> + >> + return pb; >> + } >> + >> + /** >> + * Test the ability for the Windows launcher to do proper application argument >> + * detection and expansion, when using the long form module option and all passed in >> + * command line arguments are prefixed with a dash. >> + * >> + * These tests are not expected to work on *nixes, and are ignored. >> + */ >> + public void testWindowsWithLongFormModuleOption() throws Exception { >> + if (!IS_WINDOWS) { >> + return; >> + } >> + >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >> + // We should be able to find the argument --help as an application argument >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help"); >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >> + // We should be able to see argument expansion happen >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + SRC_DIR.resolve(TEST_MODULE).toString() + "\\*.java", >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help") >> + .shouldContain("module-info.java"); >> + } >> + >> + >> + /** >> + * Test that --module= is terminating for VM argument processing just like --module >> + */ >> + public void testLongFormModuleOptionTermination() throws Exception { >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >> + // deemed as application arguments >> + OutputAnalyzer output = ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--module-path=" + dir, >> + "--module=" + mid)) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("argv[ 0] = '--module-path=" + dir) >> + .shouldContain("argv[ 1] = '--module=" + mid); >> + >> + if (IS_WINDOWS) { >> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >> + } >> + >> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >> + // This command line will not work as --module= is terminating and the module will be not found >> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >> + assertTrue(exitValue != 0); >> + } >> } >> >> From: Kumar Srinivasan >> Sent: December 10, 2019 8:43 PM >> To: Nikola Grcevski >> Cc: Henry Jen ; Alan Bateman ; core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> [Resend; cc'ing the group] >> >> Hi Nikola, >> >> Generally looks great to me. I would have moved initModulesDir to TestHelper.createSimpleModule(File dir). >> TestHelper.java contains a collection of test related utilities needed by the launcher, it will help someone >> else use it to create a simple module. >> >> I would have rewritten this >> + ArrayList scratchpad = new ArrayList<>(); >> + scratchpad.add("module test {}"); >> + createFile(new File(testDir, "module-info.java"), scratchpad); >> + scratchpad.clear(); >> + scratchpad.add("package launcher;"); >> + scratchpad.add("import java.util.Arrays;"); >> + scratchpad.add("public class Main {"); >> + scratchpad.add("public static void main(String[] args) {"); >> + scratchpad.add("System.out.println(Arrays.toString(args));"); >> + scratchpad.add("}"); >> + scratchpad.add("}"); >> + createFile(new File(launcherTestDir, "Main.java"), scratchpad); >> >> as follows: >> String a1[] = {"module test{}"}; >> createFile(new File(testDir, "module-info.java", Arrays.asList(a1)); >> >> String a2[] = { >> "package launcher;", >> .... >> .... >> } >> createFile(new File(launcherTestDir, "Main.java"), Arrays.asList(a2)); >> >> This might make the code neater. >> >> Besides that, looks very good. >> >> Thanks >> Kumar >> >> >> On Mon, Dec 9, 2019 at 1:58 PM Nikola Grcevski wrote: >> Hi Henry and Kumar, >> >> Thank you again for the review! I have added the fix to isTerminalOpt and used both of your suggestions to make new tests. >> With native memory tracking enabled, I could actually see a crash on both Linux and Windows without the suggested fix. >> >> I tested the changes again on both Linux and Windows, and the new unit tests fail if isTerminalOpt doesn?t check for ?module= >> as per Henry's suggestion. >> >> I'm attaching the new patch (my apologies for the size) at the bottom of this email after my signature. If I haven't covered >> certain aspects in the new tests please let me know, I'm more than happy to extend them further. I've updated the webrev >> to reflect the latest patch if it's easier to read: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=s0720HUSIGiCLzUS3t4PceseBVGJ30iyO%2F4QLqGKCuI%3D&reserved=0 >> >> Thanks again! >> Nikola >> >> diff -r bd436284147d src/java.base/share/native/libjli/args.c >> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/share/native/libjli/args.c Mon Dec 09 16:08:54 2019 -0500 >> @@ -130,6 +130,8 @@ >> } >> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >> stopExpansion = JNI_TRUE; >> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >> + idx = argsCount; >> } >> } else { >> if (!expectingNoDashArg) { >> @@ -449,6 +451,7 @@ >> return JLI_StrCmp(arg, "-jar") == 0 || >> JLI_StrCmp(arg, "-m") == 0 || >> JLI_StrCmp(arg, "--module") == 0 || >> + JLI_StrCCmp(arg, "--module=") == 0 || >> JLI_StrCmp(arg, "--dry-run") == 0 || >> JLI_StrCmp(arg, "-h") == 0 || >> JLI_StrCmp(arg, "-?") == 0 || >> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >> +++ b/src/java.base/windows/native/libjli/java_md.c Mon Dec 09 16:08:54 2019 -0500 >> @@ -34,6 +34,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include "java.h" >> @@ -1015,6 +1016,17 @@ >> >> // sanity check, match the args we have, to the holy grail >> idx = JLI_GetAppArgIndex(); >> + >> + // First arg index is NOT_FOUND >> + if (idx < 0) { >> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >> + // a different negative index >> + assert (idx == -1); >> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >> + JLI_TraceLauncher("passing arguments as-is.\n"); >> + return NewPlatformStringArray(env, strv, argc); >> + } >> + >> isTool = (idx == 0); >> if (isTool) { idx++; } // skip tool name >> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >> diff -r bd436284147d test/jdk/tools/launcher/ArgsEnvVar.java >> --- a/test/jdk/tools/launcher/ArgsEnvVar.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/ArgsEnvVar.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -37,6 +37,8 @@ >> import java.util.List; >> import java.util.Map; >> import java.util.regex.Pattern; >> +import java.nio.file.Paths; >> +import java.nio.file.Path; >> >> public class ArgsEnvVar extends TestHelper { >> private static File testJar = null; >> @@ -153,6 +155,7 @@ >> List.of("-jar", "test.jar"), >> List.of("-m", "test/Foo"), >> List.of("--module", "test/Foo"), >> + List.of("--module=test/Foo"), >> List.of("--dry-run"), >> List.of("-h"), >> List.of("-?"), >> @@ -241,6 +244,101 @@ >> verifyOptions(List.of("--add-exports", "java.base/jdk.internal.misc=ALL-UNNAMED", "-jar", "test.jar"), tr); >> } >> >> + /** >> + * Helper method to initialize a simple module that just prints the passed in arguments >> + */ >> + private void initModulesDir(File modulesDir) throws IOException { >> + if (modulesDir.exists()) { >> + recursiveDelete(modulesDir); >> + } >> + >> + modulesDir.mkdirs(); >> + >> + File srcDir = new File(modulesDir, "src"); >> + File modsDir = new File(modulesDir, "mods"); >> + File testDir = new File(srcDir, "test"); >> + File launcherTestDir = new File(testDir, "launcher"); >> + srcDir.mkdir(); >> + modsDir.mkdir(); >> + testDir.mkdir(); >> + launcherTestDir.mkdir(); >> + >> + ArrayList scratchpad = new ArrayList<>(); >> + scratchpad.add("module test {}"); >> + createFile(new File(testDir, "module-info.java"), scratchpad); >> + scratchpad.clear(); >> + scratchpad.add("package launcher;"); >> + scratchpad.add("import java.util.Arrays;"); >> + scratchpad.add("public class Main {"); >> + scratchpad.add("public static void main(String[] args) {"); >> + scratchpad.add("System.out.println(Arrays.toString(args));"); >> + scratchpad.add("}"); >> + scratchpad.add("}"); >> + createFile(new File(launcherTestDir, "Main.java"), scratchpad); >> + } >> + >> + @Test >> + // That that we can correctly handle the module longform argument option >> + // when supplied in an argument file >> + public void modulesInArgsFile() throws IOException { >> + File cwd = new File("."); >> + File testModuleDir = new File(cwd, "modules_test"); >> + >> + initModulesDir(testModuleDir); >> + >> + Path SRC_DIR = Paths.get(testModuleDir.getAbsolutePath(), "src"); >> + Path MODS_DIR = Paths.get(testModuleDir.getAbsolutePath(), "mods"); >> + >> + // test module / main class >> + String MODULE_OPTION = "--module=test/launcher.Main"; >> + String TEST_MODULE = "test"; >> + >> + // javac -d mods/test src/test/** >> + TestResult tr = doExec( >> + javacCmd, >> + "-d", MODS_DIR.toString(), >> + "--module-source-path", SRC_DIR.toString(), >> + "--module", TEST_MODULE); >> + >> + if (!tr.isOK()) { >> + System.out.println("test did not compile"); >> + throw new RuntimeException("Error: modules test did not compile"); >> + } >> + >> + // verify the terminating ability of --module= through environment variables >> + File argFile = createArgFile("cmdargs", List.of("--module-path", MODS_DIR.toString(), MODULE_OPTION, "--hello")); >> + env.put(JDK_JAVA_OPTIONS, "@cmdargs"); >> + tr = doExec(env, javaCmd); >> + tr.checkNegative(); >> + tr.contains("Error: Option " + MODULE_OPTION + " in @cmdargs is not allowed in environment variable JDK_JAVA_OPTIONS"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check that specifying --module and --module-path with file works >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs\""); >> + tr.contains("[--hello]"); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // check with reversed --module-path and --module in the arguments file, this will fail, --module= is terminating >> + File argFile1 = createArgFile("cmdargs1", List.of(MODULE_OPTION, "--module-path", MODS_DIR.toString(), "--hello")); >> + tr = doExec(javaCmd, "-Dfile.encoding=UTF-8", "\"@cmdargs1\""); >> + tr.checkNegative(); >> + if (!tr.testStatus) { >> + System.out.println(tr); >> + throw new RuntimeException("test fails"); >> + } >> + >> + // clean-up >> + argFile.delete(); >> + argFile1.delete(); >> + recursiveDelete(testModuleDir); >> + } >> + >> public static void main(String... args) throws Exception { >> init(); >> ArgsEnvVar a = new ArgsEnvVar(); >> diff -r bd436284147d test/jdk/tools/launcher/TestSpecialArgs.java >> --- a/test/jdk/tools/launcher/TestSpecialArgs.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/TestSpecialArgs.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -246,6 +246,10 @@ >> if (!tr.contains("Error: Could not find or load main class AbsentClass")) { >> throw new RuntimeException("Test Fails"); >> } >> + >> + // Make sure we handle correctly the module long form (--module=) >> + tr = doExec(javaCmd, "-XX:NativeMemoryTracking=summary", "--module=jdk.compiler/com.sun.tools.javac.Main", "--help"); >> + ensureNoWarnings(tr); >> } >> >> void ensureNoWarnings(TestResult tr) { >> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Mon Dec 09 16:08:54 2019 -0500 >> @@ -29,6 +29,7 @@ >> * jdk.jlink >> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >> * @run testng BasicTest >> + * @bug 8234076 >> * @summary Basic test of starting an application as a module >> */ >> >> @@ -40,6 +41,8 @@ >> >> import jdk.test.lib.compiler.CompilerUtils; >> import jdk.test.lib.process.ProcessTools; >> +import jdk.test.lib.process.OutputAnalyzer; >> +import jdk.test.lib.Utils; >> >> import org.testng.annotations.BeforeTest; >> import org.testng.annotations.Test; >> @@ -70,6 +73,8 @@ >> // the module main class >> private static final String MAIN_CLASS = "jdk.test.Main"; >> >> + // for Windows specific launcher tests >> + static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=voXq4xFGp38yvWJruKJslQY%2FOCiJXAxoBJz%2FWpkgM80%3D&reserved=0", "unknown").startsWith("Windows"); >> >> @BeforeTest >> public void compileTestModule() throws Exception { >> @@ -259,4 +264,87 @@ >> assertTrue(exitValue != 0); >> } >> >> + >> + /** >> + * Helper method that creates a ProcessBuilder with command line arguments >> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >> + */ >> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >> + >> + return pb; >> + } >> + >> + /** >> + * Test the ability for the Windows launcher to do proper application argument >> + * detection and expansion, when using the long form module option and all passed in >> + * command line arguments are prefixed with a dash. >> + * >> + * These tests are not expected to work on *nixes, and are ignored. >> + */ >> + public void testWindowsWithLongFormModuleOption() throws Exception { >> + if (!IS_WINDOWS) { >> + return; >> + } >> + >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >> + // We should be able to find the argument --help as an application argument >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help"); >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >> + // We should be able to see argument expansion happen >> + ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", >> + "--help")) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("F--help") >> + .shouldContain("module-info.java"); >> + } >> + >> + >> + /** >> + * Test that --module= is terminating for VM argument processing just like --module >> + */ >> + public void testLongFormModuleOptionTermination() throws Exception { >> + String dir = MODS_DIR.toString(); >> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >> + >> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >> + // deemed as application arguments >> + OutputAnalyzer output = ProcessTools.executeProcess( >> + createProcessWithLauncherDebugging( >> + "--module-path=" + dir, >> + "--module=" + mid, >> + "--module-path=" + dir, >> + "--module=" + mid)) >> + .outputTo(System.out) >> + .errorTo(System.out) >> + .shouldContain("argv[ 0] = '--module-path=" + dir) >> + .shouldContain("argv[ 1] = '--module=" + mid); >> + >> + if (IS_WINDOWS) { >> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >> + } >> + >> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >> + // This command line will not work as --module= is terminating and the module will be not found >> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >> + assertTrue(exitValue != 0); >> + } >> } >> >> >> From: Kumar Srinivasan >> Sent: December 7, 2019 10:28 PM >> To: Henry Jen >> Cc: Nikola Grcevski ; Alan Bateman ; mailto:core-libs-dev at openjdk.java.net >> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >> >> Hi, >> >> The launcher fix looks good, despite the launcher fix being simple, please note, >> it sometimes requires a lot more effort to write a test for it, please read on.... >> >> Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my memory and I recalled >> this change for VM's native memory tracking. >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk9%2Fjdk9%2Fjdk%2Ffile%2F37d1442d53bc%2Ftest%2Ftools%2Flauncher%2FTestSpecialArgs.java%23l243&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=vmbejj3xW9nZ%2FO9PiQByxWi1CBBnnqos%2Fm6EyJsuy3M%3D&reserved=0 >> Inspecting the above changeset, we might have to add another test for JVM native memory tracking, >> since this is a terminal argument. >> >> Maybe TestHelper could create a simple module, which prints its args, >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2F31882abe1494%2Ftest%2Fjdk%2Ftools%2Flauncher%2FTestHelper.java&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=K2YKHqi7mOejpa8B8RTQhFxOg2gtuTRunx8%2Bv3pDmso%3D&reserved=0 >> >> Kumar Srinivasan >> >> On Fri, Dec 6, 2019 at 2:44 PM Henry Jen wrote: >> Thanks for the work, the test case covers that when ?module= is used before other options, which is good. >> >> But we need another to make sure that when ?module= is put in an argument file or environment variable, that should not be allowed. The fix is simple, we need to add that to isTerminalOp() method. >> >> Cheers, >> Henry >> >>> On Dec 6, 2019, at 12:28 PM, Nikola Grcevski wrote: >>> >>> Thank you Henry! >>> >>> I have modified the fix in checkArg to use JLI_StrCCmp as suggested below and I have extended the BasicTest.java (in test/jdk/tools/launcher/modules/basic) with few additional tests. >>> >>> I don't have author status yet, therefore I'm attaching the patch right after my signature. I also updated my external webrev if that's easier to review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrcevski.github.io%2FJDK-8234076%2Fwebrev%2F&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=s0720HUSIGiCLzUS3t4PceseBVGJ30iyO%2F4QLqGKCuI%3D&reserved=0) >>> >>> Thanks again to everyone for your help with this bug. If there are any additional comments or suggestions please let me know. >>> Nikola >>> >>> diff -r bd436284147d src/java.base/share/native/libjli/args.c >>> --- a/src/java.base/share/native/libjli/args.c Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/src/java.base/share/native/libjli/args.c Fri Dec 06 15:11:36 2019 -0500 >>> @@ -130,6 +130,8 @@ >>> } >>> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>> stopExpansion = JNI_TRUE; >>> + } else if (JLI_StrCCmp(arg, "--module=") == 0) { >>> + idx = argsCount; >>> } >>> } else { >>> if (!expectingNoDashArg) { >>> diff -r bd436284147d src/java.base/windows/native/libjli/java_md.c >>> --- a/src/java.base/windows/native/libjli/java_md.c Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/src/java.base/windows/native/libjli/java_md.c Fri Dec 06 15:11:36 2019 -0500 >>> @@ -34,6 +34,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #include >>> #include "java.h" >>> @@ -1015,6 +1016,17 @@ >>> >>> // sanity check, match the args we have, to the holy grail >>> idx = JLI_GetAppArgIndex(); >>> + >>> + // First arg index is NOT_FOUND >>> + if (idx < 0) { >>> + // The only allowed value should be NOT_FOUND (-1) unless another change introduces >>> + // a different negative index >>> + assert (idx == -1); >>> + JLI_TraceLauncher("Warning: first app arg index not found, %d\n", idx); >>> + JLI_TraceLauncher("passing arguments as-is.\n"); >>> + return NewPlatformStringArray(env, strv, argc); >>> + } >>> + >>> isTool = (idx == 0); >>> if (isTool) { idx++; } // skip tool name >>> JLI_TraceLauncher("AppArgIndex: %d points to %s\n", idx, stdargs[idx].arg); >>> diff -r bd436284147d test/jdk/tools/launcher/modules/basic/BasicTest.java >>> --- a/test/jdk/tools/launcher/modules/basic/BasicTest.java Wed Nov 20 08:12:14 2019 +0800 >>> +++ b/test/jdk/tools/launcher/modules/basic/BasicTest.java Fri Dec 06 15:11:36 2019 -0500 >>> @@ -29,6 +29,7 @@ >>> * jdk.jlink >>> * @build BasicTest jdk.test.lib.compiler.CompilerUtils >>> * @run testng BasicTest >>> + * @bug 8234076 >>> * @summary Basic test of starting an application as a module >>> */ >>> >>> @@ -40,6 +41,8 @@ >>> >>> import jdk.test.lib.compiler.CompilerUtils; >>> import jdk.test.lib.process.ProcessTools; >>> +import jdk.test.lib.process.OutputAnalyzer; >>> +import jdk.test.lib.Utils; >>> >>> import org.testng.annotations.BeforeTest; >>> import org.testng.annotations.Test; >>> @@ -70,6 +73,8 @@ >>> // the module main class >>> private static final String MAIN_CLASS = "jdk.test.Main"; >>> >>> + // for Windows specific launcher tests >>> + static final boolean IS_WINDOWS = System.getProperty("https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fos.name&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=voXq4xFGp38yvWJruKJslQY%2FOCiJXAxoBJz%2FWpkgM80%3D&reserved=0", "unknown").startsWith("Windows"); >>> >>> @BeforeTest >>> public void compileTestModule() throws Exception { >>> @@ -259,4 +264,87 @@ >>> assertTrue(exitValue != 0); >>> } >>> >>> + >>> + /** >>> + * Helper method that creates a ProcessBuilder with command line arguments >>> + * while setting the _JAVA_LAUNCHER_DEBUG environment variable. >>> + */ >>> + private ProcessBuilder createProcessWithLauncherDebugging(String... cmds) { >>> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(cmds)); >>> + pb.environment().put("_JAVA_LAUNCHER_DEBUG", "true"); >>> + >>> + return pb; >>> + } >>> + >>> + /** >>> + * Test the ability for the Windows launcher to do proper application argument >>> + * detection and expansion, when using the long form module option and all passed in >>> + * command line arguments are prefixed with a dash. >>> + * >>> + * These tests are not expected to work on *nixes, and are ignored. >>> + */ >>> + public void testWindowsWithLongFormModuleOption() throws Exception { >>> + if (!IS_WINDOWS) { >>> + return; >>> + } >>> + >>> + String dir = MODS_DIR.toString(); >>> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --help >>> + // We should be able to find the argument --help as an application argument >>> + ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + "--help")) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("F--help"); >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS <...src/test>/*.java --help >>> + // We should be able to see argument expansion happen >>> + ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + SRC_DIR.resolve(TEST_MODULE).toString() + "file://*.java", >>> + "--help")) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("F--help") >>> + .shouldContain("module-info.java"); >>> + } >>> + >>> + >>> + /** >>> + * Test that --module= is terminating for VM argument processing just like --module >>> + */ >>> + public void testLongFormModuleOptionTermination() throws Exception { >>> + String dir = MODS_DIR.toString(); >>> + String mid = TEST_MODULE + "/" + MAIN_CLASS; >>> + >>> + // java --module-path=mods --module=$TESTMODULE/$MAINCLASS --module-path=mods --module=$TESTMODULE/$MAINCLASS >>> + // The first --module= will terminate the VM arguments processing. The second pair of module-path and module will be >>> + // deemed as application arguments >>> + OutputAnalyzer output = ProcessTools.executeProcess( >>> + createProcessWithLauncherDebugging( >>> + "--module-path=" + dir, >>> + "--module=" + mid, >>> + "--module-path=" + dir, >>> + "--module=" + mid)) >>> + .outputTo(System.out) >>> + .errorTo(System.out) >>> + .shouldContain("argv[ 0] = '--module-path=" + dir) >>> + .shouldContain("argv[ 1] = '--module=" + mid); >>> + >>> + if (IS_WINDOWS) { >>> + output.shouldContain("F--module-path=" + dir).shouldContain("F--module=" + mid); >>> + } >>> + >>> + // java --module=$TESTMODULE/$MAINCLASS --module-path=mods >>> + // This command line will not work as --module= is terminating and the module will be not found >>> + int exitValue = exec("--module=" + mid, "--module-path" + dir); >>> + assertTrue(exitValue != 0); >>> + } >>> } >>> >>> >>> -----Original Message----- >>> From: Henry Jen >>> Sent: December 6, 2019 12:03 AM >>> To: Nikola Grcevski >>> Cc: Kumar Srinivasan ; Alan Bateman ; mailto:mailto:core-libs-dev at openjdk.java.net >>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>> >>> >>>> On Dec 5, 2019, at 5:57 PM, Nikola Grcevski wrote: >>>> >>>> Hello all again! >>>> >>>> Based on the suggestion by Kumar I made the following small patch to checkArg src/java.base/share/native/libjli/args.c: >>>> >>>> --- a/src/java.base/share/native/libjli/args.c >>>> +++ b/src/java.base/share/native/libjli/args.c >>>> @@ -130,6 +130,8 @@ static void checkArg(const char *arg) { >>>> } >>>> } else if (JLI_StrCmp(arg, "--disable- at files") == 0) { >>>> stopExpansion = JNI_TRUE; >>>> + } else if (JLI_StrNCmp(arg, "--module=", 9) == 0) { >>> >>> I would suggest use JLI_StrCCmp as in java.c. I think combine this fix with origin crash prevention for -1 is a safe approach and most compatible to current behavior. >>> >>> BTW, we need the patch to be hosted on https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=QfNlx4YAu51NF%2BracTH2pN4T1NHuYCZUkvl2nSMB9C0%3D&reserved=0 or you can attach the patch to the review thread if you are not yet an author. >>> >>> Cheers, >>> Henry >>> >>> >>>> + idx = argsCount; >>>> } >>>> } else { >>>> if (!expectingNoDashArg) { >>>> >>>> The change is in common code and simply checks for the usage of --module= and deems the next argument as the start of the application arguments. I can confirm that using -m instead of --module doesn't allow for the = separator to be used, so we only need to check for --module= if this is a desired change. >>>> >>>> I tested with various combinations on the command line and I couldn't find a set of arguments ordering that breaks the terminating quality of --module. >>>> >>>> I also performed series of tests to try to break the argument expansion on Windows with this change, but it worked in all instances. The testcase is working correctly with this change, as well as the javac launcher command as proposed by Kumar (java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java). >>>> >>>> I ran all the launcher tests on both Windows and Linux and all tests pass. >>>> >>>> Please let me know if this is a preferred approach to address this bug or if you think there's a potential problem with the change. If this is an acceptable fix I can create new webrev with set of tests for the various edge cases I tried, and new launcher specific tests that ensure argument expansion is performed on Windows with this module usage. >>>> >>>> Thank you, >>>> Nikola >>>> >>>> -----Original Message----- >>>> From: Henry Jen >>>> Sent: December 4, 2019 8:26 PM >>>> To: Kumar Srinivasan ; Alan Bateman >>>> ; Nikola Grcevski >>>> >>>> Cc: mailto:mailto:core-libs-dev at openjdk.java.net >>>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>>> >>>>> On Dec 4, 2019, at 1:15 PM, Kumar Srinivasan wrote: >>>>> >>>>> Hi Nikola, >>>>> >>>>> It looks ok to me, I will leave it to Henry and Alan to bless this. >>>>> >>>>> IMHO: I think we should fix it correctly now than later, I don't >>>>> think it is all that difficult AFAICT all the launcher has to do is >>>>> identify "--module==", then the next argument is the first index. >>>>> >>>> >>>> I don?t disagree, if we can decide whether ?module= is allowed. Based on my understanding and the document for java[1], the ?module= is not necessarily correct. >>>> >>>> If we decided to accept it, the fix would be make sure the index set correctly as Kumar suggested, and the fix can be relatively simple. >>>> >>>> FWIW, it?s still possible the index is NOT_FOUND if there is no main class specified, but that should never cause crash as if no main class is found, the launcher should either execute other terminal argument or display help. >>>> >>>> I agree the fix is not complete as it only make sure no crash can happen. It doesn?t actually make ?module= illegal and show help in case of that. At this point, there is a discrepancy in launcher code regard ?module usage, and we need to fix that. >>>> >>>> I?ll let Alan to comment about the ?module option usage. >>>> >>>> The webrev looks good to me, although I would like to see the test be more close to other arguments processing test, but since this can only be reproduced with ?module= usage, I assume this is not bad. >>>> >>>> [1] >>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs >>>> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Foracle.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086613230&sdata=OtYRav6tKD%2BthebvIhi376aRMVyPPRkrXnT8CDz9oWQ%3D&reserved=0 >>>> &data=02%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >>>> e9b608d77a0999a8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63711205 >>>> 3962510892&sdata=bh5Phj2Ti%2B%2FWKLK9VfWXIFXVfTRDBOjSkYTkrQ5k%2FvY >>>> %3D&reserved=0 >>>> >>>>> Kumar >>>>> >>>>> On Tue, Dec 3, 2019 at 5:29 PM Nikola Grcevski wrote: >>>>> Hi Henry and Kumar, >>>>> >>>>> Thanks again for your comments! I have updated the test to be part of test/jdk/tools/launcher/modules/basic, it took a lot less code to achieve the same amount of testing. I added a new test method inside BasicTest.java and tested on both Windows and Linux. >>>>> >>>>> Please find my updated webrev here for your review: >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrc >>>>> e >>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086623229&sdata=FSUfXSdZEk%2F%2BRVJQ9eUN3iA1Sibo9DZ5BCi5GmDHv6Y%3D&reserved=0 >>>>> c >>>>> evski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824629806&sdata=7VMZnWzyp9ZSG%2FzVaxUMFUuqeikdR%2FIvDGg2p0AqRTU%3D&reserved=0 >>>>> f >>>>> 141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=ee0dSSSJ >>>>> % >>>>> 2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>>> >>>>> Cheers, >>>>> >>>>> Nikola >>>>> >>>>> -----Original Message----- >>>>> From: Henry Jen >>>>> Sent: December 3, 2019 11:39 AM >>>>> To: Kumar Srinivasan >>>>> Cc: Nikola Grcevski ; Alan Bateman >>>>> ; mailto:mailto:core-libs-dev at openjdk.java.net >>>>> Subject: Re: [EXTERNAL] JDK-8234076 bug fix candidate >>>>> >>>>> Kumar, >>>>> >>>>> Great to have you look at this, you are correct, this patch doesn?t address the wildcard expansion issue, but only to address the potential crash if a main class is not specified as Nikola pointed out. >>>>> >>>>> We definitely need a follow up to fix wildcard expansion. The pointer to simplify the test is helpful, it would make the test more obvious. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>>> On Dec 3, 2019, at 7:14 AM, Kumar Srinivasan wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Sorry for chiming in late in the review process, for what it's worth.... >>>>>> >>>>>> 1. It is not at all clear to me if this solution is correct, yes it averts the problem of not finding the main-class >>>>>> and subsequent crash, but it does not address wildcard arguments expansion. >>>>>> >>>>>> What if we have >>>>>> % java --module-path=mods --module=jdk.compiler/com.sun.tools.javac.Main *.java >>>>>> Where jdk.compiler is a java compiler implementation (javac). >>>>>> The user would expect the above compiler module to build all the .java files in that directory, >>>>>> and this fix will not address that. >>>>>> >>>>>> Some background: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu >>>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgs.openjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086623229&sdata=QqUa6h6WjyW2%2Fp9SktM7nLZzEnv0K1%2BAdFXkDQ8dI5s%3D&reserved=0 >>>>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824639758&sdata=mH19URBhYu0rW%2Bpsl91V9e3TcwPD%2BDX0YSNbXao5H8o%3D&reserved=0 >>>>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=b >>>>>> 0wl3x8AVS%2BJIrHHG5ivM%2FZtfgn2IRno2AauSVcRWlg%3D&reserved=0 >>>>>> Please see all the related bugs in the above JIRA issue. >>>>>> >>>>>> Paragraph #6 in this interview surmises the wild card behavior on Windows: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww. >>>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fprinceton.edu&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086623229&sdata=cdMin3jUqzpvkWSzRgaSKWqYW8mhXx570UeetH7AbSY%3D&reserved=0 >>>>>> 2%7C01%7CNikola.Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824649719&sdata=%2FUxEEDQrTgIk2Y%2Bd%2FPz67ocYVqRXncW%2FsITD%2BWpemSY%3D&reserved=0 >>>>>> 92228c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797 >>>>>> 544&sdata=D1gprSmaQp1v9BB07EmYsX1%2FF4n9CGXMl8yIDJdnQ%2Bg%3D& >>>>>> ;reserved=0 >>>>>> >>>>>> 2. Though the arguments related tests are in Aaarghs.java the modules related tests for the launcher are at: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg >>>>>> .https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086623229&sdata=NwkNTOf2qiPKtUctl7wecn0Oxu75cMubH1HzSMq2vFM%3D&reserved=0 >>>>>> Ftools%2Flauncher%2Fmodules%2Fbasic&data=02%7C01%7CNikola.Grcevs >>>>>> ki%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824659675&sdata=HvTbDg9uHe5WDu0OVcH%2BPF5mgYHWv2OUHYAWY2EheFo%3D&reserved=0 >>>>>> 41af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=L4SzTviE >>>>>> WgKoBrrZ2nU%2BPJFhairYv8ZPDqW%2FNtAXEN0%3D&reserved=0 >>>>>> Using the modules test framework may make the test simpler. >>>>>> >>>>>> Kumar Srinivasan >>>>>> >>>>>> >>>>>> On Mon, Dec 2, 2019 at 11:34 AM Nikola Grcevski wrote: >>>>>> Hi Alan and Henry, >>>>>> >>>>>> Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed with a dash. Later on the arguments are validated, however we might crash before then on Windows because of the negative index access. In this case, the customer command was valid (modules usage) and the program runs successfully. >>>>>> >>>>>> I created a webrev here for the change, including a new test in Arrrghs.java: >>>>>> >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgr >>>>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcevski.github.io&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7C5f3bed3f0f724724dd3608d77f07a29f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117543086623229&sdata=0Xpbx25XswIubMpWSiVzGRIisFvP2dNh6z8h%2F0kFm7Q%3D&reserved=0 >>>>>> .Grcevski%https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7CNikola.Grcevski%40microsoft.com%7Cefcfbecd0afc44ef1ee808d77ddb7496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116253824669630&sdata=XX0qBV1e5ucqPSL%2B4YciHNXR29evREuIRDFwTSxaqHU%3D&reserved=0 >>>>>> 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C637111061023797544&sdata=e >>>>>> e0dSSSJ%2BXZogFtgPl8xFcUZ0P%2BX%2FR2G7x%2F4jjqiRIE%3D&reserved=0 >>>>>> >>>>>> I copied the test validation and assertion style of other code inside the test class. >>>>>> >>>>>> Please let me know if you have any comments or suggestions. >>>>>> >>>>>> Thanks again! >>>>>> >>>>>> -----Original Message----- >>>>>> From: Henry Jen >>>>>> Sent: December 2, 2019 12:26 PM >>>>>> To: Alan Bateman >>>>>> Cc: Nikola Grcevski ; >>>>>> mailto:mailto:core-libs-dev at openjdk.java.net >>>>>> Subject: [EXTERNAL] Re: JDK-8234076 bug fix candidate >>>>>> >>>>>> The fix looks reasonable to me, basically, if the command argument format is not legal, it?s possible we won?t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. >>>>>> >>>>>> I think we should add a test case for this, probably in test/jdk/tools/launcher/Arrrghs.java. >>>>>> >>>>>> As I understand it, the argument validation is done in a later stage after calling JLI_Launch. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> >>>>>>> On Dec 2, 2019, at 2:12 AM, Alan Bateman wrote: >>>>>>> >>>>>>> On 20/11/2019 19:42, Nikola Grcevski wrote: >>>>>>>> : >>>>>>>> >>>>>>>> Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. >>>>>>>> >>>>>>> I think you're in the right area but I would have expected the arg index to 0 here. Henry Jen (cc'ed) might have some comments on this. >>>>>>> >>>>>>> -Alan > From chris.hegarty at oracle.com Thu Dec 12 15:46:41 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 Dec 2019 15:46:41 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <6C8BC7CC-6210-4DD3-BBAB-A7F52C1F8A07@oracle.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> <12784CB4-7357-4F19-B307-1AE8354D40F7@oracle.com> <523d08f4-5604-3a2d-7245-733a5fdc028b@oracle.com> <6C8BC7CC-6210-4DD3-BBAB-A7F52C1F8A07@oracle.com> Message-ID: <54E4ADE2-0FCF-4FE6-9F92-7DC3366E5AB1@oracle.com> > On 11 Dec 2019, at 16:43, Paul Sandoz wrote: > > Looks very good, +1 This looks very good to me too. Nice work. -Chris. > Paul. > >> On Dec 11, 2019, at 7:39 AM, Maurizio Cimadamore wrote: >> >> I went ahead and created a new revision: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6/ >> Delta from latest (v5) here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6_delta/ >> No javadoc chnages here. >> >> Summary of changes: >> >> * addressed Paul feedback on MemoryScope >> * on further testing, I found two issues on var handle construction from layouts: >> - PathElement.sequenceElement(long) does not add the sequence element offset to the new path element offset >> - the layout path machiner does not check that strides are a multiple of alignment - this allow creation of 'bad' var handles which are guaranteed not to work in for all indices - consider this layout: >> >> var seq = MemoryLayout.ofSequence(JAVA_SHORT.withBitAlignment(32)); >> >> The above layout has an issue: the element requests 32-bit alignent, but the elements are only 16 bits apart. So, for odd access indices, there will be an alignment exception. >> >> If you create a VarHandle with combinators, strides are checked against alignment, so it is not possible to obtain a VarHandle for the above layout. But with the Layout API is possible, because the layout path machinery does not enforce same restriction. >> >> I've now fixed the code in LayoutPath (most of the changes are due to a rename from 'scale' to 'stride') to take care of this. >> >> Bonus point: since offsets must satisfy alignment, and all strides must also satisfy same alignment - it follows that whetever offset can come out of the VH index machinery, it will be aligned. This means that, in the VarHandle code we can just check the base address. In other words, the memory location accessed by the VarHandle will be something like (below N denotes alignment, s1..sn are strides, O1..Om are offsets): >> >> >> >> address = base + offset >> >> where: >> >> offset = N * s1 * i1 + N * s2 * i2 ... + N * sn * in + N * O1 + N * O2 + ... N * Om >> = N * (s1 * i1 + s2 * i2 ... + sn * in + O1 + O2 + ... Om) >> = N * K >> >> >> >> So, in order to show that the "address" is aligned, we only have to show that "base" is a multiple of N. This helps a lot, as e.g. when looping through a native array, the base array stays the same, and only the offset part changes, which means C2 will have no troubles hoisting out the alignment check out of the loop. >> >> >> As things appear stable, I do not plan to make any other changes to the implementation/API ahead of integration, unless there's something critical which reviewers think should be fixed. >> >> Thanks >> Maurizio >> >> >> >> >> On 11/12/2019 00:13, Maurizio Cimadamore wrote: >>> >>> On 10/12/2019 18:45, Paul Sandoz wrote: >>>> MemoryScope changes look good. >>>> >>>> In j.u.concurrent we use ExceptionInInitializerError in the static blocks when there is an error looking up the VH, >>>> >>>> FWIW close can also fail because it has already been closed but the exception message does not distinguish between the two states (active or already closed). >>>> Paul. >>>> >>> Hi Paul, >>> >>> would something like this be satisfactory? >>> >>> >>> diff -r 50ef46599c56 src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java >>> --- a/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java Tue Dec 10 16:28:03 2019 +0000 >>> +++ b/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java Wed Dec 11 00:12:20 2019 +0000 >>> @@ -48,7 +48,7 @@ >>> try { >>> COUNT_HANDLE = MethodHandles.lookup().findVarHandle(MemoryScope.class, "activeCount", int.class); >>> } catch (Throwable ex) { >>> - throw new IllegalStateException(ex); >>> + throw new ExceptionInInitializerError(ex); >>> } >>> } >>> >>> @@ -107,6 +107,9 @@ >>> >>> void close() { >>> if (!COUNT_HANDLE.compareAndSet(this, UNACQUIRED, CLOSED)) { >>> + //first check if already closed... >>> + checkAliveConfined(); >>> + //...if not, then we have acquired views that are still active >>> throw new IllegalStateException("Cannot close a segment that has active acquired views"); >>> } >>> if (cleanupAction != null) { >>> >>> >>> >>> If you need a full webrev please let me know. >>> >>> Thanks >>> Maurizio >>> > From Roger.Riggs at oracle.com Thu Dec 12 15:46:23 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 12 Dec 2019 10:46:23 -0500 Subject: 8235668: LineNumberReader#getLineNumber() returns wrong line number (one fewer) in Lucene test In-Reply-To: <0B1EABC7-4962-430D-B6F1-0C72516EA22F@oracle.com> References: <0B1EABC7-4962-430D-B6F1-0C72516EA22F@oracle.com> Message-ID: <058002bc-4e78-50d2-b9c0-8cb91c662e49@oracle.com> Hi Brian, ok, the revert looks fine. Roger On 12/11/19 7:08 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8235668 > http://cr.openjdk.java.net/~bpb/8235668/webrev.00/ > > Due to the problems reported in [1], in the interest of not changing longstanding behavior, we would like to revert the fix for [2], despite the fact that it makes the behavior of LineNumberReader more consistent with its specification. An issue [3] was filed to revisit this situation in the future. > > The changes made to revert BufferedReader were done manually but the other two files were straight reversions to the previous delta. Note that the copyright date ?2019? is removed from the test. Is that correct? > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8235668 > [2] https://bugs.openjdk.java.net/browse/JDK-8230342 > [3] https://bugs.openjdk.java.net/browse/JDK-8235792 From Alan.Bateman at oracle.com Thu Dec 12 16:04:39 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Dec 2019 16:04:39 +0000 Subject: 8235668: LineNumberReader#getLineNumber() returns wrong line number (one fewer) in Lucene test In-Reply-To: <0B1EABC7-4962-430D-B6F1-0C72516EA22F@oracle.com> References: <0B1EABC7-4962-430D-B6F1-0C72516EA22F@oracle.com> Message-ID: <0dfef36f-2df5-55cd-c654-6b15eb6a48a1@oracle.com> On 12/12/2019 00:08, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8235668 > http://cr.openjdk.java.net/~bpb/8235668/webrev.00/ > > Due to the problems reported in [1], in the interest of not changing longstanding behavior, we would like to revert the fix for [2], despite the fact that it makes the behavior of LineNumberReader more consistent with its specification. An issue [3] was filed to revisit this situation in the future. > > The changes made to revert BufferedReader were done manually but the other two files were straight reversions to the previous delta. Note that the copyright date ?2019? is removed from the test. Is that correct? > Thanks for doing this, it looks okay to me. -Alan From alexey.semenyuk at oracle.com Thu Dec 12 16:42:17 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 12 Dec 2019 11:42:17 -0500 Subject: RFR (trivial): 8235833: PosixPlatform.cpp should not include sysctl.h In-Reply-To: <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> References: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> Message-ID: <9238b422-869f-ea36-552a-fd33b87391cd@oracle.com> Looks good. - Alexey On 12/12/2019 8:23 AM, Yasumasa Suenaga wrote: > Hi Andrew, > > I can see same error whether --disable-precompiled-headers or not. > So I filed it to JBS and uploaded webrev. > Could you review it? > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8235833 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235833/webrev.00/ > > It works fine on Fedora 31. > I've pushed it to submit repo. I believe it passes all tests. > > > Thanks, > > Yasumasa > > > On 2019/12/12 19:25, Andrew Haley wrote: >> On 12/12/19 9:31 AM, Yasumasa Suenaga wrote: >>> AFAICS sysctl.h provides `sysctl()` and some macros, but they are >>> not used in PosixPlatform.cpp . >>> In fact, I did not see any error when I remove `#include >>> ` from it. >> >> You probably won't see an error unless you configure with >> --disable-precompiled-headers. Please try that, and we can then >> consider removing that #include. >> From huizhe.wang at oracle.com Thu Dec 12 19:32:03 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 12 Dec 2019 11:32:03 -0800 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider In-Reply-To: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> Message-ID: <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> Hi Naoto, Does the new code block, 4156 - 4174, need a conditional statement, that is when it's for a standard timezon? Before this change, or before a custom TimeZoneNameProvider is attempted, the process didn't need to loop through regionIds to add display names. Thanks, Joe On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8235238 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ > > The fix will retrieve the custom zone names from the time zone name > provider, for the custom ZoneRulesProvider implementations. > > Naoto From naoto.sato at oracle.com Thu Dec 12 20:31:32 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Dec 2019 12:31:32 -0800 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider In-Reply-To: <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> Message-ID: <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com> Hi Joe, Thank you for the review. The original code loops through zoneStrings array, and if the id exists in regionIds, then adds their display names in the tree (4142-4154). This process is not altered with my change. My change made regionIds mutable (line 4127) so that after the loop, it only contains custom ids by calling remove() (line 4144). Thus the new added block will only retrieve names for custom ids. Or am I missing something in your comment? Naoto On 12/12/19 11:32 AM, Joe Wang wrote: > Hi Naoto, > > Does the new code block, 4156 - 4174, need a conditional statement, that > is when it's for a standard timezon? Before this change, or before a > custom TimeZoneNameProvider is attempted, the process didn't need to > loop through regionIds to add display names. > > Thanks, > Joe > > On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8235238 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ >> >> The fix will retrieve the custom zone names from the time zone name >> provider, for the custom ZoneRulesProvider implementations. >> >> Naoto > From huizhe.wang at oracle.com Thu Dec 12 20:42:58 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 12 Dec 2019 12:42:58 -0800 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider In-Reply-To: <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com> References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com> Message-ID: <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com> On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > Thank you for the review. > > The original code loops through zoneStrings array, and if the id > exists in regionIds, then adds their display names in the tree > (4142-4154). This process is not altered with my change. My change > made regionIds mutable (line 4127) so that after the loop, it only > contains custom ids by calling remove() (line 4144). Thus the new > added block will only retrieve names for custom ids. Or am I missing > something in your comment? Ok, that's what I was looking for. Thanks for the explanation. The changes look good to me then. Best, Joe > > Naoto > > On 12/12/19 11:32 AM, Joe Wang wrote: >> Hi Naoto, >> >> Does the new code block, 4156 - 4174, need a conditional statement, >> that is when it's for a standard timezon? Before this change, or >> before a custom TimeZoneNameProvider is attempted, the process didn't >> need to loop through regionIds to add display names. >> >> Thanks, >> Joe >> >> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix for the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8235238 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ >>> >>> The fix will retrieve the custom zone names from the time zone name >>> provider, for the custom ZoneRulesProvider implementations. >>> >>> Naoto >> From Roger.Riggs at oracle.com Thu Dec 12 21:37:34 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 12 Dec 2019 16:37:34 -0500 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider In-Reply-To: <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com> References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com> <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com> Message-ID: <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com> +1 There's quite a bit of work being done to get the eligible stings as part of each parse but it doesn't look easy to re-use it acrosses parses. Roger On 12/12/19 3:42 PM, Joe Wang wrote: > > > On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> Thank you for the review. >> >> The original code loops through zoneStrings array, and if the id >> exists in regionIds, then adds their display names in the tree >> (4142-4154). This process is not altered with my change. My change >> made regionIds mutable (line 4127) so that after the loop, it only >> contains custom ids by calling remove() (line 4144). Thus the new >> added block will only retrieve names for custom ids. Or am I missing >> something in your comment? > > Ok, that's what I was looking for. Thanks for the explanation. The > changes look good to me then. > > Best, > Joe > >> >> Naoto >> >> On 12/12/19 11:32 AM, Joe Wang wrote: >>> Hi Naoto, >>> >>> Does the new code block, 4156 - 4174, need a conditional statement, >>> that is when it's for a standard timezon? Before this change, or >>> before a custom TimeZoneNameProvider is attempted, the process >>> didn't need to loop through regionIds to add display names. >>> >>> Thanks, >>> Joe >>> >>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the fix for the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8235238 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ >>>> >>>> The fix will retrieve the custom zone names from the time zone name >>>> provider, for the custom ZoneRulesProvider implementations. >>>> >>>> Naoto >>> > From naoto.sato at oracle.com Thu Dec 12 22:07:15 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 12 Dec 2019 14:07:15 -0800 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider In-Reply-To: <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com> References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com> <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com> <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com> Message-ID: <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com> Sorry, I seem to have posted an old webrev, which included unnecessary retrieval of the generic name (4168-4173 in v.00). Here is the correct webrev: http://cr.openjdk.java.net/~naoto/8235238/webrev.01/ Naoto On 12/12/19 1:37 PM, Roger Riggs wrote: > +1 > > There's quite a bit of work being done to get the eligible stings > as part of each parse but it doesn't look easy to re-use it acrosses > parses. > > Roger > > > On 12/12/19 3:42 PM, Joe Wang wrote: >> >> >> On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote: >>> Hi Joe, >>> >>> Thank you for the review. >>> >>> The original code loops through zoneStrings array, and if the id >>> exists in regionIds, then adds their display names in the tree >>> (4142-4154). This process is not altered with my change. My change >>> made regionIds mutable (line 4127) so that after the loop, it only >>> contains custom ids by calling remove() (line 4144). Thus the new >>> added block will only retrieve names for custom ids. Or am I missing >>> something in your comment? >> >> Ok, that's what I was looking for. Thanks for the explanation. The >> changes look good to me then. >> >> Best, >> Joe >> >>> >>> Naoto >>> >>> On 12/12/19 11:32 AM, Joe Wang wrote: >>>> Hi Naoto, >>>> >>>> Does the new code block, 4156 - 4174, need a conditional statement, >>>> that is when it's for a standard timezon? Before this change, or >>>> before a custom TimeZoneNameProvider is attempted, the process >>>> didn't need to loop through regionIds to add display names. >>>> >>>> Thanks, >>>> Joe >>>> >>>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8235238 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ >>>>> >>>>> The fix will retrieve the custom zone names from the time zone name >>>>> provider, for the custom ZoneRulesProvider implementations. >>>>> >>>>> Naoto >>>> >> > From verghese at amazon.com Thu Dec 12 22:07:59 2019 From: verghese at amazon.com (Verghese, Clive) Date: Thu, 12 Dec 2019 22:07:59 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> Message-ID: <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> Hi, Requesting review for JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger reaches this class and uses the toString function to print the class. Steps to reproduce this is attached in the JBS issue. Regards, Clive Verghese From maurizio.cimadamore at oracle.com Thu Dec 12 23:05:38 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 12 Dec 2019 23:05:38 +0000 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <7765b06b-acf2-f11f-980e-33af4ca3934c@oracle.com> <14719046-4d92-d9ff-c59e-924e10212edf@oracle.com> <24fdb620-2b26-0647-524f-71a40b50d9d3@oracle.com> <515c1a7a-19d7-ba0a-fc93-024fe828bedb@oracle.com> <12784CB4-7357-4F19-B307-1AE8354D40F7@oracle.com> <523d08f4-5604-3a2d-7245-733a5fdc028b@oracle.com> Message-ID: I've just pushed this patch to jdk/jdk14. I'd like to thank all the reviewers for the great (and quick) feedback. Cheers Maurizio On 11/12/2019 15:39, Maurizio Cimadamore wrote: > I went ahead and created a new revision: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6/ > > Delta from latest (v5) here: > > http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v6_delta/ > > No javadoc chnages here. > > Summary of changes: > > * addressed Paul feedback on MemoryScope > * on further testing, I found two issues on var handle construction > from layouts: > ?? - PathElement.sequenceElement(long) does not add the sequence > element offset to the new path element offset > ?? - the layout path machiner does not check that strides are a > multiple of alignment - this allow creation of 'bad' var handles which > are guaranteed not to work in for all indices - consider this layout: > > var seq = MemoryLayout.ofSequence(JAVA_SHORT.withBitAlignment(32)); > > The above layout has an issue: the element requests 32-bit alignent, > but the elements are only 16 bits apart. So, for odd access indices, > there will be an alignment exception. > > If you create a VarHandle with combinators, strides are checked > against alignment, so it is not possible to obtain a VarHandle for the > above layout. But with the Layout API is possible, because the layout > path machinery does not enforce same restriction. > > I've now fixed the code in LayoutPath (most of the changes are due to > a rename from 'scale' to 'stride') to take care of this. > > Bonus point: since offsets must satisfy alignment, and all strides > must also satisfy same alignment - it follows that whetever offset can > come out of the VH index machinery, it will be aligned. This means > that, in the VarHandle code we can just check the base address. In > other words, the memory location accessed by the VarHandle will be > something like (below N denotes alignment, s1..sn are strides, O1..Om > are offsets): > > > address = base + offset > > where: > > offset = N * s1 * i1 + N * s2 * i2 ... + N * sn * in + N * O1 + N * O2 > + ... N * Om > = N * (s1 * i1 + s2 * i2 ... + sn * in + O1 + O2 + ... Om) > = N * K > > > So, in order to show that the "address" is aligned, we only have to > show that "base" is a multiple of N. This helps a lot, as e.g. when > looping through a native array, the base array stays the same, and > only the offset part changes, which means C2 will have no troubles > hoisting out the alignment check out of the loop. > > > As things appear stable, I do not plan to make any other changes to > the implementation/API ahead of integration, unless there's something > critical which reviewers think should be fixed. > > Thanks > Maurizio > > > On 11/12/2019 00:13, Maurizio Cimadamore wrote: >> >> On 10/12/2019 18:45, Paul Sandoz wrote: >>> MemoryScope changes look good. >>> >>> In j.u.concurrent we use ExceptionInInitializerError in the static >>> blocks when there is an error looking up the VH, >>> >>> FWIW close can also fail because it has already been closed but the >>> exception message does not distinguish between the two states >>> (active or already closed). >>> ? Paul. >>> >> Hi Paul, >> >> would something like this be satisfactory? >> >> >> diff -r 50ef46599c56 >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java >> --- >> a/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java >> Tue Dec 10 16:28:03 2019 +0000 >> +++ >> b/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java >> Wed Dec 11 00:12:20 2019 +0000 >> @@ -48,7 +48,7 @@ >> ???????? try { >> ???????????? COUNT_HANDLE = >> MethodHandles.lookup().findVarHandle(MemoryScope.class, >> "activeCount", int.class); >> ???????? } catch (Throwable ex) { >> -??????????? throw new IllegalStateException(ex); >> +??????????? throw new ExceptionInInitializerError(ex); >> ???????? } >> ???? } >> >> @@ -107,6 +107,9 @@ >> >> ???? void close() { >> ???????? if (!COUNT_HANDLE.compareAndSet(this, UNACQUIRED, CLOSED)) { >> +??????????? //first check if already closed... >> +??????????? checkAliveConfined(); >> +??????????? //...if not, then we have acquired views that are still >> active >> ???????????? throw new IllegalStateException("Cannot close a segment >> that has active acquired views"); >> ???????? } >> ???????? if (cleanupAction != null) { >> >> >> >> If you need a full webrev please let me know. >> >> Thanks >> Maurizio >> From verghese at amazon.com Fri Dec 13 00:05:03 2019 From: verghese at amazon.com (Verghese, Clive) Date: Fri, 13 Dec 2019 00:05:03 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> Message-ID: <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> Additional information regarding the field array. It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. The original implementation was intending to display the second half of the array. Though the outer loop iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated this to display the whole array. Regards, Clive Verghese From: "Verghese, Clive" Date: Thursday, December 12, 2019 at 2:07 PM To: "core-libs-dev at openjdk.java.net" Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString Hi, Requesting review for JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger reaches this class and uses the toString function to print the class. Steps to reproduce this is attached in the JBS issue. Regards, Clive Verghese From john.r.rose at oracle.com Fri Dec 13 00:22:18 2019 From: john.r.rose at oracle.com (John Rose) Date: Thu, 12 Dec 2019 16:22:18 -0800 Subject: RFR JDK-8234049: Implementation of Memory Access API (Incubator) In-Reply-To: <55613fbc-a8b2-b4bb-d4f1-5b08c2b91014@gmail.com> References: <05c71944-cd1d-d5c7-3e0d-704fdfb5f5c3@oracle.com> <55613fbc-a8b2-b4bb-d4f1-5b08c2b91014@gmail.com> Message-ID: On Dec 9, 2019, at 10:16 AM, Peter Levart wrote: > What do you think? Might this be better performance wise? Yes, a fast positive proof that the access is allowed can be implemented along the lines you mention. The owner token could be overloaded in additional ways, if and when we do more patterns of sharing. The case of a permanently shareable heap-allocated segment could be handled by a similar fast check, if some constant sentinel value ALL_THREADS is stored in the owner instead Thread.current(). The case of a temporarily shareable segment, held jointly by several threads, could be handled by an owner token which was suitably tied to those threads. This suggests that ?owner == currentThread()? could be at some point generalized to ?owner.accepts(currentThread())? assuming that the fast paths of OwnerSet::accepts could be optimized well. ? John From huizhe.wang at oracle.com Fri Dec 13 00:38:25 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 12 Dec 2019 16:38:25 -0800 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider In-Reply-To: <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com> References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com> <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com> <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com> <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com> Message-ID: <47fd5e55-5ed7-08a8-75c2-a2b2d145dde2@oracle.com> +1 -Joe On 12/12/19 2:07 PM, naoto.sato at oracle.com wrote: > Sorry, I seem to have posted an old webrev, which included unnecessary > retrieval of the generic name (4168-4173 in v.00). Here is the correct > webrev: > > http://cr.openjdk.java.net/~naoto/8235238/webrev.01/ > > Naoto > > > > On 12/12/19 1:37 PM, Roger Riggs wrote: >> +1 >> >> There's quite a bit of work being done to get the eligible stings >> as part of each parse but it doesn't look easy to re-use it acrosses >> parses. >> >> Roger >> >> >> On 12/12/19 3:42 PM, Joe Wang wrote: >>> >>> >>> On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote: >>>> Hi Joe, >>>> >>>> Thank you for the review. >>>> >>>> The original code loops through zoneStrings array, and if the id >>>> exists in regionIds, then adds their display names in the tree >>>> (4142-4154). This process is not altered with my change. My change >>>> made regionIds mutable (line 4127) so that after the loop, it only >>>> contains custom ids by calling remove() (line 4144). Thus the new >>>> added block will only retrieve names for custom ids. Or am I >>>> missing something in your comment? >>> >>> Ok, that's what I was looking for. Thanks for the explanation. The >>> changes look good to me then. >>> >>> Best, >>> Joe >>> >>>> >>>> Naoto >>>> >>>> On 12/12/19 11:32 AM, Joe Wang wrote: >>>>> Hi Naoto, >>>>> >>>>> Does the new code block, 4156 - 4174, need a conditional >>>>> statement, that is when it's for a standard timezon? Before this >>>>> change, or before a custom TimeZoneNameProvider is attempted, the >>>>> process didn't need to loop through regionIds to add display names. >>>>> >>>>> Thanks, >>>>> Joe >>>>> >>>>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix for the following issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8235238 >>>>>> >>>>>> The proposed changeset is located at: >>>>>> >>>>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ >>>>>> >>>>>> The fix will retrieve the custom zone names from the time zone >>>>>> name provider, for the custom ZoneRulesProvider implementations. >>>>>> >>>>>> Naoto >>>>> >>> >> From suenaga at oss.nttdata.com Fri Dec 13 02:05:20 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 13 Dec 2019 11:05:20 +0900 Subject: RFR (trivial): 8235833: PosixPlatform.cpp should not include sysctl.h In-Reply-To: <9238b422-869f-ea36-552a-fd33b87391cd@oracle.com> References: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> <9238b422-869f-ea36-552a-fd33b87391cd@oracle.com> Message-ID: Thanks Alexey! and I wait Reviewer(s). Yasumasa On 2019/12/13 1:42, Alexey Semenyuk wrote: > Looks good. > > - Alexey > > On 12/12/2019 8:23 AM, Yasumasa Suenaga wrote: >> Hi Andrew, >> >> I can see same error whether --disable-precompiled-headers or not. >> So I filed it to JBS and uploaded webrev. >> Could you review it? >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8235833 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235833/webrev.00/ >> >> It works fine on Fedora 31. >> I've pushed it to submit repo. I believe it passes all tests. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/12/12 19:25, Andrew Haley wrote: >>> On 12/12/19 9:31 AM, Yasumasa Suenaga wrote: >>>> AFAICS sysctl.h provides `sysctl()` and some macros, but they are not used in PosixPlatform.cpp . >>>> In fact, I did not see any error when I remove `#include ` from it. >>> >>> You probably won't see an error unless you configure with >>> --disable-precompiled-headers. Please try that, and we can then >>> consider removing that #include. >>> > From igor.ignatyev at oracle.com Fri Dec 13 05:19:43 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 12 Dec 2019 21:19:43 -0800 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 Message-ID: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> http://cr.openjdk.java.net/~iignatyev//8235866/webrev.00 > 5 lines changed: 0 ins; 0 del; 5 mod Hi all, could you please review this small patch which updates TEST.ROOT in all test suites to require jtreg4.2b16? 8230067[1] updated profiles to use jtreg4.2b16, but didn't update TEST.ROOT files. this patch forces all users to have jtreg4.2b16, so there will be no difference in how tests are executed locally and in automated testing infrastructures. webrev: http://cr.openjdk.java.net/~iignatyev//8235866/webrev.00 JBS: https://bugs.openjdk.java.net/browse/JDK-8235866 [1] https://bugs.openjdk.java.net/browse/JDK-8230067 Thanks, -- Igor From alexander.matveev at oracle.com Fri Dec 13 06:01:04 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 12 Dec 2019 22:01:04 -0800 Subject: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134 Message-ID: Please review fix [2] for jpackage bug [1]. Not sure why it happens, but reading output from "hdiutil attach" was not exiting immediately after process terminated with delays upto 20 seconds always and in some case upto 10 minutes and thus test was timeout. Only possible workaround found is to wait for "hdiutil attach" process to exit before reading output. In this case call to "hdiutil attach" and reading output happens very fast and does not hang for long time. Generating simple DMG image went from ~40 seconds to ~20 seconds after fix. Test was done with verbose output enabled. Thanks, Alexander [1] https://bugs.openjdk.java.net/browse/JDK-8235738 [2] http://cr.openjdk.java.net/~almatvee/8235738/webrev.00/ From david.holmes at oracle.com Fri Dec 13 06:21:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Dec 2019 16:21:24 +1000 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> Message-ID: Hi Igor, On 13/12/2019 3:19 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8235866/webrev.00 >> 5 lines changed: 0 ins; 0 del; 5 mod > > Hi all, > > could you please review this small patch which updates TEST.ROOT in all test suites to require jtreg4.2b16? > 8230067[1] updated profiles to use jtreg4.2b16, but didn't update TEST.ROOT files. this patch forces all users to have jtreg4.2b16, so there will be no difference in how tests are executed locally and in automated testing infrastructures. > > webrev: http://cr.openjdk.java.net/~iignatyev//8235866/webrev.00 So you changed everyone to b14 under 8219417 but then jaxp was reverted back to b13 under https://bugs.openjdk.java.net/browse/JDK-8219705 just a few weeks later. Does that mean jaxp has an issue with later jtreg builds? Or was that a mistake? Otherwise changes seem fine to me. When was b16 released? Thanks, David > JBS: https://bugs.openjdk.java.net/browse/JDK-8235866 > [1] https://bugs.openjdk.java.net/browse/JDK-8230067 > > Thanks, > -- Igor > > > From igor.ignatyev at oracle.com Fri Dec 13 06:46:02 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 12 Dec 2019 22:46:02 -0800 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> Message-ID: <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> > On Dec 12, 2019, at 10:21 PM, David Holmes wrote: > > Hi Igor, > > On 13/12/2019 3:19 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8235866/webrev.00 >>> 5 lines changed: 0 ins; 0 del; 5 mod >> Hi all, >> could you please review this small patch which updates TEST.ROOT in all test suites to require jtreg4.2b16? >> 8230067[1] updated profiles to use jtreg4.2b16, but didn't update TEST.ROOT files. this patch forces all users to have jtreg4.2b16, so there will be no difference in how tests are executed locally and in automated testing infrastructures. >> webrev: http://cr.openjdk.java.net/~iignatyev//8235866/webrev.00 > > So you changed everyone to b14 under 8219417 but then jaxp was reverted back to b13 under > > https://bugs.openjdk.java.net/browse/JDK-8219705 > > just a few weeks later. Does that mean jaxp has an issue with later jtreg builds? Or was that a mistake? I don't see why 8219705 can require to change requiredVersion, nor do I see it being discussed in RFR (https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-March/058923.html ), so I assume it's just unrelated local changes which got integrated. but just to be safe, @Joe/Lance, were there any reasons why you needed to switch jtreg's requiredVersion back to 4.2b13 in jaxp? are there any reasons which prevent jaxp from switching to jtreg4.2b16 now? > > Otherwise changes seem fine to me. > > When was b16 released? the tag was added by Jon on Dec 03 2019. so I believe there was enough time for usual suspects to build/adjust, and I'm aware about at least one publicly available place where people can get the latest build of jtreg, if they have problems w/ building it themselves. Thanks, -- Igor > > Thanks, > David > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235866 >> [1] https://bugs.openjdk.java.net/browse/JDK-8230067 >> Thanks, >> -- Igor >> From daniel.peintner at gmail.com Fri Dec 13 07:45:00 2019 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Fri, 13 Dec 2019 08:45:00 +0100 Subject: jpackage: file-associations report wrong argument count Message-ID: All, I tried to use jpackage file-associations option to associate a given extension. This works fine. The program gets launched with the given argument (e.g., double clicking file on Windows). I have noticed though that the argument may be split due to possible whitespaces in the filename. e.g., clicking on file C:\foo.xyz works fine but C:\part1 part2.xyz gets broken up into 2 arguments. It looks the argument needs to be wrapped in quotes so that a Java program gets the right argument: ["C:\part1 part2.xyz"] instead of ["C:\part1", "part2.xyz"] as currently reported. Note: This used to work in the case of the "old" javapackager. Is this a known issue? I did not find a related issue here [1] Thanks, -- Daniel [1] https://bugs.openjdk.java.net/issues/?filter=37667 From patrick at os.amperecomputing.com Fri Dec 13 11:14:16 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Fri, 13 Dec 2019 11:14:16 +0000 Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors Message-ID: Hi Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ A recent GCC patch (supposed to be in GCC 10) exposes a couple of "multiple definition" link errors when building the jdk tip. [PATCH] PR85678: Change default to -fno-common https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html For example, the error message looks like: * For target support_native_java.base_libjava_BUILD_LIBJAVA_link: build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple definition of `parentPathv' build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first defined here collect2: error: ld returned 1 exit status This was not an issue because the original default -fcommon allowed "global variables defined without an initializer" be handled as COMMON symbols, so it would not warn the problem like "same variable is accidentally defined in more than one compilation unit". About -fcommon vs -fno-cmmon: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common Moving forward, building jdk with latest versions of GCC will trigger this error. Specifying "--with-extra-cflags='-fcommon'" can make it work, but it just got things hidden again. In addition, -fcommon's behavior "is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors." Last, in case that other jdk developers would revisit this problem once again, I suggest fixing the error explicitly instead of using "-fcommon" Regards Patrick From andy.herrick at oracle.com Fri Dec 13 14:16:52 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 13 Dec 2019 09:16:52 -0500 Subject: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134 In-Reply-To: References: Message-ID: <25a465fa-d8d8-af38-45b7-31f2ff8ecd12@oracle.com> I approve these changes. My first thought was that, if reading output only after Process is complete is valid and safe, then why not do it that way all the time ?? But comment in Process javadoc: "Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." indicates is is prudent to do this only when necessary. My second thought is that this indicates an underlying unidentified bug in the mac native code used by Process or ProcessBuilder , and although it would be better to identify and resolve the underlying problem, the fix is needed now, so this change seems appropriate. /Andy On 12/13/2019 1:01 AM, Alexander Matveev wrote: > Please review fix [2] for jpackage bug [1]. > > Not sure why it happens, but reading output from "hdiutil attach" was > not exiting immediately after process terminated with delays upto 20 > seconds always and in some case upto 10 minutes and thus test was > timeout. Only possible workaround found is to wait for "hdiutil > attach" process to exit before reading output. In this case call to > "hdiutil attach" and reading output happens very fast and does not > hang for long time. Generating simple DMG image went from ~40 seconds > to ~20 seconds after fix. Test was done with verbose output enabled. > > Thanks, > Alexander > > [1] https://bugs.openjdk.java.net/browse/JDK-8235738 > > [2] http://cr.openjdk.java.net/~almatvee/8235738/webrev.00/ From kusrinivasan at vmware.com Fri Dec 13 14:28:26 2019 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Fri, 13 Dec 2019 14:28:26 +0000 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> Message-ID: <7AC57A49-095F-4A2C-A1A3-4E2390702BB7@vmware.com> Hey Igor ? please read inlined comment below?.. [cc?ed Jon] On Dec 12, 2019, at 10:46 PM, Igor Ignatyev > wrote: On Dec 12, 2019, at 10:21 PM, David Holmes > wrote: Hi Igor, On 13/12/2019 3:19 pm, Igor Ignatyev wrote: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~iignatyev%2F%2F8235866%2Fwebrev.00&data=02%7C01%7Ckusrinivasan%40vmware.com%7C8e1128e05e8a441dfd8e08d77f983396%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118164005266666&sdata=e5sMrba8xFcOfBlFXXSSI9zRcZcSIyCQvfmfBtUN8bQ%3D&reserved=0 5 lines changed: 0 ins; 0 del; 5 mod Hi all, could you please review this small patch which updates TEST.ROOT in all test suites to require jtreg4.2b16? 8230067[1] updated profiles to use jtreg4.2b16, but didn't update TEST.ROOT files. this patch forces all users to have jtreg4.2b16, so there will be no difference in how tests are executed locally and in automated testing infrastructures. webrev: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~iignatyev%2F%2F8235866%2Fwebrev.00&data=02%7C01%7Ckusrinivasan%40vmware.com%7C8e1128e05e8a441dfd8e08d77f983396%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118164005266666&sdata=e5sMrba8xFcOfBlFXXSSI9zRcZcSIyCQvfmfBtUN8bQ%3D&reserved=0 So you changed everyone to b14 under 8219417 but then jaxp was reverted back to b13 under https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8219705&data=02%7C01%7Ckusrinivasan%40vmware.com%7C8e1128e05e8a441dfd8e08d77f983396%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118164005266666&sdata=SaI%2Bta5Ug%2BkyKP%2BSJ3iV6HsZHFtZXLU6gTWHXXn%2FyOo%3D&reserved=0 just a few weeks later. Does that mean jaxp has an issue with later jtreg builds? Or was that a mistake? I don't see why 8219705 can require to change requiredVersion, nor do I see it being discussed in RFR (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fcore-libs-dev%2F2019-March%2F058923.html&data=02%7C01%7Ckusrinivasan%40vmware.com%7C8e1128e05e8a441dfd8e08d77f983396%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118164005266666&sdata=tJ74fk0nGaqZ6ROHDYgI96CGeirjKeViQ%2BkkOhWRjN4%3D&reserved=0 ), so I assume it's just unrelated local changes which got integrated. but just to be safe, @Joe/Lance, were there any reasons why you needed to switch jtreg's requiredVersion back to 4.2b13 in jaxp? are there any reasons which prevent jaxp from switching to jtreg4.2b16 now? Otherwise changes seem fine to me. When was b16 released? the tag was added by Jon on Dec 03 2019. so I believe there was enough time for usual suspects to build/adjust, and I'm aware about at least one publicly available place where people can get the latest build of jtreg, if they have problems w/ building it themselves. This is broken since Dec 3. Do you have a contact ? you may want to let them know. Likely cause: The jerkins build is invoking the build script from the wrong directory. https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ Kumar Thanks, -- Igor Thanks, David JBS: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8235866&data=02%7C01%7Ckusrinivasan%40vmware.com%7C8e1128e05e8a441dfd8e08d77f983396%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118164005266666&sdata=BIhDQmqlS8eb1i70LoIFYWl5xgLxf9TmsDhLCtkxabw%3D&reserved=0 [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8230067&data=02%7C01%7Ckusrinivasan%40vmware.com%7C8e1128e05e8a441dfd8e08d77f983396%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637118164005266666&sdata=XA0hRPuPrvzK%2B0S25ALE2w1JWUVsUR%2B0ncwbgzpdn3c%3D&reserved=0 Thanks, -- Igor From daniel.fuchs at oracle.com Fri Dec 13 14:48:05 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 13 Dec 2019 15:48:05 +0100 Subject: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134 In-Reply-To: <25a465fa-d8d8-af38-45b7-31f2ff8ecd12@oracle.com> References: <25a465fa-d8d8-af38-45b7-31f2ff8ecd12@oracle.com> Message-ID: <9ce5f074-7a28-0871-9e59-c8f123bbee1e@oracle.com> Hi Andy, On 13/12/2019 15:16, Andy Herrick wrote: > My second thought is that this indicates an underlying unidentified bug > in the mac native code used by Process or ProcessBuilder , and although > it would be better to identify and resolve the underlying problem, the > fix is needed now, so this change seems appropriate. Roger Riggs might provide more insight about this, but indeed, if there is an underlying issue it could be prudent to log another JBS issue against Process/ProcessBuilder to investigate that underlying problem at a later time. best regards, -- daniel From andy.herrick at oracle.com Fri Dec 13 15:27:25 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 13 Dec 2019 10:27:25 -0500 Subject: jpackage: file-associations report wrong argument count In-Reply-To: References: Message-ID: <8292c1c6-3421-7140-2222-b27188d7db83@oracle.com> yes - I can see this problem locally on windows and have filed JDK-8235915 to address it. /Andy On 12/13/2019 2:45 AM, Daniel Peintner wrote: > All, > > I tried to use jpackage file-associations option to associate a given > extension. This works fine. The program gets launched with the given > argument (e.g., double clicking file on Windows). > > I have noticed though that the argument may be split due to possible > whitespaces in the filename. > > e.g., clicking on file C:\foo.xyz works fine but C:\part1 part2.xyz gets > broken up into 2 arguments. > It looks the argument needs to be wrapped in quotes so that a Java program > gets the right argument: > > ["C:\part1 part2.xyz"] > instead of > ["C:\part1", "part2.xyz"] > as currently reported. > > Note: This used to work in the case of the "old" javapackager. > > Is this a known issue? I did not find a related issue here [1] > > Thanks, > > -- Daniel > > [1] https://bugs.openjdk.java.net/issues/?filter=37667 From Roger.Riggs at oracle.com Fri Dec 13 16:02:25 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 13 Dec 2019 11:02:25 -0500 Subject: RFR 8235238: Parsing a time string ignores any custom TimeZoneNameProvider In-Reply-To: <47fd5e55-5ed7-08a8-75c2-a2b2d145dde2@oracle.com> References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com> <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com> <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com> <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com> <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com> <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com> <47fd5e55-5ed7-08a8-75c2-a2b2d145dde2@oracle.com> Message-ID: <15352625-2b93-d56e-c0c8-31ab5f288dbb@oracle.com> +1 On 12/12/19 7:38 PM, Joe Wang wrote: > +1 > > -Joe > > On 12/12/19 2:07 PM, naoto.sato at oracle.com wrote: >> Sorry, I seem to have posted an old webrev, which included >> unnecessary retrieval of the generic name (4168-4173 in v.00). Here >> is the correct webrev: >> >> http://cr.openjdk.java.net/~naoto/8235238/webrev.01/ >> >> Naoto >> >> >> >> On 12/12/19 1:37 PM, Roger Riggs wrote: >>> +1 >>> >>> There's quite a bit of work being done to get the eligible stings >>> as part of each parse but it doesn't look easy to re-use it acrosses >>> parses. >>> >>> Roger >>> >>> >>> On 12/12/19 3:42 PM, Joe Wang wrote: >>>> >>>> >>>> On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote: >>>>> Hi Joe, >>>>> >>>>> Thank you for the review. >>>>> >>>>> The original code loops through zoneStrings array, and if the id >>>>> exists in regionIds, then adds their display names in the tree >>>>> (4142-4154). This process is not altered with my change. My change >>>>> made regionIds mutable (line 4127) so that after the loop, it only >>>>> contains custom ids by calling remove() (line 4144). Thus the new >>>>> added block will only retrieve names for custom ids. Or am I >>>>> missing something in your comment? >>>> >>>> Ok, that's what I was looking for. Thanks for the explanation. The >>>> changes look good to me then. >>>> >>>> Best, >>>> Joe >>>> >>>>> >>>>> Naoto >>>>> >>>>> On 12/12/19 11:32 AM, Joe Wang wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> Does the new code block, 4156 - 4174, need a conditional >>>>>> statement, that is when it's for a standard timezon? Before this >>>>>> change, or before a custom TimeZoneNameProvider is attempted, the >>>>>> process didn't need to loop through regionIds to add display names. >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>>> >>>>>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix for the following issue: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235238 >>>>>>> >>>>>>> The proposed changeset is located at: >>>>>>> >>>>>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/ >>>>>>> >>>>>>> The fix will retrieve the custom zone names from the time zone >>>>>>> name provider, for the custom ZoneRulesProvider implementations. >>>>>>> >>>>>>> Naoto >>>>>> >>>> >>> > From volker.simonis at gmail.com Fri Dec 13 16:08:27 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Dec 2019 17:08:27 +0100 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> Message-ID: Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fields. But for "real" fields, zero is a valid value which you might want to print. You might however still consider printing the "stamps" (i.e. the lower half) as well, e.g.: sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); Thank you and best regards, Volker On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive wrote: > > Additional information regarding the field array. > > It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. > The original implementation was intending to display the second half of the array. Though the outer loop > iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated > this to display the whole array. > > Regards, > Clive Verghese > > From: "Verghese, Clive" > Date: Thursday, December 12, 2019 at 2:07 PM > To: "core-libs-dev at openjdk.java.net" > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString > > Hi, > > Requesting review for > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. > The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger > reaches this class and uses the toString function to print the class. > > Steps to reproduce this is attached in the JBS issue. > > Regards, > Clive Verghese > > From igor.ignatyev at oracle.com Fri Dec 13 16:36:50 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 13 Dec 2019 08:36:50 -0800 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: <7AC57A49-095F-4A2C-A1A3-4E2390702BB7@vmware.com> References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> <7AC57A49-095F-4A2C-A1A3-4E2390702BB7@vmware.com> Message-ID: <57E4CACC-AF3A-40C8-A36E-5C8DF57D8613@oracle.com> Hi Kumar, I haven't heard adoptopenjdk people bringing it up. I agree w/ your hypothesis, this job started to fail after https://hg.openjdk.java.net/code-tools/jtreg/rev/deee95d5d8ff which checks that '.hg' directory exists in the current directory. -- Igor > On Dec 13, 2019, at 6:28 AM, Kumar Srinivasan wrote: > > This is broken since Dec 3. Do you have a contact ? you may want to let them know. > Likely cause: The jerkins build is invoking the build script from the wrong directory. > https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ From jonathan.gibbons at oracle.com Fri Dec 13 16:47:26 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Dec 2019 08:47:26 -0800 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: <57E4CACC-AF3A-40C8-A36E-5C8DF57D8613@oracle.com> References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> <7AC57A49-095F-4A2C-A1A3-4E2390702BB7@vmware.com> <57E4CACC-AF3A-40C8-A36E-5C8DF57D8613@oracle.com> Message-ID: <1b5732f4-8520-1eaa-e688-4d4a0080f65d@oracle.com> I've been trying to contact AdoptOpenJDK folk about this and other related issues. I've not heard back yet. In the meantime, I note that these days it is reasonably easy for folk to build jtreg if they do not have easy access to the latest prebuilt binaries. There's a README in the root of the jtreg repo with details. http://hg.openjdk.java.net/code-tools/jtreg/file/c82fc1196801/README -- Jon On 12/13/19 8:36 AM, Igor Ignatyev wrote: > Hi Kumar, > > I haven't heard adoptopenjdk people bringing it up. I agree w/ your > hypothesis, this job started to fail after > https://hg.openjdk.java.net/code-tools/jtreg/rev/deee95d5d8ff?which > checks that '.hg' directory exists in the current directory. > > -- Igor > >> On Dec 13, 2019, at 6:28 AM, Kumar Srinivasan >> > wrote: >> >> This is broken since Dec 3. Do you have a contact ? you may want to >> let them know. >> Likely cause: The jerkins build is ?invoking the build script from >> the wrong directory. >> https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ > From philip.race at oracle.com Fri Dec 13 17:39:45 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Dec 2019 09:39:45 -0800 Subject: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134 In-Reply-To: <25a465fa-d8d8-af38-45b7-31f2ff8ecd12@oracle.com> References: <25a465fa-d8d8-af38-45b7-31f2ff8ecd12@oracle.com> Message-ID: > testForPresenseOnly It should be spelt testForPresenceOnly -phil. On 12/13/19 6:16 AM, Andy Herrick wrote: > I approve these changes. > > My first thought was that, if reading output only after Process is > complete is valid and safe, then why not do it that way all the time > ?? But comment in Process javadoc: "Because some native platforms only > provide limited buffer size for standard input and output streams, > failure to promptly write the input stream or read the output stream > of the process may cause the process to block, or even deadlock." > indicates is is prudent to do this only when necessary. > > My second thought is that this indicates an underlying unidentified > bug in the mac native code used by Process or ProcessBuilder , and > although it would be better to identify and resolve the underlying > problem, the fix is needed now, so this change seems appropriate. > > /Andy > > On 12/13/2019 1:01 AM, Alexander Matveev wrote: >> Please review fix [2] for jpackage bug [1]. >> >> Not sure why it happens, but reading output from "hdiutil attach" was >> not exiting immediately after process terminated with delays upto 20 >> seconds always and in some case upto 10 minutes and thus test was >> timeout. Only possible workaround found is to wait for "hdiutil >> attach" process to exit before reading output. In this case call to >> "hdiutil attach" and reading output happens very fast and does not >> hang for long time. Generating simple DMG image went from ~40 seconds >> to ~20 seconds after fix. Test was done with verbose output enabled. >> >> Thanks, >> Alexander >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235738 >> >> [2] http://cr.openjdk.java.net/~almatvee/8235738/webrev.00/ From alexey.semenyuk at oracle.com Fri Dec 13 17:47:05 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 13 Dec 2019 12:47:05 -0500 Subject: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134 In-Reply-To: References: Message-ID: <324eaaac-1780-366a-b12e-8191309af630@oracle.com> Looks ugly, but seems to be the only possible fix at the moment. Approved. - Alexey On 12/13/2019 1:01 AM, Alexander Matveev wrote: > Please review fix [2] for jpackage bug [1]. > > Not sure why it happens, but reading output from "hdiutil attach" was > not exiting immediately after process terminated with delays upto 20 > seconds always and in some case upto 10 minutes and thus test was > timeout. Only possible workaround found is to wait for "hdiutil > attach" process to exit before reading output. In this case call to > "hdiutil attach" and reading output happens very fast and does not > hang for long time. Generating simple DMG image went from ~40 seconds > to ~20 seconds after fix. Test was done with verbose output enabled. > > Thanks, > Alexander > > [1] https://bugs.openjdk.java.net/browse/JDK-8235738 > > [2] http://cr.openjdk.java.net/~almatvee/8235738/webrev.00/ From ivan.gerasimov at oracle.com Fri Dec 13 20:07:54 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 13 Dec 2019 12:07:54 -0800 Subject: RFR 8235930 : java.util.regex.PrintPattern does not print a link to the next node Message-ID: Hello! The java.util.regex package contains a debugging utility PrintPattern which is used to display the internal representation structure of a compiled regex pattern. When it prints a node that is linked to another node that has already been printed, it is supposed to print a link, but fails. The error is due to ambigous overloading of print() method. Would you please help review a trivial fix? No regression test because the utility is not something officially supported. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8235930 WEBREV: http://cr.openjdk.java.net/~igerasim/8235930/00/webrev/ -- With kind regards, Ivan Gerasimov From alexander.matveev at oracle.com Sat Dec 14 00:32:44 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 13 Dec 2019 16:32:44 -0800 Subject: RFR: JDK-8235738: tools/jpackage/macosx/NameWithSpaceTest.java failed due to exit code 134 In-Reply-To: References: <25a465fa-d8d8-af38-45b7-31f2ff8ecd12@oracle.com> Message-ID: <349f7fa1-d385-4d9d-60af-0cf070ab48e4@oracle.com> http://cr.openjdk.java.net/~almatvee/8235738/webrev.01/ Fixed testForPresenceOnly spelling error. Thanks, Alexander On 12/13/2019 9:39 AM, Phil Race wrote: >> testForPresenseOnly? It should be spelt testForPresenceOnly -phil. > > > > On 12/13/19 6:16 AM, Andy Herrick wrote: >> I approve these changes. >> >> My first thought was that, if reading output only after Process is >> complete is valid and safe, then why not do it that way all the time >> ?? But comment in Process javadoc: "Because some native platforms >> only provide limited buffer size for standard input and output >> streams, failure to promptly write the input stream or read the >> output stream of the process may cause the process to block, or even >> deadlock." indicates is is prudent to do this only when necessary. >> >> My second thought is that this indicates an underlying unidentified >> bug in the mac native code used by Process or ProcessBuilder , and >> although it would be better to identify and resolve the underlying >> problem, the fix is needed now, so this change seems appropriate. >> >> /Andy >> >> On 12/13/2019 1:01 AM, Alexander Matveev wrote: >>> Please review fix [2] for jpackage bug [1]. >>> >>> Not sure why it happens, but reading output from "hdiutil attach" >>> was not exiting immediately after process terminated with delays >>> upto 20 seconds always and in some case upto 10 minutes and thus >>> test was timeout. Only possible workaround found is to wait for >>> "hdiutil attach" process to exit before reading output. In this case >>> call to "hdiutil attach" and reading output happens very fast and >>> does not hang for long time. Generating simple DMG image went from >>> ~40 seconds to ~20 seconds after fix. Test was done with verbose >>> output enabled. >>> >>> Thanks, >>> Alexander >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8235738 >>> >>> [2] http://cr.openjdk.java.net/~almatvee/8235738/webrev.00/ > From alexey.semenyuk at oracle.com Sat Dec 14 00:47:55 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 13 Dec 2019 19:47:55 -0500 Subject: RFR: JDK-8233270: Add support to jtreg helpers to unpack packages In-Reply-To: References: <211ee3f4-06f6-e354-049b-c48e5fa14f95@oracle.com> <5DE9AFD6.5070501@oracle.com> <3f557b9a-a5bc-221f-1a45-486d0bf36e6e@oracle.com> <1fa9ffc5-d0a8-786e-763b-180fcc64925c@oracle.com> Message-ID: Phil, Let me provide more details on what is going on here. JDK-8230933 - is the fix of jpackage code assigning icons to main/additional launchers. JDK-8233270 - is primarily the enhancement of jpackage test helpers to provide functionality needed for automated testing of the fix of JDK-8230933. In order to test JDK-8230933 fix it is necessary to access contents of packages created by jpackage. This is normally done when packages are installed. However our test environment doesn't allow installing of packages. The alternative is to extract contents of packages without installing them. So in order to implement jtreg tests for JDK-8230933 fix the functionality to unpack packages was needed. JDK-8233270 was filed to track this enhancement of jpackage test helpers. Work on JDK-8233270 resulted in quite a big refactoring of tests and test helpers of jpackage: Changes to jtreg test helpers: - added support to unpack .dmg, .deb, .rpm, .msi packages. - added AdditionalLauncher helper class to test additional launchers functionality of jpackage. - added LauncherIconVerifier helper class to test how jpackage assigns icons to launchers (main and additional). - numerous minor code improvements. - bugfixes. Changes to jtreg tests: - all temporary directories/files created during tests runs that can help to investigate test failures are created in a way they are deleted only when tests pass and not when tests exit. - removed unused files from test\jdk\tools\jpackage\apps\com.other folder. - refactored additional launchers jtreg tests based on the old test helpers inherited from javapackager to use the new test helpers. Logically JDK-8230933 and JDK-8233270 issues are unrelated, they got tangled because JDK-8230933 came first and then JDK-8233270 followed. The proper way to address them was put on hold JDK-8230933 fix and implement JDK-8233270 first. Then work on JDK-8230933 fix on top of JDK-8233270. However the work on these two issues was carried out in the sandbox with the assumption they both would be a part of cumulative jpackage patch rolled in jdk14. Keeping them separated was not a priority. Hope this clarifies what is in the webrev and why JDK-8230933 and JDK-8233270 ended up in the same patch. - Alexey On 12/6/2019 3:59 PM, Phil Race wrote: > > > On 12/6/19 12:51 PM, Alexey Semenyuk wrote: >> >> >> On 12/5/2019 8:44 PM, Alexander Matveev wrote: >>> Hi Alexey, >>> >>> 1) Remove this file: >>> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaTool.java.rej >> Done. webrev updated in place. >> >>> 2) Agree with Phil, they probably should be pushed as two separate >>> bugs. >> Decoupling is not straightforward unfortunately: tests that cover >> additional launchers functionality contain fixes for both [1] and [2] >> CRs. > > So the synopsis reads like this is all about updating tests, and your > email says > "go read the bugs" and nothing more. > I think most people like to see a description of the problem and the > proposed solution > written in the review request. > > I think the source code updates are what you need to highlight. > And I don't think you have explained why it is so hard. > Saying is is hard is not the same thing as explaining why. > > I think you should decouple unless you can provide that explanation. > And definitely you need to provide explanation of the fix etc. > > -phil. > >> If there would be no strong arguments against pushing the fixes in a >> single patch, I'd rather avoid decoupling. >> >>> 3) Do you know how to run installer tests with new changes? It is >>> not clear from code. >> Fix for [1] moved code to install packages produced by jpackage from >> manage_packages.sh script into jtreg helper classes. >> If you run tests locally with test_jpackage.sh script, nothing will >> change for you. >> >> - Alexey >>> >>> Changes itself looks fine. >>> >>> Thanks, >>> Alexander >>> >>> On 12/5/2019 5:33 PM, Philip Race wrote: >>>> I don't understand the relationship between these two bugs. >>>> >>>> -phil >>>> >>>> On 12/5/19, 2:47 PM, Alexey Semenyuk wrote: >>>>> Please review? fixes for [1] and [2]. Both target jpackage tool. >>>>> >>>>> The webrev is at [3]. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233270 >>>>> >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8230933 >>>>> >>>>> [3] http://cr.openjdk.java.net/~asemenyuk/8233270/webrev.00/ >>>>> >>> >> > From martinrb at google.com Sat Dec 14 14:58:02 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 14 Dec 2019 06:58:02 -0800 Subject: RFR 8235930 : java.util.regex.PrintPattern does not print a link to the next node In-Reply-To: References: Message-ID: Hi Ivan, Did you mean to change from System.err to System.out? I might have fixed the overloading by giving one of the overloaded methods a better name. How about private static void printIndented(String s, int depth) On Fri, Dec 13, 2019 at 12:11 PM Ivan Gerasimov wrote: > Hello! > > The java.util.regex package contains a debugging utility PrintPattern > which is used to display the internal representation structure of a > compiled regex pattern. > > When it prints a node that is linked to another node that has already > been printed, it is supposed to print a link, but fails. > > The error is due to ambigous overloading of print() method. > > Would you please help review a trivial fix? > > No regression test because the utility is not something officially > supported. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8235930 > WEBREV: http://cr.openjdk.java.net/~igerasim/8235930/00/webrev/ > > -- > With kind regards, > Ivan Gerasimov > > From ivan.gerasimov at oracle.com Sat Dec 14 19:42:24 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 14 Dec 2019 11:42:24 -0800 Subject: RFR 8235930 : java.util.regex.PrintPattern does not print a link to the next node In-Reply-To: References: Message-ID: <1e62ceb2-8030-1047-9c46-0da50443d710@oracle.com> Thank you Martin for looking at this! On 12/14/19 6:58 AM, Martin Buchholz wrote: > Hi Ivan, > > Did you mean to change from System.err to System.out? > Yes.? The first string that this utility prints in main() goes to System.out. Not sure why the rest would need to go to another stream. > I might have fixed the overloading by giving one of the overloaded > methods a better name.? How about > private static void printIndented(String s, int depth) Now, after removing the overload `print(String fmt, Object ... args)` (which was just an alias of printf(String fmt, Object ... args)), we have two print() methods, and both of them indent the text. I am not planning to invest much into this utility, just wanted to fix that annoying glitch. With kind regards, Ivan > > On Fri, Dec 13, 2019 at 12:11 PM Ivan Gerasimov > > wrote: > > Hello! > > The java.util.regex package contains a debugging utility PrintPattern > which is used to display the internal representation structure of a > compiled regex pattern. > > When it prints a node that is linked to another node that has already > been printed, it is supposed to print a link, but fails. > > The error is due to ambigous overloading of print() method. > > Would you please help review a trivial fix? > > No regression test because the utility is not something officially > supported. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8235930 > WEBREV: http://cr.openjdk.java.net/~igerasim/8235930/00/webrev/ > > -- > With kind regards, > Ivan Gerasimov > -- With kind regards, Ivan Gerasimov From martinrb at google.com Sun Dec 15 06:45:54 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 14 Dec 2019 22:45:54 -0800 Subject: RFR 8235930 : java.util.regex.PrintPattern does not print a link to the next node In-Reply-To: <1e62ceb2-8030-1047-9c46-0da50443d710@oracle.com> References: <1e62ceb2-8030-1047-9c46-0da50443d710@oracle.com> Message-ID: Looks Good To Me. On Sat, Dec 14, 2019 at 11:42 AM Ivan Gerasimov wrote: > Thank you Martin for looking at this! > On 12/14/19 6:58 AM, Martin Buchholz wrote: > > Hi Ivan, > > Did you mean to change from System.err to System.out? > > Yes. The first string that this utility prints in main() goes to > System.out. > Not sure why the rest would need to go to another stream. > > I might have fixed the overloading by giving one of the overloaded methods > a better name. How about > private static void printIndented(String s, int depth) > > Now, after removing the overload `print(String fmt, Object ... args)` > (which was just an alias of printf(String fmt, Object ... args)), we have > two print() methods, and both of them indent the text. > > I am not planning to invest much into this utility, just wanted to fix > that annoying glitch. > With kind regards, > Ivan > > > > On Fri, Dec 13, 2019 at 12:11 PM Ivan Gerasimov > wrote: > >> Hello! >> >> The java.util.regex package contains a debugging utility PrintPattern >> which is used to display the internal representation structure of a >> compiled regex pattern. >> >> When it prints a node that is linked to another node that has already >> been printed, it is supposed to print a link, but fails. >> >> The error is due to ambigous overloading of print() method. >> >> Would you please help review a trivial fix? >> >> No regression test because the utility is not something officially >> supported. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8235930 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8235930/00/webrev/ >> >> -- >> With kind regards, >> Ivan Gerasimov >> >> -- > With kind regards, > Ivan Gerasimov > > From optusprepaid1 at gmail.com Sun Dec 15 16:37:45 2019 From: optusprepaid1 at gmail.com (Bradley Willcott) Date: Mon, 16 Dec 2019 00:37:45 +0800 Subject: [minor feature change] java.util.Properties Message-ID: <87c154e1-f41e-8b55-9e28-899af6f1cb42@gmail.com> Hi there, I have been told that this is the correct place is to propose a change to the Java SDK. I would like to propose the following changes to /java.util.Properties/: 1) That the current built-in treatment of the space character ' ' as a key/value pair separator, be made optional.? This would allow for keys to have un-escaped space characters in them, as is often the case in Windows '.ini' files. I have also found a few linux '.conf' files with them as well! 2) That the output of the commented Date be made optional. I already have a working modified copy of the class in my own class library.? However, this can only be a short term solution as it will become a problem once the JDK version is changed. Thoughts and helpful suggestions please. Brad. From ivan.gerasimov at oracle.com Sun Dec 15 17:39:17 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 15 Dec 2019 09:39:17 -0800 Subject: RFR 8235930 : java.util.regex.PrintPattern does not print a link to the next node In-Reply-To: References: <1e62ceb2-8030-1047-9c46-0da50443d710@oracle.com> Message-ID: Thank you Martin! Pushed. On 12/14/19 10:45 PM, Martin Buchholz wrote: > Looks Good To Me. > > -- With kind regards, Ivan Gerasimov From Alan.Bateman at oracle.com Sun Dec 15 19:26:02 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Dec 2019 19:26:02 +0000 Subject: [minor feature change] java.util.Properties In-Reply-To: <87c154e1-f41e-8b55-9e28-899af6f1cb42@gmail.com> References: <87c154e1-f41e-8b55-9e28-899af6f1cb42@gmail.com> Message-ID: <8373cf94-bdf5-d354-60fa-3a8ec3d8097d@oracle.com> On 15/12/2019 16:37, Bradley Willcott wrote: > Hi there, > > I have been told that this is the correct place is to propose a change > to the Java SDK. > > I would like to propose the following changes to /java.util.Properties/: > > 1) That the current built-in treatment of the space character ' ' as a > key/value pair separator, be made optional.? This would allow for keys > to have un-escaped space characters in them, as is often the case in > Windows '.ini' files. I have also found a few linux '.conf' files with > them as well! > > 2) That the output of the commented Date be made optional. > > I already have a working modified copy of the class in my own class > library.? However, this can only be a short term solution as it will > become a problem once the JDK version is changed. > > Thoughts and helpful suggestions please. There has been recent discussion about storing properties in a canonical form to allow for repeatable builds. It's tracked as JDK-8231640 [1] and will likely require introducing a new store method. Nobody has stepped up to run with that one yet. For the suggestion to allow spaces in keys then you'll need to research the compatibility impact. Properties files have been around since JDK 1.0 so changing the spec after all this time would require a lot of care, esp.? interop across JDK releases and cases where a property is defined over more than one "natural line". -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8231640 From thomas_vatter at web.de Sat Dec 14 17:22:07 2019 From: thomas_vatter at web.de (Thomas Vatter) Date: Sat, 14 Dec 2019 18:22:07 +0100 Subject: jpackager Message-ID: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas From swpalmer at gmail.com Mon Dec 16 01:46:28 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 15 Dec 2019 20:46:28 -0500 Subject: jpackager In-Reply-To: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> References: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> Message-ID: Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott > On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: > > Hi, > > I've created a modular jar and jre image by jlink. > > I tested it with this command: > > PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp > Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main > INFO: SimpleApp says hello > > It says "SimpleApp says hello" in the powershell window. > > > Then I packaged it by > > jpackager.exe create-image --input dist --output jp_out --name test01 > --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar > > This creates in the output folder a file structure with an exe file in it. > > When I execute the exe file fron the powershell there is no error > message, but it doesn't say "SimpleApp says hello" any more. > > Is something wrong? > > regards > > Thomas > > > > > > From martinrb at google.com Mon Dec 16 02:43:12 2019 From: martinrb at google.com (Martin Buchholz) Date: Sun, 15 Dec 2019 18:43:12 -0800 Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: References: Message-ID: Looks good to me. From martinrb at google.com Mon Dec 16 02:44:02 2019 From: martinrb at google.com (Martin Buchholz) Date: Sun, 15 Dec 2019 18:44:02 -0800 Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: References: Message-ID: forwarded to other teams for review. On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS < patrick at os.amperecomputing.com> wrote: > Hi > > Please review this patch, if it should be reviewed by any group other than > core-libs, please help forward it. Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 > Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ > > A recent GCC patch (supposed to be in GCC 10) exposes a couple of > "multiple definition" link errors when building the jdk tip. > > [PATCH] PR85678: Change default to -fno-common > https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html > > For example, the error message looks like: > * For target support_native_java.base_libjava_BUILD_LIBJAVA_link: > build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple > definition of `parentPathv' > build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first > defined here > collect2: error: ld returned 1 exit status > > This was not an issue because the original default -fcommon allowed > "global variables defined without an initializer" be handled as COMMON > symbols, so it would not warn the problem like "same variable is > accidentally defined in more than one compilation unit". > > About -fcommon vs -fno-cmmon: > https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common > > Moving forward, building jdk with latest versions of GCC will trigger this > error. Specifying "--with-extra-cflags='-fcommon'" can make it work, but > it just got things hidden again. > > In addition, -fcommon's behavior "is inconsistent with C++, and on many > targets implies a speed and code size penalty on global variable > references. It is mainly useful to enable legacy code to link without > errors." > > Last, in case that other jdk developers would revisit this problem once > again, I suggest fixing the error explicitly instead of using "-fcommon" > > Regards > Patrick > > From sureshkumar.mahaliswamy at oracle.com Mon Dec 16 09:00:53 2019 From: sureshkumar.mahaliswamy at oracle.com (Sureshkumar Mahaliswamy) Date: Mon, 16 Dec 2019 01:00:53 -0800 (PST) Subject: RFR(S) : 8234309:LFGarbageCollectedTest.java fails with parse Exception In-Reply-To: <37c6ccee-8cbe-458b-aa09-2c93289e0d8f@default> References: <37c6ccee-8cbe-458b-aa09-2c93289e0d8f@default> Message-ID: <8088e817-efe9-4191-9c75-74093376556d@default> Gentle Remainder . Kindly review , this is just a small patch. Thanks, Suresh. From: Sureshkumar Mahaliswamy Sent: Wednesday, November 27, 2019 1:16 PM To: core-libs-dev at openjdk.java.net Subject: RFR(S) : 8234309:LFGarbageCollectedTest.java fails with parse Exception Hi All, Kindly review the small patch. Moved @library /lib/testlibrary /java/lang/invokGene/common to the top to avoid the parse exception and report as Test ignored. JBS: https://bugs.openjdk.java.net/browse/JDK-8234309 Webrev: http://cr.openjdk.java.net/~vagarwal/8234309/webrev.0/ Testing: tested with jtreg. Thanks, Suresh. From sgehwolf at redhat.com Mon Dec 16 13:16:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 16 Dec 2019 14:16:21 +0100 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: <1b5732f4-8520-1eaa-e688-4d4a0080f65d@oracle.com> References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> <7AC57A49-095F-4A2C-A1A3-4E2390702BB7@vmware.com> <57E4CACC-AF3A-40C8-A36E-5C8DF57D8613@oracle.com> <1b5732f4-8520-1eaa-e688-4d4a0080f65d@oracle.com> Message-ID: Hi Jon, On Fri, 2019-12-13 at 08:47 -0800, Jonathan Gibbons wrote: > I've been trying to contact AdoptOpenJDK folk about this and other > related issues. I've not heard back yet. It's tracked at AdoptOpenJDK via: https://github.com/AdoptOpenJDK/openjdk-build/issues/1445 Thanks, Severin From andy.herrick at oracle.com Mon Dec 16 14:14:49 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 16 Dec 2019 09:14:49 -0500 Subject: jpackager In-Reply-To: References: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> Message-ID: <92963084-603f-5068-ba82-bb103dd5af26@oracle.com> That was my initial reaction too, but I don't believe that is the problem here. The arguments to jpackage used indicate you are using an older early access version of jpackage. Can you try again using the jpackage in the latest JDK14 EA from https://jdk.java.net/14/ ? /Andy On 12/15/2019 8:46 PM, Scott Palmer wrote: > Welcome to Windows. > > The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. > There is command line option to make a console app. > > --win-console > > > Scott > > > >> On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: >> >> Hi, >> >> I've created a modular jar and jre image by jlink. >> >> I tested it with this command: >> >> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp >> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main >> INFO: SimpleApp says hello >> >> It says "SimpleApp says hello" in the powershell window. >> >> >> Then I packaged it by >> >> jpackager.exe create-image --input dist --output jp_out --name test01 >> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar >> >> This creates in the output folder a file structure with an exe file in it. >> >> When I execute the exe file fron the powershell there is no error >> message, but it doesn't say "SimpleApp says hello" any more. >> >> Is something wrong? >> >> regards >> >> Thomas >> >> >> >> >> >> From sean.coffey at oracle.com Mon Dec 16 14:15:42 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 16 Dec 2019 14:15:42 +0000 Subject: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent() Message-ID: The recent crypto event logging mechanism (JDK-8148188) has introduced a regression whereby the System Logger may be invoked too early in the bootstrap phase. This causes issue when JarFile objects are locked by JarFile verifier initialization code. The logging work records an X509 Certificate which is used during the jar file verification/initialization phase and hence leads to an early System.Logger call. One thread invokes the initialization of the Logger framework via ServiceLoader and waits to lock a JarFile in use via another thread. Unfortunately that other thread is also waiting for the System Logger to initialize. For now, I think we can avoid the early Logger initialization via use of a ThreadLocal. I've tried reproducing the reported issue through manual and automated tests but to no avail. I've added a new ServiceLoader test which has concurrent threads. One is loading providers and another is initializing JarFile verifiers. Hope it helps improve code coverage for the future. JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/ -- Regards, Sean. From web127438p1 at network-inventory.de Mon Dec 16 14:44:16 2019 From: web127438p1 at network-inventory.de (Thomas Vatter) Date: Mon, 16 Dec 2019 15:44:16 +0100 Subject: jpackager In-Reply-To: <92963084-603f-5068-ba82-bb103dd5af26@oracle.com> References: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> <92963084-603f-5068-ba82-bb103dd5af26@oracle.com> Message-ID: I first read on https://openjdk.java.net/jeps/343 Then I was looking for the download and somewhere found the links http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip Since I'm on windows with OpenJDK11 installed I downloaded http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip and extracted it to the JDK bin directory. Running it from the command line with the --version option gives ??? ??? ??? > jpackager.exe --version "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin\java.exe" -Xmx512M --module-path "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin" ??? ??? ??? --add-opens jdk.jlink/jdk.tools.jlink.internal.packager=jdk.packager -m jdk.packager/jdk.packager.Main? "--version"jpackager version 11 Thomas Am 16.12.2019 um 15:14 schrieb Andy Herrick: > That was my initial reaction too, but I don't believe that is the > problem here. > > The arguments to jpackage used indicate you are using an older early > access version of jpackage. > > Can you try again using the jpackage in the latest JDK14 EA from > https://jdk.java.net/14/ ? > > /Andy > > On 12/15/2019 8:46 PM, Scott Palmer wrote: >> Welcome to Windows. >> >> The .exe is a Windows app not a Console app.? This is a distinction >> that only Microsoft seemed to think was needed.? All other platforms >> are sane. >> There is command line option to make a console app. >> >> --win-console >> >> >> Scott >> >> >> >>> On Dec 14, 2019, at 12:22 PM, Thomas Vatter >>> wrote: >>> >>> Hi, >>> >>> I've created a modular jar and jre image by jlink. >>> >>> I tested it with this command: >>> >>> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp >>> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main >>> INFO: SimpleApp says hello >>> >>> It says "SimpleApp says hello" in the powershell window. >>> >>> >>> Then I packaged it by >>> >>> jpackager.exe create-image --input dist --output jp_out --name test01 >>> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar >>> >>> This creates in the output folder a file structure with an exe file >>> in it. >>> >>> When I execute the exe file fron the powershell there is no error >>> message, but it doesn't say "SimpleApp says hello" any more. >>> >>> Is something wrong? >>> >>> regards >>> >>> Thomas >>> >>> >>> >>> >>> >>> > From Schnoor.Jonas at scheidt-bachmann-st.de Mon Dec 16 15:05:24 2019 From: Schnoor.Jonas at scheidt-bachmann-st.de (Schnoor Jonas) Date: Mon, 16 Dec 2019 15:05:24 +0000 Subject: AW: jpackager In-Reply-To: References: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> <92963084-603f-5068-ba82-bb103dd5af26@oracle.com> Message-ID: <6EC507C4A8A6514C8C72779A588B2DDD3DC7E6CB@KI-VS-EX.ki.lan> Notice the different naming: jpackage*r* vs. jpackage (without the trailing *r*). The primary purpose of JPackage*r* seems to be to package JavaFX (read: GUI) applications and AFAIK is a backport by GluonHQ of an EA version of JPackage that probably did not yet have the --win-console option. If you want to package a Windows console application you will have to use JPackage from JDK14 with the --win-console option. Jonas -----Urspr?ngliche Nachricht----- Von: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] Im Auftrag von Thomas Vatter Gesendet: Montag, 16. Dezember 2019 15:44 An: core-libs-dev at openjdk.java.net Betreff: Re: jpackager I first read on https://openjdk.java.net/jeps/343 Then I was looking for the download and somewhere found the links http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip Since I'm on windows with OpenJDK11 installed I downloaded http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip and extracted it to the JDK bin directory. Running it from the command line with the --version option gives ??? ??? ??? > jpackager.exe --version "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin\java.exe" -Xmx512M --module-path "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin" ??? ??? ??? --add-opens jdk.jlink/jdk.tools.jlink.internal.packager=jdk.packager -m jdk.packager/jdk.packager.Main? "--version"jpackager version 11 Thomas Am 16.12.2019 um 15:14 schrieb Andy Herrick: > That was my initial reaction too, but I don't believe that is the > problem here. > > The arguments to jpackage used indicate you are using an older early > access version of jpackage. > > Can you try again using the jpackage in the latest JDK14 EA from > https://jdk.java.net/14/ ? > > /Andy > > On 12/15/2019 8:46 PM, Scott Palmer wrote: >> Welcome to Windows. >> >> The .exe is a Windows app not a Console app.? This is a distinction >> that only Microsoft seemed to think was needed.? All other platforms >> are sane. >> There is command line option to make a console app. >> >> --win-console >> >> >> Scott >> >> >> >>> On Dec 14, 2019, at 12:22 PM, Thomas Vatter >>> wrote: >>> >>> Hi, >>> >>> I've created a modular jar and jre image by jlink. >>> >>> I tested it with this command: >>> >>> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp >>> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main >>> INFO: SimpleApp says hello >>> >>> It says "SimpleApp says hello" in the powershell window. >>> >>> >>> Then I packaged it by >>> >>> jpackager.exe create-image --input dist --output jp_out --name test01 >>> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar >>> >>> This creates in the output folder a file structure with an exe file >>> in it. >>> >>> When I execute the exe file fron the powershell there is no error >>> message, but it doesn't say "SimpleApp says hello" any more. >>> >>> Is something wrong? >>> >>> regards >>> >>> Thomas >>> >>> >>> >>> >>> >>> > Please see our data privacy policy: https://www.scheidt-bachmann.de/en/data-privacy/ Important Notice: This E-Mail and any files attached are confidential and may contain privileged information. If you are not the intended recipient, do not forward or disclose this E-Mail, open any attachments, make any copies or save this E-Mail anywhere. Please delete this E-Mail from your system and notify the sender (as applicable also by phone +49 2166 266-0). Thank you very much. To send this email we must process the following personal data: Your email address, first name and surname. Your data is processed solely for the purpose of sending this email and passed on to third parties only for this purpose. You have been included in the circle of recipients for our emails due to your professional, social or political position. If this position changes, or you inform us that you do not want to receive emails from us, or you object to the further processing of your data, we will delete your data and no longer use it. From web127438p1 at network-inventory.de Mon Dec 16 15:23:26 2019 From: web127438p1 at network-inventory.de (Thomas Vatter) Date: Mon, 16 Dec 2019 16:23:26 +0100 Subject: jpackager In-Reply-To: <6EC507C4A8A6514C8C72779A588B2DDD3DC7E6CB@KI-VS-EX.ki.lan> References: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> <92963084-603f-5068-ba82-bb103dd5af26@oracle.com> <6EC507C4A8A6514C8C72779A588B2DDD3DC7E6CB@KI-VS-EX.ki.lan> Message-ID: Thank you, yes. In fact I'm packaging a GUI Application, I was just having a first try with a simple console application. Thomas Am 16.12.2019 um 16:05 schrieb Schnoor Jonas: > Notice the different naming: jpackage*r* vs. jpackage (without the trailing *r*). > The primary purpose of JPackage*r* seems to be to package JavaFX (read: GUI) applications and AFAIK is a backport by GluonHQ of an EA version of JPackage that probably did not yet have the --win-console option. > > If you want to package a Windows console application you will have to use JPackage from JDK14 with the --win-console option. > > Jonas > > -----Urspr?ngliche Nachricht----- > Von: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] Im Auftrag von Thomas Vatter > Gesendet: Montag, 16. Dezember 2019 15:44 > An: core-libs-dev at openjdk.java.net > Betreff: Re: jpackager > > I first read on > > https://openjdk.java.net/jeps/343 > > Then I was looking for the download and somewhere found the links > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > Since I'm on windows with OpenJDK11 installed I downloaded > > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > and extracted it to the JDK bin directory. > > Running it from the command line with the --version option gives > > ??? ??? ??? > jpackager.exe --version > "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin\java.exe" > -Xmx512M --module-path > "c:\Programme\java\openjdk-11_28_windows-x64_bin\jdk-11\bin" > --add-opens jdk.jlink/jdk.tools.jlink.internal.packager=jdk.packager -m > jdk.packager/jdk.packager.Main? "--version"jpackager version 11 > > Thomas > > > Am 16.12.2019 um 15:14 schrieb Andy Herrick: >> That was my initial reaction too, but I don't believe that is the >> problem here. >> >> The arguments to jpackage used indicate you are using an older early >> access version of jpackage. >> >> Can you try again using the jpackage in the latest JDK14 EA from >> https://jdk.java.net/14/ ? >> >> /Andy >> >> On 12/15/2019 8:46 PM, Scott Palmer wrote: >>> Welcome to Windows. >>> >>> The .exe is a Windows app not a Console app.? This is a distinction >>> that only Microsoft seemed to think was needed.? All other platforms >>> are sane. >>> There is command line option to make a console app. >>> >>> --win-console >>> >>> >>> Scott >>> >>> >>> >>>> On Dec 14, 2019, at 12:22 PM, Thomas Vatter >>>> wrote: >>>> >>>> Hi, >>>> >>>> I've created a modular jar and jre image by jlink. >>>> >>>> I tested it with this command: >>>> >>>> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp >>>> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main >>>> INFO: SimpleApp says hello >>>> >>>> It says "SimpleApp says hello" in the powershell window. >>>> >>>> >>>> Then I packaged it by >>>> >>>> jpackager.exe create-image --input dist --output jp_out --name test01 >>>> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar >>>> >>>> This creates in the output folder a file structure with an exe file >>>> in it. >>>> >>>> When I execute the exe file fron the powershell there is no error >>>> message, but it doesn't say "SimpleApp says hello" any more. >>>> >>>> Is something wrong? >>>> >>>> regards >>>> >>>> Thomas >>>> >>>> >>>> >>>> >>>> >>>> > Please see our data privacy policy: https://www.scheidt-bachmann.de/en/data-privacy/ > Important Notice: This E-Mail and any files attached are confidential and may contain privileged information. > If you are not the intended recipient, do not forward or disclose this E-Mail, open any attachments, make any copies or save this E-Mail anywhere. > Please delete this E-Mail from your system and notify the sender (as applicable also by phone +49 2166 266-0). Thank you very much. > > To send this email we must process the following personal data: Your email address, first name and surname. > Your data is processed solely for the purpose of sending this email and passed on to third parties only for this purpose. > You have been included in the circle of recipients for our emails due to your professional, social or political position. If this position changes, or you inform us that you do not want to receive emails from us, or you object to the further processing of your data, we will delete your data and no longer use it. > From andy.herrick at oracle.com Mon Dec 16 15:32:09 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 16 Dec 2019 10:32:09 -0500 Subject: RFR: 8235915: jpackage associations fail when there are spaces in file name or path Message-ID: <079911ea-03a3-e89a-df9c-f8c4ff798d3a@oracle.com> Please review this jpackage fix to [1] at [2] the change just adds quotes around the Argument element's value in WIX xml's association definition. [1] https://bugs.openjdk.java.net/browse/JDK-8235915 [2] http://cr.openjdk.java.net/~herrick/8235915/webrev.01/ /Andy From andy.herrick at oracle.com Mon Dec 16 15:32:17 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 16 Dec 2019 10:32:17 -0500 Subject: RFR: JDK-8235667: IOUtils.copyFile() problems. In-Reply-To: <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> References: <95feef53-1a70-f92a-614d-a8a4a9fab1d4@oracle.com> <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> Message-ID: can I get a review from a Reviewer to push this simple fix in JDK-15 ? /Andy On 12/10/2019 3:00 PM, Andy Herrick wrote: > > On 12/10/2019 12:56 PM, Andy Herrick wrote: >> Please review the jpackage fix at [1] to issue [2]. >> >> This is a change to jpackage/internal/IOUtils.copyFile() to >> essentially replace it's content with a call to Files.copy() >> >> [1] http://cr.openjdk.java.net/~herrick/8235667/ >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8235667 >> >> /Andy >> > given the suggestion: >> The method ignores the return from mkdirs, you could replace that >> with Files.createDirectories if you want the IOException. > > I have revised the webrev at [3] > > [3] http://cr.openjdk.java.net/~herrick/8235667/webrev.02/ > > /Andy > From Roger.Riggs at oracle.com Mon Dec 16 15:46:07 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 16 Dec 2019 10:46:07 -0500 Subject: RFR: JDK-8235667: IOUtils.copyFile() problems. In-Reply-To: References: <95feef53-1a70-f92a-614d-a8a4a9fab1d4@oracle.com> <7b5a3315-47dc-7b1b-6a85-1986e70eafc0@oracle.com> Message-ID: <8fdfca78-76da-b14d-3b66-412d67f9a312@oracle.com> Hi Andy, The change looks ok. (As long as the files being copied have the needed execute, write and read permissions.) Roger On 12/16/19 10:32 AM, Andy Herrick wrote: > can I get a review from a Reviewer to push this simple fix in JDK-15 ? > > /Andy > > > On 12/10/2019 3:00 PM, Andy Herrick wrote: >> >> On 12/10/2019 12:56 PM, Andy Herrick wrote: >>> Please review the jpackage fix at [1] to issue [2]. >>> >>> This is a change to jpackage/internal/IOUtils.copyFile() to >>> essentially replace it's content with a call to Files.copy() >>> >>> [1] http://cr.openjdk.java.net/~herrick/8235667/ >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8235667 >>> >>> /Andy >>> >> given the suggestion: >>> The method ignores the return from mkdirs, you could replace that >>> with Files.createDirectories if you want the IOException. >> >> I have revised the webrev at [3] >> >> [3] http://cr.openjdk.java.net/~herrick/8235667/webrev.02/ >> >> /Andy >> From alexey.semenyuk at oracle.com Mon Dec 16 16:29:26 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 16 Dec 2019 11:29:26 -0500 Subject: RFR: 8235915: jpackage associations fail when there are spaces in file name or path In-Reply-To: <079911ea-03a3-e89a-df9c-f8c4ff798d3a@oracle.com> References: <079911ea-03a3-e89a-df9c-f8c4ff798d3a@oracle.com> Message-ID: <80686f50-e47e-4b23-7b9f-b423de0c92ad@oracle.com> Looks good. - Alexey On 12/16/2019 10:32 AM, Andy Herrick wrote: > Please review this jpackage fix to [1] at [2] > > the change just adds quotes around the Argument element's value in WIX > xml's association definition. > > [1] https://bugs.openjdk.java.net/browse/JDK-8235915 > > [2] http://cr.openjdk.java.net/~herrick/8235915/webrev.01/ > > /Andy > From web127438p1 at network-inventory.de Mon Dec 16 17:52:09 2019 From: web127438p1 at network-inventory.de (Thomas Vatter) Date: Mon, 16 Dec 2019 18:52:09 +0100 Subject: jpackager In-Reply-To: <92963084-603f-5068-ba82-bb103dd5af26@oracle.com> References: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> <92963084-603f-5068-ba82-bb103dd5af26@oracle.com> Message-ID: <63d0daee-46cd-f8a7-6301-e3ae067befa3@network-inventory.de> I 've tried with the recommended jpackage from JDK14 EA. The syntax has slightly changed, with the option --win-console it now shows the output as expected: > .\test01.exe Dec 16, 2019 6:41:01 PM simpleapp.SimpleApp main INFO: SimpleApp says hello Thomas Am 16.12.2019 um 15:14 schrieb Andy Herrick: > That was my initial reaction too, but I don't believe that is the > problem here. > > The arguments to jpackage used indicate you are using an older early > access version of jpackage. > > Can you try again using the jpackage in the latest JDK14 EA from > https://jdk.java.net/14/ ? > > /Andy > > On 12/15/2019 8:46 PM, Scott Palmer wrote: >> Welcome to Windows. >> >> The .exe is a Windows app not a Console app.? This is a distinction >> that only Microsoft seemed to think was needed.? All other platforms >> are sane. >> There is command line option to make a console app. >> >> --win-console >> >> >> Scott >> >> >> >>> On Dec 14, 2019, at 12:22 PM, Thomas Vatter >>> wrote: >>> >>> Hi, >>> >>> I've created a modular jar and jre image by jlink. >>> >>> I tested it with this command: >>> >>> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp >>> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main >>> INFO: SimpleApp says hello >>> >>> It says "SimpleApp says hello" in the powershell window. >>> >>> >>> Then I packaged it by >>> >>> jpackager.exe create-image --input dist --output jp_out --name test01 >>> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar >>> >>> This creates in the output folder a file structure with an exe file >>> in it. >>> >>> When I execute the exe file fron the powershell there is no error >>> message, but it doesn't say "SimpleApp says hello" any more. >>> >>> Is something wrong? >>> >>> regards >>> >>> Thomas >>> >>> >>> >>> >>> >>> > From huizhe.wang at oracle.com Mon Dec 16 17:54:50 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 16 Dec 2019 09:54:50 -0800 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> Message-ID: <6e0dc2e5-607c-b991-dad3-62fec79cb43d@oracle.com> On 12/12/19 10:46 PM, Igor Ignatyev wrote: > @Joe/Lance, > were there any reasons why you needed to switch jtreg's > requiredVersion back to 4.2b13 in jaxp? are there any reasons which > prevent jaxp from switching to jtreg4.2b16 now? > I don't recall any specific reason, if any. It would be fine to switch to jtreg4.2b16. Thanks, Joe From alexander.matveev at oracle.com Mon Dec 16 22:24:23 2019 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 16 Dec 2019 14:24:23 -0800 Subject: RFR: 8235915: jpackage associations fail when there are spaces in file name or path In-Reply-To: <079911ea-03a3-e89a-df9c-f8c4ff798d3a@oracle.com> References: <079911ea-03a3-e89a-df9c-f8c4ff798d3a@oracle.com> Message-ID: Looks good. On 12/16/2019 7:32 AM, Andy Herrick wrote: > Please review this jpackage fix to [1] at [2] > > the change just adds quotes around the Argument element's value in WIX > xml's association definition. > > [1] https://bugs.openjdk.java.net/browse/JDK-8235915 > > [2] http://cr.openjdk.java.net/~herrick/8235915/webrev.01/ > > /Andy > From igor.ignatyev at oracle.com Mon Dec 16 23:21:03 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 16 Dec 2019 15:21:03 -0800 Subject: [14] RFR(S/T) : 8235866 : bump jtreg requiredVersion to 4.2b16 In-Reply-To: <6e0dc2e5-607c-b991-dad3-62fec79cb43d@oracle.com> References: <764BB5FF-AC59-40E2-AB5A-F63A745E9AEE@oracle.com> <7522383C-1C26-4422-83CA-BB4E795CCF6B@oracle.com> <6e0dc2e5-607c-b991-dad3-62fec79cb43d@oracle.com> Message-ID: <50D6341B-2351-4975-ACEE-24BC29CFEDD5@oracle.com> thanks for confirming that Joe. -- Igor > On Dec 16, 2019, at 9:54 AM, Joe Wang wrote: > > > > On 12/12/19 10:46 PM, Igor Ignatyev wrote: >> @Joe/Lance, >> were there any reasons why you needed to switch jtreg's requiredVersion back to 4.2b13 in jaxp? are there any reasons which prevent jaxp from switching to jtreg4.2b16 now? >> > > I don't recall any specific reason, if any. It would be fine to switch to jtreg4.2b16. > > Thanks, > Joe From philip.race at oracle.com Mon Dec 16 23:40:13 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Dec 2019 15:40:13 -0800 Subject: RFR: 8235915: jpackage associations fail when there are spaces in file name or path In-Reply-To: <80686f50-e47e-4b23-7b9f-b423de0c92ad@oracle.com> References: <079911ea-03a3-e89a-df9c-f8c4ff798d3a@oracle.com> <80686f50-e47e-4b23-7b9f-b423de0c92ad@oracle.com> Message-ID: <5DF815DD.5080105@oracle.com> +1 Please add an appropriate noreg-* label to the bug. -phil On 12/16/19, 8:29 AM, Alexey Semenyuk wrote: > Looks good. > > - Alexey > > On 12/16/2019 10:32 AM, Andy Herrick wrote: >> Please review this jpackage fix to [1] at [2] >> >> the change just adds quotes around the Argument element's value in >> WIX xml's association definition. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8235915 >> >> [2] http://cr.openjdk.java.net/~herrick/8235915/webrev.01/ >> >> /Andy >> > From ivan.gerasimov at oracle.com Tue Dec 17 00:03:50 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 16 Dec 2019 16:03:50 -0800 Subject: RFR 8236034 : Use optimized Ques node for curly {0,1} quantifier Message-ID: Hello! In the regular expressions, the quantifier ? can be equally written as {0,1}. While for the former variant an optimized algorithm is used (coded in the Pattern.Ques class), the later variant uses more general and less efficient implementation (coded in the Pattern.Curly class). It would be beneficial, if we unify the implementation for these two variants of quantifier and make them both use Ques node. Also, I couldn't resist to do some refactoring in the affected potion of the code to eliminate the repetition of logics. The regression test was modified to exercise both forms of quantifiers equally well. Would you please help review this enhancement? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8236034 WEBREV: http://cr.openjdk.java.net/~igerasim/8236034/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From ivan.gerasimov at oracle.com Tue Dec 17 02:01:51 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 16 Dec 2019 18:01:51 -0800 Subject: RFR 8234423 : Modifying ArrayList.subList().subList() resets modCount of subList In-Reply-To: References: Message-ID: <51454a53-df3d-045b-f02b-ac77f390540a@oracle.com> Gentle ping. Will someone please volunteer to review this fix of a regression? Thanks in advance! > On 11/20/19 10:11 PM, Ivan Gerasimov wrote: >> Hello! >> >> When a sublist of a sublist of an ArrayList is created, its modCount >> is initialized from the ArrayList root, and not from its immediate >> parent. >> >> This means that modifying that 2nd level sublist will reset modCounts >> of the entire chain up to the root, and consequently the 1st level >> sublist won't detect concurrent modification done to the ArrayList root. >> >> Along with the fix, handling of modCount is slightly improved in a >> few other places. >> >> Would you please help review the fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234423 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8234423/00/webrev/ >> -- With kind regards, Ivan Gerasimov From patrick at os.amperecomputing.com Tue Dec 17 03:00:30 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Tue, 17 Dec 2019 03:00:30 +0000 Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: References: Message-ID: Thanks Martin. Hi net-dev, and/or security-dev Reviewers, Please help review and sponsor this patch if acceptable. It does not tend to bring any functionality changes, instead to propose an early fix, for the build (linking) errors with further toolchain (GCC 10). JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ Regards Patrick From: Martin Buchholz Sent: Monday, December 16, 2019 10:44 AM To: Patrick Zhang OS ; net-dev ; OpenJDK Cc: core-libs-dev Subject: Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors forwarded to other teams for review. On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS > wrote: Hi Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ A recent GCC patch (supposed to be in GCC 10) exposes a couple of "multiple definition" link errors when building the jdk tip. [PATCH] PR85678: Change default to -fno-common https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html For example, the error message looks like: * For target support_native_java.base_libjava_BUILD_LIBJAVA_link: build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple definition of `parentPathv' build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first defined here collect2: error: ld returned 1 exit status This was not an issue because the original default -fcommon allowed "global variables defined without an initializer" be handled as COMMON symbols, so it would not warn the problem like "same variable is accidentally defined in more than one compilation unit". About -fcommon vs -fno-cmmon: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common Moving forward, building jdk with latest versions of GCC will trigger this error. Specifying "--with-extra-cflags='-fcommon'" can make it work, but it just got things hidden again. In addition, -fcommon's behavior "is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors." Last, in case that other jdk developers would revisit this problem once again, I suggest fixing the error explicitly instead of using "-fcommon" Regards Patrick From verghese at amazon.com Tue Dec 17 03:50:17 2019 From: verghese at amazon.com (Verghese, Clive) Date: Tue, 17 Dec 2019 03:50:17 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> Message-ID: <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> Hi Volker, Thank you for the feedback. I have update the revision to reflect your comments. http://cr.openjdk.java.net/~phh/8235699/webrev.01/ Regards, Clive Verghese ?On 12/13/19, 8:09 AM, "Volker Simonis" wrote: Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fields. But for "real" fields, zero is a valid value which you might want to print. You might however still consider printing the "stamps" (i.e. the lower half) as well, e.g.: sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); Thank you and best regards, Volker On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive wrote: > > Additional information regarding the field array. > > It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. > The original implementation was intending to display the second half of the array. Though the outer loop > iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated > this to display the whole array. > > Regards, > Clive Verghese > > From: "Verghese, Clive" > Date: Thursday, December 12, 2019 at 2:07 PM > To: "core-libs-dev at openjdk.java.net" > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString > > Hi, > > Requesting review for > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. > The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger > reaches this class and uses the toString function to print the class. > > Steps to reproduce this is attached in the JBS issue. > > Regards, > Clive Verghese > > From chris.hegarty at oracle.com Tue Dec 17 11:05:51 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 Dec 2019 11:05:51 +0000 Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: References: Message-ID: The changes to the SCTP code seem ok. -Chris. > On 17 Dec 2019, at 03:00, Patrick Zhang OS wrote: > > Thanks Martin. > > Hi net-dev, and/or security-dev Reviewers, > > Please help review and sponsor this patch if acceptable. > It does not tend to bring any functionality changes, instead to propose an early fix, for the build (linking) errors with further toolchain (GCC 10). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 > Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ > > Regards > Patrick > > From: Martin Buchholz > Sent: Monday, December 16, 2019 10:44 AM > To: Patrick Zhang OS ; net-dev ; OpenJDK > Cc: core-libs-dev > Subject: Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors > > forwarded to other teams for review. > > On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS > wrote: > Hi > > Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 > Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ > > A recent GCC patch (supposed to be in GCC 10) exposes a couple of "multiple definition" link errors when building the jdk tip. > > [PATCH] PR85678: Change default to -fno-common > https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html > > For example, the error message looks like: > * For target support_native_java.base_libjava_BUILD_LIBJAVA_link: > build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple definition of `parentPathv' > build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first defined here > collect2: error: ld returned 1 exit status > > This was not an issue because the original default -fcommon allowed "global variables defined without an initializer" be handled as COMMON symbols, so it would not warn the problem like "same variable is accidentally defined in more than one compilation unit". > > About -fcommon vs -fno-cmmon: > https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common > > Moving forward, building jdk with latest versions of GCC will trigger this error. Specifying "--with-extra-cflags='-fcommon'" can make it work, but it just got things hidden again. > > In addition, -fcommon's behavior "is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors." > > Last, in case that other jdk developers would revisit this problem once again, I suggest fixing the error explicitly instead of using "-fcommon" > > Regards > Patrick From thomas_vatter at web.de Mon Dec 16 07:47:51 2019 From: thomas_vatter at web.de (Thomas Vatter) Date: Mon, 16 Dec 2019 08:47:51 +0100 Subject: jpackager In-Reply-To: References: <3f673e3b-3323-ec48-dfd8-cc27e467f64d@web.de> Message-ID: <49816dd1-71ff-c4cc-0aae-f1422de583d5@web.de> Hi Scott, thank you for you answer and explainationr, I did another test the weekend, with a JFrame Window and this is shown. Thomas Am 16.12.2019 um 02:46 schrieb Scott Palmer: > Welcome to Windows. > > The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. > There is command line option to make a console app. > > --win-console > > > Scott > > > >> On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: >> >> Hi, >> >> I've created a modular jar and jre image by jlink. >> >> I tested it with this command: >> >> PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp >> Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main >> INFO: SimpleApp says hello >> >> It says "SimpleApp says hello" in the powershell window. >> >> >> Then I packaged it by >> >> jpackager.exe create-image --input dist --output jp_out --name test01 >> --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar >> >> This creates in the output folder a file structure with an exe file in it. >> >> When I execute the exe file fron the powershell there is no error >> message, but it doesn't say "SimpleApp says hello" any more. >> >> Is something wrong? >> >> regards >> >> Thomas >> >> >> >> >> >> From igor.ignatyev at oracle.com Tue Dec 17 19:30:26 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 17 Dec 2019 11:30:26 -0800 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling Message-ID: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ > 31 lines changed: 20 ins; 11 del; 0 mod; Hi all, could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. from JBS: > currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. testing: tier1-5 JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ Thanks, -- Igor From suenaga at oss.nttdata.com Tue Dec 17 23:32:01 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 18 Dec 2019 08:32:01 +0900 Subject: RFR (trivial): 8235833: PosixPlatform.cpp should not include sysctl.h In-Reply-To: <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> References: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> Message-ID: <8b8ab138-7ed7-96f2-eaf0-47e919b00c38@oss.nttdata.com> PING: Could you review this trivial change? > JBS: https://bugs.openjdk.java.net/browse/JDK-8235833 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235833/webrev.00/ Yasumasa On 2019/12/12 22:23, Yasumasa Suenaga wrote: > Hi Andrew, > > I can see same error whether --disable-precompiled-headers or not. > So I filed it to JBS and uploaded webrev. > Could you review it? > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8235833 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235833/webrev.00/ > > It works fine on Fedora 31. > I've pushed it to submit repo. I believe it passes all tests. > > > Thanks, > > Yasumasa > > > On 2019/12/12 19:25, Andrew Haley wrote: >> On 12/12/19 9:31 AM, Yasumasa Suenaga wrote: >>> AFAICS sysctl.h provides `sysctl()` and some macros, but they are not used in PosixPlatform.cpp . >>> In fact, I did not see any error when I remove `#include ` from it. >> >> You probably won't see an error unless you configure with >> --disable-precompiled-headers. Please try that, and we can then >> consider removing that #include. >> From alexey.semenyuk at oracle.com Wed Dec 18 01:31:49 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 17 Dec 2019 20:31:49 -0500 Subject: RFR: JDK-8236138: Add tests for jmod applications Message-ID: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> Please review fix [2] for jpackage bug [1]. The fix updates jtreg tests by adding test coverage for scenarios when jpackage is used for packaging applications bundled in .jmod files. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8236138 [2] http://cr.openjdk.java.net/~asemenyuk/8236138/webrev.00 From matthias.baesken at sap.com Wed Dec 18 09:43:36 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 18 Dec 2019 09:43:36 +0000 Subject: running java with LD_DEBUG-tracing Message-ID: Hello, I recently worked a bit with the "verbose debugging information" output about operations of the dynamic linker (to sort out some lib loading issues) . See https://docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html http://man7.org/linux/man-pages/man8/ld.so.8.html about the LD_DEBUG flag. By chance I noticed the following output when running a trivial Java program : LD_DEBUG=libs /linuxx86_64/output-jdk-test/images/jdk/bin/java Test . . . 12241: 12241: /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol lookup error: undefined symbol: Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) 12241: What is wrong with "Java_jdk_internal_reflect_Reflection_getCallerClass" ? Does the error message occur because of the naming Java_jdk_internal_reflect_Reflection_getCallerClass__ with the added "__" at the end of the method (Reflection.c) ? Best regards, Matthias From david.holmes at oracle.com Wed Dec 18 12:43:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Dec 2019 22:43:34 +1000 Subject: running java with LD_DEBUG-tracing In-Reply-To: References: Message-ID: On 18/12/2019 7:43 pm, Baesken, Matthias wrote: > Hello, I recently worked a bit with the "verbose debugging information" output about operations of the dynamic linker (to sort out some lib loading issues) . > See > > https://docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html > http://man7.org/linux/man-pages/man8/ld.so.8.html > > about the LD_DEBUG flag. > > > By chance I noticed the following output when running a trivial Java program : > > LD_DEBUG=libs /linuxx86_64/output-jdk-test/images/jdk/bin/java Test > . . . > 12241: > 12241: /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol lookup error: undefined symbol: Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) > 12241: > > What is wrong with "Java_jdk_internal_reflect_Reflection_getCallerClass" ? > Does the error message occur because of the naming Java_jdk_internal_reflect_Reflection_getCallerClass__ with the added "__" at the end of the method (Reflection.c) ? That definitely looks like an error in the C source to me. The ending "__" should not be there. How is this working ?? David > > > Best regards, Matthias > > From david.holmes at oracle.com Wed Dec 18 12:51:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Dec 2019 22:51:52 +1000 Subject: running java with LD_DEBUG-tracing In-Reply-To: References: Message-ID: On 18/12/2019 10:43 pm, David Holmes wrote: > On 18/12/2019 7:43 pm, Baesken, Matthias wrote: >> Hello, I? recently worked a bit with? the? "verbose debugging >> information"? output? about operations of the?? dynamic linker? (to >> sort out some lib loading issues) . >> See >> >> https://docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html >> http://man7.org/linux/man-pages/man8/ld.so.8.html >> >> ?? about the LD_DEBUG? flag. >> >> >> By chance I noticed? the following? output when running a trivial Java >> program? : >> >> LD_DEBUG=libs???? /linuxx86_64/output-jdk-test/images/jdk/bin/java?? Test >> ?? . . . >> ????? 12241: >> ????? 12241: >> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol >> lookup error: undefined symbol: >> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) >> ????? 12241: >> >> What is wrong with >> "Java_jdk_internal_reflect_Reflection_getCallerClass"? ? >> Does the error message? occur because of? the naming >> Java_jdk_internal_reflect_Reflection_getCallerClass__? with the added >> "__"? at the end of the method? (Reflection.c) ? > > That definitely looks like an error in the C source to me. The ending > "__" should not be there. How is this working ?? Ah! It is a remnant of when there were overloads of getCallerClass. The "__" should be followed by the signature - which is empty in this case. So IIRC the lookup will first try to use the short name (without the trailing "__") which will fail, then it will use the long name which will succeed. It should be fixed so we don't waste time doing two lookups. David > > David > >> >> >> Best regards, Matthias >> >> From matthias.baesken at sap.com Wed Dec 18 12:57:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 18 Dec 2019 12:57:08 +0000 Subject: running java with LD_DEBUG-tracing In-Reply-To: References: Message-ID: Hi David, thanks for clarification . Guess we can just remove the __ now and avoid one lookup. I'll open a bug for this . Best regards, Matthias > On 18/12/2019 10:43 pm, David Holmes wrote: > > On 18/12/2019 7:43 pm, Baesken, Matthias wrote: > >> Hello, I? recently worked a bit with? the? "verbose debugging > >> information"? output? about operations of the?? dynamic linker? (to > >> sort out some lib loading issues) . > >> See > >> > >> https://docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html > >> http://man7.org/linux/man-pages/man8/ld.so.8.html > >> > >> ?? about the LD_DEBUG? flag. > >> > >> > >> By chance I noticed? the following? output when running a trivial Java > >> program? : > >> > >> LD_DEBUG=libs???? /linuxx86_64/output-jdk- > test/images/jdk/bin/java?? Test > >> ?? . . . > >> ????? 12241: > >> ????? 12241: > >> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol > >> lookup error: undefined symbol: > >> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) > >> ????? 12241: > >> > >> What is wrong with > >> "Java_jdk_internal_reflect_Reflection_getCallerClass"? ? > >> Does the error message? occur because of? the naming > >> Java_jdk_internal_reflect_Reflection_getCallerClass__? with the added > >> "__"? at the end of the method? (Reflection.c) ? > > > > That definitely looks like an error in the C source to me. The ending > > "__" should not be there. How is this working ?? > > Ah! It is a remnant of when there were overloads of getCallerClass. The > "__" should be followed by the signature - which is empty in this case. > So IIRC the lookup will first try to use the short name (without the > trailing "__") which will fail, then it will use the long name which > will succeed. > > It should be fixed so we don't waste time doing two lookups. > > David > > > > > David > > > >> > >> > >> Best regards, Matthias > >> > >> From matthias.baesken at sap.com Wed Dec 18 14:33:18 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 18 Dec 2019 14:33:18 +0000 Subject: RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing Message-ID: Hello David, Here is a change that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass - With this change, I checked the output of LD_DEBUG=libs java Test , and the error I observed before is gone . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8236183 http://cr.openjdk.java.net/~mbaesken/webrevs/8236183.0/ Thanks, Matthias > >> > >> By chance I noticed? the following? output when running a trivial Java > >> program? : > >> > >> LD_DEBUG=libs???? /linuxx86_64/output-jdk- > test/images/jdk/bin/java?? Test > >> ?? . . . > >> ????? 12241: > >> ????? 12241: > >> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol > >> lookup error: undefined symbol: > >> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) > >> ????? 12241: > >> > >> What is wrong with > >> "Java_jdk_internal_reflect_Reflection_getCallerClass"? ? > >> Does the error message? occur because of? the naming > >> Java_jdk_internal_reflect_Reflection_getCallerClass__? with the added > >> "__"? at the end of the method? (Reflection.c) ? > > > > That definitely looks like an error in the C source to me. The ending > > "__" should not be there. How is this working ?? > > Ah! It is a remnant of when there were overloads of getCallerClass. The > "__" should be followed by the signature - which is empty in this case. > So IIRC the lookup will first try to use the short name (without the > trailing "__") which will fail, then it will use the long name which > will succeed. > > It should be fixed so we don't waste time doing two lookups. > > David From claes.redestad at oracle.com Wed Dec 18 14:39:18 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 Dec 2019 15:39:18 +0100 Subject: RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing In-Reply-To: References: Message-ID: <6e676fc4-4eda-cbff-410d-4d34dbb9c134@oracle.com> Nice find! Looks good to me. /Claes On 2019-12-18 15:33, Baesken, Matthias wrote: > Hello David, > Here is a change that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass - > > With this change, I checked the output of LD_DEBUG=libs java Test , and the error I observed before is gone . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8236183 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8236183.0/ > > > Thanks, Matthias > > >>>> >>>> By chance I noticed? the following? output when running a trivial Java >>>> program? : >>>> >>>> LD_DEBUG=libs???? /linuxx86_64/output-jdk- >> test/images/jdk/bin/java?? Test >>>> ?? . . . >>>> ????? 12241: >>>> ????? 12241: >>>> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol >>>> lookup error: undefined symbol: >>>> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) >>>> ????? 12241: >>>> >>>> What is wrong with >>>> "Java_jdk_internal_reflect_Reflection_getCallerClass"? ? >>>> Does the error message? occur because of? the naming >>>> Java_jdk_internal_reflect_Reflection_getCallerClass__? with the added >>>> "__"? at the end of the method? (Reflection.c) ? >>> >>> That definitely looks like an error in the C source to me. The ending >>> "__" should not be there. How is this working ?? >> >> Ah! It is a remnant of when there were overloads of getCallerClass. The >> "__" should be followed by the signature - which is empty in this case. >> So IIRC the lookup will first try to use the short name (without the >> trailing "__") which will fail, then it will use the long name which >> will succeed. >> >> It should be fixed so we don't waste time doing two lookups. >> >> David > From andy.herrick at oracle.com Wed Dec 18 14:38:26 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 18 Dec 2019 09:38:26 -0500 Subject: RFR: JDK-8236138: Add tests for jmod applications In-Reply-To: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> References: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> Message-ID: Code looks good - ran tests locally and all passed. /Andyu On 12/17/2019 8:31 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > The fix updates jtreg tests by adding test coverage for scenarios when > jpackage is used for packaging applications bundled in .jmod files. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8236138 > > [2] http://cr.openjdk.java.net/~asemenyuk/8236138/webrev.00 From Alan.Bateman at oracle.com Wed Dec 18 14:41:48 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Dec 2019 14:41:48 +0000 Subject: RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing In-Reply-To: References: Message-ID: <1159a9ee-0bfa-62b0-f29e-f57b738b8fef@oracle.com> On 18/12/2019 14:33, Baesken, Matthias wrote: > Hello David, > Here is a change that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass - > > With this change, I checked the output of LD_DEBUG=libs java Test , and the error I observed before is gone . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8236183 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8236183.0/ > > Good sleuthing, this change looks good. -Alan. From Roger.Riggs at oracle.com Wed Dec 18 15:48:34 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 18 Dec 2019 10:48:34 -0500 Subject: RFR 8225466 : Optimize matching BMP Slice nodes In-Reply-To: <3657c460-15a0-2aa1-1092-97d196cf125b@oracle.com> References: <3657c460-15a0-2aa1-1092-97d196cf125b@oracle.com> Message-ID: Hi Ivan, Though the new code has a good effect, the asymmetry and duplication seems unnecessary. Can it be structured to have a single copy of the loop comparing the available range and still get the desired performance improvement. Like: boolean match(Matcher matcher,int i, CharSequence seq) { int[] buf =buffer; int len = buf.length; for (int j =0; j < Math.min(len, matcher.to); j++) { if (buf[j] != seq.charAt(i+j)) return false; } if (len >= matcher.to) { matcher.hitEnd =true; return false; } return next.match(matcher, i+len, seq); } Regards, Roger On 10/28/19 9:03 PM, Ivan Gerasimov wrote: > Hello! > > When building a Pattern object, the regex parser recognizes "slices" - > continuous char subsequences, which all have to be matched > case-sensitively/case-insensitively.? Matching with such a slice is > implemented as a simple loop over a portion of the input. > > In the current implementation, on each iteration of the loop it is > checked if we have hit the end of the input (which is an uncommon case). > > This check can be done only once, before the loop, which will make the > loop lighter. > > Benchmark shows up to +4% to the throughput for the case-insensitive > matching. > > Would you please help review the enhancement? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8225466 > WEBREV: http://cr.openjdk.java.net/~igerasim/8225466/00/webrev/ > > > ----------- benchmark results --------------- > > UNFIXED > Benchmark??????????????? Mode? Cnt??? Score?? Error? Units > PatternBench.sliceIFind? avgt?? 16? 190.612 ? 0.336? ns/op > > FIXED > Benchmark??????????????? Mode? Cnt??? Score?? Error? Units > PatternBench.sliceIFind? avgt?? 16? 182.954 ? 0.493? ns/op > ------------------------------------------- > From ivan.gerasimov at oracle.com Wed Dec 18 18:37:07 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 18 Dec 2019 10:37:07 -0800 Subject: RFR 8225466 : Optimize matching BMP Slice nodes In-Reply-To: References: <3657c460-15a0-2aa1-1092-97d196cf125b@oracle.com> Message-ID: <5d3df23b-86a2-e5a6-c1c5-d3fe2585d51e@oracle.com> Hi Roger. Thank you for taking a look! The variant with a single loop was the first thing I tried (should have mentioned that in the review request). Unfortunately, that showed performance decrease. I suspect that hitting the end of the input should be a less common thing, that's why it it beneficial to separate it as a slow path. With kind regards, Ivan On 12/18/19 7:48 AM, Roger Riggs wrote: > Hi Ivan, > > Though the new code has a good effect, the asymmetry and duplication > seems unnecessary. > Can it be structured to have a single copy of the loop comparing the > available range > and still get the desired performance improvement. > > Like: > > boolean match(Matcher matcher,int i, CharSequence seq) { > ??? int[] buf =buffer; > ??? int len = buf.length; > ??? for (int j =0; j < Math.min(len, matcher.to); j++) { > ??????? if (buf[j] != seq.charAt(i+j)) > ??????????? return false; > ??? } > ??? if (len >= matcher.to) { > ??????? matcher.hitEnd =true; > ??????? return false; > ??? } > ??? return next.match(matcher, i+len, seq); > } > > Regards, Roger > > > On 10/28/19 9:03 PM, Ivan Gerasimov wrote: >> Hello! >> >> When building a Pattern object, the regex parser recognizes "slices" >> - continuous char subsequences, which all have to be matched >> case-sensitively/case-insensitively.? Matching with such a slice is >> implemented as a simple loop over a portion of the input. >> >> In the current implementation, on each iteration of the loop it is >> checked if we have hit the end of the input (which is an uncommon case). >> >> This check can be done only once, before the loop, which will make >> the loop lighter. >> >> Benchmark shows up to +4% to the throughput for the case-insensitive >> matching. >> >> Would you please help review the enhancement? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8225466 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8225466/00/webrev/ >> >> >> ----------- benchmark results --------------- >> >> UNFIXED >> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >> PatternBench.sliceIFind? avgt?? 16? 190.612 ? 0.336? ns/op >> >> FIXED >> Benchmark??????????????? Mode? Cnt??? Score?? Error? Units >> PatternBench.sliceIFind? avgt?? 16? 182.954 ? 0.493? ns/op >> ------------------------------------------- >> > -- With kind regards, Ivan Gerasimov From david.holmes at oracle.com Wed Dec 18 22:02:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Dec 2019 08:02:30 +1000 Subject: RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing In-Reply-To: References: Message-ID: <1d04a084-a9b9-5a92-2e9c-1e3babc5a59f@oracle.com> Hi Matthias, Looks good. Thanks for fixing and finding. :) David On 19/12/2019 12:33 am, Baesken, Matthias wrote: > Hello David, > Here is a change that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass - > > With this change, I checked the output of LD_DEBUG=libs java Test , and the error I observed before is gone . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8236183 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8236183.0/ > > > Thanks, Matthias > > >>>> >>>> By chance I noticed? the following? output when running a trivial Java >>>> program? : >>>> >>>> LD_DEBUG=libs???? /linuxx86_64/output-jdk- >> test/images/jdk/bin/java?? Test >>>> ?? . . . >>>> ????? 12241: >>>> ????? 12241: >>>> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol >>>> lookup error: undefined symbol: >>>> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal) >>>> ????? 12241: >>>> >>>> What is wrong with >>>> "Java_jdk_internal_reflect_Reflection_getCallerClass"? ? >>>> Does the error message? occur because of? the naming >>>> Java_jdk_internal_reflect_Reflection_getCallerClass__? with the added >>>> "__"? at the end of the method? (Reflection.c) ? >>> >>> That definitely looks like an error in the C source to me. The ending >>> "__" should not be there. How is this working ?? >> >> Ah! It is a remnant of when there were overloads of getCallerClass. The >> "__" should be followed by the signature - which is empty in this case. >> So IIRC the lookup will first try to use the short name (without the >> trailing "__") which will fail, then it will use the long name which >> will succeed. >> >> It should be fixed so we don't waste time doing two lookups. >> >> David > From philip.race at oracle.com Thu Dec 19 00:17:57 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 18 Dec 2019 16:17:57 -0800 Subject: RFR: JDK-8236138: Add tests for jmod applications In-Reply-To: References: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> Message-ID: <5DFAC1B5.8010809@oracle.com> Code looks fine, I did not run the tests, but +1 assuming this has been run through a mach5 test job already. If not please submit one first. -phil. On 12/18/19, 6:38 AM, Andy Herrick wrote: > Code looks good - ran tests locally and all passed. > > /Andyu > > On 12/17/2019 8:31 PM, Alexey Semenyuk wrote: >> Please review fix [2] for jpackage bug [1]. >> >> The fix updates jtreg tests by adding test coverage for scenarios >> when jpackage is used for packaging applications bundled in .jmod files. >> >> - Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236138 >> >> [2] http://cr.openjdk.java.net/~asemenyuk/8236138/webrev.00 From aph at redhat.com Thu Dec 19 09:07:25 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Dec 2019 10:07:25 +0100 Subject: RFR (trivial): 8235833: PosixPlatform.cpp should not include sysctl.h In-Reply-To: <8b8ab138-7ed7-96f2-eaf0-47e919b00c38@oss.nttdata.com> References: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> <8b8ab138-7ed7-96f2-eaf0-47e919b00c38@oss.nttdata.com> Message-ID: On 12/17/19 11:32 PM, Yasumasa Suenaga wrote: > PING: Could you review this trivial change? > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8235833 >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235833/webrev.00/ It's OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From suenaga at oss.nttdata.com Thu Dec 19 11:08:38 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 19 Dec 2019 20:08:38 +0900 Subject: RFR (trivial): 8235833: PosixPlatform.cpp should not include sysctl.h In-Reply-To: References: <196bf715-eb83-d8f0-64f6-54ca3af39df5@oss.nttdata.com> <37123598-d26b-e6e6-d9b4-e56bd8ce39a6@oss.nttdata.com> <8b8ab138-7ed7-96f2-eaf0-47e919b00c38@oss.nttdata.com> Message-ID: Thanks Andrew! Yasumasa On 2019/12/19 18:07, Andrew Haley wrote: > On 12/17/19 11:32 PM, Yasumasa Suenaga wrote: >> PING: Could you review this trivial change? >> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8235833 >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8235833/webrev.00/ > > It's OK. > From alexey.semenyuk at oracle.com Thu Dec 19 16:25:35 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 19 Dec 2019 11:25:35 -0500 Subject: RFR: JDK-8236138: Add tests for jmod applications In-Reply-To: <5DFAC1B5.8010809@oracle.com> References: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> <5DFAC1B5.8010809@oracle.com> Message-ID: Mach5 test job was submitted, passed and I verified that changes in tests worked as expected. - Alexey On 12/18/2019 7:17 PM, Philip Race wrote: > Code looks fine, I did not run the tests, but +1 assuming this has > been run > through a mach5 test job already. If not please submit one first. > > -phil. > > On 12/18/19, 6:38 AM, Andy Herrick wrote: >> Code looks good - ran tests locally and all passed. >> >> /Andyu >> >> On 12/17/2019 8:31 PM, Alexey Semenyuk wrote: >>> Please review fix [2] for jpackage bug [1]. >>> >>> The fix updates jtreg tests by adding test coverage for scenarios >>> when jpackage is used for packaging applications bundled in .jmod >>> files. >>> >>> - Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8236138 >>> >>> [2] http://cr.openjdk.java.net/~asemenyuk/8236138/webrev.00 From sergei.tsypanov at yandex.ru Thu Dec 19 22:12:20 2019 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 20 Dec 2019 00:12:20 +0200 Subject: [PATCH] Flip operands of && in java.lang.reflect.Parameter.equals() Message-ID: <368561576793540@myt6-636ea6dfd460.qloud-c.yandex.net> Hello, while looking into an issue related to reflection I've found out that Parameter.equals() could be slightly improved by switching operands of &&. Consider the worst case when we have a method public String doSmth(String str1, String str2) { return str1 + str2; } and we compare its params: Method method = getClass().getMethod("doSmth", String.class, String.class); Parameter[] parameters = method.getParameters(); boolean sameParam = parameters[0].equals(parameters[1]) In this case we compare two Executables (which are equal) and only then fail the comparison when checking indices. I propose to employ fail-fast approach and first check indices as primitives comparation is likely to be faster than invocation of Executable.equals(). Patch is below diff --git a/src/java.base/share/classes/java/lang/reflect/Parameter.java b/src/java.base/share/classes/java/lang/reflect/Parameter.java --- a/src/java.base/share/classes/java/lang/reflect/Parameter.java +++ b/src/java.base/share/classes/java/lang/reflect/Parameter.java @@ -78,8 +78,7 @@ public boolean equals(Object obj) { if(obj instanceof Parameter) { Parameter other = (Parameter)obj; - return (other.executable.equals(executable) && - other.index == index); + return other.index == index && other.executable.equals(executable); } return false; } From alexey.semenyuk at oracle.com Fri Dec 20 01:02:12 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 19 Dec 2019 20:02:12 -0500 Subject: RFR: JDK-8232077: Investigate if default behavior should allow downgrade scenario In-Reply-To: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> References: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> Message-ID: Please review fix [2] for jpackage bug [1]. The fix changes the default setting for Windows installers to allow downgrades. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8232077 [2] http://cr.openjdk.java.net/~asemenyuk/8232077/webrev.00 From alexey.semenyuk at oracle.com Fri Dec 20 01:52:45 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 19 Dec 2019 20:52:45 -0500 Subject: RFR: JDK-8233578: Document configurable parameters of msi packages In-Reply-To: References: Message-ID: <6a0e63fe-d1c7-28b9-64c2-598a306bb693@oracle.com> Please review fix [2] for jpackage bug [1]. Comments added to the default WiX source file explaining how the default file is expected to be overridden. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8233578 [2] http://cr.openjdk.java.net/~asemenyuk/8233578/webrev.00 From sgehwolf at redhat.com Fri Dec 20 14:50:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Dec 2019 15:50:54 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> Message-ID: <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> Hi Bob, Sorry for the delay to get this updated. Changes done in this latest webrev: 1. Rebased on top of 8226575: OperatingSystemMXBean should be made container aware. File read ops now use privileged code. 2. Warning for mixed cgroup controllers and returning null for metrics. 3. Added implementations for getBlkIOServiceCount() and getBlkIOServiced() using sum of rios/wios and rbytes/wbytes across devices. Added impl for getTcpMemoryUsage() 4. Returning -2 for not supported (if the metric would return long). boolean metrics now return Boolean and null if not supported. Same for array return types. null if not supported for symmetry. 5. -XshowSettings:system output has been updated to return "N/A" for when a metric is not available. E.g. "Kernel OOM killer enabled" Boolean. 6. Tests have been updated to reflect this. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06/webrev/ incremental webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/06-incremental/webrev/ Testing: Docker tests and podman testing on cgroupsv2. I'll run it through jdk/submit as well. Hopefully this can get pushed with 8230305 early on in the jdk 15 cycle :) A couple of more inline comments below. On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: > Sorry for the delay in responding. See comments below: > > > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: > > > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get reviews of these core-libs, Linux-only, changes to > > > the Metrics subsystem? This patch implements cgroupv2 support for > > > Metrics which are currently cgroupv1-only. Fedora 31 switched to > > > cgroupv2 by default so it's time to get OpenJDK recognize it. > > > > > > Note that a couple of metrics are no longer supported with cgroupv2. > > > Most notably (not an exhaustive list, though): > > > > > > Metrics.getKernel*() family of methods. > > > Metrics.getTcp*() family of methods. > > > Metrics.getBlkIO*() family of methods. > > > Metrics.isMemoryOOMKillEnabled() > > > > > > A couple of open questions with regards to that: > > > > > > 1) > > > Most API docs of Metrics make no distiction between "unlimited" and > > > "not supported", both returning -1 for longs, for example. This is a > > > problem, because output of "java -XshowSettings:system -version" will > > > not distinguish between unlimited and not supported metrics. Would it > > > be acceptable to change the API to distinguish those cases so that > > > LauncherHelper could display them appropriately? > > > > > > 2) > > > How should we deal with "not supported" for booleans/arrays, etc.? > > > Would it make sense to return record objects from the Metrics API so > > > that this could be dealt with? E.g. > > > > > > Metrics m = ... > > > MetricResult result = m.getCpuSetCpus(); > > > switch(result.getType()) { > > > case NOT_SUPPORTED: /* do something */; break; > > > case SUPPORTED: int[] val = result.get(); break; > > > ... > > > } > > > > > > I'm bringing this up, because the proposed patch doesn't deal with the > > > above open questions as of yet. With that being said, it's mostly > > > identical to the proposed hotspot changes in [1]. > > For issue 1 and 2 ? > > I wonder if we should change the API to throw UnsupportedOperationException for those methods > that are not available. This exception is used quite a lot in the java/nio and java/net packages > for dealing with functionality not available on a host platform. > > As an alternate suggestion, we already return -2 for "not supported" for most APIs in the hotspot > implementation. We could use this for non boolean values in the Metrics API. For boolean > values, we could change the API to return ?Boolean?. A null return would signify not > implemented. This alternative has been implemented in the latest webrev. LauncherHelper has been updated to print "N/A" if some property being printed is not supported. Example output for cgroupsv2: $ ./bin/java -XshowSettings:system -version Operating System Metrics: Provider: cgroupv2 Effective CPU Count: 4 CPU Period: 100000us CPU Quota: -1 CPU Shares: -1 List of Processors: N/A List of Effective Processors: N/A List of Memory Nodes: N/A List of Available Memory Nodes: N/A CPUSet Memory Pressure Enabled: N/A Memory Limit: Unlimited Memory Soft Limit: Unlimited Memory & Swap Limit: Unlimited Kernel Memory Limit: N/A TCP Memory Limit: N/A Out Of Memory Killer Enabled: N/A openjdk version "15-internal" 2020-09-15 OpenJDK Runtime Environment (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2) OpenJDK 64-Bit Server VM (build 15-internal+0-adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231111 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/ > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java.html > > Should we check to make sure that there are no mixed cgroupv1 and cgroupv2 mounted subsystems since > you are not supporting mixing. Done. null is returned for metrics and a warning printed to stderr. > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/04/webrev/src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java.html > > It looks looks like there may be alternate ways of reporting some of the metrics that you have classified as RETVAL_NOT_SUPPORTED. > > BlkIOServicedCount (io.stat) > KernelMemory (memory.stat) > TcpMemory (memory.stat) The latest webrev has getBlkIOService* and getTcpMemoryUsage impls. I've left out kernel memory metrics as it wasn't clear what this would be. We can add that in a later patch. The size of this patch is already rather big. > You could try the same trick for getMemoryAndSwapMaxUsage which keeps track of the highest returned value. We've decided to not do this. getMemoryAndSwapMaxUsage and getMemoryMaxUsage is being returned as not supported in cgroups v2. Thanks, Severin > for the benefit of other reviewers, you should provide links to the cgroupv1 and v2 docs. > > https://www.kernel.org/doc/Documentation/cgroup-v2.txt > > > > Testing: jdk/submit and platform docker tests on Linux x86_64 (with > > > hybrid hierarchy, docker/podman) and on Linux x86_64 with unified > > > hierarchy (podman only). > > > > > > Thoughts? Suggestions? > > Do you think we should check the docker version being used for the tests to make sure it > supports cgroupv2? I assume a fairly recent version is required to work with cgroupv2. > > Bob. > > > > > Ping? > > > > > Thanks, > > > Severin > > > > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-November/039909.html From fweimer at redhat.com Fri Dec 20 15:45:43 2019 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 20 Dec 2019 16:45:43 +0100 Subject: RFR 8234362: k_standard.c is not needed and should be removed In-Reply-To: <871ru429ll.fsf@oldenburg2.str.redhat.com> (Florian Weimer's message of "Mon, 18 Nov 2019 21:49:42 +0100") References: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com> <871ru429ll.fsf@oldenburg2.str.redhat.com> Message-ID: <87y2v7f1aw.fsf@oldenburg2.str.redhat.com> * Florian Weimer: > * Florian Weimer: > >> __kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c >> is built for _IEEE_LIBM targets as well, but it appears superfluous >> there. >> >> In noticed this because GCC 10 flags an uninitialized variable in this >> code: >> >> ?/src/java.base/share/native/libfdlibm/k_standard.c: In function '__j__kernel_standard': >> ?/src/java.base/share/native/libfdlibm/k_standard.c:743:19: error: 'exc.retval' may be used uninitialized in this function [-Werror=maybe-uninitialized] >> 743 | return exc.retval; >> | ~~~^~~~~~~ >> >> Rather than debating whether this warning is reasonableor not, I would >> suggest to #ifdef out this code for _IEEE_LIBM targets (are there any >> else left?). > > I think the file should just be removed. > > Bug: > Webrev: > > As usual, I'll need a sponsor for this. Is there anything I can do to make this patch more palatable? Thanks, Florian From andy.herrick at oracle.com Fri Dec 20 16:53:24 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 20 Dec 2019 11:53:24 -0500 Subject: RFR: JDK-8232077: Investigate if default behavior should allow downgrade scenario In-Reply-To: References: <994eafae-5449-c6aa-896e-73a8734d2eb4@oracle.com> Message-ID: fix looks fine. /Andy On 12/19/2019 8:02 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > The fix changes the default setting for Windows installers to allow > downgrades. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8232077 > > [2] http://cr.openjdk.java.net/~asemenyuk/8232077/webrev.00 From andy.herrick at oracle.com Fri Dec 20 16:56:30 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 20 Dec 2019 11:56:30 -0500 Subject: RFR: JDK-8233578: Document configurable parameters of msi packages In-Reply-To: <6a0e63fe-d1c7-28b9-64c2-598a306bb693@oracle.com> References: <6a0e63fe-d1c7-28b9-64c2-598a306bb693@oracle.com> Message-ID: <563ce369-c6ec-6846-075b-06eecf7633b1@oracle.com> looks good. /Andy On 12/19/2019 8:52 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Comments added to the default WiX source file explaining how the > default file is expected to be overridden. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8233578 > > [2] http://cr.openjdk.java.net/~asemenyuk/8233578/webrev.00 From alexey.semenyuk at oracle.com Fri Dec 20 20:16:22 2019 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 20 Dec 2019 15:16:22 -0500 Subject: RFR: JDK-8236132: Add missing properties to msi installers In-Reply-To: References: Message-ID: Please review fix [2] for jpackage bug [1]. Add properties to msi installers to properly display installation location and icon of the application in the list of installed applications. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8236132 [2] http://cr.openjdk.java.net/~asemenyuk/8236132/webrev.00 From naoto.sato at oracle.com Fri Dec 20 20:57:00 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 20 Dec 2019 12:57:00 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols Message-ID: Hi, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8227313 The proposed CSR and changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8235942 https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ The change introduces the new monetary grouping separator in DecimalFormatSymbols, and it is used if a DecimalFormat instance designates currency formatting where its pattern includes the currency symbol (U+00A5). The change makes use of the CLDR data which provides two distinct grouping separators (one for generic, the other for currency) in some locales. It also addresses the similar cases for the decimal separator. Naoto From vladimir.kozlov at oracle.com Fri Dec 20 22:19:54 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Dec 2019 14:19:54 -0800 Subject: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 In-Reply-To: References: <6563F381B547594081EF9DE181D07912B2D6B7A7@fmsmsx123.amr.corp.intel.com> <70b5bff1-a2ad-6fea-24ee-f0748e2ccae6@oracle.com> <3914890d-74e3-c69e-6688-55cf9f0c8551@oracle.com> Message-ID: <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com> We should have added core-libs to review since you modified BigInteger.java. webrev02 looks good to me. Let me test it. Thanks, Vladimir On 12/20/19 1:52 PM, Kamath, Smita wrote: > Hi Vladimir, > > Thank you for reviewing the code. I have updated the code as per your recommendations ( please look at the email below). > Link to the updated webrev: https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev02/ > > Regards, > Smita > > -----Original Message----- > From: Vladimir Kozlov > Sent: Thursday, December 19, 2019 5:17 PM > To: Kamath, Smita > Cc: Viswanathan, Sandhya ; 'hotspot compiler' > Subject: Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 > > We missed AOT and JVMCI (in HS) changes similar for Base64 [1] to record StubRoutines pointers: > > StubRoutines::_bigIntegerRightShiftWorker > StubRoutines::_bigIntegerLeftShiftWorker > Smita>>>done > > In the test add an other @run command with default setting (without -XX:-TieredCompilation -Xbatch). > Smita>>>done > > Thanks, > Vladimir > > [1] http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/ > > On 12/18/19 6:33 PM, Kamath, Smita wrote: >> Hi Vladimir, >> >> I have made the code changes you suggested (please look at the email below). >> I have also enabled the intrinsic to run only when VBMI2 feature is available. >> The intrinsic shows gains of >1.5x above 4k bit BigInteger. >> >> Webrev link: >> https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev01/ >> >> Thanks, >> Smita >> >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Wednesday, December 11, 2019 10:55 AM >> To: Kamath, Smita ; 'hotspot compiler' >> ; Viswanathan, Sandhya >> >> Subject: Re: RFR(M):8167065: Add intrinsic support for double >> precision shifting on x86_64 >> >> Hi Kamath, >> >> First, general question. What performance you see when VBMI2 instructions are *not* used with your new code vs code generated by C2. >> What improvement you see when VBMI2 is used. This is to understand if we need only VBMI2 version of intrinsic or not. >> >> Second. Sandhya recently pushed 8235510 changes to rollback avx512 code for CRC32 due to performance issues. Does you change has any issues on some Intel's CPU too? Should it be excluded on such CPUs? >> >> Third. I would suggest to wait after we fork JDK 14 with this changes. I think it may be too late for 14 because we would need test this including performance testing. >> >> In assembler_x86.cpp use supports_vbmi2() instead of UseVBMI2 in assert. >> For that to work in vm_version_x86.cpp#l687 clear CPU_VBMI2 bit when UseAVX < 3 ( < avx512). You can also use supports_vbmi2() instead of (UseAVX > 2 && UseVBMI2) in stubGenerator_x86_64.cpp combinations with that. >> Smita >>>done >> >> I don't think we need separate flag UseVBMI2 - it could be controlled by UseAVX flag. We don't have flag for VNNI or other avx512 instructions subset. >> Smita >> removed UseVBMI2 flag >> >> In vm_version_x86.cpp you need to add more %s in print statement for new output. >> Smita >>> done >> >> You need to add @requires vm.compiler2.enabled to new test's commands to run it only with C2. >> Smita >>> done >> >> You need to add intrinsics to Graal's test to ignore them: >> >> http://hg.openjdk.java.net/jdk/jdk/file/d188996ea355/src/jdk.internal. >> vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/gr >> aalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#l416 >> Smita >>>done >> >> Thanks, >> Vladimir >> >> On 12/10/19 5:41 PM, Kamath, Smita wrote: >>> Hi, >>> >>> >>> As per Intel Architecture Instruction Set Reference [1] VBMI2 Operations will be supported in future Intel ISA. I would like to contribute optimizations for BigInteger shift operations using AVX512+VBMI2 instructions. This optimization is for x86_64 architecture enabled. >>> >>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8167065 >>> >>> Link to webrev : >>> http://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev00/ >>> >>> >>> >>> I ran jtreg test suite with the algorithm on Intel SDE [2] to confirm that encoding and semantics are correctly implemented. >>> >>> >>> [1] >>> https://software.intel.com/sites/default/files/managed/39/c5/325462-s >>> d m-vol-1-2abcd-3abcd.pdf (vpshrdv -> Vol. 2C 5-477 and vpshldv -> >>> Vol. >>> 2C 5-471) >>> >>> [2] >>> https://software.intel.com/en-us/articles/intel-software-development- >>> e >>> mulator >>> >>> >>> Regards, >>> >>> Smita Kamath >>> From vladimir.kozlov at oracle.com Fri Dec 20 23:47:21 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Dec 2019 15:47:21 -0800 Subject: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 In-Reply-To: <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com> References: <6563F381B547594081EF9DE181D07912B2D6B7A7@fmsmsx123.amr.corp.intel.com> <70b5bff1-a2ad-6fea-24ee-f0748e2ccae6@oracle.com> <3914890d-74e3-c69e-6688-55cf9f0c8551@oracle.com> <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com> Message-ID: Hi Smita, You have typo (should be supports_vbmi2): src/hotspot/cpu/x86/assembler_x86.cpp:6547:22: error: 'support_vbmi2' is not a member of 'VM_Version' assert(VM_Version::support_vbmi2(), "requires vbmi2"); ^~~~~~~~~~~~~ Debug build failed. I am retesting with local fix. Regards, Vladimir K On 12/20/19 2:19 PM, Vladimir Kozlov wrote: > We should have added core-libs to review since you modified BigInteger.java. > > webrev02 looks good to me. Let me test it. > > Thanks, > Vladimir > > On 12/20/19 1:52 PM, Kamath, Smita wrote: >> Hi Vladimir, >> >> Thank you for reviewing the code. I have updated the code as per your recommendations ( please look at the email below). >> Link to the updated webrev: https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev02/ >> >> Regards, >> Smita >> >> -----Original Message----- >> From: Vladimir Kozlov >> Sent: Thursday, December 19, 2019 5:17 PM >> To: Kamath, Smita >> Cc: Viswanathan, Sandhya ; 'hotspot compiler' >> Subject: Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 >> >> We missed AOT and JVMCI (in HS) changes similar for Base64 [1] to record StubRoutines pointers: >> >> StubRoutines::_bigIntegerRightShiftWorker >> StubRoutines::_bigIntegerLeftShiftWorker >> Smita>>>done >> >> In the test add an other @run command with default setting (without -XX:-TieredCompilation -Xbatch). >> Smita>>>done >> >> Thanks, >> Vladimir >> >> [1] http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/ >> >> On 12/18/19 6:33 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> I have made the code changes you suggested (please look at the email below). >>> I have also enabled the intrinsic to run only when VBMI2 feature is available. >>> The intrinsic shows gains of >1.5x above 4k bit BigInteger. >>> >>> Webrev link: >>> https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev01/ >>> >>> Thanks, >>> Smita >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Wednesday, December 11, 2019 10:55 AM >>> To: Kamath, Smita ; 'hotspot compiler' >>> ; Viswanathan, Sandhya >>> >>> Subject: Re: RFR(M):8167065: Add intrinsic support for double >>> precision shifting on x86_64 >>> >>> Hi Kamath, >>> >>> First, general question. What performance you see when VBMI2 instructions are *not* used with your new code vs code >>> generated by C2. >>> What improvement you see when VBMI2 is used. This is to understand if we need only VBMI2 version of intrinsic or not. >>> >>> Second. Sandhya recently pushed 8235510 changes to rollback avx512 code for CRC32 due to performance issues. Does you >>> change has any issues on some Intel's CPU too? Should it be excluded on such CPUs? >>> >>> Third. I would suggest to wait after we fork JDK 14 with this changes. I think it may be too late for 14 because we >>> would need test this including performance testing. >>> >>> In assembler_x86.cpp use supports_vbmi2() instead of UseVBMI2 in assert. >>> For that to work in vm_version_x86.cpp#l687 clear CPU_VBMI2 bit when UseAVX < 3 ( < avx512). You can also use >>> supports_vbmi2() instead of (UseAVX > 2 && UseVBMI2) in stubGenerator_x86_64.cpp combinations with that. >>> Smita >>>done >>> >>> I don't think we need separate flag UseVBMI2 - it could be controlled by UseAVX flag. We don't have flag for VNNI or >>> other avx512 instructions subset. >>> Smita >> removed UseVBMI2 flag >>> >>> In vm_version_x86.cpp you need to add more %s in print statement for new output. >>> Smita? >>> done >>> >>> You need to add @requires vm.compiler2.enabled to new test's commands to run it only with C2. >>> Smita >>> done >>> >>> You need to add intrinsics to Graal's test to ignore them: >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/d188996ea355/src/jdk.internal. >>> vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/gr >>> aalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#l416 >>> Smita >>>done >>> >>> Thanks, >>> Vladimir >>> >>> On 12/10/19 5:41 PM, Kamath, Smita wrote: >>>> Hi, >>>> >>>> >>>> As per Intel Architecture Instruction Set Reference [1] VBMI2 Operations will be supported in future Intel ISA. I >>>> would like to contribute optimizations for BigInteger shift operations using AVX512+VBMI2 instructions. This >>>> optimization is for x86_64 architecture enabled. >>>> >>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8167065 >>>> >>>> Link to webrev : >>>> http://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev00/ >>>> >>>> >>>> >>>> I ran jtreg test suite with the algorithm on Intel SDE [2] to confirm that encoding and semantics are correctly >>>> implemented. >>>> >>>> >>>> [1] >>>> https://software.intel.com/sites/default/files/managed/39/c5/325462-s >>>> d m-vol-1-2abcd-3abcd.pdf (vpshrdv -> Vol. 2C 5-477 and vpshldv -> >>>> Vol. >>>> 2C 5-471) >>>> >>>> [2] >>>> https://software.intel.com/en-us/articles/intel-software-development- >>>> e >>>> mulator >>>> >>>> >>>> Regards, >>>> >>>> Smita Kamath >>>> From vladimir.kozlov at oracle.com Sat Dec 21 05:12:15 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Dec 2019 21:12:15 -0800 Subject: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 In-Reply-To: References: <6563F381B547594081EF9DE181D07912B2D6B7A7@fmsmsx123.amr.corp.intel.com> <70b5bff1-a2ad-6fea-24ee-f0748e2ccae6@oracle.com> <3914890d-74e3-c69e-6688-55cf9f0c8551@oracle.com> <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com> Message-ID: Testing results are good after fixing the typo. We should consider implementing this intrinsic in Graal too. We have to upload AOT and Graal test changes anyway. Thanks, Vladimir On 12/20/19 3:47 PM, Vladimir Kozlov wrote: > Hi Smita, > > You have typo (should be supports_vbmi2): > > src/hotspot/cpu/x86/assembler_x86.cpp:6547:22: error: 'support_vbmi2' is not a member of 'VM_Version' > ??? assert(VM_Version::support_vbmi2(), "requires vbmi2"); > ?????????????????????? ^~~~~~~~~~~~~ > > Debug build failed. I am retesting with local fix. > > Regards, > Vladimir K > > On 12/20/19 2:19 PM, Vladimir Kozlov wrote: >> We should have added core-libs to review since you modified BigInteger.java. >> >> webrev02 looks good to me. Let me test it. >> >> Thanks, >> Vladimir >> >> On 12/20/19 1:52 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> Thank you for reviewing the code. I have updated the code as per your recommendations ( please look at the email below). >>> Link to the updated webrev: https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev02/ >>> >>> Regards, >>> Smita >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Thursday, December 19, 2019 5:17 PM >>> To: Kamath, Smita >>> Cc: Viswanathan, Sandhya ; 'hotspot compiler' >>> Subject: Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 >>> >>> We missed AOT and JVMCI (in HS) changes similar for Base64 [1] to record StubRoutines pointers: >>> >>> StubRoutines::_bigIntegerRightShiftWorker >>> StubRoutines::_bigIntegerLeftShiftWorker >>> Smita>>>done >>> >>> In the test add an other @run command with default setting (without -XX:-TieredCompilation -Xbatch). >>> Smita>>>done >>> >>> Thanks, >>> Vladimir >>> >>> [1] http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/ >>> >>> On 12/18/19 6:33 PM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> I have made the code changes you suggested (please look at the email below). >>>> I have also enabled the intrinsic to run only when VBMI2 feature is available. >>>> The intrinsic shows gains of >1.5x above 4k bit BigInteger. >>>> >>>> Webrev link: >>>> https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev01/ >>>> >>>> Thanks, >>>> Smita >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov >>>> Sent: Wednesday, December 11, 2019 10:55 AM >>>> To: Kamath, Smita ; 'hotspot compiler' >>>> ; Viswanathan, Sandhya >>>> >>>> Subject: Re: RFR(M):8167065: Add intrinsic support for double >>>> precision shifting on x86_64 >>>> >>>> Hi Kamath, >>>> >>>> First, general question. What performance you see when VBMI2 instructions are *not* used with your new code vs code >>>> generated by C2. >>>> What improvement you see when VBMI2 is used. This is to understand if we need only VBMI2 version of intrinsic or not. >>>> >>>> Second. Sandhya recently pushed 8235510 changes to rollback avx512 code for CRC32 due to performance issues. Does >>>> you change has any issues on some Intel's CPU too? Should it be excluded on such CPUs? >>>> >>>> Third. I would suggest to wait after we fork JDK 14 with this changes. I think it may be too late for 14 because we >>>> would need test this including performance testing. >>>> >>>> In assembler_x86.cpp use supports_vbmi2() instead of UseVBMI2 in assert. >>>> For that to work in vm_version_x86.cpp#l687 clear CPU_VBMI2 bit when UseAVX < 3 ( < avx512). You can also use >>>> supports_vbmi2() instead of (UseAVX > 2 && UseVBMI2) in stubGenerator_x86_64.cpp combinations with that. >>>> Smita >>>done >>>> >>>> I don't think we need separate flag UseVBMI2 - it could be controlled by UseAVX flag. We don't have flag for VNNI or >>>> other avx512 instructions subset. >>>> Smita >> removed UseVBMI2 flag >>>> >>>> In vm_version_x86.cpp you need to add more %s in print statement for new output. >>>> Smita? >>> done >>>> >>>> You need to add @requires vm.compiler2.enabled to new test's commands to run it only with C2. >>>> Smita >>> done >>>> >>>> You need to add intrinsics to Graal's test to ignore them: >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/d188996ea355/src/jdk.internal. >>>> vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/gr >>>> aalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#l416 >>>> Smita >>>done >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/10/19 5:41 PM, Kamath, Smita wrote: >>>>> Hi, >>>>> >>>>> >>>>> As per Intel Architecture Instruction Set Reference [1] VBMI2 Operations will be supported in future Intel ISA. I >>>>> would like to contribute optimizations for BigInteger shift operations using AVX512+VBMI2 instructions. This >>>>> optimization is for x86_64 architecture enabled. >>>>> >>>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8167065 >>>>> >>>>> Link to webrev : >>>>> http://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev00/ >>>>> >>>>> >>>>> >>>>> I ran jtreg test suite with the algorithm on Intel SDE [2] to confirm that encoding and semantics are correctly >>>>> implemented. >>>>> >>>>> >>>>> [1] >>>>> https://software.intel.com/sites/default/files/managed/39/c5/325462-s >>>>> d m-vol-1-2abcd-3abcd.pdf (vpshrdv -> Vol. 2C 5-477 and vpshldv -> >>>>> Vol. >>>>> 2C 5-471) >>>>> >>>>> [2] >>>>> https://software.intel.com/en-us/articles/intel-software-development- >>>>> e >>>>> mulator >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Smita Kamath >>>>> From jai.forums2013 at gmail.com Sat Dec 21 05:22:03 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 21 Dec 2019 10:52:03 +0530 Subject: RFR 8235361 : JAR Class-Path no longer accepts relative URLs encoding absolute Windows paths (e.g "/C:/...") In-Reply-To: <7dcdfa6e-2a99-55ca-6d54-3d0987104242@oracle.com> References: <7067cf9e-ce40-f647-b889-97017359d216@oracle.com> <7dcdfa6e-2a99-55ca-6d54-3d0987104242@oracle.com> Message-ID: <2a3b5912-9a5f-2930-358d-f98e44940f9e@gmail.com> Thank you all for the real quick fix for these 2 issues. In the context of Quarkus project, trying to get a decent workaround to get past these issues across all prominent Java versions (and OS) was starting to get a bit out of hand. But with this fixed consistently within in the JDK now, it's much more comforting that the workarounds that we have put in place in Quarkus won't need to last too long. -Jaikiran On 10/12/19 1:47 AM, Jonathan Gibbons wrote: > I note that javac now uses the same definition of tryResolveFile in > its handling of Class-Path manifest entries, and so the behavior for > the compiler and runtime should now be aligned. > > -- Jon > > > On 12/09/2019 12:10 PM, Brent Christian wrote: >> Hi, >> >> As discussed[1] last month on this alias, JAR Class-Path entries[2] >> that encode an absolute Windows path (including a drive letter, so >> e.g. "/C:/path/to/file.jar") are ignored as of 8211941. >> >> Such entries are legal relative URLs, and should not be ignored. >> Please review my fix to correct this. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8235361 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8235361/webrev06-open/ >> >> Thanks, >> -Brent >> >> 1. >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063491.html >> >> 2. >> https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute >> > From Sergey.Bylokhov at oracle.com Sun Dec 22 20:24:09 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 22 Dec 2019 23:24:09 +0300 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 Message-ID: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> Hello. Please review the fix for JDK 15. Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 I have updated the source code copyrights by the "update_copyright_year.sh" script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 because of: "JDK-8187443: Forest Consolidation: Move files to unified layout" which touched all files. -- Best regards, Sergey. From david.holmes at oracle.com Sun Dec 22 22:18:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Dec 2019 08:18:02 +1000 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> Message-ID: <541ce510-9eb7-d91d-154e-861126fd24c2@oracle.com> Hi Sergey, I've looked at the hotspot files. Changes seem okay, though for the files with dual-copyrights it isn't clear whether the Oracle copyright or other copyright should be updated for any given change. But it seems to me that if anyone wants their specific copyright updated then it is up to them to make that change at the time. Thanks for doing this tedious work. David On 23/12/2019 6:24 am, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 15. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 > Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch > Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 > > I have updated the source code copyrights by the "update_copyright_year.sh" > script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 > because of: "JDK-8187443: Forest Consolidation: Move files to unified > layout" > which touched all files. > > From weijun.wang at oracle.com Mon Dec 23 01:47:07 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 23 Dec 2019 09:47:07 +0800 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> Message-ID: <73BB85F1-9B0A-46DB-BA9B-AA3FC84977C7@oracle.com> I noticed a problem of myself but do not know if update_copyright_year.sh can deal with it more correctly. For example, --- old/src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/Aes128CtsHmacSha2EType.java 2019-12-22 19:00:54.000000000 +0300 +++ new/src/java.security.jgss/share/classes/sun/security/krb5/internal/crypto/Aes128CtsHmacSha2EType.java 2019-12-22 19:00:53.000000000 +0300 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it Here, I prepared the change in 2017 and pushed it on 2018-01-22 and forgot to update the year and the file hasn't been updated since it's first version. So precisely "Copyright (c) 2018" should be the most correct. Thanks, Max > On Dec 23, 2019, at 4:24 AM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 15. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 > Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch > Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 > > I have updated the source code copyrights by the "update_copyright_year.sh" > script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 > because of: "JDK-8187443: Forest Consolidation: Move files to unified layout" > which touched all files. > > > -- > Best regards, Sergey. From aph at redhat.com Mon Dec 23 09:39:44 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Dec 2019 10:39:44 +0100 Subject: RFR 8234362: k_standard.c is not needed and should be removed (was: Re: _IEEE_LIBM targets and __kernel_standard) In-Reply-To: <871ru429ll.fsf@oldenburg2.str.redhat.com> References: <87y2wmv3a2.fsf@oldenburg2.str.redhat.com> <871ru429ll.fsf@oldenburg2.str.redhat.com> Message-ID: <3375b63c-e8aa-ea5d-c139-408b562c86bb@redhat.com> On 11/18/19 9:49 PM, Florian Weimer wrote: > I think the file should just be removed. > > Bug: > Webrev: > > As usual, I'll need a sponsor for this. This is OK. How many patches have you done now? maybe it's time to give you commit access. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andy.herrick at oracle.com Mon Dec 23 13:14:09 2019 From: andy.herrick at oracle.com (Andy Herrick) Date: Mon, 23 Dec 2019 08:14:09 -0500 Subject: RFR: JDK-8236132: Add missing properties to msi installers In-Reply-To: References: Message-ID: <6afeee78-9c47-950d-4911-80f56aa414e5@oracle.com> looks good /Andy On 12/20/2019 3:16 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Add properties to msi installers to properly display installation > location and icon of the application in the list of installed > applications. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8236132 > > [2] http://cr.openjdk.java.net/~asemenyuk/8236132/webrev.00 From peter.levart at gmail.com Mon Dec 23 16:01:05 2019 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 23 Dec 2019 17:01:05 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> Message-ID: <84d13cbc-82ba-13ed-8580-78f528abbe33@gmail.com> Hi, On 12/2/19 6:13 PM, Bob Vandette wrote: >>> 2) >>> How should we deal with "not supported" for booleans/arrays, etc.? >>> Would it make sense to return record objects from the Metrics API so >>> that this could be dealt with? E.g. >>> >>> Metrics m = ... >>> MetricResult result = m.getCpuSetCpus(); >>> switch(result.getType()) { >>> case NOT_SUPPORTED: /* do something */; break; >>> case SUPPORTED: int[] val = result.get(); break; >>> ... >>> } >>> >>> I'm bringing this up, because the proposed patch doesn't deal with the >>> above open questions as of yet. With that being said, it's mostly >>> identical to the proposed hotspot changes in [1]. > For issue 2 ? > > I wonder if we should change the API to throw UnsupportedOperationException for those methods > that are not available. This exception is used quite a lot in the java/nio and java/net packages > for dealing with functionality not available on a host platform. OTOH, The ProcessHandle API took a different approach, returning Optional when in some situations, the requested information about a process is not known. Being either inaccessible or not supported. There's a javadoc of Processhandle.Info type: ??? /** ???? * Information snapshot about the process. ???? * The attributes of a process vary by operating system and are not available ???? * in all implementations.? Information about processes is limited ???? * by the operating system privileges of the process making the request. ???? * The return types are {@code Optional} allowing explicit tests ???? * and actions if the value is available. ???? * @since 9 ???? */ But if you already have the API cast in stone, changing it to return Optional(s) might not be backwards compatible. But so is changing the behavior to throw UnsupportedOperationException from methods that didn't already throw it. Regards, Peter From philip.race at oracle.com Mon Dec 23 18:15:20 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 23 Dec 2019 10:15:20 -0800 Subject: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS In-Reply-To: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> References: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> Message-ID: <57e519a8-a4a1-02f4-d06e-674a10fe9cdd@oracle.com> I am not sure what the right mailing list(s) are for this change. It definitely isn't a core-libs change. I think build-dev may be better. I am also unclear when this failure handler is invoked and how all this machinery works. It is only useful for headful tests and so I'd only want it enabled in such a case. And we disable the failure handlers in the headful test jobs anyway because they seem focused on taking pointless core dumps ... So we need something that can be used with headful tests only and doesn't involve re-enabling the other handlers. Also why exclude Windows ? No easy way to get the screenshot ? -phil. On 12/11/19 1:00 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 > Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 > > This change adds the "screen capture on the test failure" feature on > macOS and Linux. > ?- On Linux, it is implemented by the "gnome-screenshot" command(in > case of > ?? multiscreen+xinerama??? the whole big screen will be saved to the > "screen.png" file). > ?- On macOS it is implemented by the "screencapture" command, note > that I have > ?? used 1 file per screen, if the number of screens less than 5, other > files will be ignored. > From smita.kamath at intel.com Mon Dec 23 18:25:48 2019 From: smita.kamath at intel.com (Kamath, Smita) Date: Mon, 23 Dec 2019 18:25:48 +0000 Subject: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 In-Reply-To: References: <6563F381B547594081EF9DE181D07912B2D6B7A7@fmsmsx123.amr.corp.intel.com> <70b5bff1-a2ad-6fea-24ee-f0748e2ccae6@oracle.com> <3914890d-74e3-c69e-6688-55cf9f0c8551@oracle.com> <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com> Message-ID: Hi Vladimir, Thanks for reviewing the code. Can you please sponsor and push the changes? Regards, Smita -----Original Message----- From: Vladimir Kozlov Sent: Friday, December 20, 2019 9:12 PM To: Kamath, Smita Cc: 'hotspot compiler' ; core-libs-dev at openjdk.java.net Subject: Re: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 Testing results are good after fixing the typo. We should consider implementing this intrinsic in Graal too. We have to upload AOT and Graal test changes anyway. Thanks, Vladimir On 12/20/19 3:47 PM, Vladimir Kozlov wrote: > Hi Smita, > > You have typo (should be supports_vbmi2): > > src/hotspot/cpu/x86/assembler_x86.cpp:6547:22: error: 'support_vbmi2' is not a member of 'VM_Version' > ??? assert(VM_Version::support_vbmi2(), "requires vbmi2"); > ?????????????????????? ^~~~~~~~~~~~~ > > Debug build failed. I am retesting with local fix. > > Regards, > Vladimir K > > On 12/20/19 2:19 PM, Vladimir Kozlov wrote: >> We should have added core-libs to review since you modified BigInteger.java. >> >> webrev02 looks good to me. Let me test it. >> >> Thanks, >> Vladimir >> >> On 12/20/19 1:52 PM, Kamath, Smita wrote: >>> Hi Vladimir, >>> >>> Thank you for reviewing the code. I have updated the code as per your recommendations ( please look at the email below). >>> Link to the updated webrev: >>> https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev02/ >>> >>> Regards, >>> Smita >>> >>> -----Original Message----- >>> From: Vladimir Kozlov >>> Sent: Thursday, December 19, 2019 5:17 PM >>> To: Kamath, Smita >>> Cc: Viswanathan, Sandhya ; 'hotspot >>> compiler' >>> Subject: Re: RFR(M):8167065: Add intrinsic support for double >>> precision shifting on x86_64 >>> >>> We missed AOT and JVMCI (in HS) changes similar for Base64 [1] to record StubRoutines pointers: >>> >>> StubRoutines::_bigIntegerRightShiftWorker >>> StubRoutines::_bigIntegerLeftShiftWorker >>> Smita>>>done >>> >>> In the test add an other @run command with default setting (without -XX:-TieredCompilation -Xbatch). >>> Smita>>>done >>> >>> Thanks, >>> Vladimir >>> >>> [1] http://cr.openjdk.java.net/~srukmannagar/Base64/webrev.01/ >>> >>> On 12/18/19 6:33 PM, Kamath, Smita wrote: >>>> Hi Vladimir, >>>> >>>> I have made the code changes you suggested (please look at the email below). >>>> I have also enabled the intrinsic to run only when VBMI2 feature is available. >>>> The intrinsic shows gains of >1.5x above 4k bit BigInteger. >>>> >>>> Webrev link: >>>> https://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev01/ >>>> >>>> Thanks, >>>> Smita >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov >>>> Sent: Wednesday, December 11, 2019 10:55 AM >>>> To: Kamath, Smita ; 'hotspot compiler' >>>> ; Viswanathan, Sandhya >>>> >>>> Subject: Re: RFR(M):8167065: Add intrinsic support for double >>>> precision shifting on x86_64 >>>> >>>> Hi Kamath, >>>> >>>> First, general question. What performance you see when VBMI2 >>>> instructions are *not* used with your new code vs code generated by C2. >>>> What improvement you see when VBMI2 is used. This is to understand if we need only VBMI2 version of intrinsic or not. >>>> >>>> Second. Sandhya recently pushed 8235510 changes to rollback avx512 >>>> code for CRC32 due to performance issues. Does you change has any issues on some Intel's CPU too? Should it be excluded on such CPUs? >>>> >>>> Third. I would suggest to wait after we fork JDK 14 with this >>>> changes. I think it may be too late for 14 because we would need test this including performance testing. >>>> >>>> In assembler_x86.cpp use supports_vbmi2() instead of UseVBMI2 in assert. >>>> For that to work in vm_version_x86.cpp#l687 clear CPU_VBMI2 bit >>>> when UseAVX < 3 ( < avx512). You can also use >>>> supports_vbmi2() instead of (UseAVX > 2 && UseVBMI2) in stubGenerator_x86_64.cpp combinations with that. >>>> Smita >>>done >>>> >>>> I don't think we need separate flag UseVBMI2 - it could be >>>> controlled by UseAVX flag. We don't have flag for VNNI or other avx512 instructions subset. >>>> Smita >> removed UseVBMI2 flag >>>> >>>> In vm_version_x86.cpp you need to add more %s in print statement for new output. >>>> Smita? >>> done >>>> >>>> You need to add @requires vm.compiler2.enabled to new test's commands to run it only with C2. >>>> Smita >>> done >>>> >>>> You need to add intrinsics to Graal's test to ignore them: >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/d188996ea355/src/jdk.internal. >>>> vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org >>>> /gr >>>> aalvm/compiler/hotspot/test/CheckGraalIntrinsics.java#l416 >>>> Smita >>>done >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/10/19 5:41 PM, Kamath, Smita wrote: >>>>> Hi, >>>>> >>>>> >>>>> As per Intel Architecture Instruction Set Reference [1] VBMI2 >>>>> Operations will be supported in future Intel ISA. I would like to >>>>> contribute optimizations for BigInteger shift operations using AVX512+VBMI2 instructions. This optimization is for x86_64 architecture enabled. >>>>> >>>>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8167065 >>>>> >>>>> Link to webrev : >>>>> http://cr.openjdk.java.net/~svkamath/bigIntegerShift/webrev00/ >>>>> >>>>> >>>>> >>>>> I ran jtreg test suite with the algorithm on Intel SDE [2] to >>>>> confirm that encoding and semantics are correctly implemented. >>>>> >>>>> >>>>> [1] >>>>> https://software.intel.com/sites/default/files/managed/39/c5/32546 >>>>> 2-s d m-vol-1-2abcd-3abcd.pdf (vpshrdv -> Vol. 2C 5-477 and >>>>> vpshldv -> Vol. >>>>> 2C 5-471) >>>>> >>>>> [2] >>>>> https://software.intel.com/en-us/articles/intel-software-developme >>>>> nt- >>>>> e >>>>> mulator >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Smita Kamath >>>>> From igor.ignatyev at oracle.com Mon Dec 23 20:42:15 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 23 Dec 2019 12:42:15 -0800 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: References: Message-ID: ping? > On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >> 31 lines changed: 20 ins; 11 del; 0 mod; > > Hi all, > > could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. > > from JBS: >> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. > > > testing: tier1-5 > JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 > webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ > > Thanks, > -- Igor From david.holmes at oracle.com Mon Dec 23 21:33:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Dec 2019 07:33:16 +1000 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: References: Message-ID: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> Hi Igor, Hotspot changes seem fine. Can't comment on jdk tests. Thanks, David On 24/12/2019 6:42 am, Igor Ignatyev wrote: > ping? > >> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>> 31 lines changed: 20 ins; 11 del; 0 mod; >> >> Hi all, >> >> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >> >> from JBS: >>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >> >> >> testing: tier1-5 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >> >> Thanks, >> -- Igor > From akashche at redhat.com Mon Dec 23 23:52:22 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 23 Dec 2019 23:52:22 +0000 Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h Message-ID: Hi, Please review this minor change to jpackage, that is required for successful compilation with VS2013 toolchain: Bug: https://bugs.openjdk.java.net/browse/JDK-8236125 Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/ Some details on this problem: https://stackoverflow.com/a/24302290/314015 -- -Alex From huizhe.wang at oracle.com Tue Dec 24 01:20:41 2019 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 23 Dec 2019 17:20:41 -0800 Subject: [15] RFR: 8227313: Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols In-Reply-To: References: Message-ID: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com> Hi Naoto, Is there a need for an APINote to note the relationship between the new get/setMonetaryGroupingSeparator and get/setGroupingSeparator methods. The new method did state it "May be different from {@code grouping separator} in some locales", but that may be insufficient. For example, does setting one method affects the other (seems it should since the monetaryGroupingSeparator may be initialized by the groupingSeparator as the impl shows)? If yes, how it's affected? If no, is there a compatibility concern? In the current impl, the new get method is used when "isCurrencyFormat" is true while the new set method doesn't affect the existing 'groupingSeparator'. For existing applications that have a custom grouping separator set through setGroupingSeparator, it seems to me the custom separator won't be used moving onto the new JDK impl. A minor comment about the definition statement in the following: ??? Add the following new serializable field in|java.text.DecimalFormatSymbols|class: |/** * The grouping separator used when formatting currency values. * * @serial * @since 15 */ private char monetaryGroupingSeparator;| and that for the new get method: ??????? Gets the character used for thousands separator for currencies. While the meanings are clear, they were not as consistent as that between the existing groupingSeparator and its get method, that is: ??????? Character used for thousands separator. ?? and then the get method states: ??????? Gets the character used for thousands separator. But this is minor, your call whether to change it or not. Best,? and have a great Christmas! :-) Joe On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8227313 > > The proposed CSR and changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8235942 > https://cr.openjdk.java.net/~naoto/8227313/webrev.00/ > > The change introduces the new monetary grouping separator in > DecimalFormatSymbols, and it is used if a DecimalFormat instance > designates currency formatting where its pattern includes the currency > symbol (U+00A5). The change makes use of the CLDR data which provides > two distinct grouping separators (one for generic, the other for > currency) in some locales. It also addresses the similar cases for the > decimal separator. > > Naoto From philip.race at oracle.com Tue Dec 24 01:39:50 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 23 Dec 2019 17:39:50 -0800 Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h In-Reply-To: References: Message-ID: <5E016C66.4040502@oracle.com> Have you verified this with VS 2017 ? Not that I can see a problem but I doubt we want to trade breaking 2017 to fix 2013 ... -phil. On 12/23/19, 3:52 PM, Alex Kashchenko wrote: > Hi, > > Please review this minor change to jpackage, that is required for > successful compilation with VS2013 toolchain: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236125 > Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/ > > Some details on this problem: https://stackoverflow.com/a/24302290/314015 > From igor.ignatyev at oracle.com Tue Dec 24 04:13:18 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 23 Dec 2019 20:13:18 -0800 Subject: RFR(S): 8236111 : narrow allowSmartActionArgs disabling In-Reply-To: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> References: <423ea31a-ebf8-4cba-72a4-6fbb934f7789@oracle.com> Message-ID: <0BA46866-3DEA-44BF-B87C-2B59B84196C9@oracle.com> Thanks David. core-libs folks, could you please review jdk part of this patch? Thanks, -- Igor > On Dec 23, 2019, at 1:33 PM, David Holmes wrote: > > Hi Igor, > > Hotspot changes seem fine. Can't comment on jdk tests. > > Thanks, > David > > On 24/12/2019 6:42 am, Igor Ignatyev wrote: >> ping? >>> On Dec 17, 2019, at 11:30 AM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>>> 31 lines changed: 20 ins; 11 del; 0 mod; >>> >>> Hi all, >>> >>> could you please review this small patch which enables allowSmartActionArgs in hotspot and jdk test suites and disables them in a small number of test directories? the patch also removes TEST.properties files which enabled allowSmartActionArgs as they aren't needed anymore. >>> >>> from JBS: >>>> currently, allowSmartActionArgs is disabled for the whole hotspot and jdk test suites and enabled just in few places. this makes it a bit harder for people to use smart action arguments in these test suites as they have to not to forget to enable them. and given in all the other test suites, smart action arguments are enabled, it can be confusing and frustrating. >>> >>> >>> testing: tier1-5 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8236111 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8236111/webrev.00/ >>> >>> Thanks, >>> -- Igor From akashche at redhat.com Tue Dec 24 11:54:38 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 24 Dec 2019 11:54:38 +0000 Subject: RFR: JDK-8236125: Windows (MSVC 2013) build fails in jpackage: Need to include strsafe.h after tchar.h In-Reply-To: <5E016C66.4040502@oracle.com> References: <5E016C66.4040502@oracle.com> Message-ID: On 12/24/2019 01:39 AM, Philip Race wrote: > Have you verified this with VS 2017 ? > Not that I can see a problem but I doubt we want to trade breaking 2017 > to fix 2013 ... Yes, VS 2017 compiles fine with this fix. > > [...] > -- -Alex From Sergey.Bylokhov at oracle.com Tue Dec 24 18:22:15 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Dec 2019 21:22:15 +0300 Subject: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18 In-Reply-To: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com> Message-ID: <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com> Hello. Here is an updated version: Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/ - "jdk.internal.vm.compiler" is removed from the patch. - "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018" On 12/22/19 11:24 pm, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 15. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235975 > Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch > Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02 > > I have updated the source code copyrights by the "update_copyright_year.sh" > script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017 > because of: "JDK-8187443: Forest Consolidation: Move files to unified layout" > which touched all files. > > -- Best regards, Sergey. From philipp.kunz at paratix.ch Thu Dec 26 16:50:13 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 26 Dec 2019 17:50:13 +0100 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes Message-ID: Hi, The specification says, a line break in a manifest can occur beforeor after a Unicode character encoded in UTF-8. > ...> value: SPACE *otherchar newline *continuation> continuation: SPACE *otherchar newline> ...> otherchar: any UTF-8 character except NUL, CR and LF The current implementation breaks manifest lines at 72 bytes regardless ofhow the bytes around the break are part of a sequence of bytes encoding acharacter. Code points may use up to four bytes when encoded in UTF-8.Manifests with line breaks inside of sequences of bytes encoding Unicodecharacters in UTF-8 with more than one bytes not only are invalid UTF-8but also look ugly in text editors.For example, a manifest could look like this: import java.util.jar.Manifest;import java.util.jar.Attributes;import static java.util.jar.Attributes.Name; public class CharacterBrokenDemo1 { public static void main(String[] args) throws Exception{ Manifest mf = new Manifest(); Attributes attrs = mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION, "1.0"); attrs.put(new Name("Some-Key"), "Some languages have decorated characters, " + "for example: espa?ol"); // or "espa\u00D1ol" mf.write(System.out); }} Above code produces a result as follows with some unexpected question markswhere the encoding is invalid: > Manifest-Version: 1.0> Some-Key: Some languages have decorated characters, for example: espa?> ?ol This is of course an example written with actual question marks to get a validtext for this message. The trick here is that "Some-Key" to "example :espa"amounts to exactly one byte less encoded in UTF-8 than would fit on one linewith the 72 byte limit so that the subsequent character encoded with two bytesgets broken inside of the sequence of two bytes for this character across acontinuation line break. When decoding the resulting bytes from UTF-8 as one whole string, the twoquestion marks will not fit together again even if the line break with thecontinuation space is removed. However, Manifest::read removes the continuationline breaks ("\r\n ") before decoding the manifest header value from UTF-8 andhence can reproduce the original value. Characters encoded in UTF-8 can not only span up to four bytes for one codepoint each, there are also combining characters or classes thereof or combiningdiacritical marks or whatever the appropriate term could be, that combine morethan one code point into what is usually experienced and referred to as acharacter. The term character really gets ambiguous at this point. I wouldn't know whatthe specification actually refers to with that term "character". So rather thandiving in too much specification or any sorts of theory, let's look at anotherexample: import java.util.jar.Manifest;import java.util.jar.Attributes;import static java.util.jar.Attributes.Name; public class DemoCharacterBroken2 { public static void main(String[] args) throws Exception{ Manifest mf = new Manifest(); Attributes attrs = mf.getMainAttributes(); attrs.put(Name.MANIFEST_VERSION, "1.0"); attrs.put(new Name("Some-Key"), " ".repeat(53) + "Angstro\u0308m"); mf.write(System.out); }} which produces console output as follows: > Manifest-Version: 1.0> Some- Key: Angstro> ?m (In case this does not display well, the diaeresis is on the m on the last line) When the whole Manifest is decoded from UTF-8 as one big single string andcontinuation line breaks are not removed until after UTF-8 decoding the wholemanifest, the diaeresis (umlaut, two points above, u0308) apparently kind ofjumps onto the following letter m because somehow it cannot be combined withthe preceding space. The UTF-8 decoder (all of my editors I tried, not onlyEclipse and its console view, also less, gedit, cat and terminal) somehowtries to fix that but the diaeresis may not necessarily jump back on the "o"where it originally belonged by removing the continuation line break ("\r\n ")after UTF-8 decoding has taken place, at least that did not work for me. Hence, ideally combining diacritical marks should better not be separated fromwhatever they combine with when breaking manifest lines onto a continuationline. Such combinations, however, seem to be unlimited in terms of number ofcode points combining into the same "experienced" character. I was able tofind combinations that not only exceed the limit of 72 bytes per line but alsoexceed the line buffer size of 512 bytes in Manifest::read. These may be ratheruncommon but still possible to my own surprise. Next consideration would then be to remove that limit of 512 bytes per manifestline but exceeding it would make such manifests incompatible with previousManifest::read implementations and is not really an immediately availableoption at the moment. As a compromise, those characters including combining diacritical marks whichcombine only so many code points as that their binarily encoded form in UTF-8remains within a limit of 71 bytes can be written without an interruptingcontinuation line break, which applies to most cases, but not all. I guess thisshould suit practically and realistically to be expected values well. Another possibility would be to allow for characters that are combinations ofmultiple Unicode code points to be kept together in their encoded form in UTF-8up to 512 bytes line length limit when reading minus a space and a line breakamounting to 509 bytes, but that would still not make manifests be representedas valid Unicode in all corner cases and I guess would not probably make a realimprovement in practice over a limit of 71 bytes. Attached is a patch that tries to implement what was described above using aBreakIterator. While it works from a functional point of view, this might beless desirable performance-wise. Alternatively could be considered to do withoutthe BreakIterator and only keep Unicode code points together by not placingline breaks before a continuation byte, which however would not addresscombining diacritical marks as in the second example above. The jar file specification does not explicitly state that manifest should bevalid UTF-8, and they were not always, but it also does not state otherwise,leaving an impression that manifests could be (mis)taken for UTF-8 encodedstrings, which they also are in many or most cases and which has been confusedmany times. At the moment, the only case where a valid manifest is not also avalid UTF-8 encoded string is when a sequence of bytes encoding the samecharacter happens to be interrupted with a continuation line break. To the bestof my knowledge, all other valid manifests are also valid UTF-8 encoded strings. It would be nice, if manifests could be viewed and manipulated with all Unicodecapable editors and not only be parsed correctly with Manifest::read. Any opinions? Would someone sponsor this patch? Regards,Philipp https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#specificationhttps://bugs.openjdk.java.net/browse/JDK-6202130https://bugs.openjdk.java.net/browse/JDK-6443578https://github.com/gradle/gradle/issues/5225https://bugs.openjdk.java.net/browse/JDK-8202525https://en.wikipedia.org/wiki/Combining_character -------------- next part -------------- A non-text attachment was scrubbed... Name: 6202130-manifestutf8linebreak.patch Type: text/x-patch Size: 47155 bytes Desc: not available URL: From philipp.kunz at paratix.ch Thu Dec 26 17:06:19 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 26 Dec 2019 18:06:19 +0100 Subject: Note about Manifest Header Names starting with "From" Message-ID: <05762d129dc795beb21d44d5e13dfc1c1cd60c3d.camel@paratix.ch> Hi, The Jar File Specification [1] states that, > Note: To prevent mangling of files sent via straight e-mail, > no header will start with the four letters "From". But I can't see that this is actually the case. After nobody has fixed this point inside of many years I tend to assume that it is not at all necessary or useful. However, I cannot understand the intention behind it or how that statement got there in the first place and hence might not be aware of the full context. Instead I'd rather like to propose to update the specification by removing the quoted statement. I'm not sure if the specification [1] has changed since 13 or where the most up to date one is. Regards, Philipp [1] https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#specification From weijun.wang at oracle.com Fri Dec 27 09:40:19 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 27 Dec 2019 17:40:19 +0800 Subject: Note about Manifest Header Names starting with "From" In-Reply-To: <05762d129dc795beb21d44d5e13dfc1c1cd60c3d.camel@paratix.ch> References: <05762d129dc795beb21d44d5e13dfc1c1cd60c3d.camel@paratix.ch> Message-ID: <72FF839B-ACDD-458A-A019-24874DAC1686@oracle.com> > On Dec 27, 2019, at 1:06 AM, Philipp Kunz wrote: > > Hi, > > The Jar File Specification [1] states that, > >> Note: To prevent mangling of files sent via straight e-mail, >> no header will start with the four letters "From". > > But I can't see that this is actually the case. > > After nobody has fixed this point inside of many years I tend to assume > that it is not at all necessary or useful. However, I cannot understand > the intention behind it or how that statement got there in the first > place and hence might not be aware of the full context. Maybe if such a manifest is used inside a email and stored in a mbox file, some email agent might mistaken it as the start of a message. > > Instead I'd rather like to propose to update the specification by > removing the quoted statement. I'm OK with this. > > I'm not sure if the specification [1] has changed since 13 or where the > most up to date one is. The latest spec can be found at https://download.java.net/java/early_access/jdk15/docs/specs/jar/jar.html The spec is now built as a part of the JDK (along with api, but not tech guide). Thanks, Max > > Regards, > Philipp > > > [1] > https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#specification > From raffaello.giulietti at gmail.com Fri Dec 27 10:43:27 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 27 Dec 2019 11:43:27 +0100 Subject: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results Message-ID: The latest patches of [1] have been submitted more than 8 months ago [2]. I'm still looking for motivated reviewers. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8202555 [2] http://cr.openjdk.java.net/~bpb/4511638/webrev.03/ From aph at redhat.com Fri Dec 27 21:16:41 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Dec 2019 22:16:41 +0100 Subject: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: <91b6081d-c0b6-8afd-2b4a-cd52e8373bca@redhat.com> On 12/27/19 11:43 AM, Raffaello Giulietti wrote: > The latest patches of [1] have been submitted more than 8 months ago [2]. > I'm still looking for motivated reviewers. I am sorely aware that we have not performed well. All I can say in our defence is that we have looked at it, and a thorough review is hard, and there is significant risk touching this code. I know that Andrew Dinn would love to review it but he keeps getting dragged away to do other work. We have not forgotten you. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From raffaello.giulietti at gmail.com Fri Dec 27 22:25:07 2019 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 27 Dec 2019 23:25:07 +0100 Subject: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results In-Reply-To: <91b6081d-c0b6-8afd-2b4a-cd52e8373bca@redhat.com> References: <91b6081d-c0b6-8afd-2b4a-cd52e8373bca@redhat.com> Message-ID: On 2019-12-27 22:16, Andrew Haley wrote: > On 12/27/19 11:43 AM, Raffaello Giulietti wrote: >> The latest patches of [1] have been submitted more than 8 months ago [2]. >> I'm still looking for motivated reviewers. > > I am sorely aware that we have not performed well. All I can say in our > defence is that we have looked at it, and a thorough review is hard, > and there is significant risk touching this code. I know that Andrew > Dinn would love to review it but he keeps getting dragged away to do > other work. We have not forgotten you. > Hi Andrew & Andrew thanks for your kind reply. I'm aware that a review is harder than usual because of the size of the writing [1]. Of course, I can justify and explain every single line of the code if so requested. Most of it is based on details in the writing and is often a mere translation in Java. To my knowledge, the algorithm is quite novel, so I cannot simply refer to existing, well-established and well-known work (except for some limited aspects on Adams' Ryu work [2], which are pretty coincidental). Brain Burkhalter (Oracle) read the writing until section 8 included and stopped with section 9 which discusses the efficient implementation. I don't know if he read further in the meantime. Except in answering specific questions about my contribution, I guess I can do very little to help those interested in finding the time to dive into the details. My estimate is that it takes between 0.5 and 1 day to understand the paper and less than a couple of hours to check that the code is a direct translation in Java. As usual, YMMV. Greetings Raffaello ---- [1] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058 [2] Adams, "Ryu: Fast Float-to-String Conversion", PLDI, 2018 From Alan.Bateman at oracle.com Sat Dec 28 08:22:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 28 Dec 2019 08:22:05 +0000 Subject: RFR(M):8167065: Add intrinsic support for double precision shifting on x86_64 In-Reply-To: <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com> References: <6563F381B547594081EF9DE181D07912B2D6B7A7@fmsmsx123.amr.corp.intel.com> <70b5bff1-a2ad-6fea-24ee-f0748e2ccae6@oracle.com> <3914890d-74e3-c69e-6688-55cf9f0c8551@oracle.com> <8919a5ce-727a-fb25-e739-4c14da108a7a@oracle.com> Message-ID: On 20/12/2019 22:19, Vladimir Kozlov wrote: > We should have added core-libs to review since you modified > BigInteger.java. > This adds Objects.checkFromToIndex checks in the middle of several supporting methods. Is IOOBE really possible in these cases or are these stand in for always-on asserts to ensure the instrinic is never used when the preconditions aren't satisfied? -Alan From leventov.ru at gmail.com Sat Dec 28 09:50:10 2019 From: leventov.ru at gmail.com (Roman Leventov) Date: Sat, 28 Dec 2019 12:50:10 +0300 Subject: Note bulk methods in Javadocs for Collections.synchronizedXxx() Message-ID: I think Javadocs for Collections.synchronizedXxx() should mention not only "traversing it via Iterator, Spliterator or Stream" as something that must be synchronized externally, but also cases when a synchronized collection is an argument to a bulk collection method, including: - new ArrayList(syncList), new HashSet(syncSet), etc. - List.copyOf(syncList) - otherColl.addAll(syncList), otherColl.removeAll(syncList), otherMap.putAll(syncMap). Though this is logically inferable, this is far from being obvious and apparent. From martinrb at google.com Sat Dec 28 13:23:21 2019 From: martinrb at google.com (Martin Buchholz) Date: Sat, 28 Dec 2019 05:23:21 -0800 Subject: Note bulk methods in Javadocs for Collections.synchronizedXxx() In-Reply-To: References: Message-ID: In general you are right, but ... IIRC I once modified ArrayList(Collection) and Vector(Collection) but not HashSet(Collection) to avoid iterators due to this problem. And Collections.synchronizedXxx cannot know how other software makes use of it. On Sat, Dec 28, 2019 at 1:50 AM Roman Leventov wrote: > I think Javadocs for Collections.synchronizedXxx() should mention not > only "traversing it via Iterator, Spliterator or Stream" as something that > must be synchronized externally, but also cases when a synchronized > collection is an argument to a bulk collection method, including: > - new ArrayList(syncList), new HashSet(syncSet), etc. > - List.copyOf(syncList) > - otherColl.addAll(syncList), otherColl.removeAll(syncList), > otherMap.putAll(syncMap). > > Though this is logically inferable, this is far from being obvious and > apparent. > From pavel.rappo at oracle.com Sat Dec 28 15:23:31 2019 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 28 Dec 2019 15:23:31 +0000 Subject: Note bulk methods in Javadocs for Collections.synchronizedXxx() In-Reply-To: References: Message-ID: If we were to add something like that to the documentation, it would probably go under @apiNote (section "pitfalls", hehe). As you said, the spec says just enough to infer that. So, strictly speaking, there's no need to add that note. After all, there are infinite ways to use these, synchronized, collections incorrectly and only one way to use them right. Maybe we could tackle this (and similar requests in the future) by adding, once and for all, something like: Consider using concurrent collections instead, such as those that can be found in the java.util.concurrent package. -Pavel > On 28 Dec 2019, at 09:50, Roman Leventov wrote: > > I think Javadocs for Collections.synchronizedXxx() should mention not > only "traversing it via Iterator, Spliterator or Stream" as something that > must be synchronized externally, but also cases when a synchronized > collection is an argument to a bulk collection method, including: > - new ArrayList(syncList), new HashSet(syncSet), etc. > - List.copyOf(syncList) > - otherColl.addAll(syncList), otherColl.removeAll(syncList), > otherMap.putAll(syncMap). > > Though this is logically inferable, this is far from being obvious and > apparent. From Sergey.Bylokhov at oracle.com Mon Dec 30 19:33:13 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 30 Dec 2019 22:33:13 +0300 Subject: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS In-Reply-To: <57e519a8-a4a1-02f4-d06e-674a10fe9cdd@oracle.com> References: <931be5f0-085a-37e7-c188-18128d92227d@oracle.com> <57e519a8-a4a1-02f4-d06e-674a10fe9cdd@oracle.com> Message-ID: <4ea1a4a8-9d7a-4b4b-804c-b22c4bc0cbe7@oracle.com> On 12/23/19 9:15 pm, Phil Race wrote: > I am not sure what the right mailing list(s) are for this change. > It definitely isn't a core-libs change. I think build-dev may be better. Previous changes to these configs were discussed here, so I have send it here as well. > > I am also unclear when this failure handler is invoked and how all this machinery works. > > It is only useful for headful tests and so I'd only want it enabled in such a case. > And we disable the failure handlers in the headful test jobs anyway because they seem > focused on taking pointless core dumps ...> > So we need something that can be used with headful tests only and doesn't involve > re-enabling the other handlers. It could be useful for other tests as well and may be able to identify problems such as: - Suggestions "to open under debugger" from the native asserts - Various error dialogs from the OS And it does not spend much resources compared to current handlers. > > Also why exclude Windows ? No easy way to get the screenshot ? There is no command-line program that can take a screenshot on windows by default > > -phil. > > On 12/11/19 1:00 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 14. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233827 >> Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01 >> >> This change adds the "screen capture on the test failure" feature on macOS and Linux. >> ?- On Linux, it is implemented by the "gnome-screenshot" command(in case of >> ?? multiscreen+xinerama??? the whole big screen will be saved to the "screen.png" file). >> ?- On macOS it is implemented by the "screencapture" command, note that I have >> ?? used 1 file per screen, if the number of screens less than 5, other files will be ignored. >> > -- Best regards, Sergey. From hohensee at amazon.com Mon Dec 30 21:57:17 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 30 Dec 2019 21:57:17 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> Message-ID: <02EDE1C7-8C38-4E3C-84CA-C52650BBFC3B@amazon.com> This revision looks fine to me. Thanks, Paul ?On 12/16/19, 7:52 PM, "core-libs-dev on behalf of Verghese, Clive" wrote: Hi Volker, Thank you for the feedback. I have update the revision to reflect your comments. http://cr.openjdk.java.net/~phh/8235699/webrev.01/ Regards, Clive Verghese On 12/13/19, 8:09 AM, "Volker Simonis" wrote: Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fields. But for "real" fields, zero is a valid value which you might want to print. You might however still consider printing the "stamps" (i.e. the lower half) as well, e.g.: sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); Thank you and best regards, Volker On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive wrote: > > Additional information regarding the field array. > > It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. > The original implementation was intending to display the second half of the array. Though the outer loop > iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated > this to display the whole array. > > Regards, > Clive Verghese > > From: "Verghese, Clive" > Date: Thursday, December 12, 2019 at 2:07 PM > To: "core-libs-dev at openjdk.java.net" > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString > > Hi, > > Requesting review for > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. > The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger > reaches this class and uses the toString function to print the class. > > Steps to reproduce this is attached in the JBS issue. > > Regards, > Clive Verghese > > From volker.simonis at gmail.com Mon Dec 30 23:12:10 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 31 Dec 2019 00:12:10 +0100 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> Message-ID: Hi Clive, thanks for updating the patch. Looks good now. Do you need a sponsor for pushing? Best regards, Volker Verghese, Clive schrieb am Di., 17. Dez. 2019, 04:50: > Hi Volker, > > Thank you for the feedback. > > I have update the revision to reflect your comments. > http://cr.openjdk.java.net/~phh/8235699/webrev.01/ > > Regards, > Clive Verghese > > ?On 12/13/19, 8:09 AM, "Volker Simonis" wrote: > > Hi Clive, > > nice catch :) > > I think it would be better though to only iterate up to MAX_FIELD and > print "field[MAX_FIELD + i]", otherwise you may miss to print valid > fields. The reason is that with your current solution "isSet()" will > now be called not only for "stamp" fields, but also for "real" fields. > But for "real" fields, zero is a valid value which you might want to > print. You might however still consider printing the "stamps" (i.e. > the lower half) as well, e.g.: > > sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); > > Thank you and best regards, > Volker > > On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive > wrote: > > > > Additional information regarding the field array. > > > > It is meant to hold two arrays, the lower half holds the stamp. And > the upper half holds the fields. > > The original implementation was intending to display the second half > of the array. Though the outer loop > > iterated through the whole array. Therefore causing an > ArrayIndexOutOfBoundsException. I have updated > > this to display the whole array. > > > > Regards, > > Clive Verghese > > > > From: "Verghese, Clive" > > Date: Thursday, December 12, 2019 at 2:07 PM > > To: "core-libs-dev at openjdk.java.net" > > > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in > CalendarBuilder.toString > > > > Hi, > > > > Requesting review for > > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > > > CalendarBuilder.toString method has a bug which causes an > ArrayIndexOutOfBoundsException exception. > > The class is an internal jdk class that is restricted to java.text > package. The bug is observed when the debugger > > reaches this class and uses the toString function to print the class. > > > > Steps to reproduce this is attached in the JBS issue. > > > > Regards, > > Clive Verghese > > > > > > > From felixxfyang at tencent.com Tue Dec 31 01:18:43 2019 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Tue, 31 Dec 2019 01:18:43 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString(Internet mail) In-Reply-To: <02EDE1C7-8C38-4E3C-84CA-C52650BBFC3B@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <02EDE1C7-8C38-4E3C-84CA-C52650BBFC3B@amazon.com> Message-ID: Hi Volker? Please update last modified date "Copyright (c) 2010, 2014," to "Copyright (c) 2010, 2019," Thanks, Felix ?? 2019/12/31 ??5:59??core-libs-dev ?? Hohensee, Paul? ??: This revision looks fine to me. Thanks, Paul On 12/16/19, 7:52 PM, "core-libs-dev on behalf of Verghese, Clive" wrote: Hi Volker, Thank you for the feedback. I have update the revision to reflect your comments. http://cr.openjdk.java.net/~phh/8235699/webrev.01/ Regards, Clive Verghese On 12/13/19, 8:09 AM, "Volker Simonis" wrote: Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fields. But for "real" fields, zero is a valid value which you might want to print. You might however still consider printing the "stamps" (i.e. the lower half) as well, e.g.: sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); Thank you and best regards, Volker On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive wrote: > > Additional information regarding the field array. > > It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. > The original implementation was intending to display the second half of the array. Though the outer loop > iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated > this to display the whole array. > > Regards, > Clive Verghese > > From: "Verghese, Clive" > Date: Thursday, December 12, 2019 at 2:07 PM > To: "core-libs-dev at openjdk.java.net" > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString > > Hi, > > Requesting review for > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. > The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger > reaches this class and uses the toString function to print the class. > > Steps to reproduce this is attached in the JBS issue. > > Regards, > Clive Verghese > > From felixxfyang at tencent.com Tue Dec 31 02:05:24 2019 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Tue, 31 Dec 2019 02:05:24 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString(Internet mail) In-Reply-To: References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <02EDE1C7-8C38-4E3C-84CA-C52650BBFC3B@amazon.com> Message-ID: <097178D7-E87E-436C-813A-BF8E64BE6644@tencent.com> Excuse me, Should be "Clive" -Felix ?? 2019/12/31 ??9:18??felixxfyang(???)? ??: Hi Volker? Please update last modified date "Copyright (c) 2010, 2014," to "Copyright (c) 2010, 2019," Thanks, Felix ? 2019/12/31 ??5:59??core-libs-dev ?? Hohensee, Paul? ??: This revision looks fine to me. Thanks, Paul On 12/16/19, 7:52 PM, "core-libs-dev on behalf of Verghese, Clive" wrote: Hi Volker, Thank you for the feedback. I have update the revision to reflect your comments. http://cr.openjdk.java.net/~phh/8235699/webrev.01/ Regards, Clive Verghese On 12/13/19, 8:09 AM, "Volker Simonis" wrote: Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fields. But for "real" fields, zero is a valid value which you might want to print. You might however still consider printing the "stamps" (i.e. the lower half) as well, e.g.: sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); Thank you and best regards, Volker On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive wrote: > > Additional information regarding the field array. > > It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. > The original implementation was intending to display the second half of the array. Though the outer loop > iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated > this to display the whole array. > > Regards, > Clive Verghese > > From: "Verghese, Clive" > Date: Thursday, December 12, 2019 at 2:07 PM > To: "core-libs-dev at openjdk.java.net" > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString > > Hi, > > Requesting review for > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. > The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger > reaches this class and uses the toString function to print the class. > > Steps to reproduce this is attached in the JBS issue. > > Regards, > Clive Verghese > > From weijun.wang at oracle.com Tue Dec 31 03:18:50 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 31 Dec 2019 11:18:50 +0800 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> Message-ID: There is neither a test nor a noreg-* label. I would add a regression test even if reflection is needed. Or you can make it noreg-trivial. Thanks, Max > On Dec 17, 2019, at 11:50 AM, Verghese, Clive wrote: > > Hi Volker, > > Thank you for the feedback. > > I have update the revision to reflect your comments. > http://cr.openjdk.java.net/~phh/8235699/webrev.01/ > > Regards, > Clive Verghese > > ?On 12/13/19, 8:09 AM, "Volker Simonis" wrote: > > Hi Clive, > > nice catch :) > > I think it would be better though to only iterate up to MAX_FIELD and > print "field[MAX_FIELD + i]", otherwise you may miss to print valid > fields. The reason is that with your current solution "isSet()" will > now be called not only for "stamp" fields, but also for "real" fields. > But for "real" fields, zero is a valid value which you might want to > print. You might however still consider printing the "stamps" (i.e. > the lower half) as well, e.g.: > > sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); > > Thank you and best regards, > Volker > > On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive wrote: >> >> Additional information regarding the field array. >> >> It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. >> The original implementation was intending to display the second half of the array. Though the outer loop >> iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated >> this to display the whole array. >> >> Regards, >> Clive Verghese >> >> From: "Verghese, Clive" >> Date: Thursday, December 12, 2019 at 2:07 PM >> To: "core-libs-dev at openjdk.java.net" >> Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString >> >> Hi, >> >> Requesting review for >> JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 >> Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ >> >> CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. >> The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger >> reaches this class and uses the toString function to print the class. >> >> Steps to reproduce this is attached in the JBS issue. >> >> Regards, >> Clive Verghese >> >> > > From verghese at amazon.com Tue Dec 31 16:54:33 2019 From: verghese at amazon.com (Verghese, Clive) Date: Tue, 31 Dec 2019 16:54:33 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> Message-ID: <4CFFF316-4161-43B3-85DA-694176842EF9@amazon.com> Hi Volker, Thank you for reviewing the changes and approving. It would be great if you could sponsor the change as well. Regards, Clive Verghese From: Volker Simonis Date: Monday, December 30, 2019 at 3:13 PM To: "Verghese, Clive" Cc: Java Core Libs Subject: Re: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString Hi Clive, thanks for updating the patch. Looks good now. Do you need a sponsor for pushing? Best regards, Volker Verghese, Clive > schrieb am Di., 17. Dez. 2019, 04:50: Hi Volker, Thank you for the feedback. I have update the revision to reflect your comments. http://cr.openjdk.java.net/~phh/8235699/webrev.01/ Regards, Clive Verghese On 12/13/19, 8:09 AM, "Volker Simonis" > wrote: Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fields. But for "real" fields, zero is a valid value which you might want to print. You might however still consider printing the "stamps" (i.e. the lower half) as well, e.g.: sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); Thank you and best regards, Volker On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive > wrote: > > Additional information regarding the field array. > > It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. > The original implementation was intending to display the second half of the array. Though the outer loop > iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated > this to display the whole array. > > Regards, > Clive Verghese > > From: "Verghese, Clive" > > Date: Thursday, December 12, 2019 at 2:07 PM > To: "core-libs-dev at openjdk.java.net" > > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString > > Hi, > > Requesting review for > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. > The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger > reaches this class and uses the toString function to print the class. > > Steps to reproduce this is attached in the JBS issue. > > Regards, > Clive Verghese > > From verghese at amazon.com Tue Dec 31 16:59:40 2019 From: verghese at amazon.com (Verghese, Clive) Date: Tue, 31 Dec 2019 16:59:40 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString(Internet mail) In-Reply-To: <097178D7-E87E-436C-813A-BF8E64BE6644@tencent.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <02EDE1C7-8C38-4E3C-84CA-C52650BBFC3B@amazon.com> <097178D7-E87E-436C-813A-BF8E64BE6644@tencent.com> Message-ID: <64BB8741-6AD1-4A5B-B3A8-FCB23F188E33@amazon.com> Thanks for the feedback, I will update the Copyright date. Regards, Clive Verghese ?On 12/30/19, 6:06 PM, "felixxfyang(???)" wrote: Excuse me, Should be "Clive" -Felix ? 2019/12/31 ??9:18??felixxfyang(???)? ??: Hi Volker? Please update last modified date "Copyright (c) 2010, 2014," to "Copyright (c) 2010, 2019," Thanks, Felix ? 2019/12/31 ??5:59??core-libs-dev ?? Hohensee, Paul? ??: This revision looks fine to me. Thanks, Paul On 12/16/19, 7:52 PM, "core-libs-dev on behalf of Verghese, Clive" wrote: Hi Volker, Thank you for the feedback. I have update the revision to reflect your comments. http://cr.openjdk.java.net/~phh/8235699/webrev.01/ Regards, Clive Verghese On 12/13/19, 8:09 AM, "Volker Simonis" wrote: Hi Clive, nice catch :) I think it would be better though to only iterate up to MAX_FIELD and print "field[MAX_FIELD + i]", otherwise you may miss to print valid fields. The reason is that with your current solution "isSet()" will now be called not only for "stamp" fields, but also for "real" fields. But for "real" fields, zero is a valid value which you might want to print. You might however still consider printing the "stamps" (i.e. the lower half) as well, e.g.: sj.add(i + "=" + field[i] + ":" + field[MAX_FIELD + i]); Thank you and best regards, Volker On Fri, Dec 13, 2019 at 1:05 AM Verghese, Clive wrote: > > Additional information regarding the field array. > > It is meant to hold two arrays, the lower half holds the stamp. And the upper half holds the fields. > The original implementation was intending to display the second half of the array. Though the outer loop > iterated through the whole array. Therefore causing an ArrayIndexOutOfBoundsException. I have updated > this to display the whole array. > > Regards, > Clive Verghese > > From: "Verghese, Clive" > Date: Thursday, December 12, 2019 at 2:07 PM > To: "core-libs-dev at openjdk.java.net" > Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString > > Hi, > > Requesting review for > JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8235699 > Webrev : https://cr.openjdk.java.net/~phh/8235699/webrev.00/ > > CalendarBuilder.toString method has a bug which causes an ArrayIndexOutOfBoundsException exception. > The class is an internal jdk class that is restricted to java.text package. The bug is observed when the debugger > reaches this class and uses the toString function to print the class. > > Steps to reproduce this is attached in the JBS issue. > > Regards, > Clive Verghese > > From Alan.Bateman at oracle.com Tue Dec 31 17:06:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Dec 2019 17:06:46 +0000 Subject: RFR 8235699 : ArrayIndexOutOfBoundsException in CalendarBuilder.toString In-Reply-To: <4CFFF316-4161-43B3-85DA-694176842EF9@amazon.com> References: <21E5B36B-256D-4CC7-A869-B78A8384A1FC@amazon.com> <9823C35D-B89A-4FFC-85B9-BCB81D34151C@amazon.com> <192DC928-C290-4957-84DC-55AB1B785977@amazon.com> <64E6A572-7694-4780-BA35-080ADFA09E5D@amazon.com> <4CFFF316-4161-43B3-85DA-694176842EF9@amazon.com> Message-ID: <6d674d42-32e5-2abc-ef2f-d3dd1fe0c3d8@oracle.com> On 31/12/2019 16:54, Verghese, Clive wrote: > Hi Volker, > > Thank you for reviewing the changes and approving. > Do you know if there is any test coverage for this method? The builder is package-private and I think your original mail said that it was uncovered when invoking the toString from the debugger so I assume not. I think we should at least try to add a test. -Alan