From mikhailo.seledtsov at oracle.com Mon Mar 3 11:06:41 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 03 Mar 2014 14:06:41 -0500 Subject: RFR (XS): JDK-8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) In-Reply-To: <52FBC486.3000500@oracle.com> References: <52F55660.2080000@oracle.com> <52FB95ED.90005@oracle.com> <52FBBEE3.6040405@oracle.com> <52FBC486.3000500@oracle.com> Message-ID: <5314D2C1.7030500@oracle.com> Please review the updated webrev at http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.01/ Thank you, Misha On 2/12/2014 1:59 PM, Coleen Phillimore wrote: > > On 2/12/14 1:35 PM, Mikhailo Seledtsov wrote: >> Hi Coleen, >> >> Thank you for the review. Would it be OK if I print the message that >> comes thru after the message that I introduced? >> >> There is a variety of messages that are passed to fail_continue() >> depending on who calls it; checking/asserting on each message in the >> test would be a large overhead; also some of these messages do not >> convey "attempted, but failed" meaning. > > That seems fine if you want to prefix the message with yours, or > append yours. Whatever makes sense in the context of the message. > > Coleen > >> >> Thank you, >> Misha >> >> On 2/12/2014 10:40 AM, Coleen Phillimore wrote: >>> >>> Misha, >>> There is a message that comes through to fail_continue(). Why don't >>> you use that message? >>> thanks, >>> Coleen >>> >>> On 2/7/14 4:55 PM, Mikhailo Seledtsov wrote: >>>> Please review this small change that improves testability of CDS, >>>> and will aid in fixing several intermittently failing CDS tests. >>>> >>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8033990 >>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.00/ >>>> Testing: >>>> Basic testing: >>>> - ran "Xshare:auto -version", "-XX:+Verbose >>>> -XX:+PrintMiscellaneous -Xshare:auto -version" before and after the >>>> archive was created >>>> - ran "XX:+Verbose -XX:+PrintMiscellaneous -Xshare:auto >>>> -version" on Windows where ASLR occasionally prevents sharing >>>> >>>> JT-Reg: runtime/SharedArchiveFile, with and w/o the >>>> additional options -vmoptions:"-XX:+Verbose -XX:+PrintMiscellaneous" >>>> >>>> Tonga: a sub-set of vm.parallel_class_loading.testlist, >>>> with -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous -showversion" >>>> Tonga (vm.parallel_class_loading.testlist >>>> -vmopts " -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous >>>> -showversion") >>>> - ongoing. Plan not to run full testlist since the >>>> change is small and trivial >>>> >>>> JPRT: standard JPRT: 2014-02-07-210345.mseledtsov.work01 >>>> - ongoing >>>> >>>> Thank you, >>>> Misha >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140303/99e725d5/attachment.html From andreas.eriksson at oracle.com Mon Mar 3 16:12:51 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 04 Mar 2014 01:12:51 +0100 Subject: RFR: JDK-8033696: "assert(thread != NULL) failed: just checking" due to Thread::current() and JNI pthread interaction In-Reply-To: <530F30C1.7070601@oracle.com> References: <52F8FC95.5090608@oracle.com> <530E4B1C.2070201@oracle.com> <530F122F.1090107@oracle.com> <530F23DE.8010008@oracle.com> <530F30C1.7070601@oracle.com> Message-ID: <53151A83.1090106@oracle.com> That output was because the VMThread didn't reset it's TLS before exiting (presumably since the VM is shutting down anyway). This meant that the thread pointer destructor was run until the pthread implementation gave up. I added code that sets the thread pointer to NULL before exiting the VMThread, ensuring the thread pointer destructor is never called for the exiting VMThread. A new updated webrev can be found here: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.01/ I also removed the bug reference from the comments, since I got the feeling that it's usually discouraged. Thanks, Andreas On 2014-02-27 13:34, Andreas Eriksson wrote: > Oh, sorry, I misread your mail. > > I will look into the pthread output from java -version. > > Thread 80103f400 has exited with leftover thread-specific data after 4 > destructor iterations > > Thanks, > Andreas > > On 2014-02-27 12:39, Dmitry Samersoff wrote: >> Andreas, >> >> I's not growing - always only two threads. >> >> -Dmitry >> >> On 2014-02-27 14:23, Andreas Eriksson wrote: >>> Thanks Dmitry. >>> >>> There are no crashes, only an assert that is hit if running with a >>> debug >>> build. >>> Otherwise the active threads keep growing, like you are seeing. >>> >>> It is worrying that they keep growing with the patch as well. >>> I will have to look at it and see what can be done. >>> >>> Regards, >>> Andreas >>> >>> On 2014-02-26 21:14, Dmitry Samersoff wrote: >>>> Andreas, >>>> >>>> With JDK7 I didn't observe any crash with or without your patch. >>>> Without the patch the number of active threads constantly grows, >>>> with patch it remains the same. >>>> >>>> >>>> uname -a >>>> FreeBSD samersoff.net 9.2-RELEASE FreeBSD 9.2-RELEASE #1: Thu Jan 2 >>>> 02:15:13 MSK 2014 dms at minext:/sys/amd64/compile/MIRCAT amd64 >>>> >>>> >>>> With patch: >>>> >>>> #java -version >>>> >>>> openjdk version "1.7.0_45" >>>> OpenJDK Runtime Environment (build 1.7.0_45-b18) >>>> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) >>>> Thread 80103f400 has exited with leftover thread-specific data after 4 >>>> destructor iterations >>>> >>>> #$JAVA_HOME/bin/java -Djava.library.path=$NATIVE com.test.callback.App >>>> >>>> Java callback: native thread: 34376799232, java thread: Thread-391, 2 >>>> active threads >>>> Successfully detached native thread 0x801045400 >>>> Deleting callback >>>> >>>> >>>> Without patch: >>>> >>>> #/opt/openjdk7/bin/java -version >>>> >>>> openjdk version "1.7.0_25" >>>> OpenJDK Runtime Environment (build 1.7.0_25-b15) >>>> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode) >>>> >>>> #/opt/openjdk7/bin/java -Djava.library.path=$NATIVE >>>> com.test.callback.App >>>> >>>> Java callback: native thread: 34376788992, java thread: Thread-402, >>>> 404 >>>> active threads >>>> Successfully detached native thread 0x801042c00 >>>> Deleting callback >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-02-10 20:21, Andreas Eriksson wrote: >>>>> Hi, >>>>> >>>>> Could I please get reviews for this change. >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696 >>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/ >>>>> Mail discussion: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html >>>>> >>>>> >>>>> >>>>> >>>>> Summary: >>>>> JNI code is using pthread_key_create with a destructor to detach the >>>>> thread from the JVM when the thread is exiting. >>>>> For some flavors of Linux and BSD the JVM is also using the >>>>> pthread_key_create, to store the Thread::current() value in a thread >>>>> local storage. >>>>> Since the thread local storage containing the thread pointer is >>>>> erased >>>>> (by pthread) before the JNI destructor runs, we run >>>>> detachCurrentThread >>>>> on a thread that has NULL as current thread. >>>>> This fix uses a destructor for the thread pointer that restores the >>>>> value, so that the JNI destructor can run detachCurrentThread >>>>> successfully. >>>>> More info in JBS. >>>>> >>>>> Testing: >>>>> Native code regtest attached to JBS tested on Linux, but not on Mac >>>>> since I don't have access to one. >>>>> JPRT ran without a problem. >>>>> >>>>> Regards, >>>>> Andreas >> > From coleen.phillimore at oracle.com Mon Mar 3 17:18:31 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 03 Mar 2014 20:18:31 -0500 Subject: RFR (xs) 8036547: test/runtime/CompressedOops/CompressedClassPointers.java fails with product bui,ld Message-ID: <531529E7.8010807@oracle.com> Summary: Use PrintCompressedOopsMode and these other flags that match printing compressed oop information open webrev at http://cr.openjdk.java.net/~coleenp/8036547/ bug link https://bugs.openjdk.java.net/browse/JDK-8036547 Tested with product build this time (and fastdebug). Thanks, Coleen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140303/ea12a7e4/attachment.html From christian.tornqvist at oracle.com Tue Mar 4 03:07:27 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 4 Mar 2014 06:07:27 -0500 Subject: RFR (xs) 8036547: test/runtime/CompressedOops/CompressedClassPointers.java fails with product bui, ld In-Reply-To: <531529E7.8010807@oracle.com> References: <531529E7.8010807@oracle.com> Message-ID: <002401cf3799$edff76e0$c9fe64a0$@oracle.com> Hi Coleen, Looks good, thanks for fixing this. Thanks, Christian From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Monday, March 3, 2014 8:19 PM To: hotspot-runtime-dev Subject: RFR (xs) 8036547: test/runtime/CompressedOops/CompressedClassPointers.java fails with product bui,ld Summary: Use PrintCompressedOopsMode and these other flags that match printing compressed oop information open webrev at http://cr.openjdk.java.net/~coleenp/8036547/ bug link https://bugs.openjdk.java.net/browse/JDK-8036547 Tested with product build this time (and fastdebug). Thanks, Coleen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140304/053a5555/attachment.html From staffan.larsen at oracle.com Tue Mar 4 04:10:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 4 Mar 2014 13:10:09 +0100 Subject: RFR (xs) 8036547: test/runtime/CompressedOops/CompressedClassPointers.java fails with product bui, ld In-Reply-To: <531529E7.8010807@oracle.com> References: <531529E7.8010807@oracle.com> Message-ID: <0CB8FA6A-081C-4D2E-B2D1-E13F8C4CC8D5@oracle.com> Looks good! Thanks, /Staffan On 4 mar 2014, at 02:18, Coleen Phillimore wrote: > Summary: Use PrintCompressedOopsMode and these other flags that match printing compressed oop information > > open webrev at http://cr.openjdk.java.net/~coleenp/8036547/ > bug link https://bugs.openjdk.java.net/browse/JDK-8036547 > > Tested with product build this time (and fastdebug). > > Thanks, > Coleen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140304/e6b41519/attachment.html From coleen.phillimore at oracle.com Tue Mar 4 06:55:00 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 04 Mar 2014 09:55:00 -0500 Subject: RFR (xs) 8036547: test/runtime/CompressedOops/CompressedClassPointers.java fails with product bui,ld In-Reply-To: <0CB8FA6A-081C-4D2E-B2D1-E13F8C4CC8D5@oracle.com> References: <531529E7.8010807@oracle.com> <0CB8FA6A-081C-4D2E-B2D1-E13F8C4CC8D5@oracle.com> Message-ID: <5315E944.8080309@oracle.com> Thanks Staffan and Christian. Coleen On 3/4/14 7:10 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 4 mar 2014, at 02:18, Coleen Phillimore > > > wrote: > >> Summary: Use PrintCompressedOopsMode and these other flags that match >> printing compressed oop information >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8036547/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8036547 >> >> Tested with product build this time (and fastdebug). >> >> Thanks, >> Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140304/d1532d2c/attachment.html From gerald.thornbrugh at oracle.com Tue Mar 4 07:15:25 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 04 Mar 2014 08:15:25 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup Message-ID: <5315EE0D.50809@oracle.com> Hi, I am a member of the Oracle Hotspot group and there is an initiative to clean up things like uninitialized variables and unclosed file descriptors in JDK8. This is a backport of fixes that have already been putback into JDK9. I have run UTE and JPRT tests on Solaris machines without proflems. The below webrev show the fixes for the Solaris area. Bug: https://bugs.openjdk.java.net/browse/JDK-8029776 Webrev: http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ Please review my changes and let me know if you have questions. Thanks, Gerald Thornbrugh From volker.simonis at gmail.com Tue Mar 4 08:36:16 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Mar 2014 17:36:16 +0100 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <5315EE0D.50809@oracle.com> References: <5315EE0D.50809@oracle.com> Message-ID: Hi Gerald, the bug is not visible. Could you please fix this. Thank you and best regards, Volker On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh wrote: > Hi, > > I am a member of the Oracle Hotspot group and there is an initiative to > clean up > things like uninitialized variables and unclosed file descriptors in JDK8. > This is a > backport of fixes that have already been putback into JDK9. I have run UTE > and > JPRT tests on Solaris machines without proflems. The below webrev show the > fixes for > the Solaris area. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8029776 > > Webrev: > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ > > Please review my changes and let me know if you have questions. > > Thanks, > > Gerald Thornbrugh From gerald.thornbrugh at oracle.com Tue Mar 4 08:47:17 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 04 Mar 2014 09:47:17 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: References: <5315EE0D.50809@oracle.com> Message-ID: <53160395.6020702@oracle.com> Hi Volker, Sorry about that, I will look into this and get back to you. Thanks! Jerry > Hi Gerald, > > the bug is not visible. Could you please fix this. > > Thank you and best regards, > Volker > > > On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh > wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative to >> clean up >> things like uninitialized variables and unclosed file descriptors in JDK8. >> This is a >> backport of fixes that have already been putback into JDK9. I have run UTE >> and >> JPRT tests on Solaris machines without proflems. The below webrev show the >> fixes for >> the Solaris area. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8029776 >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh From gerald.thornbrugh at oracle.com Tue Mar 4 09:18:30 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 04 Mar 2014 10:18:30 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: References: <5315EE0D.50809@oracle.com> Message-ID: <53160AE6.6030206@oracle.com> Hi Volker, The bug is not visible because it was inadvertently marked as confidential. Since changing it from confidential to an open state is not a reasonable option I will just state the description of the bug fix. JDK-8029776 describes JDK8 Solaris specific code cleanup to address possible unclosed file descriptors, to make array indexes more readable and make sure functions return values. Does this help? Thanks! Gerald Thornbrugh > Hi Gerald, > > the bug is not visible. Could you please fix this. > > Thank you and best regards, > Volker > > > On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh > wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative to >> clean up >> things like uninitialized variables and unclosed file descriptors in JDK8. >> This is a >> backport of fixes that have already been putback into JDK9. I have run UTE >> and >> JPRT tests on Solaris machines without proflems. The below webrev show the >> fixes for >> the Solaris area. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8029776 >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh From volker.simonis at gmail.com Tue Mar 4 09:38:20 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Mar 2014 18:38:20 +0100 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <53160AE6.6030206@oracle.com> References: <5315EE0D.50809@oracle.com> <53160AE6.6030206@oracle.com> Message-ID: Hi Gerald, thanks for providing the bug description. For this bug I think that's not really a problem because the synopsis as well as the change itself are already quite straight forward. My comment was intended more as a general hint to raise the awareness such that people don't create confidential bugs if this is not absolutely necessary. Also the fact that for some reason it seems to impossible to "open" a bug which was once flagged as "confidential" seems unnecessarily restrictive to me. All this makes it sometimes very hard for the community (but also for licensees) to understand what's going on. And this is not just the missing description during a review, but also the information when and to which repository a fix is integrated, which backports exist and so on. That's all very important and useful information for people outside Oracle which build their own OpenJDK/Java distribution. Thanks, Volker On Tue, Mar 4, 2014 at 6:18 PM, Gerald Thornbrugh wrote: > Hi Volker, > > The bug is not visible because it was inadvertently marked as confidential. > Since changing it from confidential to an open state is not a reasonable > option I will just state the description of the bug fix. > > JDK-8029776 describes JDK8 Solaris specific code cleanup to address > possible unclosed file descriptors, to make array indexes more readable > and make sure functions return values. > > Does this help? > > Thanks! > > Gerald Thornbrugh > > >> Hi Gerald, >> >> the bug is not visible. Could you please fix this. >> >> Thank you and best regards, >> Volker >> >> >> On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh >> wrote: >>> >>> Hi, >>> >>> I am a member of the Oracle Hotspot group and there is an initiative to >>> clean up >>> things like uninitialized variables and unclosed file descriptors in >>> JDK8. >>> This is a >>> backport of fixes that have already been putback into JDK9. I have run >>> UTE >>> and >>> JPRT tests on Solaris machines without proflems. The below webrev show >>> the >>> fixes for >>> the Solaris area. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8029776 >>> >>> Webrev: >>> >>> >>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >>> >>> Please review my changes and let me know if you have questions. >>> >>> Thanks, >>> >>> Gerald Thornbrugh > > From daniel.daugherty at oracle.com Tue Mar 4 10:09:08 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 04 Mar 2014 11:09:08 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <5315EE0D.50809@oracle.com> References: <5315EE0D.50809@oracle.com> Message-ID: <531616C4.9010504@oracle.com> Jerry, Reviewed by comparing your JDK9 patch file against the JDK8u patch file. Thumbs up. Dan On 3/4/14 8:15 AM, Gerald Thornbrugh wrote: > Hi, > > I am a member of the Oracle Hotspot group and there is an initiative > to clean up > things like uninitialized variables and unclosed file descriptors in > JDK8. This is a > backport of fixes that have already been putback into JDK9. I have run > UTE and > JPRT tests on Solaris machines without proflems. The below webrev show > the fixes for > the Solaris area. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8029776 > > Webrev: > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ > > > Please review my changes and let me know if you have questions. > > Thanks, > > Gerald Thornbrugh > From gerald.thornbrugh at oracle.com Tue Mar 4 10:10:20 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 04 Mar 2014 11:10:20 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <531616C4.9010504@oracle.com> References: <5315EE0D.50809@oracle.com> <531616C4.9010504@oracle.com> Message-ID: <5316170C.6050006@oracle.com> Hi Dan, Thanks for the review. Jerry > Jerry, > > Reviewed by comparing your JDK9 patch file against the JDK8u patch > file. Thumbs up. > > Dan > > > On 3/4/14 8:15 AM, Gerald Thornbrugh wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative >> to clean up >> things like uninitialized variables and unclosed file descriptors in >> JDK8. This is a >> backport of fixes that have already been putback into JDK9. I have >> run UTE and >> JPRT tests on Solaris machines without proflems. The below webrev >> show the fixes for >> the Solaris area. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8029776 >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >> >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh >> > From mikhailo.seledtsov at oracle.com Tue Mar 4 11:13:45 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 04 Mar 2014 14:13:45 -0500 Subject: RFR (XS): JDK-8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) In-Reply-To: <5314D2C1.7030500@oracle.com> References: <52F55660.2080000@oracle.com> <52FB95ED.90005@oracle.com> <52FBBEE3.6040405@oracle.com> <52FBC486.3000500@oracle.com> <5314D2C1.7030500@oracle.com> Message-ID: <531625E9.2090404@oracle.com> Here is webrev v02, updated after discussion with Coleen: http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.02/ Misha On 3/3/2014 2:06 PM, Mikhailo Seledtsov wrote: > Please review the updated webrev at > http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.01/ > > > Thank you, > Misha > > On 2/12/2014 1:59 PM, Coleen Phillimore wrote: >> >> On 2/12/14 1:35 PM, Mikhailo Seledtsov wrote: >>> Hi Coleen, >>> >>> Thank you for the review. Would it be OK if I print the message >>> that comes thru after the message that I introduced? >>> >>> There is a variety of messages that are passed to fail_continue() >>> depending on who calls it; checking/asserting on each message in the >>> test would be a large overhead; also some of these messages do not >>> convey "attempted, but failed" meaning. >> >> That seems fine if you want to prefix the message with yours, or >> append yours. Whatever makes sense in the context of the message. >> >> Coleen >> >>> >>> Thank you, >>> Misha >>> >>> On 2/12/2014 10:40 AM, Coleen Phillimore wrote: >>>> >>>> Misha, >>>> There is a message that comes through to fail_continue(). Why >>>> don't you use that message? >>>> thanks, >>>> Coleen >>>> >>>> On 2/7/14 4:55 PM, Mikhailo Seledtsov wrote: >>>>> Please review this small change that improves testability of >>>>> CDS, and will aid in fixing several intermittently failing CDS tests. >>>>> >>>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8033990 >>>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.00/ >>>>> Testing: >>>>> Basic testing: >>>>> - ran "Xshare:auto -version", "-XX:+Verbose >>>>> -XX:+PrintMiscellaneous -Xshare:auto -version" before and after >>>>> the archive was created >>>>> - ran "XX:+Verbose -XX:+PrintMiscellaneous >>>>> -Xshare:auto -version" on Windows where ASLR occasionally prevents >>>>> sharing >>>>> >>>>> JT-Reg: runtime/SharedArchiveFile, with and w/o the >>>>> additional options -vmoptions:"-XX:+Verbose -XX:+PrintMiscellaneous" >>>>> >>>>> Tonga: a sub-set of vm.parallel_class_loading.testlist, >>>>> with -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous -showversion" >>>>> Tonga (vm.parallel_class_loading.testlist >>>>> -vmopts " -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous >>>>> -showversion") >>>>> - ongoing. Plan not to run full testlist since the >>>>> change is small and trivial >>>>> >>>>> JPRT: standard JPRT: 2014-02-07-210345.mseledtsov.work01 >>>>> - ongoing >>>>> >>>>> Thank you, >>>>> Misha >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140304/c43c9a9a/attachment-0001.html From coleen.phillimore at oracle.com Tue Mar 4 11:17:56 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 04 Mar 2014 14:17:56 -0500 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <5316170C.6050006@oracle.com> References: <5315EE0D.50809@oracle.com> <531616C4.9010504@oracle.com> <5316170C.6050006@oracle.com> Message-ID: <531626E4.1080109@oracle.com> Agree, looks good. Coleen On 3/4/14 1:10 PM, Gerald Thornbrugh wrote: > Hi Dan, > > Thanks for the review. > > Jerry >> Jerry, >> >> Reviewed by comparing your JDK9 patch file against the JDK8u patch >> file. Thumbs up. >> >> Dan >> >> >> On 3/4/14 8:15 AM, Gerald Thornbrugh wrote: >>> Hi, >>> >>> I am a member of the Oracle Hotspot group and there is an initiative >>> to clean up >>> things like uninitialized variables and unclosed file descriptors in >>> JDK8. This is a >>> backport of fixes that have already been putback into JDK9. I have >>> run UTE and >>> JPRT tests on Solaris machines without proflems. The below webrev >>> show the fixes for >>> the Solaris area. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8029776 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >>> >>> >>> Please review my changes and let me know if you have questions. >>> >>> Thanks, >>> >>> Gerald Thornbrugh >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140304/02f007d8/attachment.html From gerald.thornbrugh at oracle.com Tue Mar 4 11:20:27 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 04 Mar 2014 12:20:27 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <531626E4.1080109@oracle.com> References: <5315EE0D.50809@oracle.com> <531616C4.9010504@oracle.com> <5316170C.6050006@oracle.com> <531626E4.1080109@oracle.com> Message-ID: <5316277B.8020102@oracle.com> Hi Coleen, Thanks for the review. Jerry > > Agree, looks good. > Coleen > > On 3/4/14 1:10 PM, Gerald Thornbrugh wrote: >> Hi Dan, >> >> Thanks for the review. >> >> Jerry >>> Jerry, >>> >>> Reviewed by comparing your JDK9 patch file against the JDK8u patch >>> file. Thumbs up. >>> >>> Dan >>> >>> >>> On 3/4/14 8:15 AM, Gerald Thornbrugh wrote: >>>> Hi, >>>> >>>> I am a member of the Oracle Hotspot group and there is an >>>> initiative to clean up >>>> things like uninitialized variables and unclosed file descriptors >>>> in JDK8. This is a >>>> backport of fixes that have already been putback into JDK9. I have >>>> run UTE and >>>> JPRT tests on Solaris machines without proflems. The below webrev >>>> show the fixes for >>>> the Solaris area. >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8029776 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >>>> >>>> >>>> Please review my changes and let me know if you have questions. >>>> >>>> Thanks, >>>> >>>> Gerald Thornbrugh >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140304/fb2cff59/attachment.html From christian.tornqvist at oracle.com Tue Mar 4 15:05:27 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 4 Mar 2014 18:05:27 -0500 Subject: RFR (XS): JDK-8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) In-Reply-To: <531625E9.2090404@oracle.com> References: <52F55660.2080000@oracle.com> <52FB95ED.90005@oracle.com> <52FBBEE3.6040405@oracle.com> <52FBC486.3000500@oracle.com> <5314D2C1.7030500@oracle.com> <531625E9.2090404@oracle.com> Message-ID: <015c01cf37fe$3d966100$b8c32300$@oracle.com> Looks good! Thanks, Christian From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Mikhailo Seledtsov Sent: Tuesday, March 4, 2014 2:14 PM To: Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR (XS): JDK-8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) Here is webrev v02, updated after discussion with Coleen: http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.02/ Misha On 3/3/2014 2:06 PM, Mikhailo Seledtsov wrote: Please review the updated webrev at http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.01/ Thank you, Misha On 2/12/2014 1:59 PM, Coleen Phillimore wrote: On 2/12/14 1:35 PM, Mikhailo Seledtsov wrote: Hi Coleen, Thank you for the review. Would it be OK if I print the message that comes thru after the message that I introduced? There is a variety of messages that are passed to fail_continue() depending on who calls it; checking/asserting on each message in the test would be a large overhead; also some of these messages do not convey "attempted, but failed" meaning. That seems fine if you want to prefix the message with yours, or append yours. Whatever makes sense in the context of the message. Coleen Thank you, Misha On 2/12/2014 10:40 AM, Coleen Phillimore wrote: Misha, There is a message that comes through to fail_continue(). Why don't you use that message? thanks, Coleen On 2/7/14 4:55 PM, Mikhailo Seledtsov wrote: Please review this small change that improves testability of CDS, and will aid in fixing several intermittently failing CDS tests. JBS: https://jbs.oracle.com/bugs/browse/JDK-8033990 Webrev: http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.00/ Testing: Basic testing: - ran "Xshare:auto -version", "-XX:+Verbose -XX:+PrintMiscellaneous -Xshare:auto -version" before and after the archive was created - ran "XX:+Verbose -XX:+PrintMiscellaneous -Xshare:auto -version" on Windows where ASLR occasionally prevents sharing JT-Reg: runtime/SharedArchiveFile, with and w/o the additional options -vmoptions:"-XX:+Verbose -XX:+PrintMiscellaneous" Tonga: a sub-set of vm.parallel_class_loading.testlist, with -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous -showversion" Tonga (vm.parallel_class_loading.testlist -vmopts " -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous -showversion") - ongoing. Plan not to run full testlist since the change is small and trivial JPRT: standard JPRT: 2014-02-07-210345.mseledtsov.work01 - ongoing Thank you, Misha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140304/db368464/attachment.html From david.holmes at oracle.com Tue Mar 4 19:53:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Mar 2014 13:53:02 +1000 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: References: <5315EE0D.50809@oracle.com> <53160AE6.6030206@oracle.com> Message-ID: <53169F9E.4000005@oracle.com> Hi Volker, On 5/03/2014 3:38 AM, Volker Simonis wrote: > Hi Gerald, > > thanks for providing the bug description. > > For this bug I think that's not really a problem because the synopsis > as well as the change itself are already quite straight forward. > > My comment was intended more as a general hint to raise the awareness > such that people don't create confidential bugs if this is not > absolutely necessary. > > Also the fact that for some reason it seems to impossible to "open" a > bug which was once flagged as "confidential" seems unnecessarily > restrictive to me. Unfortunately it is a restriction imposed by the way JBS/Jira operates. Once a bug is marked non-confidential any data that was ever present in a part of the report that was not itself marked confidential (ie comments can be confidential) will be visible in the bug history. So unfortunately once a bug is confidential it generally has to stay that way. And if we accidentally make something public that should be confidential we then have to flag the whole bug as confidential. Though in the latter case I would suggest that we should file a new open bug and close the confidential one as a duplicate (that works okay for new bugs, but not for backports of course). David ----- > All this makes it sometimes very hard for the community (but also for > licensees) to understand what's going on. And this is not just the > missing description during a review, but also the information when and > to which repository a fix is integrated, which backports exist and so > on. That's all very important and useful information for people > outside Oracle which build their own OpenJDK/Java distribution. > > Thanks, > Volker > > > On Tue, Mar 4, 2014 at 6:18 PM, Gerald Thornbrugh > wrote: >> Hi Volker, >> >> The bug is not visible because it was inadvertently marked as confidential. >> Since changing it from confidential to an open state is not a reasonable >> option I will just state the description of the bug fix. >> >> JDK-8029776 describes JDK8 Solaris specific code cleanup to address >> possible unclosed file descriptors, to make array indexes more readable >> and make sure functions return values. >> >> Does this help? >> >> Thanks! >> >> Gerald Thornbrugh >> >> >>> Hi Gerald, >>> >>> the bug is not visible. Could you please fix this. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh >>> wrote: >>>> >>>> Hi, >>>> >>>> I am a member of the Oracle Hotspot group and there is an initiative to >>>> clean up >>>> things like uninitialized variables and unclosed file descriptors in >>>> JDK8. >>>> This is a >>>> backport of fixes that have already been putback into JDK9. I have run >>>> UTE >>>> and >>>> JPRT tests on Solaris machines without proflems. The below webrev show >>>> the >>>> fixes for >>>> the Solaris area. >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8029776 >>>> >>>> Webrev: >>>> >>>> >>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >>>> >>>> Please review my changes and let me know if you have questions. >>>> >>>> Thanks, >>>> >>>> Gerald Thornbrugh >> >> From dmitry.samersoff at oracle.com Wed Mar 5 00:52:03 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 05 Mar 2014 12:52:03 +0400 Subject: RT_Baseline merged to HS_Main In-Reply-To: <20140305084701.9934D624EF@hg.openjdk.java.net> References: <20140305084701.9934D624EF@hg.openjdk.java.net> Message-ID: <5316E5B3.5060402@oracle.com> FYI -------- Original Message -------- Subject: hg: jdk9/hs/hotspot: 8 new changesets Date: Wed, 05 Mar 2014 08:46:43 +0000 From: dmitry.samersoff at oracle.com To: jdk9-all-changes at openjdk.java.net, jdk9-hs-changes at openjdk.java.net Changeset: 4c76be9856fc Author: sla Date: 2014-02-26 15:47 +0100 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/4c76be9856fc 8035150: ShouldNotReachHere() in ConstantPool::copy_entry_to Reviewed-by: dcubed, mgronlun ! src/share/vm/oops/constantPool.cpp + test/serviceability/jvmti/TestRedefineWithUnresolvedClass.java + test/serviceability/jvmti/UnresolvedClassAgent.java + test/serviceability/jvmti/UnresolvedClassAgent.mf ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java + test/testlibrary/com/oracle/java/testlibrary/Utils.java Changeset: f6301b007a16 Author: minqi Date: 2014-02-26 15:20 -0800 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f6301b007a16 6498581: ThreadInterruptTest3 produces wrong output on Windows Summary: There is race condition between os::interrupt and os::is_interrupted on Windows. In JVM_Sleep(Thread.sleep), check if thread gets interrupted, it may see interrupted but not really interrupted so cause spurious waking up (early return from sleep). Fix by checking if interrupt event really gets set thus prevent false return. For intrinsic of _isInterrupted, on Windows, go fastpath only on bit not set. Reviewed-by: acorn, kvn Contributed-by: david.holmes at oracle.com, yumin.qi at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/share/vm/opto/library_call.cpp Changeset: 047ea31fb127 Author: sla Date: 2014-02-28 14:30 +0400 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/047ea31fb127 8036010: hs: Some jtreg tests use hard coded ports Summary: bind to an ephemeral port Reviewed-by: jbachorik, sla ! test/runtime/6294277/SourceDebugExtension.java Changeset: cd30121047ac Author: igerasim Date: 2014-02-28 16:00 +0400 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/cd30121047ac 8035893: JVM_GetVersionInfo fails to zero structure Reviewed-by: sla, zgu ! src/share/vm/prims/jvm.cpp Changeset: ef7328717719 Author: dsamersoff Date: 2014-03-01 01:36 -0800 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/ef7328717719 Merge ! src/share/vm/opto/library_call.cpp Changeset: 0d8d78c0329a Author: sspitsyn Date: 2014-03-01 08:05 -0800 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/0d8d78c0329a 6471769: Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth out of sync") Summary: It is more safe to get/update data for suspended threads at a safepoint Reviewed-by: dcubed, twisti, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 2edca307b15a Author: dsamersoff Date: 2014-03-01 09:56 -0800 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/2edca307b15a 8036102: part of the fix for 6498581 lost in mismerge Summary: Restore code lost in mis-merge Reviewed-by: dcubed ! src/share/vm/opto/library_call.cpp Changeset: 7380034e5b31 Author: coleenp Date: 2014-03-03 13:58 -0500 URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/7380034e5b31 8035735: Metaspace::contains become extremely slow in some cases Summary: Call is_metadata instead which does less work for the call in debugInfo.hpp which is called for all compiled code stack frames. Reviewed-by: jmasa, dcubed ! src/share/vm/code/debugInfo.hpp ! src/share/vm/oops/metadata.hpp -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From volker.simonis at gmail.com Wed Mar 5 01:37:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 5 Mar 2014 10:37:27 +0100 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <53169F9E.4000005@oracle.com> References: <5315EE0D.50809@oracle.com> <53160AE6.6030206@oracle.com> <53169F9E.4000005@oracle.com> Message-ID: Hi David, thanks for your suggestion. Creating new bugs and closing the confidential ones as duplicates sounds reasonable and pretty simple. Hopefully this methodology will spread among Oracle engineers and they will use it BEFORE they start working on bugs which are unnecessarily flagged as confidential such that the webrev and the push can use the new, visible Bug ID. By the way, what's the exact meaning of 'confidential'. I suppose it is something like "Oracle internal" right? So there's no chance for any external contributor to ever get access to such kind of information. Regards, Volker On Wed, Mar 5, 2014 at 4:53 AM, David Holmes wrote: > Hi Volker, > > > On 5/03/2014 3:38 AM, Volker Simonis wrote: >> >> Hi Gerald, >> >> thanks for providing the bug description. >> >> For this bug I think that's not really a problem because the synopsis >> as well as the change itself are already quite straight forward. >> >> My comment was intended more as a general hint to raise the awareness >> such that people don't create confidential bugs if this is not >> absolutely necessary. >> >> Also the fact that for some reason it seems to impossible to "open" a >> bug which was once flagged as "confidential" seems unnecessarily >> restrictive to me. > > > Unfortunately it is a restriction imposed by the way JBS/Jira operates. Once > a bug is marked non-confidential any data that was ever present in a part of > the report that was not itself marked confidential (ie comments can be > confidential) will be visible in the bug history. So unfortunately once a > bug is confidential it generally has to stay that way. And if we > accidentally make something public that should be confidential we then have > to flag the whole bug as confidential. Though in the latter case I would > suggest that we should file a new open bug and close the confidential one as > a duplicate (that works okay for new bugs, but not for backports of course). > > David > ----- > > >> All this makes it sometimes very hard for the community (but also for >> licensees) to understand what's going on. And this is not just the >> missing description during a review, but also the information when and >> to which repository a fix is integrated, which backports exist and so >> on. That's all very important and useful information for people >> outside Oracle which build their own OpenJDK/Java distribution. >> >> Thanks, >> Volker >> >> >> On Tue, Mar 4, 2014 at 6:18 PM, Gerald Thornbrugh >> wrote: >>> >>> Hi Volker, >>> >>> The bug is not visible because it was inadvertently marked as >>> confidential. >>> Since changing it from confidential to an open state is not a reasonable >>> option I will just state the description of the bug fix. >>> >>> JDK-8029776 describes JDK8 Solaris specific code cleanup to address >>> possible unclosed file descriptors, to make array indexes more readable >>> and make sure functions return values. >>> >>> Does this help? >>> >>> Thanks! >>> >>> Gerald Thornbrugh >>> >>> >>>> Hi Gerald, >>>> >>>> the bug is not visible. Could you please fix this. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh >>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I am a member of the Oracle Hotspot group and there is an initiative to >>>>> clean up >>>>> things like uninitialized variables and unclosed file descriptors in >>>>> JDK8. >>>>> This is a >>>>> backport of fixes that have already been putback into JDK9. I have run >>>>> UTE >>>>> and >>>>> JPRT tests on Solaris machines without proflems. The below webrev show >>>>> the >>>>> fixes for >>>>> the Solaris area. >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8029776 >>>>> >>>>> Webrev: >>>>> >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >>>>> >>>>> Please review my changes and let me know if you have questions. >>>>> >>>>> Thanks, >>>>> >>>>> Gerald Thornbrugh >>> >>> >>> > From david.holmes at oracle.com Wed Mar 5 02:02:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Mar 2014 20:02:50 +1000 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: References: <5315EE0D.50809@oracle.com> <53160AE6.6030206@oracle.com> <53169F9E.4000005@oracle.com> Message-ID: <5316F64A.2040508@oracle.com> On 5/03/2014 7:37 PM, Volker Simonis wrote: > Hi David, > > thanks for your suggestion. > > Creating new bugs and closing the confidential ones as duplicates > sounds reasonable and pretty simple. > > Hopefully this methodology will spread among Oracle engineers and they > will use it BEFORE they start working on bugs which are unnecessarily > flagged as confidential such that the webrev and the push can use the > new, visible Bug ID. > > By the way, what's the exact meaning of 'confidential'. I suppose it > is something like "Oracle internal" right? So there's no chance for > any external contributor to ever get access to such kind of > information. In Jira terms "confidential" is restricted to certain "roles" in the project. One such role is "Oracle employee". I can't discuss what kind of information has to be flagged "confidential". David > Regards, > Volker > > > On Wed, Mar 5, 2014 at 4:53 AM, David Holmes wrote: >> Hi Volker, >> >> >> On 5/03/2014 3:38 AM, Volker Simonis wrote: >>> >>> Hi Gerald, >>> >>> thanks for providing the bug description. >>> >>> For this bug I think that's not really a problem because the synopsis >>> as well as the change itself are already quite straight forward. >>> >>> My comment was intended more as a general hint to raise the awareness >>> such that people don't create confidential bugs if this is not >>> absolutely necessary. >>> >>> Also the fact that for some reason it seems to impossible to "open" a >>> bug which was once flagged as "confidential" seems unnecessarily >>> restrictive to me. >> >> >> Unfortunately it is a restriction imposed by the way JBS/Jira operates. Once >> a bug is marked non-confidential any data that was ever present in a part of >> the report that was not itself marked confidential (ie comments can be >> confidential) will be visible in the bug history. So unfortunately once a >> bug is confidential it generally has to stay that way. And if we >> accidentally make something public that should be confidential we then have >> to flag the whole bug as confidential. Though in the latter case I would >> suggest that we should file a new open bug and close the confidential one as >> a duplicate (that works okay for new bugs, but not for backports of course). >> >> David >> ----- >> >> >>> All this makes it sometimes very hard for the community (but also for >>> licensees) to understand what's going on. And this is not just the >>> missing description during a review, but also the information when and >>> to which repository a fix is integrated, which backports exist and so >>> on. That's all very important and useful information for people >>> outside Oracle which build their own OpenJDK/Java distribution. >>> >>> Thanks, >>> Volker >>> >>> >>> On Tue, Mar 4, 2014 at 6:18 PM, Gerald Thornbrugh >>> wrote: >>>> >>>> Hi Volker, >>>> >>>> The bug is not visible because it was inadvertently marked as >>>> confidential. >>>> Since changing it from confidential to an open state is not a reasonable >>>> option I will just state the description of the bug fix. >>>> >>>> JDK-8029776 describes JDK8 Solaris specific code cleanup to address >>>> possible unclosed file descriptors, to make array indexes more readable >>>> and make sure functions return values. >>>> >>>> Does this help? >>>> >>>> Thanks! >>>> >>>> Gerald Thornbrugh >>>> >>>> >>>>> Hi Gerald, >>>>> >>>>> the bug is not visible. Could you please fix this. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> >>>>> On Tue, Mar 4, 2014 at 4:15 PM, Gerald Thornbrugh >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I am a member of the Oracle Hotspot group and there is an initiative to >>>>>> clean up >>>>>> things like uninitialized variables and unclosed file descriptors in >>>>>> JDK8. >>>>>> This is a >>>>>> backport of fixes that have already been putback into JDK9. I have run >>>>>> UTE >>>>>> and >>>>>> JPRT tests on Solaris machines without proflems. The below webrev show >>>>>> the >>>>>> fixes for >>>>>> the Solaris area. >>>>>> >>>>>> Bug: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8029776 >>>>>> >>>>>> Webrev: >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >>>>>> >>>>>> Please review my changes and let me know if you have questions. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gerald Thornbrugh >>>> >>>> >>>> >> From coleen.phillimore at oracle.com Wed Mar 5 08:09:18 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Mar 2014 11:09:18 -0500 Subject: RFR (XS): JDK-8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) In-Reply-To: <015c01cf37fe$3d966100$b8c32300$@oracle.com> References: <52F55660.2080000@oracle.com> <52FB95ED.90005@oracle.com> <52FBBEE3.6040405@oracle.com> <52FBC486.3000500@oracle.com> <5314D2C1.7030500@oracle.com> <531625E9.2090404@oracle.com> <015c01cf37fe$3d966100$b8c32300$@oracle.com> Message-ID: <53174C2E.9090807@oracle.com> This looks great. I thought you were going to add a test or is the test part of your ongoing work? thanks, Coleen On 3/4/14 6:05 PM, Christian Tornqvist wrote: > > Looks good! > > Thanks, > > Christian > > *From:*hotspot-runtime-dev-bounces at openjdk.java.net > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] *On Behalf Of > *Mikhailo Seledtsov > *Sent:* Tuesday, March 4, 2014 2:14 PM > *To:* Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR (XS): JDK-8033990: Add message to verbose output to > indicate when JVM was unable to use shared archive (with -Xshare:auto) > > Here is webrev v02, updated after discussion with Coleen: > http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.02/ > > > Misha > > On 3/3/2014 2:06 PM, Mikhailo Seledtsov wrote: > > Please review the updated webrev at > http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.01/ > > > Thank you, > Misha > > On 2/12/2014 1:59 PM, Coleen Phillimore wrote: > > On 2/12/14 1:35 PM, Mikhailo Seledtsov wrote: > > Hi Coleen, > > Thank you for the review. Would it be OK if I print the > message that comes thru after the message that I introduced? > > There is a variety of messages that are passed to > fail_continue() depending on who calls it; > checking/asserting on each message in the test would be a > large overhead; also some of these messages do not convey > "attempted, but failed" meaning. > > > That seems fine if you want to prefix the message with yours, > or append yours. Whatever makes sense in the context of the > message. > > Coleen > > > > Thank you, > Misha > > > On 2/12/2014 10:40 AM, Coleen Phillimore wrote: > > > Misha, > There is a message that comes through to > fail_continue(). Why don't you use that message? > thanks, > Coleen > > On 2/7/14 4:55 PM, Mikhailo Seledtsov wrote: > > Please review this small change that improves > testability of CDS, and will aid in fixing several > intermittently failing CDS tests. > > JBS: > https://jbs.oracle.com/bugs/browse/JDK-8033990 > Webrev: > http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.00/ > > > Testing: > Basic testing: > - ran "Xshare:auto -version", > "-XX:+Verbose -XX:+PrintMiscellaneous -Xshare:auto > -version" before and after the archive was created > - ran "XX:+Verbose > -XX:+PrintMiscellaneous -Xshare:auto -version" on > Windows where ASLR occasionally prevents sharing > > JT-Reg: runtime/SharedArchiveFile, with > and w/o the additional options > -vmoptions:"-XX:+Verbose -XX:+PrintMiscellaneous" > > Tonga: a sub-set of > vm.parallel_class_loading.testlist, with > -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous > -showversion" > Tonga > (vm.parallel_class_loading.testlist -vmopts " > -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous > -showversion") > - ongoing. Plan not to run full > testlist since the change is small and trivial > > JPRT: standard JPRT: > 2014-02-07-210345.mseledtsov.work01 > - ongoing > > Thank you, > Misha > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140305/96491433/attachment.html From mikhailo.seledtsov at oracle.com Wed Mar 5 08:56:30 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Wed, 05 Mar 2014 11:56:30 -0500 Subject: RFR (XS): JDK-8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) In-Reply-To: <53174C2E.9090807@oracle.com> References: <52F55660.2080000@oracle.com> <52FB95ED.90005@oracle.com> <52FBBEE3.6040405@oracle.com> <52FBC486.3000500@oracle.com> <5314D2C1.7030500@oracle.com> <531625E9.2090404@oracle.com> <015c01cf37fe$3d966100$b8c32300$@oracle.com> <53174C2E.9090807@oracle.com> Message-ID: <5317573E.7050509@oracle.com> Coleen, Christian, Thank you for the review. The test is part of the ongoing work; in fact, once this bug is fixed, this will open a way to fixing 3 broken CDS tests. Misha On 3/5/2014 11:09 AM, Coleen Phillimore wrote: > > This looks great. I thought you were going to add a test or is the > test part of your ongoing work? > thanks, > Coleen > > On 3/4/14 6:05 PM, Christian Tornqvist wrote: >> >> Looks good! >> >> Thanks, >> >> Christian >> >> *From:*hotspot-runtime-dev-bounces at openjdk.java.net >> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] *On Behalf Of >> *Mikhailo Seledtsov >> *Sent:* Tuesday, March 4, 2014 2:14 PM >> *To:* Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net >> *Subject:* Re: RFR (XS): JDK-8033990: Add message to verbose output >> to indicate when JVM was unable to use shared archive (with -Xshare:auto) >> >> Here is webrev v02, updated after discussion with Coleen: >> http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.02/ >> >> >> Misha >> >> On 3/3/2014 2:06 PM, Mikhailo Seledtsov wrote: >> >> Please review the updated webrev at >> http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.01/ >> >> >> Thank you, >> Misha >> >> On 2/12/2014 1:59 PM, Coleen Phillimore wrote: >> >> On 2/12/14 1:35 PM, Mikhailo Seledtsov wrote: >> >> Hi Coleen, >> >> Thank you for the review. Would it be OK if I print the >> message that comes thru after the message that I introduced? >> >> There is a variety of messages that are passed to >> fail_continue() depending on who calls it; >> checking/asserting on each message in the test would be a >> large overhead; also some of these messages do not convey >> "attempted, but failed" meaning. >> >> >> That seems fine if you want to prefix the message with yours, >> or append yours. Whatever makes sense in the context of the >> message. >> >> Coleen >> >> >> >> Thank you, >> Misha >> >> >> On 2/12/2014 10:40 AM, Coleen Phillimore wrote: >> >> >> Misha, >> There is a message that comes through to >> fail_continue(). Why don't you use that message? >> thanks, >> Coleen >> >> On 2/7/14 4:55 PM, Mikhailo Seledtsov wrote: >> >> Please review this small change that improves >> testability of CDS, and will aid in fixing >> several intermittently failing CDS tests. >> >> JBS: >> https://jbs.oracle.com/bugs/browse/JDK-8033990 >> Webrev: >> http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.00/ >> >> >> Testing: >> Basic testing: >> - ran "Xshare:auto -version", >> "-XX:+Verbose -XX:+PrintMiscellaneous >> -Xshare:auto -version" before and after the >> archive was created >> - ran "XX:+Verbose >> -XX:+PrintMiscellaneous -Xshare:auto -version" on >> Windows where ASLR occasionally prevents sharing >> >> JT-Reg: runtime/SharedArchiveFile, with >> and w/o the additional options >> -vmoptions:"-XX:+Verbose -XX:+PrintMiscellaneous" >> >> Tonga: a sub-set of >> vm.parallel_class_loading.testlist, with >> -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous >> -showversion" >> Tonga >> (vm.parallel_class_loading.testlist -vmopts " >> -Xshare:auto -XX:+Verbose -XX:+PrintMiscellaneous >> -showversion") >> - ongoing. Plan not to run full >> testlist since the change is small and trivial >> >> JPRT: standard JPRT: >> 2014-02-07-210345.mseledtsov.work01 >> - ongoing >> >> Thank you, >> Misha >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140305/03311744/attachment-0001.html From daniel.daugherty at oracle.com Wed Mar 5 09:37:50 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 05 Mar 2014 10:37:50 -0700 Subject: RFR (S): 8028280 ParkEvent leak when running modified runThese which only loads classes In-Reply-To: <52DE9946.8040404@oracle.com> References: <528E20C5.7080900@oracle.com> <528E2865.9080002@oracle.com> <5294752B.50401@oracle.com> <5297E8A4.8030101@oracle.com> <5298428F.4050809@oracle.com> <52D656EC.9050400@oracle.com> <52DE4371.7000504@oracle.com> <52DE9946.8040404@oracle.com> Message-ID: <531760EE.9010501@oracle.com> For the record, we're backporting this fix from JDK9 -> JDK8u-hs-dev. Both Frederic Parain and David Holmes (the original reviewers) have reviewed the backport. Karen Kinnear (acorn) and I have also reviewed the backport. There are no content changes between the versions; only line number and context diff anchor changes. Dan On 1/21/14 8:59 AM, David Simms wrote: > > Thanks Frederic ! > > On 21/01/2014 10:52 a.m., Frederic Parain wrote: >> Looks good to me. >> >> Fred >> >> On 01/15/2014 10:37 AM, David Simms wrote: >>> >>> Still need a 2nd reviewer (doesn't have to be capital 'R') for this >>> fix. >>> >>> Cheers >>> /David Simms >>> >>> On 11/29/2013 08:30 AM, David Simms wrote: >>>> >>>> Thanks for the review ! >>>> >>>> Inline... >>>> >>>> On 29/11/2013 2:06 a.m., David Holmes wrote: >>>>> Hi David, >>>>> >>>>> Apologies for the delay in getting back to this, and even more so >>>>> that I won't be able to respond further as I'll be on vacation the >>>>> next two weeks. Fortunately no major issues that would need further >>>>> discussion :) >>>>> >>>> It's okay, we took the bug of the critical list, it's actually hard to >>>> cause an actual OOM. >>>>> src/os/*/vm/os_*.cpp >>>>> >>>>> So ... os::naked_sleep is now morphed into os::naked_short_sleep and >>>>> is always really "naked" ie it uses an OS call. Ok. >>>>> >>>>> Why does the windows version not have: >>>>> >>>>> assert(ms < 1000, "Long sleep will break Thread.interrupt() >>>>> semantics"); >>>>> >>>>> ? >>>> Will fix. >>>>> >>>>> What is your concern with Thread.interrupt here? These sleeps aren't >>>>> involved in Thread.sleep; and the parking logic only looks for >>>>> interrupts at specific points (the existing SpinAcquire code will not >>>>> return if the thread is interrupted). The main issue with long >>>>> blocking is that the thread is not undergoing a state transition and >>>>> so a safepoint will not be reachable until the sleep is over (and we >>>>> reach a point where we check for a safepoint). I'd be worried that a >>>>> 1 second sleep might cause a problem with safepoints. Of course this >>>>> depends on what the caller does before using naked_short_sleep. >>>>> >>>> My concern is someone else looking to use naked_short_sleep() outside >>>> the current context, must be aware that this only for short periods. >>>> I.e. it is in no way interruptible. I can change the comment to be >>>> more generic, i.e. what I just said. >>>> >>>>> --- >>>>> >>>>> src/share/vm/runtime/thread.hpp >>>>> >>>>> // Low-level leaf-lock primitives used to implement >>>>> synchronization >>>>> // and native monitor-mutex infrastructure. >>>>> // Not for general synchronization use. >>>>> + // Direct naked OS primitives, safe to use standalone in lock >>>>> impl >>>>> >>>>> Your comment really only applies to SpinAcquire, not the set of >>>>> methods that the original comment block refers to. >>>> >>>> Whoops, thought that comment referred to SpinAcquire and SpinRelease, >>>> can leave it in for mux acquire and release of course. >>>>> >>>>> --- >>>>> >>>>> src/share/vm/runtime/park.cpp >>>>> >>>>> 91 // Note that if we didn't have the TSM/immortal constraint, >>>>> then >>>>> 92 // when reattaching, above, we could trim the list. >>>>> >>>>> What is the "reattaching, above" you are referring to? This comment >>>>> seem more directed to the old code than the new ?? >>>> Ah, old comment, thanks for spotting that. Although it's still true >>>> ",/above,/" needs to go. >>>>> >>>>> --- >>>>> >>>>> Overall this seems okay but I do wonder about the change in >>>>> performance profile. The scenario that caused the leak indicates a >>>>> high-level of contention. Have any of the synchronization benchmarks >>>>> been run as a sanity check? >>>> >>>> I can talk with the local performance engineer and check for >>>> regressions. Shouldn't be a problem semantically, as I'm modifying >>>> slow-path...of fairly critical code - will test. >>>> >>>> The scenario was a targeted stress test, multi-threaded class-loading >>>> from the same jar. Not quite "real-world", but since the test exist, >>>> will re-run with performance in mind. >>>> >>>> Thanks again ! >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 26/11/2013 8:17 PM, David Simms wrote: >>>>>> >>>>>> Updated patch to avoid Solaris RT link requirement... >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028280 >>>>>> Webrev: http://cr.openjdk.java.net/~dsimms/8028280/ >>>>>> >>>>>> >>>>>> Rerun testing including vm.quick-pcl.testlist on all platforms. >>>>>> >>>>>> >>>>>> On 11/21/2013 04:36 PM, David Simms wrote: >>>>>>> >>>>>>> Sorry, >>>>>>> >>>>>>> Some test failures due to Solaris ld not finding nanosleep... >>>>>>> >>>>>>> >>>>>>> On 11/21/2013 04:03 PM, David Simms wrote: >>>>>>>> >>>>>>>> Small fix for resource leakage with concurrent free list handling >>>>>>>> down in park.cpp >>>>>>>> >>>>>>>> I did modify Thread::SpinAcquire() to be independent of park event >>>>>>>> (naked OS functions only), since this method doesn't need to >>>>>>>> follow >>>>>>>> Thread.interrupt() semantics (park doesn't make sense here). >>>>>>>> >>>>>>>> This allowed a simple spin lock around the resources without >>>>>>>> worrying >>>>>>>> about the fact that park is used in runtime locks. >>>>>>>> >>>>>>>> Perhaps SpinAcquire/Release could be spit out to a separate >>>>>>>> stand-alone util class, a some point in the future. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028280 >>>>>>>> Webrev: http://cr.openjdk.java.net/~dsimms/8028280/ >>>>>>>> >>>>>>>> >>>>>>>> Testing: vm testbase, BigApps (30 mins), jtreg (all 64bit >>>>>>>> platforms) >>>>>>>> (...almost completed) >>>>>>>> >>>>>>>> >>>>>>>> /David Simms >>>>>>> >>>>>> >>>> >>> >> > > > > From gerald.thornbrugh at oracle.com Wed Mar 5 09:48:43 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 05 Mar 2014 10:48:43 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <531616C4.9010504@oracle.com> References: <5315EE0D.50809@oracle.com> <531616C4.9010504@oracle.com> Message-ID: <5317637B.2070104@oracle.com> Hi Dan, What is the next step to get my Solaris Parfait fixes into JDK8u? Do I need to choose a sponsor? Are you willing to be my sponsor? Thanks! Jerry > Jerry, > > Reviewed by comparing your JDK9 patch file against the JDK8u patch > file. Thumbs up. > > Dan > > > On 3/4/14 8:15 AM, Gerald Thornbrugh wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative >> to clean up >> things like uninitialized variables and unclosed file descriptors in >> JDK8. This is a >> backport of fixes that have already been putback into JDK9. I have >> run UTE and >> JPRT tests on Solaris machines without proflems. The below webrev >> show the fixes for >> the Solaris area. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8029776 >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >> >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh >> > From daniel.daugherty at oracle.com Wed Mar 5 09:50:03 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 05 Mar 2014 10:50:03 -0700 Subject: RFR: JDK-8029776 - Solaris code cleanup In-Reply-To: <5317637B.2070104@oracle.com> References: <5315EE0D.50809@oracle.com> <531616C4.9010504@oracle.com> <5317637B.2070104@oracle.com> Message-ID: <531763CB.4060405@oracle.com> Of course, I will sponsor your push into JDK8u-hs-dev. Dan On 3/5/14 10:48 AM, Gerald Thornbrugh wrote: > Hi Dan, > > What is the next step to get my Solaris Parfait fixes into JDK8u? > > Do I need to choose a sponsor? Are you willing to be my sponsor? > > Thanks! > > Jerry >> Jerry, >> >> Reviewed by comparing your JDK9 patch file against the JDK8u patch >> file. Thumbs up. >> >> Dan >> >> >> On 3/4/14 8:15 AM, Gerald Thornbrugh wrote: >>> Hi, >>> >>> I am a member of the Oracle Hotspot group and there is an initiative >>> to clean up >>> things like uninitialized variables and unclosed file descriptors in >>> JDK8. This is a >>> backport of fixes that have already been putback into JDK9. I have >>> run UTE and >>> JPRT tests on Solaris machines without proflems. The below webrev >>> show the fixes for >>> the Solaris area. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8029776 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8029775-webrev/0-jdk8u-hs-dev/ >>> >>> >>> Please review my changes and let me know if you have questions. >>> >>> Thanks, >>> >>> Gerald Thornbrugh >>> >> > From coleen.phillimore at oracle.com Wed Mar 5 13:46:07 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Mar 2014 16:46:07 -0500 Subject: RFR (XS): JDK-8033990: Add message to verbose output to indicate when JVM was unable to use shared archive (with -Xshare:auto) In-Reply-To: <5317573E.7050509@oracle.com> References: <52F55660.2080000@oracle.com> <52FB95ED.90005@oracle.com> <52FBBEE3.6040405@oracle.com> <52FBC486.3000500@oracle.com> <5314D2C1.7030500@oracle.com> <531625E9.2090404@oracle.com> <015c01cf37fe$3d966100$b8c32300$@oracle.com> <53174C2E.9090807@oracle.com> <5317573E.7050509@oracle.com> Message-ID: <53179B1F.3060001@oracle.com> Ok. Coleen On 3/5/14 11:56 AM, Mikhailo Seledtsov wrote: > Coleen, Christian, > > Thank you for the review. > The test is part of the ongoing work; in fact, once this bug is fixed, > this will open a way to fixing 3 broken CDS tests. > > Misha > > > On 3/5/2014 11:09 AM, Coleen Phillimore wrote: >> >> This looks great. I thought you were going to add a test or is the >> test part of your ongoing work? >> thanks, >> Coleen >> >> On 3/4/14 6:05 PM, Christian Tornqvist wrote: >>> >>> Looks good! >>> >>> Thanks, >>> >>> Christian >>> >>> *From:*hotspot-runtime-dev-bounces at openjdk.java.net >>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] *On Behalf Of >>> *Mikhailo Seledtsov >>> *Sent:* Tuesday, March 4, 2014 2:14 PM >>> *To:* Coleen Phillimore; hotspot-runtime-dev at openjdk.java.net >>> *Subject:* Re: RFR (XS): JDK-8033990: Add message to verbose output >>> to indicate when JVM was unable to use shared archive (with >>> -Xshare:auto) >>> >>> Here is webrev v02, updated after discussion with Coleen: >>> http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.02/ >>> >>> >>> Misha >>> >>> On 3/3/2014 2:06 PM, Mikhailo Seledtsov wrote: >>> >>> Please review the updated webrev at >>> http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.01/ >>> >>> >>> Thank you, >>> Misha >>> >>> On 2/12/2014 1:59 PM, Coleen Phillimore wrote: >>> >>> On 2/12/14 1:35 PM, Mikhailo Seledtsov wrote: >>> >>> Hi Coleen, >>> >>> Thank you for the review. Would it be OK if I print the >>> message that comes thru after the message that I >>> introduced? >>> >>> There is a variety of messages that are passed to >>> fail_continue() depending on who calls it; >>> checking/asserting on each message in the test would be >>> a large overhead; also some of these messages do not >>> convey "attempted, but failed" meaning. >>> >>> >>> That seems fine if you want to prefix the message with >>> yours, or append yours. Whatever makes sense in the context >>> of the message. >>> >>> Coleen >>> >>> >>> >>> Thank you, >>> Misha >>> >>> >>> On 2/12/2014 10:40 AM, Coleen Phillimore wrote: >>> >>> >>> Misha, >>> There is a message that comes through to >>> fail_continue(). Why don't you use that message? >>> thanks, >>> Coleen >>> >>> On 2/7/14 4:55 PM, Mikhailo Seledtsov wrote: >>> >>> Please review this small change that >>> improves testability of CDS, and will aid in >>> fixing several intermittently failing CDS tests. >>> >>> JBS: >>> https://jbs.oracle.com/bugs/browse/JDK-8033990 >>> Webrev: >>> http://cr.openjdk.java.net/~mseledtsov/8033990/webrev.00/ >>> >>> >>> Testing: >>> Basic testing: >>> - ran "Xshare:auto -version", >>> "-XX:+Verbose -XX:+PrintMiscellaneous >>> -Xshare:auto -version" before and after the >>> archive was created >>> - ran "XX:+Verbose >>> -XX:+PrintMiscellaneous -Xshare:auto -version" >>> on Windows where ASLR occasionally prevents sharing >>> >>> JT-Reg: runtime/SharedArchiveFile, with >>> and w/o the additional options >>> -vmoptions:"-XX:+Verbose -XX:+PrintMiscellaneous" >>> >>> Tonga: a sub-set of >>> vm.parallel_class_loading.testlist, with >>> -Xshare:auto -XX:+Verbose >>> -XX:+PrintMiscellaneous -showversion" >>> Tonga >>> (vm.parallel_class_loading.testlist -vmopts " >>> -Xshare:auto -XX:+Verbose >>> -XX:+PrintMiscellaneous -showversion") >>> - ongoing. Plan not to run full >>> testlist since the change is small and trivial >>> >>> JPRT: standard JPRT: >>> 2014-02-07-210345.mseledtsov.work01 >>> - ongoing >>> >>> Thank you, >>> Misha >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140305/db8a6adb/attachment.html From axel.siebenborn at sap.com Thu Mar 6 00:08:45 2014 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Thu, 6 Mar 2014 08:08:45 +0000 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> Hi all, could I have a review for the following change? The recursive lock count for an object is not correct, in cases, where a monitor is inflated after recursive lightweight locks. In this case, the recursion count is taken from the heavyweight monitor, represented by the class ObjectMonitor. ObjectMonitor::_recursions is the number of times ObjectMonitor::enter() was called to acquire the lock minus 1. This counter does not include the recursions of lightweight locks, that happen before inflating the monitor and is not equal to the recursion count from a Java source level point of view. I added a test to the webrev to reproduce the problem. The suggested fix is to call count_locked_objects, even if there's a heavyweight monitor and get the recursion count by iterating the vframes. Bug: https://bugs.openjdk.java.net/browse/JDK-8036666 Webrev: http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ Thanks, Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140306/0c278f7a/attachment.html From mikhailo.seledtsov at oracle.com Thu Mar 6 05:10:11 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 06 Mar 2014 08:10:11 -0500 Subject: RFR (S): JDK-8026154: [TESTBUG] runtime/CDSCompressedKPtrs/XShareAuto.java failed due to exception Message-ID: <531873B3.4010706@oracle.com> Please review this change that fixes several tests. The issues addressed by this change have similar root cause, hence I have consolidated them under the umbrella of JDK-8026154 and hope to submit them as one change set. In detail, these changes are introduced to cover situation where mapping of the shared (CDS) archive into memory fails. Such situation is a random occurance, and is most likely due to ASLR (Adress Space Layout Randomization). ASLR is a security feature managed by OS that randomizes the address where shared libraries are loaded; if the shared library is mapped into the space intended for the CDS archive, the mapping of the archive will fail. With this change, these tests take such situation into account. JBS: https://bugs.openjdk.java.net/browse/JDK-8026154 Webrev: http://cr.openjdk.java.net/~mseledtsov/8026154/webrev.00/ Testing: Exercises these tests on all standard platforms via JPRT -> PASS Local testing with number of iterations, especially on Windows where ASLR seems to be more aggressive From frederic.parain at oracle.com Thu Mar 6 08:12:41 2014 From: frederic.parain at oracle.com (frederic parain) Date: Thu, 06 Mar 2014 17:12:41 +0100 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO Message-ID: <53189E79.90806@oracle.com> Greetings, The UseVMInterruptibleIO flag removal has been scheduled a long time ago: https://bugs.openjdk.java.net/browse/JDK-4385444 Now, it's time to effectively remove this flag and its associated code. Removing this feature includes removing all the macros used to deal with interruptible I/Os, which could make the reading of the webrev hard and painful. I conservatively preserved the asserts that were inserted by the INTERRUPTIBLE macros, with one notable exception for os::read(). The original asserts checked that the current ThreadState was not _thread_in_native nor _thread_blocked. I changed it into an assert checking that the current thread state is _thread_in_vm. The rational for that is that the only real usage of os::read() on Solaris is in the ClassPathDirEntry::open_stream() method, which is always called with ThreadState ==_thread_in_vm. This change makes the TreadStateTransition simpler and avoid having to store the previous ThreadState. This choice could be revisited once the rules for ThreadStateTransition around system calls when ThreadState is _thread_in_vm are clarified (Solaris is currently the only platform doing this kind of transition for os::read()). The CR: https://bugs.openjdk.java.net/browse/JDK-8036128 The webrev: http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ Tested with vm.quick.testlist and JPRT hotspot job. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From david.holmes at oracle.com Thu Mar 6 20:40:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Mar 2014 14:40:40 +1000 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <53189E79.90806@oracle.com> References: <53189E79.90806@oracle.com> Message-ID: <53194DC8.1040502@oracle.com> Hi Fred, This looks good to me! Great to see the cleanup happen. os_solaris.cpp: This comment block seems redundant now: 5264 /* 5265 * XXX: is the following call interruptible? If so, this might 5266 * need to go through the INTERRUPT_IO() wrapper as for other 5267 * blocking, interruptible calls in this file. 5268 */ --- Aside: arguments.cpp - I guess we can file an RFE to get rid of obsolete_jvm_flags now that hsx is dead. ;-) Cheers, David On 7/03/2014 2:12 AM, frederic parain wrote: > Greetings, > > The UseVMInterruptibleIO flag removal has been > scheduled a long time ago: > https://bugs.openjdk.java.net/browse/JDK-4385444 > > Now, it's time to effectively remove this flag and > its associated code. > > Removing this feature includes removing all the > macros used to deal with interruptible I/Os, which > could make the reading of the webrev hard and painful. > I conservatively preserved the asserts that were > inserted by the INTERRUPTIBLE macros, with one > notable exception for os::read(). The original > asserts checked that the current ThreadState > was not _thread_in_native nor _thread_blocked. > I changed it into an assert checking that the > current thread state is _thread_in_vm. The > rational for that is that the only real usage > of os::read() on Solaris is in the > ClassPathDirEntry::open_stream() method, which > is always called with ThreadState ==_thread_in_vm. > This change makes the TreadStateTransition simpler > and avoid having to store the previous ThreadState. > > This choice could be revisited once the rules > for ThreadStateTransition around system calls > when ThreadState is _thread_in_vm are clarified > (Solaris is currently the only platform doing > this kind of transition for os::read()). > > The CR: > https://bugs.openjdk.java.net/browse/JDK-8036128 > > The webrev: > http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ > > Tested with vm.quick.testlist and JPRT hotspot job. > > Thanks, > > Fred > From serguei.spitsyn at oracle.com Fri Mar 7 01:32:03 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 07 Mar 2014 01:32:03 -0800 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> Message-ID: <53199213.5010708@oracle.com> Hi Axel, Thank you for fixing this issue. I'm reviewing it. It looks good in general, but a little bit more time is needed to look at the tests. Do you need a sponsor for pushing? Thanks, Serguei On 3/6/14 12:08 AM, Siebenborn, Axel wrote: > > Hi all, > > could I have a review for the following change? > > The recursive lock count for an object is not correct, in cases, where > a monitor is inflated after recursive lightweight locks. In this case, > the recursion count is taken from the heavyweight monitor, represented > by the class ObjectMonitor. ObjectMonitor::_recursions is the number > of times ObjectMonitor::enter() was called to acquire the lock minus > 1. This counter does not include the recursions of lightweight locks, > that happen before inflating the monitor and is not equal to the > recursion count from a Java source level point of view. > > I added a test to the webrev to reproduce the problem. > > The suggested fix is to call count_locked_objects, even if there's a > heavyweight monitor and get the recursion count by iterating the vframes. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8036666 > > Webrev: > > http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ > > > Thanks, > > Axel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140307/3603bc62/attachment.html From axel.siebenborn at sap.com Fri Mar 7 02:43:12 2014 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Fri, 7 Mar 2014 10:43:12 +0000 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <53199213.5010708@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C39811C4E@DEWDFEMB20C.global.corp.sap> Hi Sergui, thanks for reviewing. Yes, I need a sponsor. Thanks, Axel From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Freitag, 7. M?rz 2014 10:32 To: Siebenborn, Axel; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count Hi Axel, Thank you for fixing this issue. I'm reviewing it. It looks good in general, but a little bit more time is needed to look at the tests. Do you need a sponsor for pushing? Thanks, Serguei On 3/6/14 12:08 AM, Siebenborn, Axel wrote: Hi all, could I have a review for the following change? The recursive lock count for an object is not correct, in cases, where a monitor is inflated after recursive lightweight locks. In this case, the recursion count is taken from the heavyweight monitor, represented by the class ObjectMonitor. ObjectMonitor::_recursions is the number of times ObjectMonitor::enter() was called to acquire the lock minus 1. This counter does not include the recursions of lightweight locks, that happen before inflating the monitor and is not equal to the recursion count from a Java source level point of view. I added a test to the webrev to reproduce the problem. The suggested fix is to call count_locked_objects, even if there's a heavyweight monitor and get the recursion count by iterating the vframes. Bug: https://bugs.openjdk.java.net/browse/JDK-8036666 Webrev: http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ Thanks, Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140307/22b6e1ff/attachment.html From daniel.daugherty at oracle.com Fri Mar 7 09:29:06 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 07 Mar 2014 10:29:06 -0700 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <53189E79.90806@oracle.com> References: <53189E79.90806@oracle.com> Message-ID: <531A01E2.4020105@oracle.com> > http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ src/share/vm/runtime/globals.hpp No comments. src/share/vm/runtime/arguments.cpp No comments. src/os/solaris/vm/os_solaris.hpp No comments. src/os/solaris/vm/os_solaris.inline.hpp No comments. src/os/solaris/vm/osThread_solaris.hpp No comments. src/os/solaris/vm/os_solaris.cpp No comments other than it looks so much cleaner now! src/os/solaris/vm/osThread_solaris.cpp No comments. src/share/vm/services/runtimeService.hpp No comments. src/share/vm/services/runtimeService.cpp No comments. Nicely done! Thumbs up! Dan On 3/6/14 9:12 AM, frederic parain wrote: > Greetings, > > The UseVMInterruptibleIO flag removal has been > scheduled a long time ago: > https://bugs.openjdk.java.net/browse/JDK-4385444 > > Now, it's time to effectively remove this flag and > its associated code. > > Removing this feature includes removing all the > macros used to deal with interruptible I/Os, which > could make the reading of the webrev hard and painful. > I conservatively preserved the asserts that were > inserted by the INTERRUPTIBLE macros, with one > notable exception for os::read(). The original > asserts checked that the current ThreadState > was not _thread_in_native nor _thread_blocked. > I changed it into an assert checking that the > current thread state is _thread_in_vm. The > rational for that is that the only real usage > of os::read() on Solaris is in the > ClassPathDirEntry::open_stream() method, which > is always called with ThreadState ==_thread_in_vm. > This change makes the TreadStateTransition simpler > and avoid having to store the previous ThreadState. > > This choice could be revisited once the rules > for ThreadStateTransition around system calls > when ThreadState is _thread_in_vm are clarified > (Solaris is currently the only platform doing > this kind of transition for os::read()). > > The CR: > https://bugs.openjdk.java.net/browse/JDK-8036128 > > The webrev: > http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ > > Tested with vm.quick.testlist and JPRT hotspot job. > > Thanks, > > Fred > From coleen.phillimore at oracle.com Fri Mar 7 09:40:22 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 07 Mar 2014 12:40:22 -0500 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <531A01E2.4020105@oracle.com> References: <53189E79.90806@oracle.com> <531A01E2.4020105@oracle.com> Message-ID: <531A0486.9030108@oracle.com> I agree. This looks great. Thank you for doing this! Coleen On 3/7/14 12:29 PM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ > > src/share/vm/runtime/globals.hpp > No comments. > > src/share/vm/runtime/arguments.cpp > No comments. > > src/os/solaris/vm/os_solaris.hpp > No comments. > > src/os/solaris/vm/os_solaris.inline.hpp > No comments. > > src/os/solaris/vm/osThread_solaris.hpp > No comments. > > src/os/solaris/vm/os_solaris.cpp > No comments other than it looks so much cleaner now! > > src/os/solaris/vm/osThread_solaris.cpp > No comments. > > src/share/vm/services/runtimeService.hpp > No comments. > > src/share/vm/services/runtimeService.cpp > No comments. > > Nicely done! Thumbs up! > > Dan > > > On 3/6/14 9:12 AM, frederic parain wrote: >> Greetings, >> >> The UseVMInterruptibleIO flag removal has been >> scheduled a long time ago: >> https://bugs.openjdk.java.net/browse/JDK-4385444 >> >> Now, it's time to effectively remove this flag and >> its associated code. >> >> Removing this feature includes removing all the >> macros used to deal with interruptible I/Os, which >> could make the reading of the webrev hard and painful. >> I conservatively preserved the asserts that were >> inserted by the INTERRUPTIBLE macros, with one >> notable exception for os::read(). The original >> asserts checked that the current ThreadState >> was not _thread_in_native nor _thread_blocked. >> I changed it into an assert checking that the >> current thread state is _thread_in_vm. The >> rational for that is that the only real usage >> of os::read() on Solaris is in the >> ClassPathDirEntry::open_stream() method, which >> is always called with ThreadState ==_thread_in_vm. >> This change makes the TreadStateTransition simpler >> and avoid having to store the previous ThreadState. >> >> This choice could be revisited once the rules >> for ThreadStateTransition around system calls >> when ThreadState is _thread_in_vm are clarified >> (Solaris is currently the only platform doing >> this kind of transition for os::read()). >> >> The CR: >> https://bugs.openjdk.java.net/browse/JDK-8036128 >> >> The webrev: >> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >> >> Tested with vm.quick.testlist and JPRT hotspot job. >> >> Thanks, >> >> Fred >> > From karen.kinnear at oracle.com Fri Mar 7 11:02:35 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 7 Mar 2014 14:02:35 -0500 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <53194DC8.1040502@oracle.com> References: <53189E79.90806@oracle.com> <53194DC8.1040502@oracle.com> Message-ID: <136C9819-8005-4DCB-88D1-73858E1591D7@oracle.com> Frederic, This looks great. And thank you so much. Questions for you: 1. os::read Yes we need to clean this up. Thank you for pointing that out. I am concerned that if we skip state transitions when making OS calls that can block, that we can possibly increase pause times trying to get to a safepoint, or possibly interfere with requests for thread suspension. I updated 6523731 to include this in our cleaning up our thread state transitions. 2. os::connect The change to RESTARTABLE confuses me. I expected to see the current two step handling in case of an EINTR (see 6343810 - at the very end it describes why this is Solaris-specific). Or are you removing that because this will only be used internally and in debug mode and not from the JDK soon? 3. jstat I didn't see this in your tested list - and I believe that the way this works is dynamic, so you are probably ok, but - since you removed perfcounters - what happens if your ~/.jvmstat/jstat_options was referencing this data? and you run jstat -options and then try to dump these options? David - I asked Frederic to put this flag in the obsolete_jvm_flags - that is our current deprecation mechanism - i.e. for all the flags we are deprecating in JDK9, they should have obsoleted_in: 9, accept_until: 10. So the mechanism isn't obsolete - it triggers a warning mechanism. We can rename it and rework it to not mention HSX, but we still need to deprecate product flags even without HSX. Can we remove really old entries? Yes. Should we keep flags in there that reference JDK9? I would prefer to keep those in for JDK9, so the information gets printed for customers about when the flag became obsolete. thanks, Karen On Mar 6, 2014, at 11:40 PM, David Holmes wrote: > Hi Fred, > > This looks good to me! Great to see the cleanup happen. > > os_solaris.cpp: > > This comment block seems redundant now: > > 5264 /* > 5265 * XXX: is the following call interruptible? If so, this might > 5266 * need to go through the INTERRUPT_IO() wrapper as for other > 5267 * blocking, interruptible calls in this file. > 5268 */ > > --- > > Aside: arguments.cpp - I guess we can file an RFE to get rid of obsolete_jvm_flags now that hsx is dead. ;-) > > Cheers, > David > > On 7/03/2014 2:12 AM, frederic parain wrote: >> Greetings, >> >> The UseVMInterruptibleIO flag removal has been >> scheduled a long time ago: >> https://bugs.openjdk.java.net/browse/JDK-4385444 >> >> Now, it's time to effectively remove this flag and >> its associated code. >> >> Removing this feature includes removing all the >> macros used to deal with interruptible I/Os, which >> could make the reading of the webrev hard and painful. >> I conservatively preserved the asserts that were >> inserted by the INTERRUPTIBLE macros, with one >> notable exception for os::read(). The original >> asserts checked that the current ThreadState >> was not _thread_in_native nor _thread_blocked. >> I changed it into an assert checking that the >> current thread state is _thread_in_vm. The >> rational for that is that the only real usage >> of os::read() on Solaris is in the >> ClassPathDirEntry::open_stream() method, which >> is always called with ThreadState ==_thread_in_vm. >> This change makes the TreadStateTransition simpler >> and avoid having to store the previous ThreadState. >> >> This choice could be revisited once the rules >> for ThreadStateTransition around system calls >> when ThreadState is _thread_in_vm are clarified >> (Solaris is currently the only platform doing >> this kind of transition for os::read()). >> >> The CR: >> https://bugs.openjdk.java.net/browse/JDK-8036128 >> >> The webrev: >> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >> >> Tested with vm.quick.testlist and JPRT hotspot job. >> >> Thanks, >> >> Fred >> From serguei.spitsyn at oracle.com Mon Mar 10 07:00:43 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 10 Mar 2014 00:00:43 -0700 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <53199213.5010708@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> Message-ID: <531D631B.3050708@oracle.com> Hi Axel, The webrev link does not work now. I'll check it again tomorrow. Thanks, Serguei On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote: > Hi Axel, > > Thank you for fixing this issue. > I'm reviewing it. > It looks good in general, but a little bit more time is needed to look > at the tests. > > Do you need a sponsor for pushing? > > Thanks, > Serguei > > > On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >> >> Hi all, >> >> could I have a review for the following change? >> >> The recursive lock count for an object is not correct, in cases, >> where a monitor is inflated after recursive lightweight locks. In >> this case, the recursion count is taken from the heavyweight monitor, >> represented by the class ObjectMonitor. ObjectMonitor::_recursions is >> the number of times ObjectMonitor::enter() was called to acquire the >> lock minus 1. This counter does not include the recursions of >> lightweight locks, that happen before inflating the monitor and is >> not equal to the recursion count from a Java source level point of view. >> >> I added a test to the webrev to reproduce the problem. >> >> The suggested fix is to call count_locked_objects, even if there's a >> heavyweight monitor and get the recursion count by iterating the vframes. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8036666 >> >> Webrev: >> >> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >> >> >> Thanks, >> >> Axel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic.parain at oracle.com Mon Mar 10 15:25:20 2014 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 10 Mar 2014 16:25:20 +0100 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <136C9819-8005-4DCB-88D1-73858E1591D7@oracle.com> References: <53189E79.90806@oracle.com> <53194DC8.1040502@oracle.com> <136C9819-8005-4DCB-88D1-73858E1591D7@oracle.com> Message-ID: <531DD960.9040004@oracle.com> Karen, my answers are in-lined below. On 07/03/2014 20:02, Karen Kinnear wrote: > Frederic, > > This looks great. And thank you so much. > > Questions for you: > > 1. os::read > Yes we need to clean this up. Thank you for pointing that out. > I am concerned that if we skip state transitions when making OS calls that can block, that > we can possibly increase pause times trying to get to a safepoint, or possibly interfere with > requests for thread suspension. I updated 6523731 to include this in our cleaning up our > thread state transitions. Thanks for updating the CR. > 2. os::connect > The change to RESTARTABLE confuses me. I expected to see the current two step handling > in case of an EINTR (see 6343810 - at the very end it describes why this is Solaris-specific). > Or are you removing that because this will only be used internally and in debug mode and not > from the JDK soon? Thank you for catching that. As far as I understand it, the two steps handling was there to support non-blocking sockets, which are not used by JVM code, and of the os::connect() is not used by JDK code anymore. However, I've restored the initial two-steps handling and added comments to explain the semantic of the different errno values. The previous behavior of os::connect() is now preserved. The new webrev is here: http://cr.openjdk.java.net/~fparain/8036128/webrev.01/ > 3. jstat > I didn't see this in your tested list - and I believe that the way this works is dynamic, so you are probably > ok, but - since you removed perfcounters > - what happens if your ~/.jvmstat/jstat_options was referencing this data? > and you run jstat -options and then try to dump these options? I tested with jcmd (jcmd PerfCounter.print ) and didn't noticed anything wrong. However, I don't how to use jvmstat/jstat to read performance counters. This feature is not documented in jstat web page: http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html Thanks, Fred > David - I asked Frederic to put this flag in the obsolete_jvm_flags - that is our current deprecation mechanism - > i.e. for all the flags we are deprecating in JDK9, they should have obsoleted_in: 9, accept_until: 10. So the mechanism isn't > obsolete - it triggers a warning mechanism. We can rename it and rework it to not mention HSX, but we still > need to deprecate product flags even without HSX. Can we remove really old entries? Yes. Should we keep flags in there > that reference JDK9? I would prefer to keep those in for JDK9, so the information gets printed for customers about > when the flag became obsolete. > > thanks, > Karen > > On Mar 6, 2014, at 11:40 PM, David Holmes wrote: > >> Hi Fred, >> >> This looks good to me! Great to see the cleanup happen. >> >> os_solaris.cpp: >> >> This comment block seems redundant now: >> >> 5264 /* >> 5265 * XXX: is the following call interruptible? If so, this might >> 5266 * need to go through the INTERRUPT_IO() wrapper as for other >> 5267 * blocking, interruptible calls in this file. >> 5268 */ >> >> --- >> >> Aside: arguments.cpp - I guess we can file an RFE to get rid of obsolete_jvm_flags now that hsx is dead. ;-) >> >> Cheers, >> David >> >> On 7/03/2014 2:12 AM, frederic parain wrote: >>> Greetings, >>> >>> The UseVMInterruptibleIO flag removal has been >>> scheduled a long time ago: >>> https://bugs.openjdk.java.net/browse/JDK-4385444 >>> >>> Now, it's time to effectively remove this flag and >>> its associated code. >>> >>> Removing this feature includes removing all the >>> macros used to deal with interruptible I/Os, which >>> could make the reading of the webrev hard and painful. >>> I conservatively preserved the asserts that were >>> inserted by the INTERRUPTIBLE macros, with one >>> notable exception for os::read(). The original >>> asserts checked that the current ThreadState >>> was not _thread_in_native nor _thread_blocked. >>> I changed it into an assert checking that the >>> current thread state is _thread_in_vm. The >>> rational for that is that the only real usage >>> of os::read() on Solaris is in the >>> ClassPathDirEntry::open_stream() method, which >>> is always called with ThreadState ==_thread_in_vm. >>> This change makes the TreadStateTransition simpler >>> and avoid having to store the previous ThreadState. >>> >>> This choice could be revisited once the rules >>> for ThreadStateTransition around system calls >>> when ThreadState is _thread_in_vm are clarified >>> (Solaris is currently the only platform doing >>> this kind of transition for os::read()). >>> >>> The CR: >>> https://bugs.openjdk.java.net/browse/JDK-8036128 >>> >>> The webrev: >>> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >>> >>> Tested with vm.quick.testlist and JPRT hotspot job. >>> >>> Thanks, >>> >>> Fred >>> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From zhengyu.gu at oracle.com Mon Mar 10 15:16:16 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 10 Mar 2014 11:16:16 -0400 Subject: RFR (S): JDK-8026154: [TESTBUG] runtime/CDSCompressedKPtrs/XShareAuto.java failed due to exception In-Reply-To: <531873B3.4010706@oracle.com> References: <531873B3.4010706@oracle.com> Message-ID: <375F7934-F3B4-4077-9C39-10D3EAB60CC8@oracle.com> Looks good to me. -Zhengyu On Mar 6, 2014, at 8:10 AM, Mikhailo Seledtsov wrote: > Please review this change that fixes several tests. > The issues addressed by this change have similar root cause, hence I have consolidated them under the umbrella of JDK-8026154 and hope to submit them as one change set. > > In detail, these changes are introduced to cover situation where mapping of the shared (CDS) archive into memory fails. Such situation is a random occurance, and is most likely due > to ASLR (Adress Space Layout Randomization). ASLR is a security feature managed by OS that randomizes the address where shared libraries are loaded; if the shared library is mapped > into the space intended for the CDS archive, the mapping of the archive will fail. With this change, these tests take such situation into account. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8026154 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8026154/webrev.00/ > Testing: > Exercises these tests on all standard platforms via JPRT -> PASS > Local testing with number of iterations, especially on Windows where ASLR > seems to be more aggressive From christian.tornqvist at oracle.com Mon Mar 10 15:41:48 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 10 Mar 2014 11:41:48 -0400 Subject: RFR (S): JDK-8026154: [TESTBUG] runtime/CDSCompressedKPtrs/XShareAuto.java failed due to exception In-Reply-To: <531873B3.4010706@oracle.com> References: <531873B3.4010706@oracle.com> Message-ID: <003001cf3c77$404210c0$c0c63240$@oracle.com> Looks good! Thanks for fixing this. Thanks, Christian -----Original Message----- From: hotspot-runtime-dev-bounces at openjdk.java.net [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Mikhailo Seledtsov Sent: Thursday, March 6, 2014 8:10 AM To: hotspot-runtime-dev Subject: RFR (S): JDK-8026154: [TESTBUG] runtime/CDSCompressedKPtrs/XShareAuto.java failed due to exception Please review this change that fixes several tests. The issues addressed by this change have similar root cause, hence I have consolidated them under the umbrella of JDK-8026154 and hope to submit them as one change set. In detail, these changes are introduced to cover situation where mapping of the shared (CDS) archive into memory fails. Such situation is a random occurance, and is most likely due to ASLR (Adress Space Layout Randomization). ASLR is a security feature managed by OS that randomizes the address where shared libraries are loaded; if the shared library is mapped into the space intended for the CDS archive, the mapping of the archive will fail. With this change, these tests take such situation into account. JBS: https://bugs.openjdk.java.net/browse/JDK-8026154 Webrev: http://cr.openjdk.java.net/~mseledtsov/8026154/webrev.00/ Testing: Exercises these tests on all standard platforms via JPRT -> PASS Local testing with number of iterations, especially on Windows where ASLR seems to be more aggressive From mikhailo.seledtsov at oracle.com Mon Mar 10 18:54:00 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 10 Mar 2014 14:54:00 -0400 Subject: RFR (S): JDK-8026154: [TESTBUG] runtime/CDSCompressedKPtrs/XShareAuto.java failed due to exception In-Reply-To: <003001cf3c77$404210c0$c0c63240$@oracle.com> References: <531873B3.4010706@oracle.com> <003001cf3c77$404210c0$c0c63240$@oracle.com> Message-ID: <531E0A48.106@oracle.com> Zhengyu, Christian, Thank you for the review. Misha On 3/10/2014 11:41 AM, Christian Tornqvist wrote: > Looks good! Thanks for fixing this. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev-bounces at openjdk.java.net > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Mikhailo > Seledtsov > Sent: Thursday, March 6, 2014 8:10 AM > To: hotspot-runtime-dev > Subject: RFR (S): JDK-8026154: [TESTBUG] > runtime/CDSCompressedKPtrs/XShareAuto.java failed due to exception > > Please review this change that fixes several tests. > The issues addressed by this change have similar root cause, hence I > have consolidated them under the umbrella of JDK-8026154 and hope to submit > them as one change set. > > In detail, these changes are introduced to cover situation where > mapping of the shared (CDS) archive into memory fails. Such situation is a > random occurance, and is most likely due > to ASLR (Adress Space Layout Randomization). ASLR is a security > feature managed by OS that randomizes the address where shared libraries are > loaded; if the shared library is mapped > into the space intended for the CDS archive, the mapping of the archive > will fail. With this change, these tests take such situation into account. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8026154 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8026154/webrev.00/ > Testing: > Exercises these tests on all standard platforms via JPRT -> PASS > Local testing with number of iterations, especially on Windows > where ASLR > seems to be more aggressive > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Mon Mar 10 19:01:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 10 Mar 2014 20:01:05 +0100 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <531DD960.9040004@oracle.com> References: <53189E79.90806@oracle.com> <53194DC8.1040502@oracle.com> <136C9819-8005-4DCB-88D1-73858E1591D7@oracle.com> <531DD960.9040004@oracle.com> Message-ID: <7809F4B1-9AD6-432A-905A-D50F3BC247BD@oracle.com> On 10 mar 2014, at 16:25, frederic parain wrote: > Karen, > > my answers are in-lined below. > > On 07/03/2014 20:02, Karen Kinnear wrote: >> Frederic, >> >> This looks great. And thank you so much. >> >> Questions for you: >> >> 1. os::read >> Yes we need to clean this up. Thank you for pointing that out. >> I am concerned that if we skip state transitions when making OS calls that can block, that >> we can possibly increase pause times trying to get to a safepoint, or possibly interfere with >> requests for thread suspension. I updated 6523731 to include this in our cleaning up our >> thread state transitions. > > Thanks for updating the CR. > >> 2. os::connect >> The change to RESTARTABLE confuses me. I expected to see the current two step handling >> in case of an EINTR (see 6343810 - at the very end it describes why this is Solaris-specific). >> Or are you removing that because this will only be used internally and in debug mode and not >> from the JDK soon? > > Thank you for catching that. As far as I understand it, the two steps > handling was there to support non-blocking sockets, which are not used > by JVM code, and of the os::connect() is not used by JDK code anymore. > However, I've restored the initial two-steps handling and added comments > to explain the semantic of the different errno values. The previous > behavior of os::connect() is now preserved. > The new webrev is here: > > http://cr.openjdk.java.net/~fparain/8036128/webrev.01/ > >> 3. jstat >> I didn't see this in your tested list - and I believe that the way this works is dynamic, so you are probably >> ok, but - since you removed perfcounters >> - what happens if your ~/.jvmstat/jstat_options was referencing this data? >> and you run jstat -options and then try to dump these options? > > I tested with jcmd (jcmd PerfCounter.print ) and didn't noticed > anything wrong. However, I don't how to use jvmstat/jstat to read > performance counters. This feature is not documented in jstat web > page: > > http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html Given that the counters that were removed are in the sun.* package, which according to the comment in perfData.hpp, is a "unstable, unsupported interface?, it should be ok to remove this without too much consideration. That you could create your own jstat_options file was news to me (you always learn something new!). I could find no references to this in the doc (as Fredric points out) and very, very few mentions in a Google search. I think we are fine here, too. Just for reference, if you want to list all perf counters with jstat, the incantation is ?jstat -J-Djstat.showUnsupported=true -snap ?. Thanks, /Staffan > > Thanks, > > Fred > >> David - I asked Frederic to put this flag in the obsolete_jvm_flags - that is our current deprecation mechanism - >> i.e. for all the flags we are deprecating in JDK9, they should have obsoleted_in: 9, accept_until: 10. So the mechanism isn't >> obsolete - it triggers a warning mechanism. We can rename it and rework it to not mention HSX, but we still >> need to deprecate product flags even without HSX. Can we remove really old entries? Yes. Should we keep flags in there >> that reference JDK9? I would prefer to keep those in for JDK9, so the information gets printed for customers about >> when the flag became obsolete. >> >> thanks, >> Karen >> >> On Mar 6, 2014, at 11:40 PM, David Holmes wrote: >> >>> Hi Fred, >>> >>> This looks good to me! Great to see the cleanup happen. >>> >>> os_solaris.cpp: >>> >>> This comment block seems redundant now: >>> >>> 5264 /* >>> 5265 * XXX: is the following call interruptible? If so, this might >>> 5266 * need to go through the INTERRUPT_IO() wrapper as for other >>> 5267 * blocking, interruptible calls in this file. >>> 5268 */ >>> >>> --- >>> >>> Aside: arguments.cpp - I guess we can file an RFE to get rid of obsolete_jvm_flags now that hsx is dead. ;-) >>> >>> Cheers, >>> David >>> >>> On 7/03/2014 2:12 AM, frederic parain wrote: >>>> Greetings, >>>> >>>> The UseVMInterruptibleIO flag removal has been >>>> scheduled a long time ago: >>>> https://bugs.openjdk.java.net/browse/JDK-4385444 >>>> >>>> Now, it's time to effectively remove this flag and >>>> its associated code. >>>> >>>> Removing this feature includes removing all the >>>> macros used to deal with interruptible I/Os, which >>>> could make the reading of the webrev hard and painful. >>>> I conservatively preserved the asserts that were >>>> inserted by the INTERRUPTIBLE macros, with one >>>> notable exception for os::read(). The original >>>> asserts checked that the current ThreadState >>>> was not _thread_in_native nor _thread_blocked. >>>> I changed it into an assert checking that the >>>> current thread state is _thread_in_vm. The >>>> rational for that is that the only real usage >>>> of os::read() on Solaris is in the >>>> ClassPathDirEntry::open_stream() method, which >>>> is always called with ThreadState ==_thread_in_vm. >>>> This change makes the TreadStateTransition simpler >>>> and avoid having to store the previous ThreadState. >>>> >>>> This choice could be revisited once the rules >>>> for ThreadStateTransition around system calls >>>> when ThreadState is _thread_in_vm are clarified >>>> (Solaris is currently the only platform doing >>>> this kind of transition for os::read()). >>>> >>>> The CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8036128 >>>> >>>> The webrev: >>>> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >>>> >>>> Tested with vm.quick.testlist and JPRT hotspot job. >>>> >>>> Thanks, >>>> >>>> Fred >>>> >> > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From serguei.spitsyn at oracle.com Tue Mar 11 08:50:37 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Mar 2014 01:50:37 -0700 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <531D631B.3050708@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> Message-ID: <531ECE5D.1070303@oracle.com> Hi Axel, The webrev link is resolvable now. Thank you for taking care about your broken account on the cr.openjdk server! I have some comments on the test case ... - This is nice test, thank you for providing it! - The location of the test must be different as it is a JVMTI test: test/serviceability/jvmti/8036666 instead of test/runtime/8036666 RecursiveObjectLock,java: - A suggestion to add a synchronized method (say, nestedLock3) into the chain of calls started from the testMethod. In order to do so, the class RecursiveObjectLock needs to extend the ALock class. And the this object needs to be used in the synchronized statements and for wait()? What do you think about such test enhancement for better coverage? GetObjectLockCount.java: - The comment line 283 seems to be obsolete as the "param out" is not present anymore: 283 * @param out Stream to copy to - Could you, please, add e.printStackTrace() into the catch statements at the lines 232 and 300? - A question: It seems the errThread and outThread are started a little bit late. Would it be better to start them earlier, or it was intentional? Some minor style-related comments (I hope, it is easy to fix this before push): - Unneeded extra empty lines: 149, 174-175, 244 - A space is missed before the '{': 180, 242, 243, 246 - Unneeded extra space after and before the "(": 235, 297 - The curly brackets '{' do not follow the common style: 142, 144 We still need another reviewer for this fix. I'm ready to be a sponsor for it. Thanks, Serguei On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com wrote: > Hi Axel, > > The webrev link does not work now. > I'll check it again tomorrow. > > Thanks, > Serguei > > On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote: >> Hi Axel, >> >> Thank you for fixing this issue. >> I'm reviewing it. >> It looks good in general, but a little bit more time is needed to >> look at the tests. >> >> Do you need a sponsor for pushing? >> >> Thanks, >> Serguei >> >> >> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>> >>> Hi all, >>> >>> could I have a review for the following change? >>> >>> The recursive lock count for an object is not correct, in cases, >>> where a monitor is inflated after recursive lightweight locks. In >>> this case, the recursion count is taken from the heavyweight >>> monitor, represented by the class ObjectMonitor. >>> ObjectMonitor::_recursions is the number of times >>> ObjectMonitor::enter() was called to acquire the lock minus 1. This >>> counter does not include the recursions of lightweight locks, that >>> happen before inflating the monitor and is not equal to the >>> recursion count from a Java source level point of view. >>> >>> I added a test to the webrev to reproduce the problem. >>> >>> The suggested fix is to call count_locked_objects, even if there's a >>> heavyweight monitor and get the recursion count by iterating the >>> vframes. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>> >>> >>> Thanks, >>> >>> Axel >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.siebenborn at sap.com Tue Mar 11 15:48:57 2014 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Tue, 11 Mar 2014 15:48:57 +0000 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <531ECE5D.1070303@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> Hi Seguei, I still can't upload files to the cr.openjdk server. Meanwhile, I use our server for the new webrev: http://www.sapjvm.com/as/webrevs/8036666/ Thanks, Axel Comments inline: On 11.03.2014 09:50, serguei.spitsyn at oracle.com wrote: > Hi Axel, > > The webrev link is resolvable now. > Thank you for taking care about your broken account on the cr.openjdk server! > > I have some comments on the test case ... > > - This is nice test, thank you for providing it! > > - The location of the test must be different as it is a JVMTI test: > test/serviceability/jvmti/8036666 instead of test/runtime/8036666 I moved the test. > > RecursiveObjectLock,java: > > - A suggestion to add a synchronized method (say, nestedLock3) into the chain > of calls started from the testMethod. In order to do so, the class RecursiveObjectLock > needs to extend the ALock class. And the this object needs to be used in the > synchronized statements and for wait()? > What do you think about such test enhancement for better coverage? In order to have a synchronized method in the call chain, I synchronize on the "this" object. > GetObjectLockCount.java: > > - The comment line 283 seems to be obsolete as the "param out" is not present anymore: > > 283 * @param out Stream to copy to > > > - Could you, please, add e.printStackTrace() into the catch statements at the lines 232 and 300? > > - A question: > It seems the errThread and outThread are started a little bit late. > Would it be better to start them earlier, or it was intentional? You're right! I moved to code up. > > Some minor style-related comments (I hope, it is easy to fix this before push): > - Unneeded extra empty lines: 149, 174-175, 244 > - A space is missed before the '{': 180, 242, 243, 246 > - Unneeded extra space after and before the "(": 235, 297 > - The curly brackets '{' do not follow the common style: 142, 144 > I hope I fixed them all and added no new style violations. Do you have a tool to check this? > > We still need another reviewer for this fix. > I'm ready to be a sponsor for it. > > Thanks, > Serguei > > > On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com wrote: >> Hi Axel, >> >> The webrev link does not work now. >> I'll check it again tomorrow. >> >> Thanks, >> Serguei >> >> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Axel, >>> >>> Thank you for fixing this issue. >>> I'm reviewing it. >>> It looks good in general, but a little bit more time is needed to look at the tests. >>> >>> Do you need a sponsor for pushing? >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>> >>>> Hi all, >>>> >>>> could I have a review for the following change? >>>> >>>> The recursive lock count for an object is not correct, in cases, where a monitor is inflated after recursive lightweight locks. In this case, the recursion count is taken from the heavyweight monitor, represented by the class ObjectMonitor. ObjectMonitor::_recursions is the number of times ObjectMonitor::enter() was called to acquire the lock minus 1. This counter does not include the recursions of lightweight locks, that happen before inflating the monitor and is not equal to the recursion count from a Java source level point of view. >>>> >>>> I added a test to the webrev to reproduce the problem. >>>> >>>> The suggested fix is to call count_locked_objects, even if there's a heavyweight monitor and get the recursion count by iterating the vframes. >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>> >>>> Thanks, >>>> >>>> Axel > From serguei.spitsyn at oracle.com Tue Mar 11 18:56:03 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Mar 2014 11:56:03 -0700 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> Message-ID: <531F5C43.8080008@oracle.com> On 3/11/14 8:48 AM, Siebenborn, Axel wrote: > Hi Seguei, > I still can't upload files to the cr.openjdk server. > Meanwhile, I use our server for the new webrev: > > http://www.sapjvm.com/as/webrevs/8036666/ Thank you for the update, Axel! It is almost there. A couple of comments below. > > Thanks, > Axel > > Comments inline: > > On 11.03.2014 09:50, serguei.spitsyn at oracle.com wrote: >> Hi Axel, >> >> The webrev link is resolvable now. >> Thank you for taking care about your broken account on the cr.openjdk server! >> >> I have some comments on the test case ... >> >> - This is nice test, thank you for providing it! >> >> - The location of the test must be different as it is a JVMTI test: >> test/serviceability/jvmti/8036666 instead of test/runtime/8036666 > I moved the test. > >> RecursiveObjectLock,java: >> >> - A suggestion to add a synchronized method (say, nestedLock3) into the chain >> of calls started from the testMethod. In order to do so, the class RecursiveObjectLock >> needs to extend the ALock class. And the this object needs to be used in the >> synchronized statements and for wait()? >> What do you think about such test enhancement for better coverage? > In order to have a synchronized method in the call chain, I synchronize on the "this" object. My suggestion was to additionally test a synchronized method like the nestedLock2 below: public void testMethod() { synchronized (this) { nestedLock1(); } } public void nestedLock1() { synchronized (this) { nestedLock2(); } } public synchronized void nestedLock2() { callWait(); } > >> GetObjectLockCount.java: >> >> - The comment line 283 seems to be obsolete as the "param out" is not present anymore: >> >> 283 * @param out Stream to copy to >> >> >> - Could you, please, add e.printStackTrace() into the catch statements at the lines 232 and 300? >> >> - A question: >> It seems the errThread and outThread are started a little bit late. >> Would it be better to start them earlier, or it was intentional? > You're right! I moved to code up. The following lines need to go up as well: 198 errThread.start(); 199 outThread.start(); > >> Some minor style-related comments (I hope, it is easy to fix this before push): >> - Unneeded extra empty lines: 149, 174-175, 244 >> - A space is missed before the '{': 180, 242, 243, 246 >> - Unneeded extra space after and before the "(": 235, 297 >> - The curly brackets '{' do not follow the common style: 142, 144 >> > I hope I fixed them all and added no new style violations. > Do you have a tool to check this? There is no tool for the style consistency. But it looks good. Thank you for fixing it! > >> We still need another reviewer for this fix. Still need another reviewer. Thanks, Serguei >> I'm ready to be a sponsor for it. >> >> Thanks, >> Serguei >> >> >> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Axel, >>> >>> The webrev link does not work now. >>> I'll check it again tomorrow. >>> >>> Thanks, >>> Serguei >>> >>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Axel, >>>> >>>> Thank you for fixing this issue. >>>> I'm reviewing it. >>>> It looks good in general, but a little bit more time is needed to look at the tests. >>>> >>>> Do you need a sponsor for pushing? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>> Hi all, >>>>> >>>>> could I have a review for the following change? >>>>> >>>>> The recursive lock count for an object is not correct, in cases, where a monitor is inflated after recursive lightweight locks. In this case, the recursion count is taken from the heavyweight monitor, represented by the class ObjectMonitor. ObjectMonitor::_recursions is the number of times ObjectMonitor::enter() was called to acquire the lock minus 1. This counter does not include the recursions of lightweight locks, that happen before inflating the monitor and is not equal to the recursion count from a Java source level point of view. >>>>> >>>>> I added a test to the webrev to reproduce the problem. >>>>> >>>>> The suggested fix is to call count_locked_objects, even if there's a heavyweight monitor and get the recursion count by iterating the vframes. >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>> >>>>> Thanks, >>>>> >>>>> Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Mar 11 19:05:52 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 11 Mar 2014 20:05:52 +0100 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> Message-ID: <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> On 11 mar 2014, at 16:48, Siebenborn, Axel wrote: > Hi Seguei, > I still can't upload files to the cr.openjdk server. > Meanwhile, I use our server for the new webrev: > > http://www.sapjvm.com/as/webrevs/8036666/ > > Thanks, > Axel > > Comments inline: > > On 11.03.2014 09:50, serguei.spitsyn at oracle.com wrote: >> Hi Axel, >> >> The webrev link is resolvable now. >> Thank you for taking care about your broken account on the cr.openjdk server! >> >> I have some comments on the test case ... >> >> - This is nice test, thank you for providing it! >> >> - The location of the test must be different as it is a JVMTI test: >> test/serviceability/jvmti/8036666 instead of test/runtime/8036666 > > I moved the test. Tests should avoid the bug number in the name or path and instead use a descriptive name. See this page for some background: https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests Thanks, /Staffan > >> >> RecursiveObjectLock,java: >> >> - A suggestion to add a synchronized method (say, nestedLock3) into the chain >> of calls started from the testMethod. In order to do so, the class RecursiveObjectLock >> needs to extend the ALock class. And the this object needs to be used in the >> synchronized statements and for wait()? >> What do you think about such test enhancement for better coverage? > > In order to have a synchronized method in the call chain, I synchronize on the "this" object. > >> GetObjectLockCount.java: >> >> - The comment line 283 seems to be obsolete as the "param out" is not present anymore: >> >> 283 * @param out Stream to copy to >> >> >> - Could you, please, add e.printStackTrace() into the catch statements at the lines 232 and 300? >> >> - A question: >> It seems the errThread and outThread are started a little bit late. >> Would it be better to start them earlier, or it was intentional? > > You're right! I moved to code up. > >> >> Some minor style-related comments (I hope, it is easy to fix this before push): >> - Unneeded extra empty lines: 149, 174-175, 244 >> - A space is missed before the '{': 180, 242, 243, 246 >> - Unneeded extra space after and before the "(": 235, 297 >> - The curly brackets '{' do not follow the common style: 142, 144 >> > > I hope I fixed them all and added no new style violations. > Do you have a tool to check this? > >> >> We still need another reviewer for this fix. >> I'm ready to be a sponsor for it. >> >> Thanks, >> Serguei >> >> >> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Axel, >>> >>> The webrev link does not work now. >>> I'll check it again tomorrow. >>> >>> Thanks, >>> Serguei >>> >>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Axel, >>>> >>>> Thank you for fixing this issue. >>>> I'm reviewing it. >>>> It looks good in general, but a little bit more time is needed to look at the tests. >>>> >>>> Do you need a sponsor for pushing? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>> >>>>> Hi all, >>>>> >>>>> could I have a review for the following change? >>>>> >>>>> The recursive lock count for an object is not correct, in cases, where a monitor is inflated after recursive lightweight locks. In this case, the recursion count is taken from the heavyweight monitor, represented by the class ObjectMonitor. ObjectMonitor::_recursions is the number of times ObjectMonitor::enter() was called to acquire the lock minus 1. This counter does not include the recursions of lightweight locks, that happen before inflating the monitor and is not equal to the recursion count from a Java source level point of view. >>>>> >>>>> I added a test to the webrev to reproduce the problem. >>>>> >>>>> The suggested fix is to call count_locked_objects, even if there's a heavyweight monitor and get the recursion count by iterating the vframes. >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>> >>>>> Thanks, >>>>> >>>>> Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Mar 11 19:25:23 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Mar 2014 12:25:23 -0700 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> Message-ID: <531F6323.1010109@oracle.com> On 3/11/14 12:05 PM, Staffan Larsen wrote: > > On 11 mar 2014, at 16:48, Siebenborn, Axel > wrote: > >> Hi Seguei, >> I still can't upload files to the cr.openjdk server. >> Meanwhile, I use our server for the new webrev: >> >> http://www.sapjvm.com/as/webrevs/8036666/ >> >> Thanks, >> Axel >> >> Comments inline: >> >> On 11.03.2014 09:50,serguei.spitsyn at oracle.com >> wrote: >>> Hi Axel, >>> >>> The webrev link is resolvable now. >>> Thank you for taking care about your broken account on the >>> cr.openjdk server! >>> >>> I have some comments on the test case ... >>> >>> - This is nice test, thank you for providing it! >>> >>> - The location of the test must be different as it is a JVMTI test: >>> test/serviceability/jvmti/8036666 instead of test/runtime/8036666 >> >> I moved the test. > > Tests should avoid the bug number in the name or path and instead use > a descriptive name. See this page for some background: > https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests The test files have already descriptive names. So, it would be enough to remove the bug number from the path. Sorry, I had to catch it too in the first place. Thanks, Serguei > > Thanks, > /Staffan > >> >>> >>> RecursiveObjectLock,java: >>> >>> - A suggestion to add a synchronized method (say, nestedLock3) into >>> the chain >>> of calls started from the testMethod. In order to do so, the >>> class RecursiveObjectLock >>> needs to extend the ALock class. And the this object needs to be >>> used in the >>> synchronized statements and for wait()? >>> What do you think about such test enhancement for better coverage? >> >> In order to have a synchronized method in the call chain, I >> synchronize on the "this" object. >> >>> GetObjectLockCount.java: >>> >>> - The comment line 283 seems to be obsolete as the "param out" is >>> not present anymore: >>> >>> 283 * @param out Stream to copy to >>> >>> >>> - Could you, please, add e.printStackTrace() into the catch >>> statements at the lines 232 and 300? >>> >>> - A question: >>> It seems the errThread and outThread are started a little bit >>> late. >>> Would it be better to start them earlier, or it was intentional? >> >> You're right! I moved to code up. >> >>> >>> Some minor style-related comments (I hope, it is easy to fix this >>> before push): >>> - Unneeded extra empty lines: 149, 174-175, 244 >>> - A space is missed before the '{': 180, 242, 243, 246 >>> - Unneeded extra space after and before the "(": 235, 297 >>> - The curly brackets '{' do not follow the common style: 142, 144 >>> >> >> I hope I fixed them all and added no new style violations. >> Do you have a tool to check this? >> >>> >>> We still need another reviewer for this fix. >>> I'm ready to be a sponsor for it. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com >>> wrote: >>>> Hi Axel, >>>> >>>> The webrev link does not work now. >>>> I'll check it again tomorrow. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com >>>> wrote: >>>>> Hi Axel, >>>>> >>>>> Thank you for fixing this issue. >>>>> I'm reviewing it. >>>>> It looks good in general, but a little bit more time is needed to >>>>> look at the tests. >>>>> >>>>> Do you need a sponsor for pushing? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> could I have a review for the following change? >>>>>> >>>>>> The recursive lock count for an object is not correct, in cases, >>>>>> where a monitor is inflated after recursive lightweight locks. In >>>>>> this case, the recursion count is taken from the heavyweight >>>>>> monitor, represented by the class ObjectMonitor. >>>>>> ObjectMonitor::_recursions is the number of times >>>>>> ObjectMonitor::enter() was called to acquire the lock minus 1. >>>>>> This counter does not include the recursions of lightweight >>>>>> locks, that happen before inflating the monitor and is not equal >>>>>> to the recursion count from a Java source level point of view. >>>>>> >>>>>> I added a test to the webrev to reproduce the problem. >>>>>> >>>>>> The suggested fix is to call count_locked_objects, even if >>>>>> there's a heavyweight monitor and get the recursion count by >>>>>> iterating the vframes. >>>>>> >>>>>> Bug: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>>> >>>>>> Webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Axel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.siebenborn at sap.com Wed Mar 12 15:21:41 2014 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Wed, 12 Mar 2014 15:21:41 +0000 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <531F6323.1010109@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> <531F6323.1010109@oracle.com> Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C39812EC9@DEWDFEMB20C.global.corp.sap> Hi Serguei, I created a new webrev: http://www.sapjvm.com/as/webrevs/8036666_1/ I incorporated your suggestions and moved the test files. Thanks, Axel On 11.03.2014 20:25, serguei.spitsyn at oracle.com wrote: > On 3/11/14 12:05 PM, Staffan Larsen wrote: >> >> On 11 mar 2014, at 16:48, Siebenborn, Axel > wrote: >>> Hi Seguei, >>> I still can't upload files to the cr.openjdk server. >>> Meanwhile, I use our server for the new webrev: >>> >>> http://www.sapjvm.com/as/webrevs/8036666/ >>> >>> Thanks, >>> Axel >>> >>> Comments inline: >>> >>> On 11.03.2014 09:50,serguei.spitsyn at oracle.com wrote: >>>> Hi Axel, >>>> >>>> The webrev link is resolvable now. >>>> Thank you for taking care about your broken account on the cr.openjdk server! >>>> >>>> I have some comments on the test case ... >>>> >>>> - This is nice test, thank you for providing it! >>>> >>>> - The location of the test must be different as it is a JVMTI test: >>>> test/serviceability/jvmti/8036666 instead of test/runtime/8036666 >>> >>> I moved the test. >> >> Tests should avoid the bug number in the name or path and instead use a descriptive name. See this page for some background: https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests > > The test files have already descriptive names. > So, it would be enough to remove the bug number from the path. > Sorry, I had to catch it too in the first place. > > Thanks, > Serguei >> >> Thanks, >> /Staffan >>>> >>>> RecursiveObjectLock,java: >>>> >>>> - A suggestion to add a synchronized method (say, nestedLock3) into the chain >>>> of calls started from the testMethod. In order to do so, the class RecursiveObjectLock >>>> needs to extend the ALock class. And the this object needs to be used in the >>>> synchronized statements and for wait()? >>>> What do you think about such test enhancement for better coverage? >>> >>> In order to have a synchronized method in the call chain, I synchronize on the "this" object. >>>> GetObjectLockCount.java: >>>> >>>> - The comment line 283 seems to be obsolete as the "param out" is not present anymore: >>>> >>>> 283 * @param out Stream to copy to >>>> >>>> >>>> - Could you, please, add e.printStackTrace() into the catch statements at the lines 232 and 300? >>>> >>>> - A question: >>>> It seems the errThread and outThread are started a little bit late. >>>> Would it be better to start them earlier, or it was intentional? >>> >>> You're right! I moved to code up. >>>> >>>> Some minor style-related comments (I hope, it is easy to fix this before push): >>>> - Unneeded extra empty lines: 149, 174-175, 244 >>>> - A space is missed before the '{': 180, 242, 243, 246 >>>> - Unneeded extra space after and before the "(": 235, 297 >>>> - The curly brackets '{' do not follow the common style: 142, 144 >>> >>> I hope I fixed them all and added no new style violations. >>> Do you have a tool to check this? >>>> >>>> We still need another reviewer for this fix. >>>> I'm ready to be a sponsor for it. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Axel, >>>>> >>>>> The webrev link does not work now. >>>>> I'll check it again tomorrow. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Axel, >>>>>> >>>>>> Thank you for fixing this issue. >>>>>> I'm reviewing it. >>>>>> It looks good in general, but a little bit more time is needed to look at the tests. >>>>>> >>>>>> Do you need a sponsor for pushing? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> could I have a review for the following change? >>>>>>> >>>>>>> The recursive lock count for an object is not correct, in cases, where a monitor is inflated after recursive lightweight locks. In this case, the recursion count is taken from the heavyweight monitor, represented by the class ObjectMonitor. ObjectMonitor::_recursions is the number of times ObjectMonitor::enter() was called to acquire the lock minus 1. This counter does not include the recursions of lightweight locks, that happen before inflating the monitor and is not equal to the recursion count from a Java source level point of view. >>>>>>> >>>>>>> I added a test to the webrev to reproduce the problem. >>>>>>> >>>>>>> The suggested fix is to call count_locked_objects, even if there's a heavyweight monitor and get the recursion count by iterating the vframes. >>>>>>> >>>>>>> Bug: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>>>> >>>>>>> Webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Axel > From serguei.spitsyn at oracle.com Wed Mar 12 17:34:02 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Mar 2014 10:34:02 -0700 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C39812EC9@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> <531F6323.1010109@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39812EC9@DEWDFEMB20C.global.corp.sap> Message-ID: <53209A8A.6070601@oracle.com> Hi Axel, Thank you for the changes! It looks good, but one more place need a fix (expected must be 4 now): 230 if (recursionCount != 4) { 231 throw new AssertionError("recursions: expected 3, but was " + recursionCount); 232 } Thanks, Serguei On 3/12/14 8:21 AM, Siebenborn, Axel wrote: > Hi Serguei, > I created a new webrev: > > http://www.sapjvm.com/as/webrevs/8036666_1/ > > I incorporated your suggestions and moved the test files. > > Thanks, > Axel > > > On 11.03.2014 20:25, serguei.spitsyn at oracle.com wrote: >> On 3/11/14 12:05 PM, Staffan Larsen wrote: >>> On 11 mar 2014, at 16:48, Siebenborn, Axel > wrote: >>>> Hi Seguei, >>>> I still can't upload files to the cr.openjdk server. >>>> Meanwhile, I use our server for the new webrev: >>>> >>>> http://www.sapjvm.com/as/webrevs/8036666/ >>>> >>>> Thanks, >>>> Axel >>>> >>>> Comments inline: >>>> >>>> On 11.03.2014 09:50,serguei.spitsyn at oracle.com wrote: >>>>> Hi Axel, >>>>> >>>>> The webrev link is resolvable now. >>>>> Thank you for taking care about your broken account on the cr.openjdk server! >>>>> >>>>> I have some comments on the test case ... >>>>> >>>>> - This is nice test, thank you for providing it! >>>>> >>>>> - The location of the test must be different as it is a JVMTI test: >>>>> test/serviceability/jvmti/8036666 instead of test/runtime/8036666 >>>> I moved the test. >>> Tests should avoid the bug number in the name or path and instead use a descriptive name. See this page for some background: https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests >> The test files have already descriptive names. >> So, it would be enough to remove the bug number from the path. >> Sorry, I had to catch it too in the first place. >> >> Thanks, >> Serguei >>> Thanks, >>> /Staffan >>>>> RecursiveObjectLock,java: >>>>> >>>>> - A suggestion to add a synchronized method (say, nestedLock3) into the chain >>>>> of calls started from the testMethod. In order to do so, the class RecursiveObjectLock >>>>> needs to extend the ALock class. And the this object needs to be used in the >>>>> synchronized statements and for wait()? >>>>> What do you think about such test enhancement for better coverage? >>>> In order to have a synchronized method in the call chain, I synchronize on the "this" object. >>>>> GetObjectLockCount.java: >>>>> >>>>> - The comment line 283 seems to be obsolete as the "param out" is not present anymore: >>>>> >>>>> 283 * @param out Stream to copy to >>>>> >>>>> >>>>> - Could you, please, add e.printStackTrace() into the catch statements at the lines 232 and 300? >>>>> >>>>> - A question: >>>>> It seems the errThread and outThread are started a little bit late. >>>>> Would it be better to start them earlier, or it was intentional? >>>> You're right! I moved to code up. >>>>> Some minor style-related comments (I hope, it is easy to fix this before push): >>>>> - Unneeded extra empty lines: 149, 174-175, 244 >>>>> - A space is missed before the '{': 180, 242, 243, 246 >>>>> - Unneeded extra space after and before the "(": 235, 297 >>>>> - The curly brackets '{' do not follow the common style: 142, 144 >>>> I hope I fixed them all and added no new style violations. >>>> Do you have a tool to check this? >>>>> We still need another reviewer for this fix. >>>>> I'm ready to be a sponsor for it. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Axel, >>>>>> >>>>>> The webrev link does not work now. >>>>>> I'll check it again tomorrow. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Axel, >>>>>>> >>>>>>> Thank you for fixing this issue. >>>>>>> I'm reviewing it. >>>>>>> It looks good in general, but a little bit more time is needed to look at the tests. >>>>>>> >>>>>>> Do you need a sponsor for pushing? >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> could I have a review for the following change? >>>>>>>> >>>>>>>> The recursive lock count for an object is not correct, in cases, where a monitor is inflated after recursive lightweight locks. In this case, the recursion count is taken from the heavyweight monitor, represented by the class ObjectMonitor. ObjectMonitor::_recursions is the number of times ObjectMonitor::enter() was called to acquire the lock minus 1. This counter does not include the recursions of lightweight locks, that happen before inflating the monitor and is not equal to the recursion count from a Java source level point of view. >>>>>>>> >>>>>>>> I added a test to the webrev to reproduce the problem. >>>>>>>> >>>>>>>> The suggested fix is to call count_locked_objects, even if there's a heavyweight monitor and get the recursion count by iterating the vframes. >>>>>>>> >>>>>>>> Bug: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.qi at oracle.com Wed Mar 12 21:52:22 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 12 Mar 2014 14:52:22 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell Message-ID: <5320D716.3030008@oracle.com> Hi, Can I have your codereview for this simple change: http://cr.openjdk.java.net/~minqi/6536943/webrev00/ Summary: Under non-interactive shell, -Xcheck:jni output warning for SIGINT, since non-interactive shells set SIGINT to SIG_IGN as part of the job control features. The fix is that don't check signal handlers if java run in a non-interactive shell. This applies to all platforms except for Windows. Thanks Yumin From yumin.qi at oracle.com Wed Mar 12 23:55:05 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 12 Mar 2014 16:55:05 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <5320D716.3030008@oracle.com> References: <5320D716.3030008@oracle.com> Message-ID: <5320F3D9.1000708@oracle.com> Forget to mention tests: JPRT test; manually testing on Java2Demo, for both shell and non-interactive shell. This is only disabling checking signal handlers under non-interactive shell, so no need to test more. Thanks Yumin On 3/12/2014 2:52 PM, Yumin Qi wrote: > Hi, Can I have your codereview for this simple change: > > http://cr.openjdk.java.net/~minqi/6536943/webrev00/ > > Summary: Under non-interactive shell, -Xcheck:jni output warning for > SIGINT, since non-interactive shells set SIGINT to SIG_IGN as part of > the job control features. The fix is that don't check signal handlers > if java run in a non-interactive shell. This applies to all platforms > except for Windows. > > Thanks > Yumin From david.holmes at oracle.com Thu Mar 13 05:08:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Mar 2014 15:08:05 +1000 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <5320F3D9.1000708@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> Message-ID: <53213D35.2080205@oracle.com> Hi Yumin, Not sure that disabling all signal checks because there is a problem with one signal is the right solution for this. That said I don't know what utility the signal checks provide in the first place. Can anyone comment on that? David On 13/03/2014 9:55 AM, Yumin Qi wrote: > Forget to mention tests: > JPRT test; > manually testing on Java2Demo, for both shell and non-interactive shell. > > This is only disabling checking signal handlers under non-interactive > shell, so no need to test more. > > Thanks > Yumin > > On 3/12/2014 2:52 PM, Yumin Qi wrote: >> Hi, Can I have your codereview for this simple change: >> >> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >> >> Summary: Under non-interactive shell, -Xcheck:jni output warning for >> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as part of >> the job control features. The fix is that don't check signal handlers >> if java run in a non-interactive shell. This applies to all platforms >> except for Windows. >> >> Thanks >> Yumin > From axel.siebenborn at sap.com Thu Mar 13 08:19:37 2014 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Thu, 13 Mar 2014 08:19:37 +0000 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <53209A8A.6070601@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> <531F6323.1010109@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39812EC9@DEWDFEMB20C.global.corp.sap> <53209A8A.6070601@oracle.com> Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C39813076@DEWDFEMB20C.global.corp.sap> Hi Serguei, new webrev: http://www.sapjvm.com/as/webrevs/8036666_2/ I should review my own changes more carefully. Sorry for that. Thanks, Axel On 12.03.2014 18:34, serguei.spitsyn at oracle.com wrote: > Hi Axel, > > Thank you for the changes! It looks good, but one more place need a > fix (expected must be 4 now): > > 230 if (recursionCount != 4) { 231 throw new > AssertionError("recursions: expected 3, but was " + recursionCount); > 232 } > > > Thanks, Serguei > > > On 3/12/14 8:21 AM, Siebenborn, Axel wrote: >> Hi Serguei, I created a new webrev: >> >> http://www.sapjvm.com/as/webrevs/8036666_1/ >> >> I incorporated your suggestions and moved the test files. >> >> Thanks, Axel >> >> >> On 11.03.2014 20:25, serguei.spitsyn at oracle.com wrote: >>> On 3/11/14 12:05 PM, Staffan Larsen wrote: >>>> On 11 mar 2014, at 16:48, Siebenborn, Axel >>>> > >>>> wrote: >>>>> Hi Seguei, I still can't upload files to the cr.openjdk >>>>> server. Meanwhile, I use our server for the new webrev: >>>>> >>>>> http://www.sapjvm.com/as/webrevs/8036666/ >>>>> >>>>> Thanks, Axel >>>>> >>>>> Comments inline: >>>>> >>>>> On 11.03.2014 09:50,serguei.spitsyn at oracle.com >>>>> wrote: >>>>>> Hi Axel, >>>>>> >>>>>> The webrev link is resolvable now. Thank you for taking >>>>>> care about your broken account on the cr.openjdk server! >>>>>> >>>>>> I have some comments on the test case ... >>>>>> >>>>>> - This is nice test, thank you for providing it! >>>>>> >>>>>> - The location of the test must be different as it is a >>>>>> JVMTI test: test/serviceability/jvmti/8036666 instead of >>>>>> test/runtime/8036666 >>>>> I moved the test. >>>> Tests should avoid the bug number in the name or path and >>>> instead use a descriptive name. See this page for some >>>> background: >>>> https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests >>> >>>> The test files have already descriptive names. >>> So, it would be enough to remove the bug number from the path. >>> Sorry, I had to catch it too in the first place. >>> >>> Thanks, Serguei >>>> Thanks, /Staffan >>>>>> RecursiveObjectLock,java: >>>>>> >>>>>> - A suggestion to add a synchronized method (say, >>>>>> nestedLock3) into the chain of calls started from the >>>>>> testMethod. In order to do so, the class >>>>>> RecursiveObjectLock needs to extend the ALock class. And >>>>>> the this object needs to be used in the synchronized >>>>>> statements and for wait()? What do you think about such >>>>>> test enhancement for better coverage? >>>>> In order to have a synchronized method in the call chain, I >>>>> synchronize on the "this" object. >>>>>> GetObjectLockCount.java: >>>>>> >>>>>> - The comment line 283 seems to be obsolete as the "param >>>>>> out" is not present anymore: >>>>>> >>>>>> 283 * @param out Stream to copy to >>>>>> >>>>>> >>>>>> - Could you, please, add e.printStackTrace() into the catch >>>>>> statements at the lines 232 and 300? >>>>>> >>>>>> - A question: It seems the errThread and outThread are >>>>>> started a little bit late. Would it be better to start them >>>>>> earlier, or it was intentional? >>>>> You're right! I moved to code up. >>>>>> Some minor style-related comments (I hope, it is easy to >>>>>> fix this before push): - Unneeded extra empty lines: >>>>>> 149, 174-175, 244 - A space is missed before the '{': >>>>>> 180, 242, 243, 246 - Unneeded extra space after and before >>>>>> the "(": 235, 297 - The curly brackets '{' do not follow >>>>>> the common style: 142, 144 >>>>> I hope I fixed them all and added no new style violations. Do >>>>> you have a tool to check this? >>>>>> We still need another reviewer for this fix. I'm ready to >>>>>> be a sponsor for it. >>>>>> >>>>>> Thanks, Serguei >>>>>> >>>>>> >>>>>> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>>> Hi Axel, >>>>>>> >>>>>>> The webrev link does not work now. I'll check it again >>>>>>> tomorrow. >>>>>>> >>>>>>> Thanks, Serguei >>>>>>> >>>>>>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com >>>>>>> wrote: >>>>>>>> Hi Axel, >>>>>>>> >>>>>>>> Thank you for fixing this issue. I'm reviewing it. It >>>>>>>> looks good in general, but a little bit more time is >>>>>>>> needed to look at the tests. >>>>>>>> >>>>>>>> Do you need a sponsor for pushing? >>>>>>>> >>>>>>>> Thanks, Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> could I have a review for the following change? >>>>>>>>> >>>>>>>>> The recursive lock count for an object is not >>>>>>>>> correct, in cases, where a monitor is inflated after >>>>>>>>> recursive lightweight locks. In this case, the >>>>>>>>> recursion count is taken from the heavyweight >>>>>>>>> monitor, represented by the class ObjectMonitor. >>>>>>>>> ObjectMonitor::_recursions is the number of times >>>>>>>>> ObjectMonitor::enter() was called to acquire the lock >>>>>>>>> minus 1. This counter does not include the recursions >>>>>>>>> of lightweight locks, that happen before inflating >>>>>>>>> the monitor and is not equal to the recursion count >>>>>>>>> from a Java source level point of view. >>>>>>>>> >>>>>>>>> I added a test to the webrev to reproduce the >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> The suggested fix is to call count_locked_objects, >>>>>>>>> even if there's a heavyweight monitor and get the >>>>>>>>> recursion count by iterating the vframes. >>>>>>>>> >>>>>>>>> Bug: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Axel > > From dmitry.samersoff at oracle.com Thu Mar 13 13:05:54 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 13 Mar 2014 17:05:54 +0400 Subject: RR(S, TEST) JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux Message-ID: <5321AD32.7010107@oracle.com> Hi Everyone, Please review test-only fix: JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux The test has it's own java launcher. This launcher compiles against $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java. Also I'd changed the test to use variables from test_env.sh -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Mar 13 13:28:07 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 13 Mar 2014 17:28:07 +0400 Subject: RR(S, TEST) JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux Message-ID: <5321B267.1010904@oracle.com> Hi Everyone, Please review test-only fix: JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux http://cr.openjdk.java.net/~dsamersoff/JDK-8037279/webrev.01/ The test has it's own java launcher. This launcher compiles against $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java. Also I'd changed the test to use variables from test_env.sh -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Mar 13 13:30:50 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 13 Mar 2014 17:30:50 +0400 Subject: RR(S, TEST) JDK-8029139: [TESTBUG] runtime/InitialThreadOverflow/testme.sh fails with exit code 127 Message-ID: <5321B30A.6010205@oracle.com> Hi Everyone, Please review test-only fix: JDK-8029139: [TESTBUG] runtime/InitialThreadOverflow/testme.sh fails with exit code 127 http://cr.openjdk.java.net/~dsamersoff/JDK-8029139/webrev.01/ The test has it's own java launcher. This launcher compiles against $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java. Also I'd changed the test to be C not C++ as C compilation seems to be more reliable on test hosts. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yumin.qi at oracle.com Thu Mar 13 15:19:36 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 13 Mar 2014 08:19:36 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53213D35.2080205@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> Message-ID: <5321CC88.3040401@oracle.com> On 3/12/2014 10:08 PM, David Holmes wrote: > Hi Yumin, > > Not sure that disabling all signal checks because there is a problem > with one signal is the right solution for this. > Or we check if the signal is SIGINT --- skip it only. Thanks Yumin > That said I don't know what utility the signal checks provide in the > first place. Can anyone comment on that? > > David > > On 13/03/2014 9:55 AM, Yumin Qi wrote: >> Forget to mention tests: >> JPRT test; >> manually testing on Java2Demo, for both shell and non-interactive shell. >> >> This is only disabling checking signal handlers under non-interactive >> shell, so no need to test more. >> >> Thanks >> Yumin >> >> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>> Hi, Can I have your codereview for this simple change: >>> >>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>> >>> Summary: Under non-interactive shell, -Xcheck:jni output warning for >>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as part of >>> the job control features. The fix is that don't check signal handlers >>> if java run in a non-interactive shell. This applies to all platforms >>> except for Windows. >>> >>> Thanks >>> Yumin >> From karen.kinnear at oracle.com Thu Mar 13 16:31:56 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 13 Mar 2014 12:31:56 -0400 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <531DD960.9040004@oracle.com> References: <53189E79.90806@oracle.com> <53194DC8.1040502@oracle.com> <136C9819-8005-4DCB-88D1-73858E1591D7@oracle.com> <531DD960.9040004@oracle.com> Message-ID: <7048B67F-02C6-4F15-A7D5-21E9DC64E2CB@oracle.com> Frederic, The updated webrev looks great - and now that Michael McMahon has retested Solaris 10 to find out that we still have this behavior - we still need the os::connect changes. Could you add one comment to that code please, perhaps the one currently in PlainSocketImp.c - which references the 6343810 bug and the fact that this occurs for blocking sockets for Solaris 10 still. I don't need to re-review. Based on your testing and Staffan's comments, sounds like we are good with jstat - since we didn't document how to extend your options. If anyone wants to know how to do that, I have a description and a sample file. So - all set - and many thanks, Karen On Mar 10, 2014, at 11:25 AM, frederic parain wrote: > Karen, > > my answers are in-lined below. > > On 07/03/2014 20:02, Karen Kinnear wrote: >> Frederic, >> >> This looks great. And thank you so much. >> >> 2. os::connect >> The change to RESTARTABLE confuses me. I expected to see the current two step handling >> in case of an EINTR (see 6343810 - at the very end it describes why this is Solaris-specific). >> Or are you removing that because this will only be used internally and in debug mode and not >> from the JDK soon? > > Thank you for catching that. As far as I understand it, the two steps > handling was there to support non-blocking sockets, which are not used > by JVM code, and of the os::connect() is not used by JDK code anymore. > However, I've restored the initial two-steps handling and added comments > to explain the semantic of the different errno values. The previous > behavior of os::connect() is now preserved. > The new webrev is here: > > http://cr.openjdk.java.net/~fparain/8036128/webrev.01/ > >> 3. jstat >> I didn't see this in your tested list - and I believe that the way this works is dynamic, so you are probably >> ok, but - since you removed perfcounters >> - what happens if your ~/.jvmstat/jstat_options was referencing this data? >> and you run jstat -options and then try to dump these options? > > I tested with jcmd (jcmd PerfCounter.print ) and didn't noticed > anything wrong. However, I don't how to use jvmstat/jstat to read > performance counters. This feature is not documented in jstat web > page: > > http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html > > Thanks, > > Fred > >> David - I asked Frederic to put this flag in the obsolete_jvm_flags - that is our current deprecation mechanism - >> i.e. for all the flags we are deprecating in JDK9, they should have obsoleted_in: 9, accept_until: 10. So the mechanism isn't >> obsolete - it triggers a warning mechanism. We can rename it and rework it to not mention HSX, but we still >> need to deprecate product flags even without HSX. Can we remove really old entries? Yes. Should we keep flags in there >> that reference JDK9? I would prefer to keep those in for JDK9, so the information gets printed for customers about >> when the flag became obsolete. >> >> thanks, >> Karen >> >> On Mar 6, 2014, at 11:40 PM, David Holmes wrote: >> >>> Hi Fred, >>> >>> This looks good to me! Great to see the cleanup happen. >>> >>> os_solaris.cpp: >>> >>> This comment block seems redundant now: >>> >>> 5264 /* >>> 5265 * XXX: is the following call interruptible? If so, this might >>> 5266 * need to go through the INTERRUPT_IO() wrapper as for other >>> 5267 * blocking, interruptible calls in this file. >>> 5268 */ >>> >>> --- >>> >>> Aside: arguments.cpp - I guess we can file an RFE to get rid of obsolete_jvm_flags now that hsx is dead. ;-) >>> >>> Cheers, >>> David >>> >>> On 7/03/2014 2:12 AM, frederic parain wrote: >>>> Greetings, >>>> >>>> The UseVMInterruptibleIO flag removal has been >>>> scheduled a long time ago: >>>> https://bugs.openjdk.java.net/browse/JDK-4385444 >>>> >>>> Now, it's time to effectively remove this flag and >>>> its associated code. >>>> >>>> Removing this feature includes removing all the >>>> macros used to deal with interruptible I/Os, which >>>> could make the reading of the webrev hard and painful. >>>> I conservatively preserved the asserts that were >>>> inserted by the INTERRUPTIBLE macros, with one >>>> notable exception for os::read(). The original >>>> asserts checked that the current ThreadState >>>> was not _thread_in_native nor _thread_blocked. >>>> I changed it into an assert checking that the >>>> current thread state is _thread_in_vm. The >>>> rational for that is that the only real usage >>>> of os::read() on Solaris is in the >>>> ClassPathDirEntry::open_stream() method, which >>>> is always called with ThreadState ==_thread_in_vm. >>>> This change makes the TreadStateTransition simpler >>>> and avoid having to store the previous ThreadState. >>>> >>>> This choice could be revisited once the rules >>>> for ThreadStateTransition around system calls >>>> when ThreadState is _thread_in_vm are clarified >>>> (Solaris is currently the only platform doing >>>> this kind of transition for os::read()). >>>> >>>> The CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8036128 >>>> >>>> The webrev: >>>> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >>>> >>>> Tested with vm.quick.testlist and JPRT hotspot job. >>>> >>>> Thanks, >>>> >>>> Fred >>>> >> > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From yumin.qi at oracle.com Thu Mar 13 21:27:41 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 13 Mar 2014 14:27:41 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <5321CC88.3040401@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> Message-ID: <532222CD.7070504@oracle.com> David and all, I have changed to skip SIGINT only if run in a non-interactive shell. Please check webrev: http://cr.openjdk.java.net/~minqi/6536943/webrev01/ Thanks Yumin On 3/13/2014 8:19 AM, Yumin Qi wrote: > On 3/12/2014 10:08 PM, David Holmes wrote: >> Hi Yumin, >> >> Not sure that disabling all signal checks because there is a problem >> with one signal is the right solution for this. >> > Or we check if the signal is SIGINT --- skip it only. > > Thanks > Yumin >> That said I don't know what utility the signal checks provide in the >> first place. Can anyone comment on that? >> >> David >> >> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>> Forget to mention tests: >>> JPRT test; >>> manually testing on Java2Demo, for both shell and non-interactive >>> shell. >>> >>> This is only disabling checking signal handlers under non-interactive >>> shell, so no need to test more. >>> >>> Thanks >>> Yumin >>> >>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>> Hi, Can I have your codereview for this simple change: >>>> >>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>> >>>> Summary: Under non-interactive shell, -Xcheck:jni output warning for >>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as part of >>>> the job control features. The fix is that don't check signal handlers >>>> if java run in a non-interactive shell. This applies to all platforms >>>> except for Windows. >>>> >>>> Thanks >>>> Yumin >>> > From serguei.spitsyn at oracle.com Thu Mar 13 22:08:43 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 13 Mar 2014 15:08:43 -0700 Subject: RR(S, TEST) JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux In-Reply-To: <5321B267.1010904@oracle.com> References: <5321B267.1010904@oracle.com> Message-ID: <53222C6B.9070907@oracle.com> Hi Dmitry, The fix looks good and seems to be a nice cleanup. Do you see this test always failing without your fix? It is not clear if it fixes the original issue. But this step seems to be in the right direction anyway. Thanks, Serguei On 3/13/14 6:28 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review test-only fix: > > JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux > > http://cr.openjdk.java.net/~dsamersoff/JDK-8037279/webrev.01/ > > The test has it's own java launcher. This launcher compiles against > $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java. > > Also I'd changed the test to use variables from test_env.sh > > -Dmitry > From serguei.spitsyn at oracle.com Thu Mar 13 22:13:24 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 13 Mar 2014 15:13:24 -0700 Subject: RR(S, TEST) JDK-8029139: [TESTBUG] runtime/InitialThreadOverflow/testme.sh fails with exit code 127 In-Reply-To: <5321B30A.6010205@oracle.com> References: <5321B30A.6010205@oracle.com> Message-ID: <53222D84.6010807@oracle.com> Look good. Thanks, Serguei On 3/13/14 6:30 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review test-only fix: > > JDK-8029139: [TESTBUG] runtime/InitialThreadOverflow/testme.sh fails > with exit code 127 > > http://cr.openjdk.java.net/~dsamersoff/JDK-8029139/webrev.01/ > > The test has it's own java launcher. This launcher compiles against > $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java. > > Also I'd changed the test to be C not C++ as C compilation seems to be > more reliable on test hosts. > > -Dmitry > From dean.long at oracle.com Thu Mar 13 22:28:09 2014 From: dean.long at oracle.com (Dean Long) Date: Thu, 13 Mar 2014 15:28:09 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <532222CD.7070504@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> Message-ID: <532230F9.9090305@oracle.com> (isatty(fileno(stdin)) || sig != SIGINT) You might want to reverse that: (sig != SIGINT || isatty(fileno(stdin))) because isatty() could be expensive. dl On 3/13/2014 2:27 PM, Yumin Qi wrote: > David and all, > > I have changed to skip SIGINT only if run in a non-interactive > shell. Please check webrev: > > http://cr.openjdk.java.net/~minqi/6536943/webrev01/ > > Thanks > Yumin > > On 3/13/2014 8:19 AM, Yumin Qi wrote: >> On 3/12/2014 10:08 PM, David Holmes wrote: >>> Hi Yumin, >>> >>> Not sure that disabling all signal checks because there is a problem >>> with one signal is the right solution for this. >>> >> Or we check if the signal is SIGINT --- skip it only. >> >> Thanks >> Yumin >>> That said I don't know what utility the signal checks provide in the >>> first place. Can anyone comment on that? >>> >>> David >>> >>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>> Forget to mention tests: >>>> JPRT test; >>>> manually testing on Java2Demo, for both shell and non-interactive >>>> shell. >>>> >>>> This is only disabling checking signal handlers under non-interactive >>>> shell, so no need to test more. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>> Hi, Can I have your codereview for this simple change: >>>>> >>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>> >>>>> Summary: Under non-interactive shell, -Xcheck:jni output warning for >>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as part of >>>>> the job control features. The fix is that don't check signal handlers >>>>> if java run in a non-interactive shell. This applies to all platforms >>>>> except for Windows. >>>>> >>>>> Thanks >>>>> Yumin >>>> >> > From yumin.qi at oracle.com Thu Mar 13 23:10:45 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 13 Mar 2014 16:10:45 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <532230F9.9090305@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> Message-ID: <53223AF5.1000007@oracle.com> Thanks for review. I will change the order. Yumin On 3/13/2014 3:28 PM, Dean Long wrote: > (isatty(fileno(stdin)) || sig != SIGINT) > > You might want to reverse that: > > (sig != SIGINT || isatty(fileno(stdin))) > > because isatty() could be expensive. > > dl > > > On 3/13/2014 2:27 PM, Yumin Qi wrote: >> David and all, >> >> I have changed to skip SIGINT only if run in a non-interactive >> shell. Please check webrev: >> >> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >> >> Thanks >> Yumin >> >> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>> Hi Yumin, >>>> >>>> Not sure that disabling all signal checks because there is a >>>> problem with one signal is the right solution for this. >>>> >>> Or we check if the signal is SIGINT --- skip it only. >>> >>> Thanks >>> Yumin >>>> That said I don't know what utility the signal checks provide in >>>> the first place. Can anyone comment on that? >>>> >>>> David >>>> >>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>> Forget to mention tests: >>>>> JPRT test; >>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>> shell. >>>>> >>>>> This is only disabling checking signal handlers under non-interactive >>>>> shell, so no need to test more. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>> Hi, Can I have your codereview for this simple change: >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>> >>>>>> Summary: Under non-interactive shell, -Xcheck:jni output warning >>>>>> for >>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>> part of >>>>>> the job control features. The fix is that don't check signal >>>>>> handlers >>>>>> if java run in a non-interactive shell. This applies to all >>>>>> platforms >>>>>> except for Windows. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>> >>> >> > From yumin.qi at oracle.com Fri Mar 14 04:18:28 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 13 Mar 2014 21:18:28 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53223AF5.1000007@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> Message-ID: <53228314.2020409@oracle.com> Have changed, new URL at: http://cr.openjdk.java.net/~minqi/6536943/webrev02 Thanks Yumin On 3/13/2014 4:10 PM, Yumin Qi wrote: > Thanks for review. I will change the order. > > Yumin > > On 3/13/2014 3:28 PM, Dean Long wrote: >> (isatty(fileno(stdin)) || sig != SIGINT) >> >> You might want to reverse that: >> >> (sig != SIGINT || isatty(fileno(stdin))) >> >> because isatty() could be expensive. >> >> dl >> >> >> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>> David and all, >>> >>> I have changed to skip SIGINT only if run in a non-interactive >>> shell. Please check webrev: >>> >>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>> >>> Thanks >>> Yumin >>> >>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>> Hi Yumin, >>>>> >>>>> Not sure that disabling all signal checks because there is a >>>>> problem with one signal is the right solution for this. >>>>> >>>> Or we check if the signal is SIGINT --- skip it only. >>>> >>>> Thanks >>>> Yumin >>>>> That said I don't know what utility the signal checks provide in >>>>> the first place. Can anyone comment on that? >>>>> >>>>> David >>>>> >>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>> Forget to mention tests: >>>>>> JPRT test; >>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>> shell. >>>>>> >>>>>> This is only disabling checking signal handlers under >>>>>> non-interactive >>>>>> shell, so no need to test more. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>> >>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>> warning for >>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>> part of >>>>>>> the job control features. The fix is that don't check signal >>>>>>> handlers >>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>> platforms >>>>>>> except for Windows. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>> >>>> >>> >> > From david.holmes at oracle.com Fri Mar 14 05:02:57 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Mar 2014 15:02:57 +1000 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53228314.2020409@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> Message-ID: <53228D81.2070207@oracle.com> On 14/03/2014 2:18 PM, Yumin Qi wrote: > Have changed, new URL at: > http://cr.openjdk.java.net/~minqi/6536943/webrev02 Thanks I agree with the new logic. However I can't comment on whether isatty actually tests for the desired condition. David > Thanks > Yumin > > On 3/13/2014 4:10 PM, Yumin Qi wrote: >> Thanks for review. I will change the order. >> >> Yumin >> >> On 3/13/2014 3:28 PM, Dean Long wrote: >>> (isatty(fileno(stdin)) || sig != SIGINT) >>> >>> You might want to reverse that: >>> >>> (sig != SIGINT || isatty(fileno(stdin))) >>> >>> because isatty() could be expensive. >>> >>> dl >>> >>> >>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>> David and all, >>>> >>>> I have changed to skip SIGINT only if run in a non-interactive >>>> shell. Please check webrev: >>>> >>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> Not sure that disabling all signal checks because there is a >>>>>> problem with one signal is the right solution for this. >>>>>> >>>>> Or we check if the signal is SIGINT --- skip it only. >>>>> >>>>> Thanks >>>>> Yumin >>>>>> That said I don't know what utility the signal checks provide in >>>>>> the first place. Can anyone comment on that? >>>>>> >>>>>> David >>>>>> >>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>> Forget to mention tests: >>>>>>> JPRT test; >>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>> shell. >>>>>>> >>>>>>> This is only disabling checking signal handlers under >>>>>>> non-interactive >>>>>>> shell, so no need to test more. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>> >>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>> warning for >>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>> part of >>>>>>>> the job control features. The fix is that don't check signal >>>>>>>> handlers >>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>> platforms >>>>>>>> except for Windows. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>> >>>>> >>>> >>> >> > From dmitry.samersoff at oracle.com Fri Mar 14 08:40:14 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Mar 2014 12:40:14 +0400 Subject: RR(S, TEST) JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux In-Reply-To: <53222C6B.9070907@oracle.com> References: <5321B267.1010904@oracle.com> <53222C6B.9070907@oracle.com> Message-ID: <5322C06E.3070203@oracle.com> Serguei, Thank you for review. On 2014-03-14 02:08, serguei.spitsyn at oracle.com wrote: > The fix looks good and seems to be a nice cleanup. > > Do you see this test always failing without your fix? It's always testing COMPILEJAVA not TESTJAVA so if both points to the same image - test works as expected, if not - test result is not predictable. > It is not clear if it fixes the original issue. > But this step seems to be in the right direction anyway. Yes, I'm not sure it the root of crash. But it's better to fix it. -Dmitry > > Thanks, > Serguei > > > On 3/13/14 6:28 AM, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review test-only fix: >> >> JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8037279/webrev.01/ >> >> The test has it's own java launcher. This launcher compiles against >> $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java. >> >> Also I'd changed the test to use variables from test_env.sh >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From markus.gronlund at oracle.com Fri Mar 14 09:22:23 2014 From: markus.gronlund at oracle.com (Markus Gr?nlund) Date: Fri, 14 Mar 2014 02:22:23 -0700 (PDT) Subject: RFR(S): 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility Message-ID: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> Greetings, Kindly asking for reviews for the following changeset: 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8037340 Previously, unpackTime() was used to calculate the absolute time value for passing to sem_timedwait() for waiting on a Semaphore. UnpackTime() has been updated to be based on CLOCK_MONOTONIC which does not work for Semaphores, which are always associated with CLOCK_REALTIME. http://linux.die.net/man/3/sem_timedwait Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Mar 14 09:43:07 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Mar 2014 19:43:07 +1000 Subject: RFR(S): 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility In-Reply-To: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> References: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> Message-ID: <5322CF2B.6070507@oracle.com> Hi Markus, This seems excessively complicated. There is no need to completely duplicate unpackTime the way you have (now we have three methods doing almost the same thing!). clock_gettime availability just shouldn't be an issue these days on our supported platforms, and in any case tying it to supports_monotonic_clock is just misleading as you may have clock_gettime but not a monotonic clock (unlikely but possible). If you are really paranoid about clock_gettime then just use gettimeofday and be done with it. Further if you insisted on taking this approach change the signature to take secs and nsecs as it is pointless converting them to a single nsecs in the caller only to break them back into separate secs and nsecs inside the method! Or if you really feel strongly about this form then change the signature to take the clock as an argument - with a default parameter providing CLOCK_MONOTONIC. But I stick by what I suggested in the bug report. Just use clock_gettime on CLOCK_REALTIME. David On 14/03/2014 7:22 PM, Markus Gr?nlund wrote: > Greetings, > > Kindly asking for reviews for the following changeset: > > 8037340: Linux semaphores are associated with CLOCK_REALTIME and need > relative to absolute time conversion utility > > Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037340 > > Previously, unpackTime() was used to calculate the absolute time value > for passing to sem_timedwait() for waiting on a Semaphore. > > UnpackTime() has been updated to be based on CLOCK_MONOTONIC which does > not work for Semaphores, which are always associated with CLOCK_REALTIME. > > http://linux.die.net/man/3/sem_timedwait > > Thanks > > Markus > From markus.gronlund at oracle.com Fri Mar 14 11:12:11 2014 From: markus.gronlund at oracle.com (Markus Gr?nlund) Date: Fri, 14 Mar 2014 04:12:11 -0700 (PDT) Subject: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME In-Reply-To: <5322CF2B.6070507@oracle.com> References: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> <5322CF2B.6070507@oracle.com> Message-ID: <19f64639-c9cc-48db-be06-4ef760e3e9ba@default> Updated: http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ /Markus -----Original Message----- From: David Holmes Sent: den 14 mars 2014 10:43 To: Markus Gr?nlund; serviceability-dev at openjdk.net; hotspot-runtime-dev Subject: Re: RFR(S): 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility Hi Markus, This seems excessively complicated. There is no need to completely duplicate unpackTime the way you have (now we have three methods doing almost the same thing!). clock_gettime availability just shouldn't be an issue these days on our supported platforms, and in any case tying it to supports_monotonic_clock is just misleading as you may have clock_gettime but not a monotonic clock (unlikely but possible). If you are really paranoid about clock_gettime then just use gettimeofday and be done with it. Further if you insisted on taking this approach change the signature to take secs and nsecs as it is pointless converting them to a single nsecs in the caller only to break them back into separate secs and nsecs inside the method! Or if you really feel strongly about this form then change the signature to take the clock as an argument - with a default parameter providing CLOCK_MONOTONIC. But I stick by what I suggested in the bug report. Just use clock_gettime on CLOCK_REALTIME. David On 14/03/2014 7:22 PM, Markus Gr?nlund wrote: > Greetings, > > Kindly asking for reviews for the following changeset: > > 8037340: Linux semaphores are associated with CLOCK_REALTIME and need > relative to absolute time conversion utility > > Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037340 > > Previously, unpackTime() was used to calculate the absolute time value > for passing to sem_timedwait() for waiting on a Semaphore. > > UnpackTime() has been updated to be based on CLOCK_MONOTONIC which > does not work for Semaphores, which are always associated with CLOCK_REALTIME. > > http://linux.die.net/man/3/sem_timedwait > > Thanks > > Markus > From frederic.parain at oracle.com Fri Mar 14 12:05:55 2014 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 14 Mar 2014 13:05:55 +0100 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <531A0486.9030108@oracle.com> References: <53189E79.90806@oracle.com> <531A01E2.4020105@oracle.com> <531A0486.9030108@oracle.com> Message-ID: <5322F0A3.10608@oracle.com> Dan, Coleen, Thank you for the review. Fred On 07/03/2014 18:40, Coleen Phillimore wrote: > > I agree. This looks great. Thank you for doing this! > Coleen > > On 3/7/14 12:29 PM, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >> >> src/share/vm/runtime/globals.hpp >> No comments. >> >> src/share/vm/runtime/arguments.cpp >> No comments. >> >> src/os/solaris/vm/os_solaris.hpp >> No comments. >> >> src/os/solaris/vm/os_solaris.inline.hpp >> No comments. >> >> src/os/solaris/vm/osThread_solaris.hpp >> No comments. >> >> src/os/solaris/vm/os_solaris.cpp >> No comments other than it looks so much cleaner now! >> >> src/os/solaris/vm/osThread_solaris.cpp >> No comments. >> >> src/share/vm/services/runtimeService.hpp >> No comments. >> >> src/share/vm/services/runtimeService.cpp >> No comments. >> >> Nicely done! Thumbs up! >> >> Dan >> >> >> On 3/6/14 9:12 AM, frederic parain wrote: >>> Greetings, >>> >>> The UseVMInterruptibleIO flag removal has been >>> scheduled a long time ago: >>> https://bugs.openjdk.java.net/browse/JDK-4385444 >>> >>> Now, it's time to effectively remove this flag and >>> its associated code. >>> >>> Removing this feature includes removing all the >>> macros used to deal with interruptible I/Os, which >>> could make the reading of the webrev hard and painful. >>> I conservatively preserved the asserts that were >>> inserted by the INTERRUPTIBLE macros, with one >>> notable exception for os::read(). The original >>> asserts checked that the current ThreadState >>> was not _thread_in_native nor _thread_blocked. >>> I changed it into an assert checking that the >>> current thread state is _thread_in_vm. The >>> rational for that is that the only real usage >>> of os::read() on Solaris is in the >>> ClassPathDirEntry::open_stream() method, which >>> is always called with ThreadState ==_thread_in_vm. >>> This change makes the TreadStateTransition simpler >>> and avoid having to store the previous ThreadState. >>> >>> This choice could be revisited once the rules >>> for ThreadStateTransition around system calls >>> when ThreadState is _thread_in_vm are clarified >>> (Solaris is currently the only platform doing >>> this kind of transition for os::read()). >>> >>> The CR: >>> https://bugs.openjdk.java.net/browse/JDK-8036128 >>> >>> The webrev: >>> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >>> >>> Tested with vm.quick.testlist and JPRT hotspot job. >>> >>> Thanks, >>> >>> Fred >>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Fri Mar 14 12:06:28 2014 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 14 Mar 2014 13:06:28 +0100 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <53194DC8.1040502@oracle.com> References: <53189E79.90806@oracle.com> <53194DC8.1040502@oracle.com> Message-ID: <5322F0C4.90204@oracle.com> David, Thank you for the review. Fred On 07/03/2014 05:40, David Holmes wrote: > Hi Fred, > > This looks good to me! Great to see the cleanup happen. > > os_solaris.cpp: > > This comment block seems redundant now: > > 5264 /* > 5265 * XXX: is the following call interruptible? If so, this might > 5266 * need to go through the INTERRUPT_IO() wrapper as for other > 5267 * blocking, interruptible calls in this file. > 5268 */ > > --- > > Aside: arguments.cpp - I guess we can file an RFE to get rid of > obsolete_jvm_flags now that hsx is dead. ;-) > > Cheers, > David > > On 7/03/2014 2:12 AM, frederic parain wrote: >> Greetings, >> >> The UseVMInterruptibleIO flag removal has been >> scheduled a long time ago: >> https://bugs.openjdk.java.net/browse/JDK-4385444 >> >> Now, it's time to effectively remove this flag and >> its associated code. >> >> Removing this feature includes removing all the >> macros used to deal with interruptible I/Os, which >> could make the reading of the webrev hard and painful. >> I conservatively preserved the asserts that were >> inserted by the INTERRUPTIBLE macros, with one >> notable exception for os::read(). The original >> asserts checked that the current ThreadState >> was not _thread_in_native nor _thread_blocked. >> I changed it into an assert checking that the >> current thread state is _thread_in_vm. The >> rational for that is that the only real usage >> of os::read() on Solaris is in the >> ClassPathDirEntry::open_stream() method, which >> is always called with ThreadState ==_thread_in_vm. >> This change makes the TreadStateTransition simpler >> and avoid having to store the previous ThreadState. >> >> This choice could be revisited once the rules >> for ThreadStateTransition around system calls >> when ThreadState is _thread_in_vm are clarified >> (Solaris is currently the only platform doing >> this kind of transition for os::read()). >> >> The CR: >> https://bugs.openjdk.java.net/browse/JDK-8036128 >> >> The webrev: >> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >> >> Tested with vm.quick.testlist and JPRT hotspot job. >> >> Thanks, >> >> Fred >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From frederic.parain at oracle.com Fri Mar 14 12:07:36 2014 From: frederic.parain at oracle.com (frederic parain) Date: Fri, 14 Mar 2014 13:07:36 +0100 Subject: RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO In-Reply-To: <7048B67F-02C6-4F15-A7D5-21E9DC64E2CB@oracle.com> References: <53189E79.90806@oracle.com> <53194DC8.1040502@oracle.com> <136C9819-8005-4DCB-88D1-73858E1591D7@oracle.com> <531DD960.9040004@oracle.com> <7048B67F-02C6-4F15-A7D5-21E9DC64E2CB@oracle.com> Message-ID: <5322F108.2010004@oracle.com> Karen, Thank you for the review and all your investigations on the Solaris connect() semantic. Fred On 13/03/2014 17:31, Karen Kinnear wrote: > Frederic, > > The updated webrev looks great - and now that Michael McMahon has retested Solaris 10 > to find out that we still have this behavior - we still need the os::connect changes. > > Could you add one comment to that code please, perhaps the one currently > in PlainSocketImp.c - which references the 6343810 bug and the fact that this > occurs for blocking sockets for Solaris 10 still. I don't need to re-review. > > Based on your testing and Staffan's comments, sounds like we are good with jstat - > since we didn't document how to extend your options. > > If anyone wants to know how to do that, I have a description and a sample file. > > So - all set - and many thanks, > Karen > > On Mar 10, 2014, at 11:25 AM, frederic parain wrote: > >> Karen, >> >> my answers are in-lined below. >> >> On 07/03/2014 20:02, Karen Kinnear wrote: >>> Frederic, >>> >>> This looks great. And thank you so much. >>> >>> 2. os::connect >>> The change to RESTARTABLE confuses me. I expected to see the current two step handling >>> in case of an EINTR (see 6343810 - at the very end it describes why this is Solaris-specific). >>> Or are you removing that because this will only be used internally and in debug mode and not >>> from the JDK soon? >> >> Thank you for catching that. As far as I understand it, the two steps >> handling was there to support non-blocking sockets, which are not used >> by JVM code, and of the os::connect() is not used by JDK code anymore. >> However, I've restored the initial two-steps handling and added comments >> to explain the semantic of the different errno values. The previous >> behavior of os::connect() is now preserved. >> The new webrev is here: >> >> http://cr.openjdk.java.net/~fparain/8036128/webrev.01/ >> >>> 3. jstat >>> I didn't see this in your tested list - and I believe that the way this works is dynamic, so you are probably >>> ok, but - since you removed perfcounters >>> - what happens if your ~/.jvmstat/jstat_options was referencing this data? >>> and you run jstat -options and then try to dump these options? >> >> I tested with jcmd (jcmd PerfCounter.print ) and didn't noticed >> anything wrong. However, I don't how to use jvmstat/jstat to read >> performance counters. This feature is not documented in jstat web >> page: >> >> http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html >> >> Thanks, >> >> Fred >> >>> David - I asked Frederic to put this flag in the obsolete_jvm_flags - that is our current deprecation mechanism - >>> i.e. for all the flags we are deprecating in JDK9, they should have obsoleted_in: 9, accept_until: 10. So the mechanism isn't >>> obsolete - it triggers a warning mechanism. We can rename it and rework it to not mention HSX, but we still >>> need to deprecate product flags even without HSX. Can we remove really old entries? Yes. Should we keep flags in there >>> that reference JDK9? I would prefer to keep those in for JDK9, so the information gets printed for customers about >>> when the flag became obsolete. >>> >>> thanks, >>> Karen >>> >>> On Mar 6, 2014, at 11:40 PM, David Holmes wrote: >>> >>>> Hi Fred, >>>> >>>> This looks good to me! Great to see the cleanup happen. >>>> >>>> os_solaris.cpp: >>>> >>>> This comment block seems redundant now: >>>> >>>> 5264 /* >>>> 5265 * XXX: is the following call interruptible? If so, this might >>>> 5266 * need to go through the INTERRUPT_IO() wrapper as for other >>>> 5267 * blocking, interruptible calls in this file. >>>> 5268 */ >>>> >>>> --- >>>> >>>> Aside: arguments.cpp - I guess we can file an RFE to get rid of obsolete_jvm_flags now that hsx is dead. ;-) >>>> >>>> Cheers, >>>> David >>>> >>>> On 7/03/2014 2:12 AM, frederic parain wrote: >>>>> Greetings, >>>>> >>>>> The UseVMInterruptibleIO flag removal has been >>>>> scheduled a long time ago: >>>>> https://bugs.openjdk.java.net/browse/JDK-4385444 >>>>> >>>>> Now, it's time to effectively remove this flag and >>>>> its associated code. >>>>> >>>>> Removing this feature includes removing all the >>>>> macros used to deal with interruptible I/Os, which >>>>> could make the reading of the webrev hard and painful. >>>>> I conservatively preserved the asserts that were >>>>> inserted by the INTERRUPTIBLE macros, with one >>>>> notable exception for os::read(). The original >>>>> asserts checked that the current ThreadState >>>>> was not _thread_in_native nor _thread_blocked. >>>>> I changed it into an assert checking that the >>>>> current thread state is _thread_in_vm. The >>>>> rational for that is that the only real usage >>>>> of os::read() on Solaris is in the >>>>> ClassPathDirEntry::open_stream() method, which >>>>> is always called with ThreadState ==_thread_in_vm. >>>>> This change makes the TreadStateTransition simpler >>>>> and avoid having to store the previous ThreadState. >>>>> >>>>> This choice could be revisited once the rules >>>>> for ThreadStateTransition around system calls >>>>> when ThreadState is _thread_in_vm are clarified >>>>> (Solaris is currently the only platform doing >>>>> this kind of transition for os::read()). >>>>> >>>>> The CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8036128 >>>>> >>>>> The webrev: >>>>> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/ >>>>> >>>>> Tested with vm.quick.testlist and JPRT hotspot job. >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>> >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From karen.kinnear at oracle.com Fri Mar 14 15:42:21 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 14 Mar 2014 11:42:21 -0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53228314.2020409@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> Message-ID: Yumin, Latest code looks good. Thank you for reducing the check to SIGINT only. I don't know of a better check than isatty on stdin. David, My memory on the signal checks is that we had customers reporting bugs when they had overridden some of the signal handlers the vm uses internally, so this tells them if they did that. thanks, Karen On Mar 14, 2014, at 12:18 AM, Yumin Qi wrote: > Have changed, new URL at: > http://cr.openjdk.java.net/~minqi/6536943/webrev02 > > Thanks > Yumin > > On 3/13/2014 4:10 PM, Yumin Qi wrote: >> Thanks for review. I will change the order. >> >> Yumin >> >> On 3/13/2014 3:28 PM, Dean Long wrote: >>> (isatty(fileno(stdin)) || sig != SIGINT) >>> >>> You might want to reverse that: >>> >>> (sig != SIGINT || isatty(fileno(stdin))) >>> >>> because isatty() could be expensive. >>> >>> dl >>> >>> >>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>> David and all, >>>> >>>> I have changed to skip SIGINT only if run in a non-interactive shell. Please check webrev: >>>> >>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> Not sure that disabling all signal checks because there is a problem with one signal is the right solution for this. >>>>>> >>>>> Or we check if the signal is SIGINT --- skip it only. >>>>> >>>>> Thanks >>>>> Yumin >>>>>> That said I don't know what utility the signal checks provide in the first place. Can anyone comment on that? >>>>>> >>>>>> David >>>>>> >>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>> Forget to mention tests: >>>>>>> JPRT test; >>>>>>> manually testing on Java2Demo, for both shell and non-interactive shell. >>>>>>> >>>>>>> This is only disabling checking signal handlers under non-interactive >>>>>>> shell, so no need to test more. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>> >>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output warning for >>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as part of >>>>>>>> the job control features. The fix is that don't check signal handlers >>>>>>>> if java run in a non-interactive shell. This applies to all platforms >>>>>>>> except for Windows. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>> >>>>> >>>> >>> >> > From dmitry.samersoff at oracle.com Fri Mar 14 16:05:43 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Mar 2014 20:05:43 +0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53228314.2020409@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> Message-ID: <532328D7.6090506@oracle.com> Yumin. I find the only place per os_*.cpp where we check for SIGINT os/linux/vm/os_linux.cpp 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); so it might make sense to place it under if isatty() {} rather than change macro. Also isatty() call is expensive and will not give you expected result if stdin is redirected (e.g. by custom launcher) I think it's safe to check whether the handler for SIGINT is SIG_IGN and skip the check in this case. -Dmitry On 2014-03-14 08:18, Yumin Qi wrote: > Have changed, new URL at: > http://cr.openjdk.java.net/~minqi/6536943/webrev02 > > Thanks > Yumin > > On 3/13/2014 4:10 PM, Yumin Qi wrote: >> Thanks for review. I will change the order. >> >> Yumin >> >> On 3/13/2014 3:28 PM, Dean Long wrote: >>> (isatty(fileno(stdin)) || sig != SIGINT) >>> >>> You might want to reverse that: >>> >>> (sig != SIGINT || isatty(fileno(stdin))) >>> >>> because isatty() could be expensive. >>> >>> dl >>> >>> >>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>> David and all, >>>> >>>> I have changed to skip SIGINT only if run in a non-interactive >>>> shell. Please check webrev: >>>> >>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>> Hi Yumin, >>>>>> >>>>>> Not sure that disabling all signal checks because there is a >>>>>> problem with one signal is the right solution for this. >>>>>> >>>>> Or we check if the signal is SIGINT --- skip it only. >>>>> >>>>> Thanks >>>>> Yumin >>>>>> That said I don't know what utility the signal checks provide in >>>>>> the first place. Can anyone comment on that? >>>>>> >>>>>> David >>>>>> >>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>> Forget to mention tests: >>>>>>> JPRT test; >>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>> shell. >>>>>>> >>>>>>> This is only disabling checking signal handlers under >>>>>>> non-interactive >>>>>>> shell, so no need to test more. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>> >>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>> warning for >>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>> part of >>>>>>>> the job control features. The fix is that don't check signal >>>>>>>> handlers >>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>> platforms >>>>>>>> except for Windows. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>> >>>>> >>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yumin.qi at oracle.com Fri Mar 14 16:12:56 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 09:12:56 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53228D81.2070207@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <53228D81.2070207@oracle.com> Message-ID: <53232A88.102@oracle.com> David, Do you mean if isatty actually tells whether a java running in a non-interactive shell? I don't understand your question, for a simple test: #include #include int main(int argc, char **argv) { printf("Test isatty:\n"); if (!isatty(fileno(stdin))) printf("Running in non-interactive shell\n"); else printf("Running in regular shell\n"); return 0; } It prints out: -bash-3.00$ ./testisatty Test isatty: Running in regular shell -bash-3.00$ ./testisatty & [1] 8033 -bash-3.00$ Test isatty: Running in regular shell [1]+ Done ./testisatty -bash-3.00$ sh -c "./testisatty" Test isatty: Running in regular shell -bash-3.00$ -bash-3.00$ sh -c "./testisatty &" -bash-3.00$ Test isatty: Running in non-interactive shell Thanks Yumin On 3/13/2014 10:02 PM, David Holmes wrote: > On 14/03/2014 2:18 PM, Yumin Qi wrote: >> Have changed, new URL at: >> http://cr.openjdk.java.net/~minqi/6536943/webrev02 > > Thanks I agree with the new logic. > > However I can't comment on whether isatty actually tests for the > desired condition. > > David > >> Thanks >> Yumin >> >> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>> Thanks for review. I will change the order. >>> >>> Yumin >>> >>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>> >>>> You might want to reverse that: >>>> >>>> (sig != SIGINT || isatty(fileno(stdin))) >>>> >>>> because isatty() could be expensive. >>>> >>>> dl >>>> >>>> >>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>> David and all, >>>>> >>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>> shell. Please check webrev: >>>>> >>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>> Hi Yumin, >>>>>>> >>>>>>> Not sure that disabling all signal checks because there is a >>>>>>> problem with one signal is the right solution for this. >>>>>>> >>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>>> That said I don't know what utility the signal checks provide in >>>>>>> the first place. Can anyone comment on that? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>> Forget to mention tests: >>>>>>>> JPRT test; >>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>> shell. >>>>>>>> >>>>>>>> This is only disabling checking signal handlers under >>>>>>>> non-interactive >>>>>>>> shell, so no need to test more. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>> >>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>> warning for >>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>> part of >>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>> handlers >>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>> platforms >>>>>>>>> except for Windows. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>> >>>>>> >>>>> >>>> >>> >> From yumin.qi at oracle.com Fri Mar 14 16:27:50 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 09:27:50 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <532328D7.6090506@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> Message-ID: <53232E06.3060406@oracle.com> Dmitry, case INTERRUPT_SIGNAL: jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); break; Do you mean we use if (isatty(fileno(stdin))) jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); else jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); I think this will solve the problem. Need more opinions. Under redirecting, isatty still can correctly tests for non-interactive shell, please check bug comments. Thanks Yumin On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: > Yumin. > > I find the only place per os_*.cpp where we check for SIGINT > > os/linux/vm/os_linux.cpp > > 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); > > so it might make sense to place it under > > if isatty() {} > > rather than change macro. > > Also isatty() call is expensive and will not give you expected result if > stdin is redirected (e.g. by custom launcher) > > > I think it's safe to check whether the handler for SIGINT is SIG_IGN > and skip the check in this case. > > -Dmitry > > > On 2014-03-14 08:18, Yumin Qi wrote: >> Have changed, new URL at: >> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >> >> Thanks >> Yumin >> >> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>> Thanks for review. I will change the order. >>> >>> Yumin >>> >>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>> >>>> You might want to reverse that: >>>> >>>> (sig != SIGINT || isatty(fileno(stdin))) >>>> >>>> because isatty() could be expensive. >>>> >>>> dl >>>> >>>> >>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>> David and all, >>>>> >>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>> shell. Please check webrev: >>>>> >>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>> Hi Yumin, >>>>>>> >>>>>>> Not sure that disabling all signal checks because there is a >>>>>>> problem with one signal is the right solution for this. >>>>>>> >>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>>> That said I don't know what utility the signal checks provide in >>>>>>> the first place. Can anyone comment on that? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>> Forget to mention tests: >>>>>>>> JPRT test; >>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>> shell. >>>>>>>> >>>>>>>> This is only disabling checking signal handlers under >>>>>>>> non-interactive >>>>>>>> shell, so no need to test more. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>> >>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>> warning for >>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>> part of >>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>> handlers >>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>> platforms >>>>>>>>> except for Windows. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin > From yumin.qi at oracle.com Fri Mar 14 16:57:39 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 09:57:39 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53232E06.3060406@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> Message-ID: <53233503.1020807@oracle.com> Dmitry, #define INTERRUPT_SIGNAL SIGUSR1 I think this is not SIGINT. Thanks Yumin On 3/14/2014 9:27 AM, Yumin Qi wrote: > Dmitry, > > case INTERRUPT_SIGNAL: > jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); > break; > > Do you mean we use > if (isatty(fileno(stdin))) > jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); > else > jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); > > I think this will solve the problem. Need more opinions. > > Under redirecting, isatty still can correctly tests for > non-interactive shell, please check bug comments. > > Thanks > Yumin > > > On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >> Yumin. >> >> I find the only place per os_*.cpp where we check for SIGINT >> >> os/linux/vm/os_linux.cpp >> >> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >> >> so it might make sense to place it under >> >> if isatty() {} >> >> rather than change macro. >> >> Also isatty() call is expensive and will not give you expected result if >> stdin is redirected (e.g. by custom launcher) >> >> >> I think it's safe to check whether the handler for SIGINT is SIG_IGN >> and skip the check in this case. >> >> -Dmitry >> >> >> On 2014-03-14 08:18, Yumin Qi wrote: >>> Have changed, new URL at: >>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>> >>> Thanks >>> Yumin >>> >>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>> Thanks for review. I will change the order. >>>> >>>> Yumin >>>> >>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>> >>>>> You might want to reverse that: >>>>> >>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>> >>>>> because isatty() could be expensive. >>>>> >>>>> dl >>>>> >>>>> >>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>> David and all, >>>>>> >>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>> shell. Please check webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>> Hi Yumin, >>>>>>>> >>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>> problem with one signal is the right solution for this. >>>>>>>> >>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>> the first place. Can anyone comment on that? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>> Forget to mention tests: >>>>>>>>> JPRT test; >>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>> shell. >>>>>>>>> >>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>> non-interactive >>>>>>>>> shell, so no need to test more. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>> >>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>> warning for >>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>> part of >>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>> handlers >>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>> platforms >>>>>>>>>> except for Windows. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >> > From yumin.qi at oracle.com Fri Mar 14 17:09:58 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 10:09:58 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53233503.1020807@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> Message-ID: <532337E6.8010106@oracle.com> More, the defined signals from SIGINT: (linux): #define BREAK_SIGNAL SIGQUIT /* Thread dumping support. */ #define INTERRUPT_SIGNAL SIGUSR1 /* Interruptible I/O support. */ #define SHUTDOWN1_SIGNAL SIGHUP /* Shutdown Hooks support. */ #define SHUTDOWN2_SIGNAL SIGINT #define SHUTDOWN3_SIGNAL SIGTERM So the check signal comes from SHUTDOWN2: if (!ReduceSignalUsage) { DO_SIGNAL_CHECK(SHUTDOWN1_SIGNAL); DO_SIGNAL_CHECK(SHUTDOWN2_SIGNAL); DO_SIGNAL_CHECK(SHUTDOWN3_SIGNAL); DO_SIGNAL_CHECK(BREAK_SIGNAL); } If using -Xrs we would not see the ouput warning. Thanks Yumin On 3/14/2014 9:57 AM, Yumin Qi wrote: > Dmitry, > > #define INTERRUPT_SIGNAL SIGUSR1 > > I think this is not SIGINT. > > Thanks > Yumin > > On 3/14/2014 9:27 AM, Yumin Qi wrote: >> Dmitry, >> >> case INTERRUPT_SIGNAL: >> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >> break; >> >> Do you mean we use >> if (isatty(fileno(stdin))) >> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >> else >> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >> >> I think this will solve the problem. Need more opinions. >> >> Under redirecting, isatty still can correctly tests for >> non-interactive shell, please check bug comments. >> >> Thanks >> Yumin >> >> >> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>> Yumin. >>> >>> I find the only place per os_*.cpp where we check for SIGINT >>> >>> os/linux/vm/os_linux.cpp >>> >>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>> >>> so it might make sense to place it under >>> >>> if isatty() {} >>> >>> rather than change macro. >>> >>> Also isatty() call is expensive and will not give you expected >>> result if >>> stdin is redirected (e.g. by custom launcher) >>> >>> >>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>> and skip the check in this case. >>> >>> -Dmitry >>> >>> >>> On 2014-03-14 08:18, Yumin Qi wrote: >>>> Have changed, new URL at: >>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>> Thanks for review. I will change the order. >>>>> >>>>> Yumin >>>>> >>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>> >>>>>> You might want to reverse that: >>>>>> >>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>> >>>>>> because isatty() could be expensive. >>>>>> >>>>>> dl >>>>>> >>>>>> >>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>> David and all, >>>>>>> >>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>> shell. Please check webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>> Hi Yumin, >>>>>>>>> >>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>> >>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>> Forget to mention tests: >>>>>>>>>> JPRT test; >>>>>>>>>> manually testing on Java2Demo, for both shell and >>>>>>>>>> non-interactive >>>>>>>>>> shell. >>>>>>>>>> >>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>> non-interactive >>>>>>>>>> shell, so no need to test more. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>> >>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>> warning for >>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>> part of >>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>> handlers >>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>> platforms >>>>>>>>>>> except for Windows. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>> >> > From karen.kinnear at oracle.com Fri Mar 14 17:10:54 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 14 Mar 2014 13:10:54 -0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53233503.1020807@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> Message-ID: <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> #define SHUTDOWN_SIGNAL1 SIGINT I also wondered about checking if the current SIGINT interrupt handler setting was SIG_IGN. The question is - do we want to only not report for non-interactive or for anyone who has set SIG_IGN? I was leaning in the direction of non-interactive. thanks Karen On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: > Dmitry, > > #define INTERRUPT_SIGNAL SIGUSR1 > > I think this is not SIGINT. > > Thanks > Yumin > > On 3/14/2014 9:27 AM, Yumin Qi wrote: >> Dmitry, >> >> case INTERRUPT_SIGNAL: >> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >> break; >> >> Do you mean we use >> if (isatty(fileno(stdin))) >> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >> else >> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >> >> I think this will solve the problem. Need more opinions. >> >> Under redirecting, isatty still can correctly tests for non-interactive shell, please check bug comments. >> >> Thanks >> Yumin >> >> >> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>> Yumin. >>> >>> I find the only place per os_*.cpp where we check for SIGINT >>> >>> os/linux/vm/os_linux.cpp >>> >>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>> >>> so it might make sense to place it under >>> >>> if isatty() {} >>> >>> rather than change macro. >>> >>> Also isatty() call is expensive and will not give you expected result if >>> stdin is redirected (e.g. by custom launcher) >>> >>> >>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>> and skip the check in this case. >>> >>> -Dmitry >>> >>> >>> On 2014-03-14 08:18, Yumin Qi wrote: >>>> Have changed, new URL at: >>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>> Thanks for review. I will change the order. >>>>> >>>>> Yumin >>>>> >>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>> >>>>>> You might want to reverse that: >>>>>> >>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>> >>>>>> because isatty() could be expensive. >>>>>> >>>>>> dl >>>>>> >>>>>> >>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>> David and all, >>>>>>> >>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>> shell. Please check webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>> Hi Yumin, >>>>>>>>> >>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>> >>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>> Forget to mention tests: >>>>>>>>>> JPRT test; >>>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>>> shell. >>>>>>>>>> >>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>> non-interactive >>>>>>>>>> shell, so no need to test more. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>> >>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>> warning for >>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>> part of >>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>> handlers >>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>> platforms >>>>>>>>>>> except for Windows. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>> >> > From dmitry.samersoff at oracle.com Fri Mar 14 17:13:54 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Mar 2014 21:13:54 +0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53232E06.3060406@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> Message-ID: <532338D2.9080000@oracle.com> Yumin, 1. We can do: if (isatty(fileno(stdin))) { DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); } instead of changing macro 2. or we can do: case INTERRUPT_SIGNAL: if ( CAST_FROM_FN_PTR(address, SIG_DFL) || CAST_FROM_FN_PTR(address, SIG_IGN) ) { // take handler OK path } as I think it's safe in all cases to have INTERRUPT_SIGNAL ignored. 3. isatty() should return False (didn't check it though) if stdin is closed and reopen as a regular file before launching java. (i.e. someone launched java from other process or create VM directly) So I'm for option (2) above. Also it might be faster to use fstat() and check whether st_mode == S_ISCHR. -Dmitry On 2014-03-14 20:27, Yumin Qi wrote: > Dmitry, > > case INTERRUPT_SIGNAL: > jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); > break; > > Do you mean we use > if (isatty(fileno(stdin))) > jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); > else > jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); > > I think this will solve the problem. Need more opinions. > > Under redirecting, isatty still can correctly tests for non-interactive > shell, please check bug comments. > > Thanks > Yumin > > > On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >> Yumin. >> >> I find the only place per os_*.cpp where we check for SIGINT >> >> os/linux/vm/os_linux.cpp >> >> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >> >> so it might make sense to place it under >> >> if isatty() {} >> >> rather than change macro. >> >> Also isatty() call is expensive and will not give you expected result if >> stdin is redirected (e.g. by custom launcher) >> >> >> I think it's safe to check whether the handler for SIGINT is SIG_IGN >> and skip the check in this case. >> >> -Dmitry >> >> >> On 2014-03-14 08:18, Yumin Qi wrote: >>> Have changed, new URL at: >>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>> >>> Thanks >>> Yumin >>> >>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>> Thanks for review. I will change the order. >>>> >>>> Yumin >>>> >>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>> >>>>> You might want to reverse that: >>>>> >>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>> >>>>> because isatty() could be expensive. >>>>> >>>>> dl >>>>> >>>>> >>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>> David and all, >>>>>> >>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>> shell. Please check webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>> Hi Yumin, >>>>>>>> >>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>> problem with one signal is the right solution for this. >>>>>>>> >>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>> the first place. Can anyone comment on that? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>> Forget to mention tests: >>>>>>>>> JPRT test; >>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>> shell. >>>>>>>>> >>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>> non-interactive >>>>>>>>> shell, so no need to test more. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>> >>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>> warning for >>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>> part of >>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>> handlers >>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>> platforms >>>>>>>>>> except for Windows. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yumin.qi at oracle.com Fri Mar 14 17:17:11 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 10:17:11 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> Message-ID: <53233997.9040301@oracle.com> Karen, I agree only report non-interactive shell warning --- if under other case user replace the signal handler, we should give warning. This lets me think of the fix one more time, do we really want to silent for non-reactive shell? It is no harm for customer knows what happened --- it is the shell replace the handler. If user understand that, it is OK I think. Thanks Yumin On 3/14/2014 10:10 AM, Karen Kinnear wrote: > #define SHUTDOWN_SIGNAL1 SIGINT > > I also wondered about checking if the current SIGINT interrupt handler setting was > SIG_IGN. > > The question is - do we want to only not report for non-interactive or for anyone who > has set SIG_IGN? I was leaning in the direction of non-interactive. > > thanks > Karen > > On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: > >> Dmitry, >> >> #define INTERRUPT_SIGNAL SIGUSR1 >> >> I think this is not SIGINT. >> >> Thanks >> Yumin >> >> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>> Dmitry, >>> >>> case INTERRUPT_SIGNAL: >>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>> break; >>> >>> Do you mean we use >>> if (isatty(fileno(stdin))) >>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>> else >>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>> >>> I think this will solve the problem. Need more opinions. >>> >>> Under redirecting, isatty still can correctly tests for non-interactive shell, please check bug comments. >>> >>> Thanks >>> Yumin >>> >>> >>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>> Yumin. >>>> >>>> I find the only place per os_*.cpp where we check for SIGINT >>>> >>>> os/linux/vm/os_linux.cpp >>>> >>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>> >>>> so it might make sense to place it under >>>> >>>> if isatty() {} >>>> >>>> rather than change macro. >>>> >>>> Also isatty() call is expensive and will not give you expected result if >>>> stdin is redirected (e.g. by custom launcher) >>>> >>>> >>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>> and skip the check in this case. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>> Have changed, new URL at: >>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>> Thanks for review. I will change the order. >>>>>> >>>>>> Yumin >>>>>> >>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>> >>>>>>> You might want to reverse that: >>>>>>> >>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>> >>>>>>> because isatty() could be expensive. >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> >>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>> David and all, >>>>>>>> >>>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>>> shell. Please check webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>> Hi Yumin, >>>>>>>>>> >>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>> >>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>> Forget to mention tests: >>>>>>>>>>> JPRT test; >>>>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>>>> shell. >>>>>>>>>>> >>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>> non-interactive >>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>> >>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>> warning for >>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>>> part of >>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>> handlers >>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>> platforms >>>>>>>>>>>> except for Windows. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin From dmitry.samersoff at oracle.com Fri Mar 14 17:22:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Mar 2014 21:22:18 +0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <532337E6.8010106@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <532337E6.8010106@oracle.com> Message-ID: <53233ACA.7040504@oracle.com> Yumin. Yes. my bad. -Dmitry On 2014-03-14 21:09, Yumin Qi wrote: > More, the defined signals from SIGINT: > > (linux): > #define BREAK_SIGNAL SIGQUIT /* Thread dumping support. */ > #define INTERRUPT_SIGNAL SIGUSR1 /* Interruptible I/O support. */ > #define SHUTDOWN1_SIGNAL SIGHUP /* Shutdown Hooks support. */ > #define SHUTDOWN2_SIGNAL SIGINT > #define SHUTDOWN3_SIGNAL SIGTERM > > So the check signal comes from SHUTDOWN2: > > if (!ReduceSignalUsage) { > DO_SIGNAL_CHECK(SHUTDOWN1_SIGNAL); > DO_SIGNAL_CHECK(SHUTDOWN2_SIGNAL); > DO_SIGNAL_CHECK(SHUTDOWN3_SIGNAL); > DO_SIGNAL_CHECK(BREAK_SIGNAL); > } > > If using -Xrs we would not see the ouput warning. > > Thanks > Yumin > > > On 3/14/2014 9:57 AM, Yumin Qi wrote: >> Dmitry, >> >> #define INTERRUPT_SIGNAL SIGUSR1 >> >> I think this is not SIGINT. >> >> Thanks >> Yumin >> >> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>> Dmitry, >>> >>> case INTERRUPT_SIGNAL: >>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>> break; >>> >>> Do you mean we use >>> if (isatty(fileno(stdin))) >>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>> else >>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>> >>> I think this will solve the problem. Need more opinions. >>> >>> Under redirecting, isatty still can correctly tests for >>> non-interactive shell, please check bug comments. >>> >>> Thanks >>> Yumin >>> >>> >>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>> Yumin. >>>> >>>> I find the only place per os_*.cpp where we check for SIGINT >>>> >>>> os/linux/vm/os_linux.cpp >>>> >>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>> >>>> so it might make sense to place it under >>>> >>>> if isatty() {} >>>> >>>> rather than change macro. >>>> >>>> Also isatty() call is expensive and will not give you expected >>>> result if >>>> stdin is redirected (e.g. by custom launcher) >>>> >>>> >>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>> and skip the check in this case. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>> Have changed, new URL at: >>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>> Thanks for review. I will change the order. >>>>>> >>>>>> Yumin >>>>>> >>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>> >>>>>>> You might want to reverse that: >>>>>>> >>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>> >>>>>>> because isatty() could be expensive. >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> >>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>> David and all, >>>>>>>> >>>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>>> shell. Please check webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>> Hi Yumin, >>>>>>>>>> >>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>> >>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>> Forget to mention tests: >>>>>>>>>>> JPRT test; >>>>>>>>>>> manually testing on Java2Demo, for both shell and >>>>>>>>>>> non-interactive >>>>>>>>>>> shell. >>>>>>>>>>> >>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>> non-interactive >>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>> >>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>> warning for >>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>>> part of >>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>> handlers >>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>> platforms >>>>>>>>>>>> except for Windows. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From karen.kinnear at oracle.com Fri Mar 14 17:22:34 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 14 Mar 2014 13:22:34 -0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53233997.9040301@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> <53233997.9040301@oracle.com> Message-ID: Yumin, I had the same question. Another possibility would be to leave the check in, and to add a comment after reporting SIGINT as SIG_IGN that this could be an artifact of running in a non-interactive shell opinions? thanks, Karen On Mar 14, 2014, at 1:17 PM, Yumin Qi wrote: > Karen, > > I agree only report non-interactive shell warning --- if under other case user replace the signal handler, we should give warning. This lets me think of the fix one more time, do we really want to silent for non-reactive shell? It is no harm for customer knows what happened --- it is the shell replace the handler. If user understand that, it is OK I think. > > Thanks > Yumin > > On 3/14/2014 10:10 AM, Karen Kinnear wrote: >> #define SHUTDOWN_SIGNAL1 SIGINT >> >> I also wondered about checking if the current SIGINT interrupt handler setting was >> SIG_IGN. >> >> The question is - do we want to only not report for non-interactive or for anyone who >> has set SIG_IGN? I was leaning in the direction of non-interactive. >> >> thanks >> Karen >> >> On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: >> >>> Dmitry, >>> >>> #define INTERRUPT_SIGNAL SIGUSR1 >>> >>> I think this is not SIGINT. >>> >>> Thanks >>> Yumin >>> >>> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>>> Dmitry, >>>> >>>> case INTERRUPT_SIGNAL: >>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>> break; >>>> >>>> Do you mean we use >>>> if (isatty(fileno(stdin))) >>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>> else >>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>>> >>>> I think this will solve the problem. Need more opinions. >>>> >>>> Under redirecting, isatty still can correctly tests for non-interactive shell, please check bug comments. >>>> >>>> Thanks >>>> Yumin >>>> >>>> >>>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>>> Yumin. >>>>> >>>>> I find the only place per os_*.cpp where we check for SIGINT >>>>> >>>>> os/linux/vm/os_linux.cpp >>>>> >>>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>>> >>>>> so it might make sense to place it under >>>>> >>>>> if isatty() {} >>>>> >>>>> rather than change macro. >>>>> >>>>> Also isatty() call is expensive and will not give you expected result if >>>>> stdin is redirected (e.g. by custom launcher) >>>>> >>>>> >>>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>>> and skip the check in this case. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>>> Have changed, new URL at: >>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>>> Thanks for review. I will change the order. >>>>>>> >>>>>>> Yumin >>>>>>> >>>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>>> >>>>>>>> You might want to reverse that: >>>>>>>> >>>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>>> >>>>>>>> because isatty() could be expensive. >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>> >>>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>>> David and all, >>>>>>>>> >>>>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>>>> shell. Please check webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>>> Hi Yumin, >>>>>>>>>>> >>>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>>> >>>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>>> Forget to mention tests: >>>>>>>>>>>> JPRT test; >>>>>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>>>>> shell. >>>>>>>>>>>> >>>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>>> non-interactive >>>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>>> warning for >>>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>>>> part of >>>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>>> handlers >>>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>>> platforms >>>>>>>>>>>>> except for Windows. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin > From dmitry.samersoff at oracle.com Fri Mar 14 17:26:34 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Mar 2014 21:26:34 +0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53232E06.3060406@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> Message-ID: <53233BCA.5010106@oracle.com> Yumin, (* fixed with correct signal name *) 1. We can do: if (isatty(fileno(stdin))) { DO_SIGNAL_CHECK(SHUTDOWN2_SIGNAL); } instead of changing macro 2. or we can do: case SHUTDOWN2_SIGNAL: if ( thisHandler == (address) user_handler() || thisHandler == CAST_FROM_FN_PTR(address, SIG_IGN) ) { // take handler OK path } as I think it's safe in all cases to have SIGINT ignored. 3. isatty() should return False (didn't check it though) if stdin is closed and reopen as a regular file before launching java. (i.e. someone launched java from other process or create VM directly) So I'm for option (2) above. Also it might be faster to use fstat() and check whether st_mode == S_ISCHR. -Dmitry On 2014-03-14 20:27, Yumin Qi wrote: > Dmitry, > > case INTERRUPT_SIGNAL: > jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); > break; > > Do you mean we use > if (isatty(fileno(stdin))) > jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); > else > jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); > > I think this will solve the problem. Need more opinions. > > Under redirecting, isatty still can correctly tests for non-interactive > shell, please check bug comments. > > Thanks > Yumin > > > On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >> Yumin. >> >> I find the only place per os_*.cpp where we check for SIGINT >> >> os/linux/vm/os_linux.cpp >> >> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >> >> so it might make sense to place it under >> >> if isatty() {} >> >> rather than change macro. >> >> Also isatty() call is expensive and will not give you expected result if >> stdin is redirected (e.g. by custom launcher) >> >> >> I think it's safe to check whether the handler for SIGINT is SIG_IGN >> and skip the check in this case. >> >> -Dmitry >> >> >> On 2014-03-14 08:18, Yumin Qi wrote: >>> Have changed, new URL at: >>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>> >>> Thanks >>> Yumin >>> >>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>> Thanks for review. I will change the order. >>>> >>>> Yumin >>>> >>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>> >>>>> You might want to reverse that: >>>>> >>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>> >>>>> because isatty() could be expensive. >>>>> >>>>> dl >>>>> >>>>> >>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>> David and all, >>>>>> >>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>> shell. Please check webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>> Hi Yumin, >>>>>>>> >>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>> problem with one signal is the right solution for this. >>>>>>>> >>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>> the first place. Can anyone comment on that? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>> Forget to mention tests: >>>>>>>>> JPRT test; >>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>> shell. >>>>>>>>> >>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>> non-interactive >>>>>>>>> shell, so no need to test more. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>> >>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>> warning for >>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>> part of >>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>> handlers >>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>> platforms >>>>>>>>>> except for Windows. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From coleen.phillimore at oracle.com Fri Mar 14 18:08:01 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Mar 2014 14:08:01 -0400 Subject: RFR 8036630: Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array Message-ID: <53234581.80000@oracle.com> Summary: Call ProtectionDomain constructor instead of making all fields null. bug link https://bugs.openjdk.java.net/browse/JDK-8036630 hotspot change: open webrev at http://cr.openjdk.java.net/~coleenp/8036630/ Tested with jdk/test/java/security, and jck lang, vm, and api/java_lang tests, and manual test. Thanks, Coleen From yumin.qi at oracle.com Fri Mar 14 18:35:19 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 11:35:19 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> <53233997.9040301@oracle.com> Message-ID: <53234BE7.6030908@oracle.com> Karen and all, http://cr.openjdk.java.net/~minqi/6536943/webrev03/ This version only still keeps original version of checking for signal plus more info printout like: Warning: SIGINT handler expected:libjvm.so+0x894d30 found:0x0000000000000001 Running in non-interactive shell, SIGINT handler is replaced by shell <--------------------------- newly added output Signal Handlers: SIGSEGV: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGBUS: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGFPE: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGPIPE: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGXFSZ: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGILL: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGUSR1: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none SIGUSR2: [libjvm.so+0x893710], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO SIGHUP: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGINT: SIG_IGN, sa_mask[0]=00000000000000000000000000000000, sa_flags=none <------------------------------------------------- user can get hint from here SIGTERM: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO SIGQUIT: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO Let me know if it is OK. Thanks Yumin On 3/14/2014 10:22 AM, Karen Kinnear wrote: > Yumin, > > I had the same question. > > Another possibility would be to leave the check in, and to add a comment > after reporting SIGINT as SIG_IGN that this could be an artifact of running in a non-interactive shell > > opinions? > > thanks, > Karen > > On Mar 14, 2014, at 1:17 PM, Yumin Qi wrote: > >> Karen, >> >> I agree only report non-interactive shell warning --- if under other case user replace the signal handler, we should give warning. This lets me think of the fix one more time, do we really want to silent for non-reactive shell? It is no harm for customer knows what happened --- it is the shell replace the handler. If user understand that, it is OK I think. >> >> Thanks >> Yumin >> >> On 3/14/2014 10:10 AM, Karen Kinnear wrote: >>> #define SHUTDOWN_SIGNAL1 SIGINT >>> >>> I also wondered about checking if the current SIGINT interrupt handler setting was >>> SIG_IGN. >>> >>> The question is - do we want to only not report for non-interactive or for anyone who >>> has set SIG_IGN? I was leaning in the direction of non-interactive. >>> >>> thanks >>> Karen >>> >>> On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: >>> >>>> Dmitry, >>>> >>>> #define INTERRUPT_SIGNAL SIGUSR1 >>>> >>>> I think this is not SIGINT. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>>>> Dmitry, >>>>> >>>>> case INTERRUPT_SIGNAL: >>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>> break; >>>>> >>>>> Do you mean we use >>>>> if (isatty(fileno(stdin))) >>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>> else >>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>>>> >>>>> I think this will solve the problem. Need more opinions. >>>>> >>>>> Under redirecting, isatty still can correctly tests for non-interactive shell, please check bug comments. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> >>>>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>>>> Yumin. >>>>>> >>>>>> I find the only place per os_*.cpp where we check for SIGINT >>>>>> >>>>>> os/linux/vm/os_linux.cpp >>>>>> >>>>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>>>> >>>>>> so it might make sense to place it under >>>>>> >>>>>> if isatty() {} >>>>>> >>>>>> rather than change macro. >>>>>> >>>>>> Also isatty() call is expensive and will not give you expected result if >>>>>> stdin is redirected (e.g. by custom launcher) >>>>>> >>>>>> >>>>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>>>> and skip the check in this case. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>>>> Have changed, new URL at: >>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>>>> Thanks for review. I will change the order. >>>>>>>> >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>>>> >>>>>>>>> You might want to reverse that: >>>>>>>>> >>>>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>>>> >>>>>>>>> because isatty() could be expensive. >>>>>>>>> >>>>>>>>> dl >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>>>> David and all, >>>>>>>>>> >>>>>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>>>>> shell. Please check webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>> >>>>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>>>> >>>>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>>>> Forget to mention tests: >>>>>>>>>>>>> JPRT test; >>>>>>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>>>>>> shell. >>>>>>>>>>>>> >>>>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>>>> non-interactive >>>>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>>>> warning for >>>>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>>>>> part of >>>>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>>>> handlers >>>>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>>>> platforms >>>>>>>>>>>>>> except for Windows. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin From dmitry.samersoff at oracle.com Fri Mar 14 19:07:13 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Mar 2014 23:07:13 +0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53234BE7.6030908@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> <53233997.9040301@oracle.com> <53234BE7.6030908@oracle.com> Message-ID: <53235361.8030806@oracle.com> Yumin, This version is OK for me. -Dmitry On 2014-03-14 22:35, Yumin Qi wrote: > Karen and all, > > http://cr.openjdk.java.net/~minqi/6536943/webrev03/ > > This version only still keeps original version of checking for signal > plus more info printout like: > > Warning: SIGINT handler expected:libjvm.so+0x894d30 > found:0x0000000000000001 > Running in non-interactive shell, SIGINT handler is replaced by shell > <--------------------------- newly added output > Signal Handlers: > SIGSEGV: [libjvm.so+0x892040], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0x892040], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0x892040], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0x892040], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0x892040], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0x892040], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR1: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, > sa_flags=none > SIGUSR2: [libjvm.so+0x893710], > sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0x894d30], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: SIG_IGN, sa_mask[0]=00000000000000000000000000000000, > sa_flags=none <------------------------------------------------- user > can get hint from here > SIGTERM: [libjvm.so+0x894d30], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0x894d30], > sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Let me know if it is OK. > > Thanks > Yumin > > On 3/14/2014 10:22 AM, Karen Kinnear wrote: >> Yumin, >> >> I had the same question. >> >> Another possibility would be to leave the check in, and to add a comment >> after reporting SIGINT as SIG_IGN that this could be an artifact of >> running in a non-interactive shell >> >> opinions? >> >> thanks, >> Karen >> >> On Mar 14, 2014, at 1:17 PM, Yumin Qi wrote: >> >>> Karen, >>> >>> I agree only report non-interactive shell warning --- if under >>> other case user replace the signal handler, we should give warning. >>> This lets me think of the fix one more time, do we really want to >>> silent for non-reactive shell? It is no harm for customer knows what >>> happened --- it is the shell replace the handler. If user understand >>> that, it is OK I think. >>> >>> Thanks >>> Yumin >>> >>> On 3/14/2014 10:10 AM, Karen Kinnear wrote: >>>> #define SHUTDOWN_SIGNAL1 SIGINT >>>> >>>> I also wondered about checking if the current SIGINT interrupt >>>> handler setting was >>>> SIG_IGN. >>>> >>>> The question is - do we want to only not report for non-interactive >>>> or for anyone who >>>> has set SIG_IGN? I was leaning in the direction of non-interactive. >>>> >>>> thanks >>>> Karen >>>> >>>> On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: >>>> >>>>> Dmitry, >>>>> >>>>> #define INTERRUPT_SIGNAL SIGUSR1 >>>>> >>>>> I think this is not SIGINT. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>>>>> Dmitry, >>>>>> >>>>>> case INTERRUPT_SIGNAL: >>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>> break; >>>>>> >>>>>> Do you mean we use >>>>>> if (isatty(fileno(stdin))) >>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>> else >>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>>>>> >>>>>> I think this will solve the problem. Need more opinions. >>>>>> >>>>>> Under redirecting, isatty still can correctly tests for >>>>>> non-interactive shell, please check bug comments. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>>>>> Yumin. >>>>>>> >>>>>>> I find the only place per os_*.cpp where we check for SIGINT >>>>>>> >>>>>>> os/linux/vm/os_linux.cpp >>>>>>> >>>>>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>>>>> >>>>>>> so it might make sense to place it under >>>>>>> >>>>>>> if isatty() {} >>>>>>> >>>>>>> rather than change macro. >>>>>>> >>>>>>> Also isatty() call is expensive and will not give you expected >>>>>>> result if >>>>>>> stdin is redirected (e.g. by custom launcher) >>>>>>> >>>>>>> >>>>>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>>>>> and skip the check in this case. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>>>>> Have changed, new URL at: >>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>>>>> Thanks for review. I will change the order. >>>>>>>>> >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>>>>> >>>>>>>>>> You might want to reverse that: >>>>>>>>>> >>>>>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>>>>> >>>>>>>>>> because isatty() could be expensive. >>>>>>>>>> >>>>>>>>>> dl >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>>>>> David and all, >>>>>>>>>>> >>>>>>>>>>> I have changed to skip SIGINT only if run in a >>>>>>>>>>> non-interactive >>>>>>>>>>> shell. Please check webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>>>>> >>>>>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>>> That said I don't know what utility the signal checks >>>>>>>>>>>>> provide in >>>>>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>>>>> Forget to mention tests: >>>>>>>>>>>>>> JPRT test; >>>>>>>>>>>>>> manually testing on Java2Demo, for both shell and >>>>>>>>>>>>>> non-interactive >>>>>>>>>>>>>> shell. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>>>>> non-interactive >>>>>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>>>>> warning for >>>>>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to >>>>>>>>>>>>>>> SIG_IGN as >>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>>>>> handlers >>>>>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>> except for Windows. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yumin.qi at oracle.com Fri Mar 14 19:45:51 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 12:45:51 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53235361.8030806@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> <53233997.9040301@oracle.com> <53234BE7.6030908@oracle.com> <53235361.8030806@oracle.com> Message-ID: <53235C6F.8030005@oracle.com> Thanks for review Yumin On 3/14/2014 12:07 PM, Dmitry Samersoff wrote: > Yumin, > > This version is OK for me. > > -Dmitry > > > On 2014-03-14 22:35, Yumin Qi wrote: >> Karen and all, >> >> http://cr.openjdk.java.net/~minqi/6536943/webrev03/ >> >> This version only still keeps original version of checking for signal >> plus more info printout like: >> >> Warning: SIGINT handler expected:libjvm.so+0x894d30 >> found:0x0000000000000001 >> Running in non-interactive shell, SIGINT handler is replaced by shell >> <--------------------------- newly added output >> Signal Handlers: >> SIGSEGV: [libjvm.so+0x892040], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGBUS: [libjvm.so+0x892040], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGFPE: [libjvm.so+0x892040], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGPIPE: [libjvm.so+0x892040], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGXFSZ: [libjvm.so+0x892040], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGILL: [libjvm.so+0x892040], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGUSR1: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, >> sa_flags=none >> SIGUSR2: [libjvm.so+0x893710], >> sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> SIGHUP: [libjvm.so+0x894d30], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGINT: SIG_IGN, sa_mask[0]=00000000000000000000000000000000, >> sa_flags=none <------------------------------------------------- user >> can get hint from here >> SIGTERM: [libjvm.so+0x894d30], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGQUIT: [libjvm.so+0x894d30], >> sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> Let me know if it is OK. >> >> Thanks >> Yumin >> >> On 3/14/2014 10:22 AM, Karen Kinnear wrote: >>> Yumin, >>> >>> I had the same question. >>> >>> Another possibility would be to leave the check in, and to add a comment >>> after reporting SIGINT as SIG_IGN that this could be an artifact of >>> running in a non-interactive shell >>> >>> opinions? >>> >>> thanks, >>> Karen >>> >>> On Mar 14, 2014, at 1:17 PM, Yumin Qi wrote: >>> >>>> Karen, >>>> >>>> I agree only report non-interactive shell warning --- if under >>>> other case user replace the signal handler, we should give warning. >>>> This lets me think of the fix one more time, do we really want to >>>> silent for non-reactive shell? It is no harm for customer knows what >>>> happened --- it is the shell replace the handler. If user understand >>>> that, it is OK I think. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/14/2014 10:10 AM, Karen Kinnear wrote: >>>>> #define SHUTDOWN_SIGNAL1 SIGINT >>>>> >>>>> I also wondered about checking if the current SIGINT interrupt >>>>> handler setting was >>>>> SIG_IGN. >>>>> >>>>> The question is - do we want to only not report for non-interactive >>>>> or for anyone who >>>>> has set SIG_IGN? I was leaning in the direction of non-interactive. >>>>> >>>>> thanks >>>>> Karen >>>>> >>>>> On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: >>>>> >>>>>> Dmitry, >>>>>> >>>>>> #define INTERRUPT_SIGNAL SIGUSR1 >>>>>> >>>>>> I think this is not SIGINT. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>>>>>> Dmitry, >>>>>>> >>>>>>> case INTERRUPT_SIGNAL: >>>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>>> break; >>>>>>> >>>>>>> Do you mean we use >>>>>>> if (isatty(fileno(stdin))) >>>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>>> else >>>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>>>>>> >>>>>>> I think this will solve the problem. Need more opinions. >>>>>>> >>>>>>> Under redirecting, isatty still can correctly tests for >>>>>>> non-interactive shell, please check bug comments. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> >>>>>>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>>>>>> Yumin. >>>>>>>> >>>>>>>> I find the only place per os_*.cpp where we check for SIGINT >>>>>>>> >>>>>>>> os/linux/vm/os_linux.cpp >>>>>>>> >>>>>>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>>>>>> >>>>>>>> so it might make sense to place it under >>>>>>>> >>>>>>>> if isatty() {} >>>>>>>> >>>>>>>> rather than change macro. >>>>>>>> >>>>>>>> Also isatty() call is expensive and will not give you expected >>>>>>>> result if >>>>>>>> stdin is redirected (e.g. by custom launcher) >>>>>>>> >>>>>>>> >>>>>>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>>>>>> and skip the check in this case. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>>>>>> Have changed, new URL at: >>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>>>>>> Thanks for review. I will change the order. >>>>>>>>>> >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>>>>>> >>>>>>>>>>> You might want to reverse that: >>>>>>>>>>> >>>>>>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>>>>>> >>>>>>>>>>> because isatty() could be expensive. >>>>>>>>>>> >>>>>>>>>>> dl >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>> David and all, >>>>>>>>>>>> >>>>>>>>>>>> I have changed to skip SIGINT only if run in a >>>>>>>>>>>> non-interactive >>>>>>>>>>>> shell. Please check webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>>>>>> >>>>>>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> That said I don't know what utility the signal checks >>>>>>>>>>>>>> provide in >>>>>>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>>>>>> Forget to mention tests: >>>>>>>>>>>>>>> JPRT test; >>>>>>>>>>>>>>> manually testing on Java2Demo, for both shell and >>>>>>>>>>>>>>> non-interactive >>>>>>>>>>>>>>> shell. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>>>>>> non-interactive >>>>>>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>>>>>> warning for >>>>>>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to >>>>>>>>>>>>>>>> SIG_IGN as >>>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>>>>>> handlers >>>>>>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>> except for Windows. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Yumin > From karen.kinnear at oracle.com Fri Mar 14 19:56:24 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 14 Mar 2014 15:56:24 -0400 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <53234BE7.6030908@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> <53233997.9040301@oracle.com> <53234BE7.6030908@oracle.com> Message-ID: <20E43012-2B34-4F36-AB10-2AF50CD8E593@oracle.com> Yumin, Thank you so much - I like this one better. Can you please fix two things in the comment lines. non-reactive is non-interactive SIGIGN is SIG_IGN thanks, Karen On Mar 14, 2014, at 2:35 PM, Yumin Qi wrote: > Karen and all, > > http://cr.openjdk.java.net/~minqi/6536943/webrev03/ > > This version only still keeps original version of checking for signal plus more info printout like: > > Warning: SIGINT handler expected:libjvm.so+0x894d30 found:0x0000000000000001 > Running in non-interactive shell, SIGINT handler is replaced by shell <--------------------------- newly added output > Signal Handlers: > SIGSEGV: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR1: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none > SIGUSR2: [libjvm.so+0x893710], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: SIG_IGN, sa_mask[0]=00000000000000000000000000000000, sa_flags=none <------------------------------------------------- user can get hint from here > SIGTERM: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO > > Let me know if it is OK. > > Thanks > Yumin > > On 3/14/2014 10:22 AM, Karen Kinnear wrote: >> Yumin, >> >> I had the same question. >> >> Another possibility would be to leave the check in, and to add a comment >> after reporting SIGINT as SIG_IGN that this could be an artifact of running in a non-interactive shell >> >> opinions? >> >> thanks, >> Karen >> >> On Mar 14, 2014, at 1:17 PM, Yumin Qi wrote: >> >>> Karen, >>> >>> I agree only report non-interactive shell warning --- if under other case user replace the signal handler, we should give warning. This lets me think of the fix one more time, do we really want to silent for non-reactive shell? It is no harm for customer knows what happened --- it is the shell replace the handler. If user understand that, it is OK I think. >>> >>> Thanks >>> Yumin >>> >>> On 3/14/2014 10:10 AM, Karen Kinnear wrote: >>>> #define SHUTDOWN_SIGNAL1 SIGINT >>>> >>>> I also wondered about checking if the current SIGINT interrupt handler setting was >>>> SIG_IGN. >>>> >>>> The question is - do we want to only not report for non-interactive or for anyone who >>>> has set SIG_IGN? I was leaning in the direction of non-interactive. >>>> >>>> thanks >>>> Karen >>>> >>>> On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: >>>> >>>>> Dmitry, >>>>> >>>>> #define INTERRUPT_SIGNAL SIGUSR1 >>>>> >>>>> I think this is not SIGINT. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>>>>> Dmitry, >>>>>> >>>>>> case INTERRUPT_SIGNAL: >>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>> break; >>>>>> >>>>>> Do you mean we use >>>>>> if (isatty(fileno(stdin))) >>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>> else >>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>>>>> >>>>>> I think this will solve the problem. Need more opinions. >>>>>> >>>>>> Under redirecting, isatty still can correctly tests for non-interactive shell, please check bug comments. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> >>>>>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>>>>> Yumin. >>>>>>> >>>>>>> I find the only place per os_*.cpp where we check for SIGINT >>>>>>> >>>>>>> os/linux/vm/os_linux.cpp >>>>>>> >>>>>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>>>>> >>>>>>> so it might make sense to place it under >>>>>>> >>>>>>> if isatty() {} >>>>>>> >>>>>>> rather than change macro. >>>>>>> >>>>>>> Also isatty() call is expensive and will not give you expected result if >>>>>>> stdin is redirected (e.g. by custom launcher) >>>>>>> >>>>>>> >>>>>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>>>>> and skip the check in this case. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>>>>> Have changed, new URL at: >>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>>>>> >>>>>>>> Thanks >>>>>>>> Yumin >>>>>>>> >>>>>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>>>>> Thanks for review. I will change the order. >>>>>>>>> >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>>>>> >>>>>>>>>> You might want to reverse that: >>>>>>>>>> >>>>>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>>>>> >>>>>>>>>> because isatty() could be expensive. >>>>>>>>>> >>>>>>>>>> dl >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>>>>> David and all, >>>>>>>>>>> >>>>>>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>>>>>> shell. Please check webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Yumin >>>>>>>>>>> >>>>>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>>>>> >>>>>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>>>>> Forget to mention tests: >>>>>>>>>>>>>> JPRT test; >>>>>>>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>>>>>>> shell. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>>>>> non-interactive >>>>>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>>>>> warning for >>>>>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>>>>> handlers >>>>>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>> except for Windows. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin > From yumin.qi at oracle.com Fri Mar 14 19:57:59 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 14 Mar 2014 12:57:59 -0700 Subject: RFR: 6536943: Bogus -Xcheck:jni warning for SIG_INT action for SIGINT in JVM started from non-interactive shell In-Reply-To: <20E43012-2B34-4F36-AB10-2AF50CD8E593@oracle.com> References: <5320D716.3030008@oracle.com> <5320F3D9.1000708@oracle.com> <53213D35.2080205@oracle.com> <5321CC88.3040401@oracle.com> <532222CD.7070504@oracle.com> <532230F9.9090305@oracle.com> <53223AF5.1000007@oracle.com> <53228314.2020409@oracle.com> <532328D7.6090506@oracle.com> <53232E06.3060406@oracle.com> <53233503.1020807@oracle.com> <9B1636E7-264C-42D7-B4DE-7BAAD059C8A1@oracle.com> <53233997.9040301@oracle.com> <53234BE7.6030908@oracle.com> <20E43012-2B34-4F36-AB10-2AF50CD8E593@oracle.com> Message-ID: <53235F47.6030308@oracle.com> Thanks for your review, I will change in the webrev and push work too. No further notifications. Yumin On 3/14/2014 12:56 PM, Karen Kinnear wrote: > Yumin, > > Thank you so much - I like this one better. > > Can you please fix two things in the comment lines. > non-reactive is non-interactive > SIGIGN is SIG_IGN > > thanks, > Karen > > On Mar 14, 2014, at 2:35 PM, Yumin Qi wrote: > >> Karen and all, >> >> http://cr.openjdk.java.net/~minqi/6536943/webrev03/ >> >> This version only still keeps original version of checking for signal plus more info printout like: >> >> Warning: SIGINT handler expected:libjvm.so+0x894d30 found:0x0000000000000001 >> Running in non-interactive shell, SIGINT handler is replaced by shell <--------------------------- newly added output >> Signal Handlers: >> SIGSEGV: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGBUS: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGFPE: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGPIPE: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGXFSZ: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGILL: [libjvm.so+0x892040], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGUSR1: SIG_DFL, sa_mask[0]=00000000000000000000000000000000, sa_flags=none >> SIGUSR2: [libjvm.so+0x893710], sa_mask[0]=00000000000000000000000000000000, sa_flags=SA_RESTART|SA_SIGINFO >> SIGHUP: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGINT: SIG_IGN, sa_mask[0]=00000000000000000000000000000000, sa_flags=none <------------------------------------------------- user can get hint from here >> SIGTERM: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> SIGQUIT: [libjvm.so+0x894d30], sa_mask[0]=11111111011111111101111111111110, sa_flags=SA_RESTART|SA_SIGINFO >> >> Let me know if it is OK. >> >> Thanks >> Yumin >> >> On 3/14/2014 10:22 AM, Karen Kinnear wrote: >>> Yumin, >>> >>> I had the same question. >>> >>> Another possibility would be to leave the check in, and to add a comment >>> after reporting SIGINT as SIG_IGN that this could be an artifact of running in a non-interactive shell >>> >>> opinions? >>> >>> thanks, >>> Karen >>> >>> On Mar 14, 2014, at 1:17 PM, Yumin Qi wrote: >>> >>>> Karen, >>>> >>>> I agree only report non-interactive shell warning --- if under other case user replace the signal handler, we should give warning. This lets me think of the fix one more time, do we really want to silent for non-reactive shell? It is no harm for customer knows what happened --- it is the shell replace the handler. If user understand that, it is OK I think. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 3/14/2014 10:10 AM, Karen Kinnear wrote: >>>>> #define SHUTDOWN_SIGNAL1 SIGINT >>>>> >>>>> I also wondered about checking if the current SIGINT interrupt handler setting was >>>>> SIG_IGN. >>>>> >>>>> The question is - do we want to only not report for non-interactive or for anyone who >>>>> has set SIG_IGN? I was leaning in the direction of non-interactive. >>>>> >>>>> thanks >>>>> Karen >>>>> >>>>> On Mar 14, 2014, at 12:57 PM, Yumin Qi wrote: >>>>> >>>>>> Dmitry, >>>>>> >>>>>> #define INTERRUPT_SIGNAL SIGUSR1 >>>>>> >>>>>> I think this is not SIGINT. >>>>>> >>>>>> Thanks >>>>>> Yumin >>>>>> >>>>>> On 3/14/2014 9:27 AM, Yumin Qi wrote: >>>>>>> Dmitry, >>>>>>> >>>>>>> case INTERRUPT_SIGNAL: >>>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>>> break; >>>>>>> >>>>>>> Do you mean we use >>>>>>> if (isatty(fileno(stdin))) >>>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_DFL); >>>>>>> else >>>>>>> jvmHandler = CAST_FROM_FN_PTR(address, SIG_IGN); >>>>>>> >>>>>>> I think this will solve the problem. Need more opinions. >>>>>>> >>>>>>> Under redirecting, isatty still can correctly tests for non-interactive shell, please check bug comments. >>>>>>> >>>>>>> Thanks >>>>>>> Yumin >>>>>>> >>>>>>> >>>>>>> On 3/14/2014 9:05 AM, Dmitry Samersoff wrote: >>>>>>>> Yumin. >>>>>>>> >>>>>>>> I find the only place per os_*.cpp where we check for SIGINT >>>>>>>> >>>>>>>> os/linux/vm/os_linux.cpp >>>>>>>> >>>>>>>> 4498: DO_SIGNAL_CHECK(INTERRUPT_SIGNAL); >>>>>>>> >>>>>>>> so it might make sense to place it under >>>>>>>> >>>>>>>> if isatty() {} >>>>>>>> >>>>>>>> rather than change macro. >>>>>>>> >>>>>>>> Also isatty() call is expensive and will not give you expected result if >>>>>>>> stdin is redirected (e.g. by custom launcher) >>>>>>>> >>>>>>>> >>>>>>>> I think it's safe to check whether the handler for SIGINT is SIG_IGN >>>>>>>> and skip the check in this case. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2014-03-14 08:18, Yumin Qi wrote: >>>>>>>>> Have changed, new URL at: >>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev02 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Yumin >>>>>>>>> >>>>>>>>> On 3/13/2014 4:10 PM, Yumin Qi wrote: >>>>>>>>>> Thanks for review. I will change the order. >>>>>>>>>> >>>>>>>>>> Yumin >>>>>>>>>> >>>>>>>>>> On 3/13/2014 3:28 PM, Dean Long wrote: >>>>>>>>>>> (isatty(fileno(stdin)) || sig != SIGINT) >>>>>>>>>>> >>>>>>>>>>> You might want to reverse that: >>>>>>>>>>> >>>>>>>>>>> (sig != SIGINT || isatty(fileno(stdin))) >>>>>>>>>>> >>>>>>>>>>> because isatty() could be expensive. >>>>>>>>>>> >>>>>>>>>>> dl >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/13/2014 2:27 PM, Yumin Qi wrote: >>>>>>>>>>>> David and all, >>>>>>>>>>>> >>>>>>>>>>>> I have changed to skip SIGINT only if run in a non-interactive >>>>>>>>>>>> shell. Please check webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev01/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Yumin >>>>>>>>>>>> >>>>>>>>>>>> On 3/13/2014 8:19 AM, Yumin Qi wrote: >>>>>>>>>>>>> On 3/12/2014 10:08 PM, David Holmes wrote: >>>>>>>>>>>>>> Hi Yumin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not sure that disabling all signal checks because there is a >>>>>>>>>>>>>> problem with one signal is the right solution for this. >>>>>>>>>>>>>> >>>>>>>>>>>>> Or we check if the signal is SIGINT --- skip it only. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Yumin >>>>>>>>>>>>>> That said I don't know what utility the signal checks provide in >>>>>>>>>>>>>> the first place. Can anyone comment on that? >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 13/03/2014 9:55 AM, Yumin Qi wrote: >>>>>>>>>>>>>>> Forget to mention tests: >>>>>>>>>>>>>>> JPRT test; >>>>>>>>>>>>>>> manually testing on Java2Demo, for both shell and non-interactive >>>>>>>>>>>>>>> shell. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is only disabling checking signal handlers under >>>>>>>>>>>>>>> non-interactive >>>>>>>>>>>>>>> shell, so no need to test more. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Yumin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/12/2014 2:52 PM, Yumin Qi wrote: >>>>>>>>>>>>>>>> Hi, Can I have your codereview for this simple change: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/6536943/webrev00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary: Under non-interactive shell, -Xcheck:jni output >>>>>>>>>>>>>>>> warning for >>>>>>>>>>>>>>>> SIGINT, since non-interactive shells set SIGINT to SIG_IGN as >>>>>>>>>>>>>>>> part of >>>>>>>>>>>>>>>> the job control features. The fix is that don't check signal >>>>>>>>>>>>>>>> handlers >>>>>>>>>>>>>>>> if java run in a non-interactive shell. This applies to all >>>>>>>>>>>>>>>> platforms >>>>>>>>>>>>>>>> except for Windows. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Yumin From magnus.ihse.bursie at oracle.com Mon Mar 17 11:14:15 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Mar 2014 12:14:15 +0100 Subject: [8u] jdk8\hotspot\src\os\windows\vm\version.rc(57) : warning RC4003: not enough actual parameters for macro 'STR' In-Reply-To: <52B9A40B.70001@orange.fr> References: <52B9A40B.70001@orange.fr> Message-ID: <5326D907.4090801@oracle.com> Picking up an old mail that was cross-posted to build-dev some time ago... It never seems anyone on the hotspot list replied to this. Since it's pure hotspot code it's out of scope for the build-dev list. While this is a minor fix, we do want to get rid of warnings, and I think we should acknowledge all attributions from the community, and at the very least reply to them. If the fix is not working or not needed, a reply stating that would be good. /Magnus On 2013-12-24 16:11, Francis ANDRE wrote: > Hi > > > On windows, the jdk8\hotspot\src\os\windows\vm\version.rc at line 57 > is missing the HS_COMPANY: > > BEGIN > BLOCK "000004b0" > BEGIN > VALUE "CompanyName", XSTR(HS_COMPANY) "\0" > VALUE "FileDescription", XSTR(HS_FILEDESC) "\0" > VALUE "FileVersion", XSTR(HS_DOTVER) "\0" > VALUE "Full Version", XSTR(HS_BUILD_ID) "\0" > VALUE "InternalName", XSTR(HS_INTERNAL_NAME) "\0" > VALUE "LegalCopyright", XSTR(HS_COPYRIGHT) "\0" > VALUE "OriginalFilename", XSTR(HS_FNAME) "\0" > VALUE "ProductName", XSTR(HS_NAME) "\0" > VALUE "ProductVersion", XSTR(JDK_DOTVER) "\0" > END > > > That is why the resource compiler is producing this warning > > Z:\JDK\jdk8\hotspot\src\os\windows\vm\version.rc(57) : warning RC4003: > not enough actual parameters for macro 'STR' > > > > Here the fix to avoid this warning by setting up the HS_COMPANY to the > COMPANY_NAME variable in make/windows/build.make > > Francis > > --- a/make/windows/build.make > +++ b/make/windows/build.make > @@ -147,6 +147,8 @@ > !endif > !endif > > +HS_COMPANY=$(COMPANY_NAME) > + > # Following the Web Start / Plugin model here.... > # We can have update versions like "01a", but Windows requires > # we use only integers in the file version field. So: > > > From coleen.phillimore at oracle.com Mon Mar 17 15:57:55 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 17 Mar 2014 11:57:55 -0400 Subject: RFR 8036630: Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array In-Reply-To: <53234581.80000@oracle.com> References: <53234581.80000@oracle.com> Message-ID: <53271B83.60802@oracle.com> I copied over the webrev now. It's a small review. Thanks, Coleen On 3/14/14 2:08 PM, Coleen Phillimore wrote: > Summary: Call ProtectionDomain constructor instead of making all > fields null. > > bug link https://bugs.openjdk.java.net/browse/JDK-8036630 > > hotspot change: > > open webrev at http://cr.openjdk.java.net/~coleenp/8036630/ > > Tested with jdk/test/java/security, and jck lang, vm, and > api/java_lang tests, and manual test. > > Thanks, > Coleen From frederic.parain at oracle.com Mon Mar 17 16:28:07 2014 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 17 Mar 2014 17:28:07 +0100 Subject: RFR 8036630: Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array In-Reply-To: <53271B83.60802@oracle.com> References: <53234581.80000@oracle.com> <53271B83.60802@oracle.com> Message-ID: <53272297.6050702@oracle.com> Coleen, Looks good to me. Fred On 17/03/2014 16:57, Coleen Phillimore wrote: > > I copied over the webrev now. It's a small review. > Thanks, > Coleen > > On 3/14/14 2:08 PM, Coleen Phillimore wrote: >> Summary: Call ProtectionDomain constructor instead of making all >> fields null. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8036630 >> >> hotspot change: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8036630/ >> >> Tested with jdk/test/java/security, and jck lang, vm, and >> api/java_lang tests, and manual test. >> >> Thanks, >> Coleen > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From coleen.phillimore at oracle.com Mon Mar 17 17:00:42 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 17 Mar 2014 13:00:42 -0400 Subject: RFR 8036630: Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array In-Reply-To: <53272297.6050702@oracle.com> References: <53234581.80000@oracle.com> <53271B83.60802@oracle.com> <53272297.6050702@oracle.com> Message-ID: <53272A3A.3050409@oracle.com> Thanks, Fred! Coleen On 3/17/14 12:28 PM, frederic parain wrote: > Coleen, > > Looks good to me. > > Fred > > On 17/03/2014 16:57, Coleen Phillimore wrote: >> >> I copied over the webrev now. It's a small review. >> Thanks, >> Coleen >> >> On 3/14/14 2:08 PM, Coleen Phillimore wrote: >>> Summary: Call ProtectionDomain constructor instead of making all >>> fields null. >>> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8036630 >>> >>> hotspot change: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8036630/ >>> >>> Tested with jdk/test/java/security, and jck lang, vm, and >>> api/java_lang tests, and manual test. >>> >>> Thanks, >>> Coleen >> > From dmitry.samersoff at oracle.com Mon Mar 17 22:01:11 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 18 Mar 2014 02:01:11 +0400 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C39813076@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> <531F6323.1010109@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39812EC9@DEWDFEMB20C.global.corp.sap> <53209A8A.6070601@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39813076@DEWDFEMB20C.global.corp.sap> Message-ID: <532770A7.3080705@oracle.com> Axel, The changes it self looks good for me. But it looks like the owning_thread is always NULL if owner is NULL, so we can safely move this code to ll.1017 and join two identical ifs together. Also comment on ll. 1019 is misleading, could you remove it? -Dmitry On 2014-03-13 12:19, Siebenborn, Axel wrote: > Hi Serguei, > new webrev: > http://www.sapjvm.com/as/webrevs/8036666_2/ > I should review my own changes more carefully. > Sorry for that. > Thanks, > Axel > > > > On 12.03.2014 18:34, serguei.spitsyn at oracle.com wrote: >> Hi Axel, >> >> Thank you for the changes! It looks good, but one more place need a >> fix (expected must be 4 now): >> >> 230 if (recursionCount != 4) { 231 throw new >> AssertionError("recursions: expected 3, but was " + recursionCount); >> 232 } >> >> >> Thanks, Serguei >> >> >> On 3/12/14 8:21 AM, Siebenborn, Axel wrote: >>> Hi Serguei, I created a new webrev: >>> >>> http://www.sapjvm.com/as/webrevs/8036666_1/ >>> >>> I incorporated your suggestions and moved the test files. >>> >>> Thanks, Axel >>> >>> >>> On 11.03.2014 20:25, serguei.spitsyn at oracle.com wrote: >>>> On 3/11/14 12:05 PM, Staffan Larsen wrote: >>>>> On 11 mar 2014, at 16:48, Siebenborn, Axel >>>>> > >>>>> wrote: >>>>>> Hi Seguei, I still can't upload files to the cr.openjdk >>>>>> server. Meanwhile, I use our server for the new webrev: >>>>>> >>>>>> http://www.sapjvm.com/as/webrevs/8036666/ >>>>>> >>>>>> Thanks, Axel >>>>>> >>>>>> Comments inline: >>>>>> >>>>>> On 11.03.2014 09:50,serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>>> Hi Axel, >>>>>>> >>>>>>> The webrev link is resolvable now. Thank you for taking >>>>>>> care about your broken account on the cr.openjdk server! >>>>>>> >>>>>>> I have some comments on the test case ... >>>>>>> >>>>>>> - This is nice test, thank you for providing it! >>>>>>> >>>>>>> - The location of the test must be different as it is a >>>>>>> JVMTI test: test/serviceability/jvmti/8036666 instead of >>>>>>> test/runtime/8036666 >>>>>> I moved the test. >>>>> Tests should avoid the bug number in the name or path and >>>>> instead use a descriptive name. See this page for some >>>>> background: >>>>> https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests >>>> >>>>> > The test files have already descriptive names. >>>> So, it would be enough to remove the bug number from the path. >>>> Sorry, I had to catch it too in the first place. >>>> >>>> Thanks, Serguei >>>>> Thanks, /Staffan >>>>>>> RecursiveObjectLock,java: >>>>>>> >>>>>>> - A suggestion to add a synchronized method (say, >>>>>>> nestedLock3) into the chain of calls started from the >>>>>>> testMethod. In order to do so, the class >>>>>>> RecursiveObjectLock needs to extend the ALock class. And >>>>>>> the this object needs to be used in the synchronized >>>>>>> statements and for wait()? What do you think about such >>>>>>> test enhancement for better coverage? >>>>>> In order to have a synchronized method in the call chain, I >>>>>> synchronize on the "this" object. >>>>>>> GetObjectLockCount.java: >>>>>>> >>>>>>> - The comment line 283 seems to be obsolete as the "param >>>>>>> out" is not present anymore: >>>>>>> >>>>>>> 283 * @param out Stream to copy to >>>>>>> >>>>>>> >>>>>>> - Could you, please, add e.printStackTrace() into the catch >>>>>>> statements at the lines 232 and 300? >>>>>>> >>>>>>> - A question: It seems the errThread and outThread are >>>>>>> started a little bit late. Would it be better to start them >>>>>>> earlier, or it was intentional? >>>>>> You're right! I moved to code up. >>>>>>> Some minor style-related comments (I hope, it is easy to >>>>>>> fix this before push): - Unneeded extra empty lines: >>>>>>> 149, 174-175, 244 - A space is missed before the '{': >>>>>>> 180, 242, 243, 246 - Unneeded extra space after and before >>>>>>> the "(": 235, 297 - The curly brackets '{' do not follow >>>>>>> the common style: 142, 144 >>>>>> I hope I fixed them all and added no new style violations. Do >>>>>> you have a tool to check this? >>>>>>> We still need another reviewer for this fix. I'm ready to >>>>>>> be a sponsor for it. >>>>>>> >>>>>>> Thanks, Serguei >>>>>>> >>>>>>> >>>>>>> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com >>>>>>> wrote: >>>>>>>> Hi Axel, >>>>>>>> >>>>>>>> The webrev link does not work now. I'll check it again >>>>>>>> tomorrow. >>>>>>>> >>>>>>>> Thanks, Serguei >>>>>>>> >>>>>>>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com >>>>>>>> wrote: >>>>>>>>> Hi Axel, >>>>>>>>> >>>>>>>>> Thank you for fixing this issue. I'm reviewing it. It >>>>>>>>> looks good in general, but a little bit more time is >>>>>>>>> needed to look at the tests. >>>>>>>>> >>>>>>>>> Do you need a sponsor for pushing? >>>>>>>>> >>>>>>>>> Thanks, Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> could I have a review for the following change? >>>>>>>>>> >>>>>>>>>> The recursive lock count for an object is not >>>>>>>>>> correct, in cases, where a monitor is inflated after >>>>>>>>>> recursive lightweight locks. In this case, the >>>>>>>>>> recursion count is taken from the heavyweight >>>>>>>>>> monitor, represented by the class ObjectMonitor. >>>>>>>>>> ObjectMonitor::_recursions is the number of times >>>>>>>>>> ObjectMonitor::enter() was called to acquire the lock >>>>>>>>>> minus 1. This counter does not include the recursions >>>>>>>>>> of lightweight locks, that happen before inflating >>>>>>>>>> the monitor and is not equal to the recursion count >>>>>>>>>> from a Java source level point of view. >>>>>>>>>> >>>>>>>>>> I added a test to the webrev to reproduce the >>>>>>>>>> problem. >>>>>>>>>> >>>>>>>>>> The suggested fix is to call count_locked_objects, >>>>>>>>>> even if there's a heavyweight monitor and get the >>>>>>>>>> recursion count by iterating the vframes. >>>>>>>>>> >>>>>>>>>> Bug: >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > Thanks, >>>>>>>>>> >>>>>>>>>> Axel >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From markus.gronlund at oracle.com Tue Mar 18 06:59:26 2014 From: markus.gronlund at oracle.com (Markus Gr?nlund) Date: Mon, 17 Mar 2014 23:59:26 -0700 (PDT) Subject: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME In-Reply-To: <19f64639-c9cc-48db-be06-4ef760e3e9ba@default> References: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> <5322CF2B.6070507@oracle.com> <19f64639-c9cc-48db-be06-4ef760e3e9ba@default> Message-ID: Hi again, I have updated and simplified the change: http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ Thanks in advance Markus -----Original Message----- From: Markus Gr?nlund Sent: den 14 mars 2014 12:12 To: David Holmes Cc: serviceability-dev at openjdk.net; hotspot-runtime-dev Subject: RE: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME Updated: http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ /Markus -----Original Message----- From: David Holmes Sent: den 14 mars 2014 10:43 To: Markus Gr?nlund; serviceability-dev at openjdk.net; hotspot-runtime-dev Subject: Re: RFR(S): 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility Hi Markus, This seems excessively complicated. There is no need to completely duplicate unpackTime the way you have (now we have three methods doing almost the same thing!). clock_gettime availability just shouldn't be an issue these days on our supported platforms, and in any case tying it to supports_monotonic_clock is just misleading as you may have clock_gettime but not a monotonic clock (unlikely but possible). If you are really paranoid about clock_gettime then just use gettimeofday and be done with it. Further if you insisted on taking this approach change the signature to take secs and nsecs as it is pointless converting them to a single nsecs in the caller only to break them back into separate secs and nsecs inside the method! Or if you really feel strongly about this form then change the signature to take the clock as an argument - with a default parameter providing CLOCK_MONOTONIC. But I stick by what I suggested in the bug report. Just use clock_gettime on CLOCK_REALTIME. David On 14/03/2014 7:22 PM, Markus Gr?nlund wrote: > Greetings, > > Kindly asking for reviews for the following changeset: > > 8037340: Linux semaphores are associated with CLOCK_REALTIME and need > relative to absolute time conversion utility > > Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037340 > > Previously, unpackTime() was used to calculate the absolute time value > for passing to sem_timedwait() for waiting on a Semaphore. > > UnpackTime() has been updated to be based on CLOCK_MONOTONIC which > does not work for Semaphores, which are always associated with CLOCK_REALTIME. > > http://linux.die.net/man/3/sem_timedwait > > Thanks > > Markus > From zhengyu.gu at oracle.com Tue Mar 18 16:23:51 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 18 Mar 2014 12:23:51 -0400 Subject: RFR 8036630: Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array In-Reply-To: <53271B83.60802@oracle.com> References: <53234581.80000@oracle.com> <53271B83.60802@oracle.com> Message-ID: Good to me too. -Zhengyu On Mar 17, 2014, at 11:57 AM, Coleen Phillimore wrote: > > I copied over the webrev now. It's a small review. > Thanks, > Coleen > > On 3/14/14 2:08 PM, Coleen Phillimore wrote: >> Summary: Call ProtectionDomain constructor instead of making all fields null. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8036630 >> >> hotspot change: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8036630/ >> >> Tested with jdk/test/java/security, and jck lang, vm, and api/java_lang tests, and manual test. >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Tue Mar 18 17:17:46 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 18 Mar 2014 13:17:46 -0400 Subject: RFR 8036630: Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array In-Reply-To: References: <53234581.80000@oracle.com> <53271B83.60802@oracle.com> Message-ID: <53287FBA.9030702@oracle.com> Thanks Zhengyu. Coleen On 3/18/14 12:23 PM, Zhengyu Gu wrote: > Good to me too. > > -Zhengyu > > On Mar 17, 2014, at 11:57 AM, Coleen Phillimore wrote: > >> I copied over the webrev now. It's a small review. >> Thanks, >> Coleen >> >> On 3/14/14 2:08 PM, Coleen Phillimore wrote: >>> Summary: Call ProtectionDomain constructor instead of making all fields null. >>> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8036630 >>> >>> hotspot change: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8036630/ >>> >>> Tested with jdk/test/java/security, and jck lang, vm, and api/java_lang tests, and manual test. >>> >>> Thanks, >>> Coleen From axel.siebenborn at sap.com Wed Mar 19 08:05:40 2014 From: axel.siebenborn at sap.com (Siebenborn, Axel) Date: Wed, 19 Mar 2014 08:05:40 +0000 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <532770A7.3080705@oracle.com> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> <531F6323.1010109@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39812EC9@DEWDFEMB20C.global.corp.sap> <53209A8A.6070601@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39813076@DEWDFEMB20C.global.corp.sap> <532770A7.3080705@oracle.com> Message-ID: <02D5D45C1F8DB848A7AE20E80EE61A5C398147F8@DEWDFEMB20C.global.corp.sap> Hi Dmitri, Thank you for the review. You're right, the code gets cleaner this way. New webrev: http://www.sapjvm.com/as/webrevs/8036666_3/ Thanks, Axel On 17.03.2014 23:01, Dmitry Samersoff wrote: > Axel, > > The changes it self looks good for me. > > But it looks like the owning_thread is always NULL if > owner is NULL, so we can safely move this code > to ll.1017 and join two identical ifs together. > > Also comment on ll. 1019 is misleading, could you remove it? > > -Dmitry > > On 2014-03-13 12:19, Siebenborn, Axel wrote: >> Hi Serguei, >> new webrev: >> http://www.sapjvm.com/as/webrevs/8036666_2/ >> I should review my own changes more carefully. >> Sorry for that. >> Thanks, >> Axel >> >> >> >> On 12.03.2014 18:34, serguei.spitsyn at oracle.com wrote: >>> Hi Axel, >>> >>> Thank you for the changes! It looks good, but one more place need a >>> fix (expected must be 4 now): >>> >>> 230 if (recursionCount != 4) { 231 throw new >>> AssertionError("recursions: expected 3, but was " + recursionCount); >>> 232 } >>> >>> >>> Thanks, Serguei >>> >>> >>> On 3/12/14 8:21 AM, Siebenborn, Axel wrote: >>>> Hi Serguei, I created a new webrev: >>>> >>>> http://www.sapjvm.com/as/webrevs/8036666_1/ >>>> >>>> I incorporated your suggestions and moved the test files. >>>> >>>> Thanks, Axel >>>> >>>> >>>> On 11.03.2014 20:25, serguei.spitsyn at oracle.com wrote: >>>>> On 3/11/14 12:05 PM, Staffan Larsen wrote: >>>>>> On 11 mar 2014, at 16:48, Siebenborn, Axel >>>>>> > >>>>>> wrote: >>>>>>> Hi Seguei, I still can't upload files to the cr.openjdk >>>>>>> server. Meanwhile, I use our server for the new webrev: >>>>>>> >>>>>>> http://www.sapjvm.com/as/webrevs/8036666/ >>>>>>> >>>>>>> Thanks, Axel >>>>>>> >>>>>>> Comments inline: >>>>>>> >>>>>>> On 11.03.2014 09:50,serguei.spitsyn at oracle.com >>>>>>> wrote: >>>>>>>> Hi Axel, >>>>>>>> >>>>>>>> The webrev link is resolvable now. Thank you for taking >>>>>>>> care about your broken account on the cr.openjdk server! >>>>>>>> >>>>>>>> I have some comments on the test case ... >>>>>>>> >>>>>>>> - This is nice test, thank you for providing it! >>>>>>>> >>>>>>>> - The location of the test must be different as it is a >>>>>>>> JVMTI test: test/serviceability/jvmti/8036666 instead of >>>>>>>> test/runtime/8036666 >>>>>>> I moved the test. >>>>>> Tests should avoid the bug number in the name or path and >>>>>> instead use a descriptive name. See this page for some >>>>>> background: >>>>>> https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests >>>>> >>>>>> >> The test files have already descriptive names. >>>>> So, it would be enough to remove the bug number from the path. >>>>> Sorry, I had to catch it too in the first place. >>>>> >>>>> Thanks, Serguei >>>>>> Thanks, /Staffan >>>>>>>> RecursiveObjectLock,java: >>>>>>>> >>>>>>>> - A suggestion to add a synchronized method (say, >>>>>>>> nestedLock3) into the chain of calls started from the >>>>>>>> testMethod. In order to do so, the class >>>>>>>> RecursiveObjectLock needs to extend the ALock class. And >>>>>>>> the this object needs to be used in the synchronized >>>>>>>> statements and for wait()? What do you think about such >>>>>>>> test enhancement for better coverage? >>>>>>> In order to have a synchronized method in the call chain, I >>>>>>> synchronize on the "this" object. >>>>>>>> GetObjectLockCount.java: >>>>>>>> >>>>>>>> - The comment line 283 seems to be obsolete as the "param >>>>>>>> out" is not present anymore: >>>>>>>> >>>>>>>> 283 * @param out Stream to copy to >>>>>>>> >>>>>>>> >>>>>>>> - Could you, please, add e.printStackTrace() into the catch >>>>>>>> statements at the lines 232 and 300? >>>>>>>> >>>>>>>> - A question: It seems the errThread and outThread are >>>>>>>> started a little bit late. Would it be better to start them >>>>>>>> earlier, or it was intentional? >>>>>>> You're right! I moved to code up. >>>>>>>> Some minor style-related comments (I hope, it is easy to >>>>>>>> fix this before push): - Unneeded extra empty lines: >>>>>>>> 149, 174-175, 244 - A space is missed before the '{': >>>>>>>> 180, 242, 243, 246 - Unneeded extra space after and before >>>>>>>> the "(": 235, 297 - The curly brackets '{' do not follow >>>>>>>> the common style: 142, 144 >>>>>>> I hope I fixed them all and added no new style violations. Do >>>>>>> you have a tool to check this? >>>>>>>> We still need another reviewer for this fix. I'm ready to >>>>>>>> be a sponsor for it. >>>>>>>> >>>>>>>> Thanks, Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com >>>>>>>> wrote: >>>>>>>>> Hi Axel, >>>>>>>>> >>>>>>>>> The webrev link does not work now. I'll check it again >>>>>>>>> tomorrow. >>>>>>>>> >>>>>>>>> Thanks, Serguei >>>>>>>>> >>>>>>>>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com >>>>>>>>> wrote: >>>>>>>>>> Hi Axel, >>>>>>>>>> >>>>>>>>>> Thank you for fixing this issue. I'm reviewing it. It >>>>>>>>>> looks good in general, but a little bit more time is >>>>>>>>>> needed to look at the tests. >>>>>>>>>> >>>>>>>>>> Do you need a sponsor for pushing? >>>>>>>>>> >>>>>>>>>> Thanks, Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> could I have a review for the following change? >>>>>>>>>>> >>>>>>>>>>> The recursive lock count for an object is not >>>>>>>>>>> correct, in cases, where a monitor is inflated after >>>>>>>>>>> recursive lightweight locks. In this case, the >>>>>>>>>>> recursion count is taken from the heavyweight >>>>>>>>>>> monitor, represented by the class ObjectMonitor. >>>>>>>>>>> ObjectMonitor::_recursions is the number of times >>>>>>>>>>> ObjectMonitor::enter() was called to acquire the lock >>>>>>>>>>> minus 1. This counter does not include the recursions >>>>>>>>>>> of lightweight locks, that happen before inflating >>>>>>>>>>> the monitor and is not equal to the recursion count >>>>>>>>>>> from a Java source level point of view. >>>>>>>>>>> >>>>>>>>>>> I added a test to the webrev to reproduce the >>>>>>>>>>> problem. >>>>>>>>>>> >>>>>>>>>>> The suggested fix is to call count_locked_objects, >>>>>>>>>>> even if there's a heavyweight monitor and get the >>>>>>>>>>> recursion count by iterating the vframes. >>>>>>>>>>> >>>>>>>>>>> Bug: >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> Thanks, >>>>>>>>>>> >>>>>>>>>>> Axel >>> >>> >> > > From david.holmes at oracle.com Wed Mar 19 08:33:24 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Mar 2014 18:33:24 +1000 Subject: RFR 8036630: Null ProtectionDomain in JVM can cause NPE because principals field is not initialized to an empty array In-Reply-To: <53271B83.60802@oracle.com> References: <53234581.80000@oracle.com> <53271B83.60802@oracle.com> Message-ID: <53295654.5090607@oracle.com> Looks good Coleen. Thanks, David On 18/03/2014 1:57 AM, Coleen Phillimore wrote: > > I copied over the webrev now. It's a small review. > Thanks, > Coleen > > On 3/14/14 2:08 PM, Coleen Phillimore wrote: >> Summary: Call ProtectionDomain constructor instead of making all >> fields null. >> >> bug link https://bugs.openjdk.java.net/browse/JDK-8036630 >> >> hotspot change: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8036630/ >> >> Tested with jdk/test/java/security, and jck lang, vm, and >> api/java_lang tests, and manual test. >> >> Thanks, >> Coleen > From david.holmes at oracle.com Wed Mar 19 08:40:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Mar 2014 18:40:29 +1000 Subject: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME In-Reply-To: References: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> <5322CF2B.6070507@oracle.com> <19f64639-c9cc-48db-be06-4ef760e3e9ba@default> Message-ID: <532957FD.1090103@oracle.com> On 18/03/2014 4:59 PM, Markus Gr?nlund wrote: > Hi again, > > I have updated and simplified the change: > > http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ Thanks Markus - this looks good to me. David > Thanks in advance > Markus > > > -----Original Message----- > From: Markus Gr?nlund > Sent: den 14 mars 2014 12:12 > To: David Holmes > Cc: serviceability-dev at openjdk.net; hotspot-runtime-dev > Subject: RE: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME > > Updated: > > http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ > > /Markus > > -----Original Message----- > From: David Holmes > Sent: den 14 mars 2014 10:43 > To: Markus Gr?nlund; serviceability-dev at openjdk.net; hotspot-runtime-dev > Subject: Re: RFR(S): 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility > > Hi Markus, > > This seems excessively complicated. There is no need to completely duplicate unpackTime the way you have (now we have three methods doing almost the same thing!). clock_gettime availability just shouldn't be an issue these days on our supported platforms, and in any case tying it to supports_monotonic_clock is just misleading as you may have clock_gettime but not a monotonic clock (unlikely but possible). If you are really paranoid about clock_gettime then just use gettimeofday and be done with it. > > Further if you insisted on taking this approach change the signature to take secs and nsecs as it is pointless converting them to a single nsecs in the caller only to break them back into separate secs and nsecs inside the method! > > Or if you really feel strongly about this form then change the signature to take the clock as an argument - with a default parameter providing CLOCK_MONOTONIC. > > But I stick by what I suggested in the bug report. Just use clock_gettime on CLOCK_REALTIME. > > David > > On 14/03/2014 7:22 PM, Markus Gr?nlund wrote: >> Greetings, >> >> Kindly asking for reviews for the following changeset: >> >> 8037340: Linux semaphores are associated with CLOCK_REALTIME and need >> relative to absolute time conversion utility >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8037340 >> >> Previously, unpackTime() was used to calculate the absolute time value >> for passing to sem_timedwait() for waiting on a Semaphore. >> >> UnpackTime() has been updated to be based on CLOCK_MONOTONIC which >> does not work for Semaphores, which are always associated with CLOCK_REALTIME. >> >> http://linux.die.net/man/3/sem_timedwait >> >> Thanks >> >> Markus >> From markus.gronlund at oracle.com Wed Mar 19 10:27:05 2014 From: markus.gronlund at oracle.com (Markus Gr?nlund) Date: Wed, 19 Mar 2014 03:27:05 -0700 (PDT) Subject: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME In-Reply-To: <532957FD.1090103@oracle.com> References: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> <5322CF2B.6070507@oracle.com> <19f64639-c9cc-48db-be06-4ef760e3e9ba@default> <532957FD.1090103@oracle.com> Message-ID: Thanks David! /Markus -----Original Message----- From: David Holmes Sent: den 19 mars 2014 09:40 To: Markus Gr?nlund; serviceability-dev at openjdk.net; hotspot-runtime-dev Subject: Re: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME On 18/03/2014 4:59 PM, Markus Gr?nlund wrote: > Hi again, > > I have updated and simplified the change: > > http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ Thanks Markus - this looks good to me. David > Thanks in advance > Markus > > > -----Original Message----- > From: Markus Gr?nlund > Sent: den 14 mars 2014 12:12 > To: David Holmes > Cc: serviceability-dev at openjdk.net; hotspot-runtime-dev > Subject: RE: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME > > Updated: > > http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ > > /Markus > > -----Original Message----- > From: David Holmes > Sent: den 14 mars 2014 10:43 > To: Markus Gr?nlund; serviceability-dev at openjdk.net; > hotspot-runtime-dev > Subject: Re: RFR(S): 8037340: Linux semaphores are associated with > CLOCK_REALTIME and need relative to absolute time conversion utility > > Hi Markus, > > This seems excessively complicated. There is no need to completely duplicate unpackTime the way you have (now we have three methods doing almost the same thing!). clock_gettime availability just shouldn't be an issue these days on our supported platforms, and in any case tying it to supports_monotonic_clock is just misleading as you may have clock_gettime but not a monotonic clock (unlikely but possible). If you are really paranoid about clock_gettime then just use gettimeofday and be done with it. > > Further if you insisted on taking this approach change the signature to take secs and nsecs as it is pointless converting them to a single nsecs in the caller only to break them back into separate secs and nsecs inside the method! > > Or if you really feel strongly about this form then change the signature to take the clock as an argument - with a default parameter providing CLOCK_MONOTONIC. > > But I stick by what I suggested in the bug report. Just use clock_gettime on CLOCK_REALTIME. > > David > > On 14/03/2014 7:22 PM, Markus Gr?nlund wrote: >> Greetings, >> >> Kindly asking for reviews for the following changeset: >> >> 8037340: Linux semaphores are associated with CLOCK_REALTIME and need >> relative to absolute time conversion utility >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8037340 >> >> Previously, unpackTime() was used to calculate the absolute time >> value for passing to sem_timedwait() for waiting on a Semaphore. >> >> UnpackTime() has been updated to be based on CLOCK_MONOTONIC which >> does not work for Semaphores, which are always associated with CLOCK_REALTIME. >> >> http://linux.die.net/man/3/sem_timedwait >> >> Thanks >> >> Markus >> From staffan.larsen at oracle.com Thu Mar 20 10:21:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 20 Mar 2014 11:21:42 +0100 Subject: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME In-Reply-To: References: <309e7adc-2e3d-4080-8d54-c953bf77b259@default> <5322CF2B.6070507@oracle.com> <19f64639-c9cc-48db-be06-4ef760e3e9ba@default> Message-ID: <33F68BAC-E94E-40F3-80DD-03DBDB9AFA4B@oracle.com> Looks good! Thanks, /Staffan On 18 mar 2014, at 07:59, Markus Gr?nlund wrote: > Hi again, > > I have updated and simplified the change: > > http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ > > Thanks in advance > Markus > > > -----Original Message----- > From: Markus Gr?nlund > Sent: den 14 mars 2014 12:12 > To: David Holmes > Cc: serviceability-dev at openjdk.net; hotspot-runtime-dev > Subject: RE: RFR(S): 8037340: Linux semaphores to use CLOCK_REALTIME > > Updated: > > http://cr.openjdk.java.net/~mgronlun/8037340/webrev02/ > > /Markus > > -----Original Message----- > From: David Holmes > Sent: den 14 mars 2014 10:43 > To: Markus Gr?nlund; serviceability-dev at openjdk.net; hotspot-runtime-dev > Subject: Re: RFR(S): 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility > > Hi Markus, > > This seems excessively complicated. There is no need to completely duplicate unpackTime the way you have (now we have three methods doing almost the same thing!). clock_gettime availability just shouldn't be an issue these days on our supported platforms, and in any case tying it to supports_monotonic_clock is just misleading as you may have clock_gettime but not a monotonic clock (unlikely but possible). If you are really paranoid about clock_gettime then just use gettimeofday and be done with it. > > Further if you insisted on taking this approach change the signature to take secs and nsecs as it is pointless converting them to a single nsecs in the caller only to break them back into separate secs and nsecs inside the method! > > Or if you really feel strongly about this form then change the signature to take the clock as an argument - with a default parameter providing CLOCK_MONOTONIC. > > But I stick by what I suggested in the bug report. Just use clock_gettime on CLOCK_REALTIME. > > David > > On 14/03/2014 7:22 PM, Markus Gr?nlund wrote: >> Greetings, >> >> Kindly asking for reviews for the following changeset: >> >> 8037340: Linux semaphores are associated with CLOCK_REALTIME and need >> relative to absolute time conversion utility >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8037340 >> >> Previously, unpackTime() was used to calculate the absolute time value >> for passing to sem_timedwait() for waiting on a Semaphore. >> >> UnpackTime() has been updated to be based on CLOCK_MONOTONIC which >> does not work for Semaphores, which are always associated with CLOCK_REALTIME. >> >> http://linux.die.net/man/3/sem_timedwait >> >> Thanks >> >> Markus >> From coleen.phillimore at oracle.com Thu Mar 20 19:39:32 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Mar 2014 15:39:32 -0400 Subject: RFR 8031820: NPG: Fix remaining references to metadata as oops in comments Message-ID: <532B43F4.5030506@oracle.com> Also fixed: 8012125: Comments for ConstantPoolCache should reflect the addition of resolved_references in ConstantPool Summary: Updated comments in metadata header files, and renamed this_oop variables to this_cp or this_k when referring to constant pool or classes. open webrev at http://cr.openjdk.java.net/~coleenp/8031820/ bug link https://bugs.openjdk.java.net/browse/JDK-8031820 Tested with jck, all jtreg hotspot tests and nsk vm.quick.testlist. Thanks, Coleen From calvin.cheung at oracle.com Thu Mar 20 20:49:42 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 20 Mar 2014 13:49:42 -0700 Subject: RFR (XS): 8033566: warning from b128 for hotspot/src/share/vm/runtime/frame.cpp: JNI primitive type mismatch Message-ID: <532B5466.5000501@oracle.com> Please review this small fix for fixing a warning from our internal code analysis tool. The problem is that on 64-bit platforms, the uintptr_t is 64-bit and we tried to return it as a jint which is always 32-bit. A simple fix is to add an assert to make sure the value is <= max_jint before returning it as a jint. bug: https://bugs.openjdk.java.net/browse/JDK-8033566 (internal, below is the details) Expecting value of JNI primitive type jint in return at line 536 of jdk8-b128/src/hotspot/src/share/vm/runtime/frame.cpp in function frame::interpreter_frame_expression_stack_size() webrev: http://cr.openjdk.java.net/~ccheung/8033566/webrev/ Tests: jprt jtreg hotspot tests thanks, Calvin From yumin.qi at oracle.com Thu Mar 20 22:33:00 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 20 Mar 2014 15:33:00 -0700 Subject: RFR (XS): 8033566: warning from b128 for hotspot/src/share/vm/runtime/frame.cpp: JNI primitive type mismatch In-Reply-To: <532B5466.5000501@oracle.com> References: <532B5466.5000501@oracle.com> Message-ID: <532B6C9C.9080207@oracle.com> Looks good. Yumin On 3/20/2014 1:49 PM, Calvin Cheung wrote: > Please review this small fix for fixing a warning from our internal code > analysis tool. The problem is that on 64-bit platforms, the uintptr_t is > 64-bit and we tried to return it as a jint which is always 32-bit. > A simple fix is to add an assert to make sure the value is <= max_jint > before returning it as a jint. > > bug: https://bugs.openjdk.java.net/browse/JDK-8033566 > (internal, below is the details) > Expecting value of JNI primitive type jint in return at line 536 of > jdk8-b128/src/hotspot/src/share/vm/runtime/frame.cpp in function > frame::interpreter_frame_expression_stack_size() > > > webrev: http://cr.openjdk.java.net/~ccheung/8033566/webrev/ > > Tests: > jprt > jtreg hotspot tests > > thanks, > Calvin From calvin.cheung at oracle.com Thu Mar 20 22:39:29 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 20 Mar 2014 15:39:29 -0700 Subject: RFR (XS): 8033566: warning from b128 for hotspot/src/share/vm/runtime/frame.cpp: JNI primitive type mismatch In-Reply-To: <532B6C9C.9080207@oracle.com> References: <532B5466.5000501@oracle.com> <532B6C9C.9080207@oracle.com> Message-ID: <532B6E21.6010300@oracle.com> Yumin, thanks for your quick review. Calvin On 3/20/2014 3:33 PM, Yumin Qi wrote: > Looks good. > > Yumin > > On 3/20/2014 1:49 PM, Calvin Cheung wrote: >> Please review this small fix for fixing a warning from our internal code >> analysis tool. The problem is that on 64-bit platforms, the uintptr_t is >> 64-bit and we tried to return it as a jint which is always 32-bit. >> A simple fix is to add an assert to make sure the value is <= max_jint >> before returning it as a jint. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8033566 >> (internal, below is the details) >> Expecting value of JNI primitive type jint in return at line 536 of >> jdk8-b128/src/hotspot/src/share/vm/runtime/frame.cpp in function >> frame::interpreter_frame_expression_stack_size() >> >> >> webrev: http://cr.openjdk.java.net/~ccheung/8033566/webrev/ >> >> Tests: >> jprt >> jtreg hotspot tests >> >> thanks, >> Calvin > From stefan.karlsson at oracle.com Fri Mar 21 09:02:02 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 21 Mar 2014 10:02:02 +0100 Subject: RFR 8031820: NPG: Fix remaining references to metadata as oops in comments In-Reply-To: <532B43F4.5030506@oracle.com> References: <532B43F4.5030506@oracle.com> Message-ID: <532C000A.20508@oracle.com> On 2014-03-20 20:39, Coleen Phillimore wrote: > Also fixed: > 8012125: Comments for ConstantPoolCache should reflect the addition of > resolved_references in ConstantPool > Summary: Updated comments in metadata header files, and renamed > this_oop variables to this_cp or this_k when referring to constant > pool or classes. > > open webrev at http://cr.openjdk.java.net/~coleenp/8031820/ Looks good. Thanks for cleaning this up! Small comments: http://cr.openjdk.java.net/~coleenp/8031820/src/share/vm/oops/constMethod.hpp.frames.html 42 // critical at all. Accessing the checked exceptions table is used by reflection, 43 // so we put that last to make access to it fast. It doesn't look like we put the checked exceptions table at the end of the constMethod. http://cr.openjdk.java.net/~coleenp/8031820/src/share/vm/oops/constantPool.hpp.udiff.html friend class VMStructs; - friend class BytecodeInterpreter; // Directly extracts an oop in the pool for fast instanceof/checkcast + friend class BytecodeInterpreter; // Directly extracts an klass in the pool for fast instanceof/checkcast + friend class Universe; // For null constructor Do we need/want this extra blank line? http://cr.openjdk.java.net/~coleenp/8031820/src/share/vm/oops/cpCache.hpp.udiff.html I haven't verified that this comment is correct. Not related to this patch, but is there a reason why all these functions are static and take a constantPoolHandle as the first parameter, instead of being instance member functions? My guess is that it's just to make sure MetadataOnStackMark finds this_cp. + static Method* method_at_if_loaded (constantPoolHandle this_cp, int which); + static bool has_appendix_at_if_loaded (constantPoolHandle this_cp, int which); + static oop appendix_at_if_loaded (constantPoolHandle this_cp, int which); + static bool has_method_type_at_if_loaded (constantPoolHandle this_cp, int which); + static oop method_type_at_if_loaded (constantPoolHandle this_cp, int which); + static Klass* klass_at_if_loaded (constantPoolHandle this_cp, int which); + static Klass* klass_ref_at_if_loaded (constantPoolHandle this_cp, int which); thanks, StefanK > bug link https://bugs.openjdk.java.net/browse/JDK-8031820 > > Tested with jck, all jtreg hotspot tests and nsk vm.quick.testlist. > > Thanks, > Coleen From poonam.bajaj at oracle.com Fri Mar 21 12:52:35 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Fri, 21 Mar 2014 18:22:35 +0530 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters Message-ID: <532C3613.7030808@oracle.com> Hi, Review request for: JDK-7119643 : It is not possible to read files with a path longer than 2048 characters Problem and Fix: This bug is a regression from 6u29 and exists only on Linux platform. With the fix for 6348631, a limit of MAX_PATH (2K) got introduced on the file path length in the os::open() and os::stat() functions in os_linux.cpp. These changes remove that limit. These changes also add a regression test case to check that the files having path longer than 2048 are read without any error. Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ This fix needs to go into 9, 8u, 7u and 6u. Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerald.thornbrugh at oracle.com Fri Mar 21 14:11:08 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 21 Mar 2014 08:11:08 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup Message-ID: <532C487C.1090004@oracle.com> Hi, I am a member of the Oracle Hotspot group and there is an initiative to clean up things like uninitialized variables and unclosed file descriptors in JDK8. This is a backport of fixes that have already been putback into JDK9. I have run UTE and JPRT tests on Linux machines without problems. The below webrev show the fixes for the Linux area. Bug: This bug is not visible because it has been marked as Oracle confidential. JDK-8033464 describes a JDK8 Linux specific code cleanup to address possible uninitialized variables and unclosed file descriptors. These issues were addressed in the fix. https://bugs.openjdk.java.net/browse/JDK-8033464 Webrev: http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ Please review my changes and let me know if you have questions. Thanks, Gerald Thornbrugh From daniel.daugherty at oracle.com Fri Mar 21 14:30:18 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 21 Mar 2014 08:30:18 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C487C.1090004@oracle.com> References: <532C487C.1090004@oracle.com> Message-ID: <532C4CFA.9050507@oracle.com> > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ src/os/linux/vm/os_linux.cpp No comments. src/os/linux/vm/perfMemory_linux.cpp No comments. Thumbs up! Dan On 3/21/14 8:11 AM, Gerald Thornbrugh wrote: > Hi, > > I am a member of the Oracle Hotspot group and there is an initiative > to clean up > things like uninitialized variables and unclosed file descriptors in > JDK8. This is a > backport of fixes that have already been putback into JDK9. I have run > UTE and > JPRT tests on Linux machines without problems. The below webrev show > the fixes for > the Linux area. > > Bug: > > This bug is not visible because it has been marked as Oracle > confidential. > > JDK-8033464 describes a JDK8 Linux specific code cleanup to address > possible uninitialized variables and unclosed file descriptors. These > issues > were addressed in the fix. > > https://bugs.openjdk.java.net/browse/JDK-8033464 > > > Webrev: > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ > > > > > Please review my changes and let me know if you have questions. > > Thanks, > > Gerald Thornbrugh From gerald.thornbrugh at oracle.com Fri Mar 21 14:30:56 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 21 Mar 2014 08:30:56 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C4CFA.9050507@oracle.com> References: <532C487C.1090004@oracle.com> <532C4CFA.9050507@oracle.com> Message-ID: <532C4D20.2060506@oracle.com> Hi Dan, Thanks for the review. Jerry > > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ > > > src/os/linux/vm/os_linux.cpp > No comments. > > src/os/linux/vm/perfMemory_linux.cpp > No comments. > > Thumbs up! > > Dan > > > On 3/21/14 8:11 AM, Gerald Thornbrugh wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative >> to clean up >> things like uninitialized variables and unclosed file descriptors in >> JDK8. This is a >> backport of fixes that have already been putback into JDK9. I have >> run UTE and >> JPRT tests on Linux machines without problems. The below webrev show >> the fixes for >> the Linux area. >> >> Bug: >> >> This bug is not visible because it has been marked as Oracle >> confidential. >> >> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >> possible uninitialized variables and unclosed file descriptors. These >> issues >> were addressed in the fix. >> >> https://bugs.openjdk.java.net/browse/JDK-8033464 >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >> >> >> >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh > From harold.seigel at oracle.com Fri Mar 21 14:35:33 2014 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 21 Mar 2014 10:35:33 -0400 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C487C.1090004@oracle.com> References: <532C487C.1090004@oracle.com> Message-ID: <532C4E35.6080403@oracle.com> Hi Gerald, Is it possible for imin and imax to be equal in get_stack_commited_bottom() ? Could you also run the hotspot jtreg tests? Thanks, Harold On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: > Hi, > > I am a member of the Oracle Hotspot group and there is an initiative > to clean up > things like uninitialized variables and unclosed file descriptors in > JDK8. This is a > backport of fixes that have already been putback into JDK9. I have run > UTE and > JPRT tests on Linux machines without problems. The below webrev show > the fixes for > the Linux area. > > Bug: > > This bug is not visible because it has been marked as Oracle > confidential. > > JDK-8033464 describes a JDK8 Linux specific code cleanup to address > possible uninitialized variables and unclosed file descriptors. These > issues > were addressed in the fix. > > https://bugs.openjdk.java.net/browse/JDK-8033464 > > > Webrev: > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ > > > > > Please review my changes and let me know if you have questions. > > Thanks, > > Gerald Thornbrugh From gerald.thornbrugh at oracle.com Fri Mar 21 14:43:37 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 21 Mar 2014 08:43:37 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C4E35.6080403@oracle.com> References: <532C487C.1090004@oracle.com> <532C4E35.6080403@oracle.com> Message-ID: <532C5019.70404@oracle.com> Hi Harold, There was a long discussion on the assert between myself, Dmitry, Coleen and Dan. The result was that imin and imax should not be equal and to verify this I ran complete JPRT, UTE and Aurora runs with fast debug bits to verify that the assert was correct. Does that answer your questions? Thanks, Gerald Thornbrugh > Hi Gerald, > > Is it possible for imin and imax to be equal in > get_stack_commited_bottom() ? > > Could you also run the hotspot jtreg tests? > > Thanks, Harold > > On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative >> to clean up >> things like uninitialized variables and unclosed file descriptors in >> JDK8. This is a >> backport of fixes that have already been putback into JDK9. I have >> run UTE and >> JPRT tests on Linux machines without problems. The below webrev show >> the fixes for >> the Linux area. >> >> Bug: >> >> This bug is not visible because it has been marked as Oracle >> confidential. >> >> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >> possible uninitialized variables and unclosed file descriptors. These >> issues >> were addressed in the fix. >> >> https://bugs.openjdk.java.net/browse/JDK-8033464 >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >> >> >> >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh > From harold.seigel at oracle.com Fri Mar 21 14:54:47 2014 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 21 Mar 2014 10:54:47 -0400 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C5019.70404@oracle.com> References: <532C487C.1090004@oracle.com> <532C4E35.6080403@oracle.com> <532C5019.70404@oracle.com> Message-ID: <532C52B7.1060302@oracle.com> Hi Gerald, Thanks for the explanation. So, what is actually being asserted is that (size >= page_sz)? Harold On 3/21/2014 10:43 AM, Gerald Thornbrugh wrote: > Hi Harold, > > There was a long discussion on the assert between myself, Dmitry, Coleen > and Dan. The result was that imin and imax should not be equal and to > verify this I ran complete JPRT, UTE and Aurora runs with fast debug > bits to > verify that the assert was correct. > > Does that answer your questions? > > Thanks, > > Gerald Thornbrugh >> Hi Gerald, >> >> Is it possible for imin and imax to be equal in >> get_stack_commited_bottom() ? >> >> Could you also run the hotspot jtreg tests? >> >> Thanks, Harold >> >> On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: >>> Hi, >>> >>> I am a member of the Oracle Hotspot group and there is an initiative >>> to clean up >>> things like uninitialized variables and unclosed file descriptors in >>> JDK8. This is a >>> backport of fixes that have already been putback into JDK9. I have >>> run UTE and >>> JPRT tests on Linux machines without problems. The below webrev show >>> the fixes for >>> the Linux area. >>> >>> Bug: >>> >>> This bug is not visible because it has been marked as Oracle >>> confidential. >>> >>> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >>> possible uninitialized variables and unclosed file descriptors. >>> These issues >>> were addressed in the fix. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8033464 >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >>> >>> >>> >>> >>> Please review my changes and let me know if you have questions. >>> >>> Thanks, >>> >>> Gerald Thornbrugh >> > From gerald.thornbrugh at oracle.com Fri Mar 21 15:01:42 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 21 Mar 2014 09:01:42 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C52B7.1060302@oracle.com> References: <532C487C.1090004@oracle.com> <532C4E35.6080403@oracle.com> <532C5019.70404@oracle.com> <532C52B7.1060302@oracle.com> Message-ID: <532C5456.1090008@oracle.com> Hi Harold, Correct, the assert could have been written a number of ways: (size >= page_sz) (pages > 0) (imin < imax) Thanks, Gerald > Hi Gerald, > > Thanks for the explanation. > > So, what is actually being asserted is that (size >= page_sz)? > > Harold > > On 3/21/2014 10:43 AM, Gerald Thornbrugh wrote: >> Hi Harold, >> >> There was a long discussion on the assert between myself, Dmitry, Coleen >> and Dan. The result was that imin and imax should not be equal and to >> verify this I ran complete JPRT, UTE and Aurora runs with fast debug >> bits to >> verify that the assert was correct. >> >> Does that answer your questions? >> >> Thanks, >> >> Gerald Thornbrugh >>> Hi Gerald, >>> >>> Is it possible for imin and imax to be equal in >>> get_stack_commited_bottom() ? >>> >>> Could you also run the hotspot jtreg tests? >>> >>> Thanks, Harold >>> >>> On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: >>>> Hi, >>>> >>>> I am a member of the Oracle Hotspot group and there is an >>>> initiative to clean up >>>> things like uninitialized variables and unclosed file descriptors >>>> in JDK8. This is a >>>> backport of fixes that have already been putback into JDK9. I have >>>> run UTE and >>>> JPRT tests on Linux machines without problems. The below webrev >>>> show the fixes for >>>> the Linux area. >>>> >>>> Bug: >>>> >>>> This bug is not visible because it has been marked as Oracle >>>> confidential. >>>> >>>> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >>>> possible uninitialized variables and unclosed file descriptors. >>>> These issues >>>> were addressed in the fix. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8033464 >>>> >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >>>> >>>> >>>> >>>> >>>> Please review my changes and let me know if you have questions. >>>> >>>> Thanks, >>>> >>>> Gerald Thornbrugh >>> >> > From coleen.phillimore at oracle.com Fri Mar 21 15:14:28 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 21 Mar 2014 11:14:28 -0400 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C5456.1090008@oracle.com> References: <532C487C.1090004@oracle.com> <532C4E35.6080403@oracle.com> <532C5019.70404@oracle.com> <532C52B7.1060302@oracle.com> <532C5456.1090008@oracle.com> Message-ID: <532C5754.9050905@oracle.com> Jerry, I think the assert should be assert(imin <= imax, "Unexpected page size"); like it is in the jdk9 source code. The assert in this change is from the original change but you had to make it <=. Coleen On 3/21/14 11:01 AM, Gerald Thornbrugh wrote: > Hi Harold, > > Correct, the assert could have been written a number of ways: > > (size >= page_sz) > (pages > 0) > (imin < imax) > > Thanks, > > Gerald >> Hi Gerald, >> >> Thanks for the explanation. >> >> So, what is actually being asserted is that (size >= page_sz)? >> >> Harold >> >> On 3/21/2014 10:43 AM, Gerald Thornbrugh wrote: >>> Hi Harold, >>> >>> There was a long discussion on the assert between myself, Dmitry, >>> Coleen >>> and Dan. The result was that imin and imax should not be equal and to >>> verify this I ran complete JPRT, UTE and Aurora runs with fast debug >>> bits to >>> verify that the assert was correct. >>> >>> Does that answer your questions? >>> >>> Thanks, >>> >>> Gerald Thornbrugh >>>> Hi Gerald, >>>> >>>> Is it possible for imin and imax to be equal in >>>> get_stack_commited_bottom() ? >>>> >>>> Could you also run the hotspot jtreg tests? >>>> >>>> Thanks, Harold >>>> >>>> On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: >>>>> Hi, >>>>> >>>>> I am a member of the Oracle Hotspot group and there is an >>>>> initiative to clean up >>>>> things like uninitialized variables and unclosed file descriptors >>>>> in JDK8. This is a >>>>> backport of fixes that have already been putback into JDK9. I have >>>>> run UTE and >>>>> JPRT tests on Linux machines without problems. The below webrev >>>>> show the fixes for >>>>> the Linux area. >>>>> >>>>> Bug: >>>>> >>>>> This bug is not visible because it has been marked as Oracle >>>>> confidential. >>>>> >>>>> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >>>>> possible uninitialized variables and unclosed file descriptors. >>>>> These issues >>>>> were addressed in the fix. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8033464 >>>>> >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >>>>> >>>>> >>>>> >>>>> >>>>> Please review my changes and let me know if you have questions. >>>>> >>>>> Thanks, >>>>> >>>>> Gerald Thornbrugh >>>> >>> >> > From gerald.thornbrugh at oracle.com Fri Mar 21 15:21:19 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 21 Mar 2014 09:21:19 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C5754.9050905@oracle.com> References: <532C487C.1090004@oracle.com> <532C4E35.6080403@oracle.com> <532C5019.70404@oracle.com> <532C52B7.1060302@oracle.com> <532C5456.1090008@oracle.com> <532C5754.9050905@oracle.com> Message-ID: <532C58EF.7040309@oracle.com> Hi Coleen, You are correct, sorry about that. I must have used the wrong patch file. Thanks! Jerry > Jerry, > > I think the assert should be > > assert(imin <= imax, "Unexpected page size"); > > like it is in the jdk9 source code. The assert in this change is from > the original change but you had to make it <=. > > Coleen > > On 3/21/14 11:01 AM, Gerald Thornbrugh wrote: >> Hi Harold, >> >> Correct, the assert could have been written a number of ways: >> >> (size >= page_sz) >> (pages > 0) >> (imin < imax) >> >> Thanks, >> >> Gerald >>> Hi Gerald, >>> >>> Thanks for the explanation. >>> >>> So, what is actually being asserted is that (size >= page_sz)? >>> >>> Harold >>> >>> On 3/21/2014 10:43 AM, Gerald Thornbrugh wrote: >>>> Hi Harold, >>>> >>>> There was a long discussion on the assert between myself, Dmitry, >>>> Coleen >>>> and Dan. The result was that imin and imax should not be equal and to >>>> verify this I ran complete JPRT, UTE and Aurora runs with fast >>>> debug bits to >>>> verify that the assert was correct. >>>> >>>> Does that answer your questions? >>>> >>>> Thanks, >>>> >>>> Gerald Thornbrugh >>>>> Hi Gerald, >>>>> >>>>> Is it possible for imin and imax to be equal in >>>>> get_stack_commited_bottom() ? >>>>> >>>>> Could you also run the hotspot jtreg tests? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: >>>>>> Hi, >>>>>> >>>>>> I am a member of the Oracle Hotspot group and there is an >>>>>> initiative to clean up >>>>>> things like uninitialized variables and unclosed file descriptors >>>>>> in JDK8. This is a >>>>>> backport of fixes that have already been putback into JDK9. I >>>>>> have run UTE and >>>>>> JPRT tests on Linux machines without problems. The below webrev >>>>>> show the fixes for >>>>>> the Linux area. >>>>>> >>>>>> Bug: >>>>>> >>>>>> This bug is not visible because it has been marked as Oracle >>>>>> confidential. >>>>>> >>>>>> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >>>>>> possible uninitialized variables and unclosed file descriptors. >>>>>> These issues >>>>>> were addressed in the fix. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8033464 >>>>>> >>>>>> >>>>>> Webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please review my changes and let me know if you have questions. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gerald Thornbrugh >>>>> >>>> >>> >> > From gerald.thornbrugh at oracle.com Fri Mar 21 15:27:13 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Fri, 21 Mar 2014 09:27:13 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C58EF.7040309@oracle.com> References: <532C487C.1090004@oracle.com> <532C4E35.6080403@oracle.com> <532C5019.70404@oracle.com> <532C52B7.1060302@oracle.com> <532C5456.1090008@oracle.com> <532C5754.9050905@oracle.com> <532C58EF.7040309@oracle.com> Message-ID: <532C5A51.4060700@oracle.com> Hi Coleen, I have made the change and will retest. If the testing goes well this weekend I will resubmit the code review on Monday. Thanks! Jerry > Hi Coleen, > > You are correct, sorry about that. > I must have used the wrong patch file. > > Thanks! > > Jerry >> Jerry, >> >> I think the assert should be >> >> assert(imin <= imax, "Unexpected page size"); >> >> like it is in the jdk9 source code. The assert in this change is >> from the original change but you had to make it <=. >> >> Coleen >> >> On 3/21/14 11:01 AM, Gerald Thornbrugh wrote: >>> Hi Harold, >>> >>> Correct, the assert could have been written a number of ways: >>> >>> (size >= page_sz) >>> (pages > 0) >>> (imin < imax) >>> >>> Thanks, >>> >>> Gerald >>>> Hi Gerald, >>>> >>>> Thanks for the explanation. >>>> >>>> So, what is actually being asserted is that (size >= page_sz)? >>>> >>>> Harold >>>> >>>> On 3/21/2014 10:43 AM, Gerald Thornbrugh wrote: >>>>> Hi Harold, >>>>> >>>>> There was a long discussion on the assert between myself, Dmitry, >>>>> Coleen >>>>> and Dan. The result was that imin and imax should not be equal >>>>> and to >>>>> verify this I ran complete JPRT, UTE and Aurora runs with fast >>>>> debug bits to >>>>> verify that the assert was correct. >>>>> >>>>> Does that answer your questions? >>>>> >>>>> Thanks, >>>>> >>>>> Gerald Thornbrugh >>>>>> Hi Gerald, >>>>>> >>>>>> Is it possible for imin and imax to be equal in >>>>>> get_stack_commited_bottom() ? >>>>>> >>>>>> Could you also run the hotspot jtreg tests? >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>>> On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I am a member of the Oracle Hotspot group and there is an >>>>>>> initiative to clean up >>>>>>> things like uninitialized variables and unclosed file >>>>>>> descriptors in JDK8. This is a >>>>>>> backport of fixes that have already been putback into JDK9. I >>>>>>> have run UTE and >>>>>>> JPRT tests on Linux machines without problems. The below webrev >>>>>>> show the fixes for >>>>>>> the Linux area. >>>>>>> >>>>>>> Bug: >>>>>>> >>>>>>> This bug is not visible because it has been marked as Oracle >>>>>>> confidential. >>>>>>> >>>>>>> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >>>>>>> possible uninitialized variables and unclosed file descriptors. >>>>>>> These issues >>>>>>> were addressed in the fix. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8033464 >>>>>>> >>>>>>> >>>>>>> Webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review my changes and let me know if you have questions. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gerald Thornbrugh >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Fri Mar 21 15:57:23 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 21 Mar 2014 11:57:23 -0400 Subject: RFR 8031820: NPG: Fix remaining references to metadata as oops in comments In-Reply-To: <532C000A.20508@oracle.com> References: <532B43F4.5030506@oracle.com> <532C000A.20508@oracle.com> Message-ID: <532C6163.1050006@oracle.com> Thank you Stefan for reading the new comments! On 3/21/14 5:02 AM, Stefan Karlsson wrote: > > On 2014-03-20 20:39, Coleen Phillimore wrote: >> Also fixed: >> 8012125: Comments for ConstantPoolCache should reflect the addition >> of resolved_references in ConstantPool >> Summary: Updated comments in metadata header files, and renamed >> this_oop variables to this_cp or this_k when referring to constant >> pool or classes. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8031820/ > > Looks good. Thanks for cleaning this up! > > > Small comments: > > http://cr.openjdk.java.net/~coleenp/8031820/src/share/vm/oops/constMethod.hpp.frames.html > > > 42 // critical at all. Accessing the checked exceptions table is > used by reflection, > 43 // so we put that last to make access to it fast. > > It doesn't look like we put the checked exceptions table at the end of > the constMethod. You're right. This was an old comment moved. I reworked it a bit. See: http://cr.openjdk.java.net/~coleenp/8031820_2 > > > http://cr.openjdk.java.net/~coleenp/8031820/src/share/vm/oops/constantPool.hpp.udiff.html > > > friend class VMStructs; > - friend class BytecodeInterpreter; // Directly extracts an oop in > the pool for fast instanceof/checkcast > + friend class BytecodeInterpreter; // Directly extracts an klass in > the pool for fast instanceof/checkcast > + > friend class Universe; // For null constructor > > Do we need/want this extra blank line? > I took it out. > > http://cr.openjdk.java.net/~coleenp/8031820/src/share/vm/oops/cpCache.hpp.udiff.html > > > I haven't verified that this comment is correct. > > > Not related to this patch, but is there a reason why all these > functions are static and take a constantPoolHandle as the first > parameter, instead of being instance member functions? My guess is > that it's just to make sure MetadataOnStackMark finds this_cp. > > + static Method* method_at_if_loaded (constantPoolHandle > this_cp, int which); > + static bool has_appendix_at_if_loaded (constantPoolHandle > this_cp, int which); > + static oop appendix_at_if_loaded (constantPoolHandle > this_cp, int which); > + static bool has_method_type_at_if_loaded (constantPoolHandle > this_cp, int which); > + static oop method_type_at_if_loaded (constantPoolHandle > this_cp, int which); > + static Klass* klass_at_if_loaded (constantPoolHandle > this_cp, int which); > + static Klass* klass_ref_at_if_loaded (constantPoolHandle > this_cp, int which); > It's historical baggage when they were oops but probably MetadataOnStackMark needs these to be handles, so I've left them in. I think slowly we can turn them into instance member functions but not yet. Thanks! Coleen > > thanks, > StefanK > >> bug link https://bugs.openjdk.java.net/browse/JDK-8031820 >> >> Tested with jck, all jtreg hotspot tests and nsk vm.quick.testlist. >> >> Thanks, >> Coleen > From daniel.daugherty at oracle.com Fri Mar 21 16:35:12 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 21 Mar 2014 10:35:12 -0600 Subject: RFR: JDK-8033464 - Linux code cleanup In-Reply-To: <532C5754.9050905@oracle.com> References: <532C487C.1090004@oracle.com> <532C4E35.6080403@oracle.com> <532C5019.70404@oracle.com> <532C52B7.1060302@oracle.com> <532C5456.1090008@oracle.com> <532C5754.9050905@oracle.com> Message-ID: <532C6A40.6050107@oracle.com> Good catch! I compared with patch file for the original JDK9 change and it matched. However, the assertion error was fixed by a follow up changeset in JDK9. My mistake for not catching this before it went out for wider review. Dan On 3/21/14 9:14 AM, Coleen Phillimore wrote: > Jerry, > > I think the assert should be > > assert(imin <= imax, "Unexpected page size"); > > like it is in the jdk9 source code. The assert in this change is from > the original change but you had to make it <=. > > Coleen > > On 3/21/14 11:01 AM, Gerald Thornbrugh wrote: >> Hi Harold, >> >> Correct, the assert could have been written a number of ways: >> >> (size >= page_sz) >> (pages > 0) >> (imin < imax) >> >> Thanks, >> >> Gerald >>> Hi Gerald, >>> >>> Thanks for the explanation. >>> >>> So, what is actually being asserted is that (size >= page_sz)? >>> >>> Harold >>> >>> On 3/21/2014 10:43 AM, Gerald Thornbrugh wrote: >>>> Hi Harold, >>>> >>>> There was a long discussion on the assert between myself, Dmitry, >>>> Coleen >>>> and Dan. The result was that imin and imax should not be equal and to >>>> verify this I ran complete JPRT, UTE and Aurora runs with fast >>>> debug bits to >>>> verify that the assert was correct. >>>> >>>> Does that answer your questions? >>>> >>>> Thanks, >>>> >>>> Gerald Thornbrugh >>>>> Hi Gerald, >>>>> >>>>> Is it possible for imin and imax to be equal in >>>>> get_stack_commited_bottom() ? >>>>> >>>>> Could you also run the hotspot jtreg tests? >>>>> >>>>> Thanks, Harold >>>>> >>>>> On 3/21/2014 10:11 AM, Gerald Thornbrugh wrote: >>>>>> Hi, >>>>>> >>>>>> I am a member of the Oracle Hotspot group and there is an >>>>>> initiative to clean up >>>>>> things like uninitialized variables and unclosed file descriptors >>>>>> in JDK8. This is a >>>>>> backport of fixes that have already been putback into JDK9. I >>>>>> have run UTE and >>>>>> JPRT tests on Linux machines without problems. The below webrev >>>>>> show the fixes for >>>>>> the Linux area. >>>>>> >>>>>> Bug: >>>>>> >>>>>> This bug is not visible because it has been marked as Oracle >>>>>> confidential. >>>>>> >>>>>> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >>>>>> possible uninitialized variables and unclosed file descriptors. >>>>>> These issues >>>>>> were addressed in the fix. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8033464 >>>>>> >>>>>> >>>>>> Webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/0-jdk8u-hs-dev/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please review my changes and let me know if you have questions. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gerald Thornbrugh >>>>> >>>> >>> >> > > > From dmitry.samersoff at oracle.com Sun Mar 23 19:19:04 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 23 Mar 2014 23:19:04 +0400 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <532C3613.7030808@oracle.com> References: <532C3613.7030808@oracle.com> Message-ID: <532F33A8.3010105@oracle.com> Poonam, 1. MAXPATHLEN == PATH_MAX and it's a system constant that comes from sys/param.h and linux/limits.h so current behavior of hotspot is absolutely correct. Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so this patch makes hotspot behavior inconsistent. Typical value of PATH_MAX is 4096 so it's unclean for me why we have problems with 2048 bytes file. We probably should check our reference build platform. 2. Test could be a pure java. -Dmitry On 2014-03-21 16:52, Poonam Bajaj wrote: > Hi, > > Review request for: > JDK-7119643 : It is > not possible to read files with a path longer than 2048 characters > > Problem and Fix: This bug is a regression from 6u29 and exists only on > Linux platform. With the fix for 6348631, a limit of MAX_PATH (2K) got > introduced on the file path length in the os::open() and os::stat() > functions in os_linux.cpp. These changes remove that limit. These > changes also add a regression test case to check that the files having > path longer than 2048 are read without any error. > > Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ > > This fix needs to go into 9, 8u, 7u and 6u. > > Thanks, > Poonam > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From poonam.bajaj at oracle.com Mon Mar 24 02:55:07 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Mon, 24 Mar 2014 08:25:07 +0530 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <532F33A8.3010105@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> Message-ID: <532F9E8B.9020807@oracle.com> Hi Dmitry, On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: > Poonam, > > 1. > > MAXPATHLEN == PATH_MAX and it's a system constant that comes from > sys/param.h and linux/limits.h so current behavior of hotspot is > absolutely correct. > > Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so this > patch makes hotspot behavior inconsistent. > > Typical value of PATH_MAX is 4096 so it's unclean for me why we have > problems with 2048 bytes file. > > We probably should check our reference build platform. The purpose of this change is to revert back to the same behavior as it was before the fix for 6348631 where we didn't have any path limitation in os::open() and os::stat() functions. But yes, you are right. We have the following in sys/param.h and linux/limits.h for the maximum allowed path length on linux platforms: #define PATH_MAX 4096 /* # chars in a path name including nul */ #define MAXPATHLEN PATH_MAX and MAXPATHLEN is also used in os_linux.cpp. So, if we have to insert the path limitation in os::open() and os::stat(), we should be using MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH defined and to a different value than MAXPATHLEN which is inconsistent with the linux definition? > 2. > > Test could be a pure java. Ok, will do. Thanks, Poonam > > -Dmitry > > On 2014-03-21 16:52, Poonam Bajaj wrote: >> Hi, >> >> Review request for: >> JDK-7119643: It is >> not possible to read files with a path longer than 2048 characters >> >> Problem and Fix: This bug is a regression from 6u29 and exists only on >> Linux platform. With the fix for 6348631, a limit of MAX_PATH (2K) got >> introduced on the file path length in the os::open() and os::stat() >> functions in os_linux.cpp. These changes remove that limit. These >> changes also add a regression test case to check that the files having >> path longer than 2048 are read without any error. >> >> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >> >> This fix needs to go into 9, 8u, 7u and 6u. >> >> Thanks, >> Poonam >> > From dmitry.samersoff at oracle.com Mon Mar 24 12:13:53 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 24 Mar 2014 16:13:53 +0400 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <532F9E8B.9020807@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> <532F9E8B.9020807@oracle.com> Message-ID: <53302181.9070204@oracle.com> Poonam, As far as I understand, MAX_PATH is here for a while but later we start using MAXPATHLEN. I would recommend to replace all usage of MAX_PATH and PATH_MAX to MAXPATHLEN if you fill that these changes is go out of scope of JDK-7119643, please replace it inside os:stat() only to solve immediate needs and file a separate CR to have it cleaned up. -Dmitry On 2014-03-24 06:55, Poonam Bajaj wrote: > Hi Dmitry, > > On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: >> Poonam, >> >> 1. >> >> MAXPATHLEN == PATH_MAX and it's a system constant that comes from >> sys/param.h and linux/limits.h so current behavior of hotspot is >> absolutely correct. >> >> Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so this >> patch makes hotspot behavior inconsistent. >> >> Typical value of PATH_MAX is 4096 so it's unclean for me why we have >> problems with 2048 bytes file. >> >> We probably should check our reference build platform. > The purpose of this change is to revert back to the same behavior as it > was before the fix for 6348631 where we didn't have any path limitation > in os::open() and os::stat() functions. > > But yes, you are right. We have the following in sys/param.h and > linux/limits.h for the maximum allowed path length on linux platforms: > #define PATH_MAX 4096 /* # chars in a path name including nul */ > #define MAXPATHLEN PATH_MAX > > and MAXPATHLEN is also used in os_linux.cpp. So, if we have to insert > the path limitation in os::open() and os::stat(), we should be using > MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH defined > and to a different value than MAXPATHLEN which is inconsistent with the > linux definition? > >> 2. >> >> Test could be a pure java. > Ok, will do. > > Thanks, > Poonam >> >> -Dmitry >> >> On 2014-03-21 16:52, Poonam Bajaj wrote: >>> Hi, >>> >>> Review request for: >>> JDK-7119643: It is >>> not possible to read files with a path longer than 2048 characters >>> >>> Problem and Fix: This bug is a regression from 6u29 and exists only on >>> Linux platform. With the fix for 6348631, a limit of MAX_PATH (2K) got >>> introduced on the file path length in the os::open() and os::stat() >>> functions in os_linux.cpp. These changes remove that limit. These >>> changes also add a regression test case to check that the files having >>> path longer than 2048 are read without any error. >>> >>> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >>> >>> This fix needs to go into 9, 8u, 7u and 6u. >>> >>> Thanks, >>> Poonam >>> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From david.holmes at oracle.com Mon Mar 24 12:17:37 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 Mar 2014 22:17:37 +1000 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <53302181.9070204@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> <532F9E8B.9020807@oracle.com> <53302181.9070204@oracle.com> Message-ID: <53302261.4@oracle.com> Dmitry, On 24/03/2014 10:13 PM, Dmitry Samersoff wrote: > Poonam, > > As far as I understand, MAX_PATH is here for a while but later we start > using MAXPATHLEN. > > I would recommend to replace all usage of MAX_PATH and PATH_MAX > to MAXPATHLEN The issue here is to remove the internal limitation. We can't just make the replacement you suggest because we will suddenly be allocating 4KB stack buffers where they were previously 2KB. That is bound to break something. David > if you fill that these changes is go out of scope of JDK-7119643, please > replace it inside os:stat() only to solve immediate needs and file a > separate CR to have it cleaned up. > > -Dmitry > > > On 2014-03-24 06:55, Poonam Bajaj wrote: >> Hi Dmitry, >> >> On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: >>> Poonam, >>> >>> 1. >>> >>> MAXPATHLEN == PATH_MAX and it's a system constant that comes from >>> sys/param.h and linux/limits.h so current behavior of hotspot is >>> absolutely correct. >>> >>> Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so this >>> patch makes hotspot behavior inconsistent. >>> >>> Typical value of PATH_MAX is 4096 so it's unclean for me why we have >>> problems with 2048 bytes file. >>> >>> We probably should check our reference build platform. >> The purpose of this change is to revert back to the same behavior as it >> was before the fix for 6348631 where we didn't have any path limitation >> in os::open() and os::stat() functions. >> >> But yes, you are right. We have the following in sys/param.h and >> linux/limits.h for the maximum allowed path length on linux platforms: >> #define PATH_MAX 4096 /* # chars in a path name including nul */ >> #define MAXPATHLEN PATH_MAX >> >> and MAXPATHLEN is also used in os_linux.cpp. So, if we have to insert >> the path limitation in os::open() and os::stat(), we should be using >> MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH defined >> and to a different value than MAXPATHLEN which is inconsistent with the >> linux definition? >> >>> 2. >>> >>> Test could be a pure java. >> Ok, will do. >> >> Thanks, >> Poonam >>> >>> -Dmitry >>> >>> On 2014-03-21 16:52, Poonam Bajaj wrote: >>>> Hi, >>>> >>>> Review request for: >>>> JDK-7119643: It is >>>> not possible to read files with a path longer than 2048 characters >>>> >>>> Problem and Fix: This bug is a regression from 6u29 and exists only on >>>> Linux platform. With the fix for 6348631, a limit of MAX_PATH (2K) got >>>> introduced on the file path length in the os::open() and os::stat() >>>> functions in os_linux.cpp. These changes remove that limit. These >>>> changes also add a regression test case to check that the files having >>>> path longer than 2048 are read without any error. >>>> >>>> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >>>> >>>> This fix needs to go into 9, 8u, 7u and 6u. >>>> >>>> Thanks, >>>> Poonam >>>> >>> > > From dmitry.samersoff at oracle.com Mon Mar 24 13:06:51 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 24 Mar 2014 17:06:51 +0400 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <53302261.4@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> <532F9E8B.9020807@oracle.com> <53302181.9070204@oracle.com> <53302261.4@oracle.com> Message-ID: <53302DEB.8080508@oracle.com> David, > The issue here is to remove the internal limitation. We can't just > make the replacement you suggest because we will suddenly be > allocating 4KB stack buffers where they were previously 2KB. That is > bound to break something. I share your concern but what we have today[1] is not acceptable. We have to make decision and either go with our own constant MAX_PATH (2*k) with clear justification why we don't follow rest of the linux or use one of system constants: MAXPATHLEN or PAH_MAX. But impact of this cleanup have to be carefully evaluated and probably out of scope of this CR. *As for proposed changes*: I'm against of dynamic allocation in stack based on user input - it can lead to stack overflow in some cases and cause intermittent failures that very hard to debug. So we should either change this value to MAXPATHLEN and hope that testing catch all problems or postpone the changes to complete and careful cleanup. [1] jaja:vm#grep -n PATH_MAX os_linux.cpp 2619: char buf[PATH_MAX+1]; jaja:vm#grep -n MAXPATHLEN os_linux.cpp 379: char buf[MAXPATHLEN]; 2310:static char saved_jvm_path[MAXPATHLEN] = {0}; 2315: if (buflen < MAXPATHLEN) { 2326: char dli_fname[MAXPATHLEN]; 5977: char buf[MAXPATHLEN]; 5978: char libmawtpath[MAXPATHLEN]; jaja:vm#grep -n MAX_PATH os_linux.cpp 110:#define MAX_PATH (2 * K) 5025: char pathbuf[MAX_PATH]; 5026: if (strlen(path) > MAX_PATH - 1) { 5052: char buf[sizeof(struct dirent) + MAX_PATH]; 5075: if (strlen(path) > MAX_PATH - 1) { 5393: char filename[MAX_PATH]; 5395: jio_snprintf(filename, MAX_PATH, PauseAtStartupFile); 5397: jio_snprintf(filename, MAX_PATH, "./vm.paused.%d", current_process_id()); -Dmitry On 2014-03-24 16:17, David Holmes wrote: > Dmitry, > > On 24/03/2014 10:13 PM, Dmitry Samersoff wrote: >> Poonam, >> >> As far as I understand, MAX_PATH is here for a while but later we start >> using MAXPATHLEN. >> >> I would recommend to replace all usage of MAX_PATH and PATH_MAX >> to MAXPATHLEN > > The issue here is to remove the internal limitation. We can't just make > the replacement you suggest because we will suddenly be allocating 4KB > stack buffers where they were previously 2KB. That is bound to break > something. > > David > >> if you fill that these changes is go out of scope of JDK-7119643, please >> replace it inside os:stat() only to solve immediate needs and file a >> separate CR to have it cleaned up. >> >> -Dmitry >> >> >> On 2014-03-24 06:55, Poonam Bajaj wrote: >>> Hi Dmitry, >>> >>> On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: >>>> Poonam, >>>> >>>> 1. >>>> >>>> MAXPATHLEN == PATH_MAX and it's a system constant that comes from >>>> sys/param.h and linux/limits.h so current behavior of hotspot is >>>> absolutely correct. >>>> >>>> Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so this >>>> patch makes hotspot behavior inconsistent. >>>> >>>> Typical value of PATH_MAX is 4096 so it's unclean for me why we have >>>> problems with 2048 bytes file. >>>> >>>> We probably should check our reference build platform. >>> The purpose of this change is to revert back to the same behavior as it >>> was before the fix for 6348631 where we didn't have any path limitation >>> in os::open() and os::stat() functions. >>> >>> But yes, you are right. We have the following in sys/param.h and >>> linux/limits.h for the maximum allowed path length on linux platforms: >>> #define PATH_MAX 4096 /* # chars in a path name including >>> nul */ >>> #define MAXPATHLEN PATH_MAX >>> >>> and MAXPATHLEN is also used in os_linux.cpp. So, if we have to insert >>> the path limitation in os::open() and os::stat(), we should be using >>> MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH defined >>> and to a different value than MAXPATHLEN which is inconsistent with the >>> linux definition? >>> >>>> 2. >>>> >>>> Test could be a pure java. >>> Ok, will do. >>> >>> Thanks, >>> Poonam >>>> >>>> -Dmitry >>>> >>>> On 2014-03-21 16:52, Poonam Bajaj wrote: >>>>> Hi, >>>>> >>>>> Review request for: >>>>> JDK-7119643: It is >>>>> not possible to read files with a path longer than 2048 characters >>>>> >>>>> Problem and Fix: This bug is a regression from 6u29 and exists only on >>>>> Linux platform. With the fix for 6348631, a limit of MAX_PATH (2K) got >>>>> introduced on the file path length in the os::open() and os::stat() >>>>> functions in os_linux.cpp. These changes remove that limit. These >>>>> changes also add a regression test case to check that the files having >>>>> path longer than 2048 are read without any error. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >>>>> >>>>> This fix needs to go into 9, 8u, 7u and 6u. >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From coleen.phillimore at oracle.com Mon Mar 24 16:59:53 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Mar 2014 12:59:53 -0400 Subject: RFR (XS): 8033566: warning from b128 for hotspot/src/share/vm/runtime/frame.cpp: JNI primitive type mismatch In-Reply-To: <532B5466.5000501@oracle.com> References: <532B5466.5000501@oracle.com> Message-ID: <53306489.8010003@oracle.com> Calvin, This looks good. Coleen On 3/20/14 4:49 PM, Calvin Cheung wrote: > Please review this small fix for fixing a warning from our internal code > analysis tool. The problem is that on 64-bit platforms, the uintptr_t is > 64-bit and we tried to return it as a jint which is always 32-bit. > A simple fix is to add an assert to make sure the value is <= max_jint > before returning it as a jint. > > bug: https://bugs.openjdk.java.net/browse/JDK-8033566 > (internal, below is the details) > Expecting value of JNI primitive type jint in return at line 536 of > jdk8-b128/src/hotspot/src/share/vm/runtime/frame.cpp in function > frame::interpreter_frame_expression_stack_size() > > > webrev: http://cr.openjdk.java.net/~ccheung/8033566/webrev/ > > Tests: > jprt > jtreg hotspot tests > > thanks, > Calvin From calvin.cheung at oracle.com Mon Mar 24 17:13:24 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 24 Mar 2014 10:13:24 -0700 Subject: RFR (XS): 8033566: warning from b128 for hotspot/src/share/vm/runtime/frame.cpp: JNI primitive type mismatch In-Reply-To: <53306489.8010003@oracle.com> References: <532B5466.5000501@oracle.com> <53306489.8010003@oracle.com> Message-ID: <533067B4.1050505@oracle.com> Thanks! I'm all set and will push the fix. Calvin On 3/24/2014 9:59 AM, Coleen Phillimore wrote: > > Calvin, > This looks good. > Coleen > > On 3/20/14 4:49 PM, Calvin Cheung wrote: >> Please review this small fix for fixing a warning from our internal code >> analysis tool. The problem is that on 64-bit platforms, the uintptr_t is >> 64-bit and we tried to return it as a jint which is always 32-bit. >> A simple fix is to add an assert to make sure the value is <= max_jint >> before returning it as a jint. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8033566 >> (internal, below is the details) >> Expecting value of JNI primitive type jint in return at line 536 of >> jdk8-b128/src/hotspot/src/share/vm/runtime/frame.cpp in function >> frame::interpreter_frame_expression_stack_size() >> >> >> webrev: http://cr.openjdk.java.net/~ccheung/8033566/webrev/ >> >> Tests: >> jprt >> jtreg hotspot tests >> >> thanks, >> Calvin > From mikhailo.seledtsov at oracle.com Mon Mar 24 17:27:19 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 24 Mar 2014 13:27:19 -0400 Subject: RFR (XS): JDK-8032222: [TESTBUG] runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with java.lang.RuntimeException Message-ID: <53306AF7.1070403@oracle.com> Please review the following small change to the test. JBS: https://bugs.openjdk.java.net/browse/JDK-8032222 Webrev: http://cr.openjdk.java.net/~mseledtsov/8032222/webrev.00/ Testing: 1. Local testing: ran the test - sanity check 2. Executed the test via JPRT 2014-03-24-163056.mseledtsov.work01 From coleen.phillimore at oracle.com Mon Mar 24 17:39:34 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Mar 2014 13:39:34 -0400 Subject: RFR (XS): JDK-8032222: [TESTBUG] runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with java.lang.RuntimeException In-Reply-To: <53306AF7.1070403@oracle.com> References: <53306AF7.1070403@oracle.com> Message-ID: <53306DD6.4000909@oracle.com> Ok. This change looks good. Coleen On 3/24/14 1:27 PM, Mikhailo Seledtsov wrote: > Please review the following small change to the test. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8032222 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8032222/webrev.00/ > > Testing: > 1. Local testing: ran the test - sanity check > 2. Executed the test via JPRT > 2014-03-24-163056.mseledtsov.work01 > From christian.tornqvist at oracle.com Mon Mar 24 17:52:18 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 24 Mar 2014 13:52:18 -0400 Subject: RFR (XS): JDK-8032222: [TESTBUG] runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with java.lang.RuntimeException In-Reply-To: <53306AF7.1070403@oracle.com> References: <53306AF7.1070403@oracle.com> Message-ID: <000401cf4789$d02c4e90$7084ebb0$@oracle.com> Hi Misha, Could you put a comment above your change explaining why this test is skipped for Mac OS? Thanks, Christian -----Original Message----- From: Mikhailo Seledtsov [mailto:mikhailo.seledtsov at oracle.com] Sent: Monday, March 24, 2014 1:27 PM To: hotspot-runtime-dev Cc: Zhengyu Gu; Christian T?rnqvist Subject: RFR (XS): JDK-8032222: [TESTBUG] runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with java.lang.RuntimeException Please review the following small change to the test. JBS: https://bugs.openjdk.java.net/browse/JDK-8032222 Webrev: http://cr.openjdk.java.net/~mseledtsov/8032222/webrev.00/ Testing: 1. Local testing: ran the test - sanity check 2. Executed the test via JPRT 2014-03-24-163056.mseledtsov.work01 From mikhailo.seledtsov at oracle.com Mon Mar 24 19:29:21 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 24 Mar 2014 15:29:21 -0400 Subject: RFR (XS): JDK-8032222: [TESTBUG] runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with java.lang.RuntimeException In-Reply-To: <000401cf4789$d02c4e90$7084ebb0$@oracle.com> References: <53306AF7.1070403@oracle.com> <000401cf4789$d02c4e90$7084ebb0$@oracle.com> Message-ID: <53308791.5090408@oracle.com> Christian, I will clarify by saying "This test has been unstable for Mac OSx (see JDK-8032222)" Thank you, Misha On 3/24/2014 1:52 PM, Christian Tornqvist wrote: > Hi Misha, > > Could you put a comment above your change explaining why this test is skipped for Mac OS? > > Thanks, > Christian > > -----Original Message----- > From: Mikhailo Seledtsov [mailto:mikhailo.seledtsov at oracle.com] > Sent: Monday, March 24, 2014 1:27 PM > To: hotspot-runtime-dev > Cc: Zhengyu Gu; Christian T?rnqvist > Subject: RFR (XS): JDK-8032222: [TESTBUG] runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with java.lang.RuntimeException > > Please review the following small change to the test. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8032222 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8032222/webrev.00/ > > Testing: > 1. Local testing: ran the test - sanity check > 2. Executed the test via JPRT > 2014-03-24-163056.mseledtsov.work01 > > From gerald.thornbrugh at oracle.com Mon Mar 24 19:47:57 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Mon, 24 Mar 2014 13:47:57 -0600 Subject: RFR: JDK-8033464 and JDK-8033931 - Linux code cleanup Message-ID: <53308BED.7010006@oracle.com> Hi, I am a member of the Oracle Hotspot group and there is an initiative to clean up things like uninitialized variables and unclosed file descriptors in JDK8. This is a backport of fixes that have already been putback into JDK9. I have run UTE and JPRT tests on Linux machines without problems. The below webrev show the fixes for the Linux area. Bugs: JDK-8033464 is not visible because it has been marked as Oracle confidential. JDK-8033464 describes a JDK8 Linux specific code cleanup to address possible uninitialized variables and unclosed file descriptors. These issues were addressed in the fix. https://bugs.openjdk.java.net/browse/JDK-8033464 JDK-8033931 is a JDK9 issue with an assert that was putback as part of the fix for JDK-8033464. It will also be addressed with this putback. https://bugs.openjdk.java.net/browse/JDK-8033931 Webrev: http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ Please review my changes and let me know if you have questions. Thanks, Gerald Thornbrugh From daniel.daugherty at oracle.com Mon Mar 24 19:53:09 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Mar 2014 13:53:09 -0600 Subject: RFR: JDK-8033464 and JDK-8033931 - Linux code cleanup In-Reply-To: <53308BED.7010006@oracle.com> References: <53308BED.7010006@oracle.com> Message-ID: <53308D25.6040205@oracle.com> > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ Thumbs up. This time I compared the diffs for these two changesets from JDK9: changeset: 5879:c2626e4f0c80 user: dcubed date: Fri Feb 07 11:47:24 2014 -0800 summary: 8033931: Several nightly tests failing with assert(imin < imax) fai led: Unexpected page size changeset: 5875:2c2a99f6cf83 parent: 5871:c86519f8d826 user: coleenp date: Thu Feb 06 14:28:35 2014 -0500 summary: 8029775: Solaris code cleanup with the patch. The only differences are white space, timestamps and diff context anchors. Dan On 3/24/14 1:47 PM, Gerald Thornbrugh wrote: > Hi, > > I am a member of the Oracle Hotspot group and there is an initiative > to clean up > things like uninitialized variables and unclosed file descriptors in > JDK8. This is a > backport of fixes that have already been putback into JDK9. I have run > UTE and > JPRT tests on Linux machines without problems. The below webrev show > the fixes for > the Linux area. > > Bugs: > > JDK-8033464 is not visible because it has been marked as Oracle > confidential. > > JDK-8033464 describes a JDK8 Linux specific code cleanup to address > possible uninitialized variables and unclosed file descriptors. These > issues > were addressed in the fix. > > https://bugs.openjdk.java.net/browse/JDK-8033464 > > JDK-8033931 is a JDK9 issue with an assert that was putback as part of > the > fix for JDK-8033464. It will also be addressed with this putback. > > https://bugs.openjdk.java.net/browse/JDK-8033931 > > Webrev: > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ > > > > Please review my changes and let me know if you have questions. > > Thanks, > > Gerald Thornbrugh From gerald.thornbrugh at oracle.com Mon Mar 24 19:56:03 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Mon, 24 Mar 2014 13:56:03 -0600 Subject: RFR: JDK-8033464 and JDK-8033931 - Linux code cleanup In-Reply-To: <53308D25.6040205@oracle.com> References: <53308BED.7010006@oracle.com> <53308D25.6040205@oracle.com> Message-ID: <53308DD3.6090403@oracle.com> Hi Dan, Thanks for the review. Gerald > > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ > > > Thumbs up. > > This time I compared the diffs for these two changesets from JDK9: > > changeset: 5879:c2626e4f0c80 > user: dcubed > date: Fri Feb 07 11:47:24 2014 -0800 > summary: 8033931: Several nightly tests failing with assert(imin < > imax) fai > led: Unexpected page size > > changeset: 5875:2c2a99f6cf83 > parent: 5871:c86519f8d826 > user: coleenp > date: Thu Feb 06 14:28:35 2014 -0500 > summary: 8029775: Solaris code cleanup > > with the patch. The only differences are white space, timestamps > and diff context anchors. > > Dan > > > On 3/24/14 1:47 PM, Gerald Thornbrugh wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative >> to clean up >> things like uninitialized variables and unclosed file descriptors in >> JDK8. This is a >> backport of fixes that have already been putback into JDK9. I have >> run UTE and >> JPRT tests on Linux machines without problems. The below webrev show >> the fixes for >> the Linux area. >> >> Bugs: >> >> JDK-8033464 is not visible because it has been marked as Oracle >> confidential. >> >> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >> possible uninitialized variables and unclosed file descriptors. These >> issues >> were addressed in the fix. >> >> https://bugs.openjdk.java.net/browse/JDK-8033464 >> >> JDK-8033931 is a JDK9 issue with an assert that was putback as part >> of the >> fix for JDK-8033464. It will also be addressed with this putback. >> >> https://bugs.openjdk.java.net/browse/JDK-8033931 >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ >> >> >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh > From dmitry.samersoff at oracle.com Mon Mar 24 20:13:26 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 25 Mar 2014 00:13:26 +0400 Subject: RFR: JDK-8033464 and JDK-8033931 - Linux code cleanup In-Reply-To: <53308BED.7010006@oracle.com> References: <53308BED.7010006@oracle.com> Message-ID: <533091E6.6030606@oracle.com> Gerald, Looks good for me! -Dmitry On 2014-03-24 23:47, Gerald Thornbrugh wrote: > Hi, > > I am a member of the Oracle Hotspot group and there is an initiative to > clean up > things like uninitialized variables and unclosed file descriptors in > JDK8. This is a > backport of fixes that have already been putback into JDK9. I have run > UTE and > JPRT tests on Linux machines without problems. The below webrev show the > fixes for > the Linux area. > > Bugs: > > JDK-8033464 is not visible because it has been marked as Oracle > confidential. > > JDK-8033464 describes a JDK8 Linux specific code cleanup to address > possible uninitialized variables and unclosed file descriptors. These > issues > were addressed in the fix. > > https://bugs.openjdk.java.net/browse/JDK-8033464 > > JDK-8033931 is a JDK9 issue with an assert that was putback as part of the > fix for JDK-8033464. It will also be addressed with this putback. > > https://bugs.openjdk.java.net/browse/JDK-8033931 > > Webrev: > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ > > > > Please review my changes and let me know if you have questions. > > Thanks, > > Gerald Thornbrugh -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From gerald.thornbrugh at oracle.com Mon Mar 24 20:17:56 2014 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Mon, 24 Mar 2014 14:17:56 -0600 Subject: RFR: JDK-8033464 and JDK-8033931 - Linux code cleanup In-Reply-To: <533091E6.6030606@oracle.com> References: <53308BED.7010006@oracle.com> <533091E6.6030606@oracle.com> Message-ID: <533092F4.9010804@oracle.com> Hi Dmitry, Thanks for the review. Gerald > Gerald, > > Looks good for me! > > -Dmitry > > On 2014-03-24 23:47, Gerald Thornbrugh wrote: >> Hi, >> >> I am a member of the Oracle Hotspot group and there is an initiative to >> clean up >> things like uninitialized variables and unclosed file descriptors in >> JDK8. This is a >> backport of fixes that have already been putback into JDK9. I have run >> UTE and >> JPRT tests on Linux machines without problems. The below webrev show the >> fixes for >> the Linux area. >> >> Bugs: >> >> JDK-8033464 is not visible because it has been marked as Oracle >> confidential. >> >> JDK-8033464 describes a JDK8 Linux specific code cleanup to address >> possible uninitialized variables and unclosed file descriptors. These >> issues >> were addressed in the fix. >> >> https://bugs.openjdk.java.net/browse/JDK-8033464 >> >> JDK-8033931 is a JDK9 issue with an assert that was putback as part of the >> fix for JDK-8033464. It will also be addressed with this putback. >> >> https://bugs.openjdk.java.net/browse/JDK-8033931 >> >> Webrev: >> >> http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ >> >> >> >> Please review my changes and let me know if you have questions. >> >> Thanks, >> >> Gerald Thornbrugh > From coleen.phillimore at oracle.com Mon Mar 24 22:13:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 24 Mar 2014 18:13:11 -0400 Subject: RFR: JDK-8033464 and JDK-8033931 - Linux code cleanup In-Reply-To: <53308BED.7010006@oracle.com> References: <53308BED.7010006@oracle.com> Message-ID: <5330ADF7.5050101@oracle.com> Looks good. Coleen On 3/24/14 3:47 PM, Gerald Thornbrugh wrote: > Hi, > > I am a member of the Oracle Hotspot group and there is an initiative > to clean up > things like uninitialized variables and unclosed file descriptors in > JDK8. This is a > backport of fixes that have already been putback into JDK9. I have run > UTE and > JPRT tests on Linux machines without problems. The below webrev show > the fixes for > the Linux area. > > Bugs: > > JDK-8033464 is not visible because it has been marked as Oracle > confidential. > > JDK-8033464 describes a JDK8 Linux specific code cleanup to address > possible uninitialized variables and unclosed file descriptors. These > issues > were addressed in the fix. > > https://bugs.openjdk.java.net/browse/JDK-8033464 > > JDK-8033931 is a JDK9 issue with an assert that was putback as part of > the > fix for JDK-8033464. It will also be addressed with this putback. > > https://bugs.openjdk.java.net/browse/JDK-8033931 > > Webrev: > > http://cr.openjdk.java.net/~dcubed/for_gthornbr/8033464-webrev/1-jdk8u-hs-dev/ > > > > Please review my changes and let me know if you have questions. > > Thanks, > > Gerald Thornbrugh From poonam.bajaj at oracle.com Tue Mar 25 04:12:33 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 25 Mar 2014 09:42:33 +0530 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <53302DEB.8080508@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> <532F9E8B.9020807@oracle.com> <53302181.9070204@oracle.com> <53302261.4@oracle.com> <53302DEB.8080508@oracle.com> Message-ID: <53310231.5070207@oracle.com> Hi David, Dmitry, I understand both the concerns: - By using MAXPATHLEN which is defined as 4096 bytes, we would be allocating 4KB stack buffers where they are currently 2KB. - By removing the path length check in these functions we open the risk of stack overflow errors by creating large buffers on the stack as the user input may be unreasonably large. How about I just remove the path length check in os::open() for this bug where we are not creating any stack buffers based on the path input given by the user, and leave os::stat() as it is where a path buffer is created on the stack based on the user input. This bug only requires to remove the limitation while opening the files and the change in os::open() would fix that. I will file another bug to take care of the inconsistent use of MAXPATHLEN and MAX_PATH in os_linux.cpp file. Let me know your thoughts. Thanks, Poonam On 3/24/2014 6:36 PM, Dmitry Samersoff wrote: > David, > >> The issue here is to remove the internal limitation. We can't just >> make the replacement you suggest because we will suddenly be >> allocating 4KB stack buffers where they were previously 2KB. That is >> bound to break something. > I share your concern but what we have today[1] is not acceptable. We > have to make decision and either go with our own constant MAX_PATH (2*k) > with clear justification why we don't follow rest of the linux or > use one of system constants: MAXPATHLEN or PAH_MAX. > > But impact of this cleanup have to be carefully evaluated and probably > out of scope of this CR. > > *As for proposed changes*: > > I'm against of dynamic allocation in stack based on user input - it can > lead to stack overflow in some cases and cause intermittent failures > that very hard to debug. > > So we should either change this value to MAXPATHLEN and hope that > testing catch all problems or postpone the changes to complete and > careful cleanup. > > [1] > > jaja:vm#grep -n PATH_MAX os_linux.cpp > > 2619: char buf[PATH_MAX+1]; > > jaja:vm#grep -n MAXPATHLEN os_linux.cpp > > 379: char buf[MAXPATHLEN]; > 2310:static char saved_jvm_path[MAXPATHLEN] = {0}; > 2315: if (buflen< MAXPATHLEN) { > 2326: char dli_fname[MAXPATHLEN]; > 5977: char buf[MAXPATHLEN]; > 5978: char libmawtpath[MAXPATHLEN]; > > jaja:vm#grep -n MAX_PATH os_linux.cpp > > 110:#define MAX_PATH (2 * K) > 5025: char pathbuf[MAX_PATH]; > 5026: if (strlen(path)> MAX_PATH - 1) { > 5052: char buf[sizeof(struct dirent) + MAX_PATH]; > 5075: if (strlen(path)> MAX_PATH - 1) { > 5393: char filename[MAX_PATH]; > 5395: jio_snprintf(filename, MAX_PATH, PauseAtStartupFile); > 5397: jio_snprintf(filename, MAX_PATH, "./vm.paused.%d", > current_process_id()); > > -Dmitry > > On 2014-03-24 16:17, David Holmes wrote: >> Dmitry, >> >> On 24/03/2014 10:13 PM, Dmitry Samersoff wrote: >>> Poonam, >>> >>> As far as I understand, MAX_PATH is here for a while but later we start >>> using MAXPATHLEN. >>> >>> I would recommend to replace all usage of MAX_PATH and PATH_MAX >>> to MAXPATHLEN >> The issue here is to remove the internal limitation. We can't just make >> the replacement you suggest because we will suddenly be allocating 4KB >> stack buffers where they were previously 2KB. That is bound to break >> something. >> >> David >> >>> if you fill that these changes is go out of scope of JDK-7119643, please >>> replace it inside os:stat() only to solve immediate needs and file a >>> separate CR to have it cleaned up. >>> >>> -Dmitry >>> >>> >>> On 2014-03-24 06:55, Poonam Bajaj wrote: >>>> Hi Dmitry, >>>> >>>> On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: >>>>> Poonam, >>>>> >>>>> 1. >>>>> >>>>> MAXPATHLEN == PATH_MAX and it's a system constant that comes from >>>>> sys/param.h and linux/limits.h so current behavior of hotspot is >>>>> absolutely correct. >>>>> >>>>> Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so this >>>>> patch makes hotspot behavior inconsistent. >>>>> >>>>> Typical value of PATH_MAX is 4096 so it's unclean for me why we have >>>>> problems with 2048 bytes file. >>>>> >>>>> We probably should check our reference build platform. >>>> The purpose of this change is to revert back to the same behavior as it >>>> was before the fix for 6348631 where we didn't have any path limitation >>>> in os::open() and os::stat() functions. >>>> >>>> But yes, you are right. We have the following in sys/param.h and >>>> linux/limits.h for the maximum allowed path length on linux platforms: >>>> #define PATH_MAX 4096 /* # chars in a path name including >>>> nul */ >>>> #define MAXPATHLEN PATH_MAX >>>> >>>> and MAXPATHLEN is also used in os_linux.cpp. So, if we have to insert >>>> the path limitation in os::open() and os::stat(), we should be using >>>> MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH defined >>>> and to a different value than MAXPATHLEN which is inconsistent with the >>>> linux definition? >>>> >>>>> 2. >>>>> >>>>> Test could be a pure java. >>>> Ok, will do. >>>> >>>> Thanks, >>>> Poonam >>>>> -Dmitry >>>>> >>>>> On 2014-03-21 16:52, Poonam Bajaj wrote: >>>>>> Hi, >>>>>> >>>>>> Review request for: >>>>>> JDK-7119643: It is >>>>>> not possible to read files with a path longer than 2048 characters >>>>>> >>>>>> Problem and Fix: This bug is a regression from 6u29 and exists only on >>>>>> Linux platform. With the fix for 6348631, a limit of MAX_PATH (2K) got >>>>>> introduced on the file path length in the os::open() and os::stat() >>>>>> functions in os_linux.cpp. These changes remove that limit. These >>>>>> changes also add a regression test case to check that the files having >>>>>> path longer than 2048 are read without any error. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >>>>>> >>>>>> This fix needs to go into 9, 8u, 7u and 6u. >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>> >>> > From dmitry.samersoff at oracle.com Tue Mar 25 06:42:40 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 25 Mar 2014 10:42:40 +0400 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <53310231.5070207@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> <532F9E8B.9020807@oracle.com> <53302181.9070204@oracle.com> <53302261.4@oracle.com> <53302DEB.8080508@oracle.com> <53310231.5070207@oracle.com> Message-ID: <53312560.7080207@oracle.com> Poonam, Your proposal looks good for me. Thank you for doing it. On 2014-03-25 08:12, Poonam Bajaj wrote: > Hi David, Dmitry, > > I understand both the concerns: > - By using MAXPATHLEN which is defined as 4096 bytes, we would be > allocating 4KB stack buffers where they are currently 2KB. > - By removing the path length check in these functions we open the risk > of stack overflow errors by creating large buffers on the stack as the > user input may be unreasonably large. > > How about I just remove the path length check in os::open() for this bug > where we are not creating any stack buffers based on the path input > given by the user, and leave os::stat() as it is where a path buffer is > created on the stack based on the user input. This bug only requires to > remove the limitation while opening the files and the change in > os::open() would fix that. > > I will file another bug to take care of the inconsistent use of > MAXPATHLEN and MAX_PATH in os_linux.cpp file. > > Let me know your thoughts. -Dmitry > > Thanks, > Poonam > > On 3/24/2014 6:36 PM, Dmitry Samersoff wrote: >> David, >> >>> The issue here is to remove the internal limitation. We can't just >>> make the replacement you suggest because we will suddenly be >>> allocating 4KB stack buffers where they were previously 2KB. That is >>> bound to break something. >> I share your concern but what we have today[1] is not acceptable. We >> have to make decision and either go with our own constant MAX_PATH (2*k) >> with clear justification why we don't follow rest of the linux or >> use one of system constants: MAXPATHLEN or PAH_MAX. >> >> But impact of this cleanup have to be carefully evaluated and probably >> out of scope of this CR. >> >> *As for proposed changes*: >> >> I'm against of dynamic allocation in stack based on user input - it can >> lead to stack overflow in some cases and cause intermittent failures >> that very hard to debug. >> >> So we should either change this value to MAXPATHLEN and hope that >> testing catch all problems or postpone the changes to complete and >> careful cleanup. >> >> [1] >> >> jaja:vm#grep -n PATH_MAX os_linux.cpp >> >> 2619: char buf[PATH_MAX+1]; >> >> jaja:vm#grep -n MAXPATHLEN os_linux.cpp >> >> 379: char buf[MAXPATHLEN]; >> 2310:static char saved_jvm_path[MAXPATHLEN] = {0}; >> 2315: if (buflen< MAXPATHLEN) { >> 2326: char dli_fname[MAXPATHLEN]; >> 5977: char buf[MAXPATHLEN]; >> 5978: char libmawtpath[MAXPATHLEN]; >> >> jaja:vm#grep -n MAX_PATH os_linux.cpp >> >> 110:#define MAX_PATH (2 * K) >> 5025: char pathbuf[MAX_PATH]; >> 5026: if (strlen(path)> MAX_PATH - 1) { >> 5052: char buf[sizeof(struct dirent) + MAX_PATH]; >> 5075: if (strlen(path)> MAX_PATH - 1) { >> 5393: char filename[MAX_PATH]; >> 5395: jio_snprintf(filename, MAX_PATH, PauseAtStartupFile); >> 5397: jio_snprintf(filename, MAX_PATH, "./vm.paused.%d", >> current_process_id()); >> >> -Dmitry >> >> On 2014-03-24 16:17, David Holmes wrote: >>> Dmitry, >>> >>> On 24/03/2014 10:13 PM, Dmitry Samersoff wrote: >>>> Poonam, >>>> >>>> As far as I understand, MAX_PATH is here for a while but later we start >>>> using MAXPATHLEN. >>>> >>>> I would recommend to replace all usage of MAX_PATH and PATH_MAX >>>> to MAXPATHLEN >>> The issue here is to remove the internal limitation. We can't just make >>> the replacement you suggest because we will suddenly be allocating 4KB >>> stack buffers where they were previously 2KB. That is bound to break >>> something. >>> >>> David >>> >>>> if you fill that these changes is go out of scope of JDK-7119643, >>>> please >>>> replace it inside os:stat() only to solve immediate needs and file a >>>> separate CR to have it cleaned up. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-24 06:55, Poonam Bajaj wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: >>>>>> Poonam, >>>>>> >>>>>> 1. >>>>>> >>>>>> MAXPATHLEN == PATH_MAX and it's a system constant that comes from >>>>>> sys/param.h and linux/limits.h so current behavior of hotspot is >>>>>> absolutely correct. >>>>>> >>>>>> Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so >>>>>> this >>>>>> patch makes hotspot behavior inconsistent. >>>>>> >>>>>> Typical value of PATH_MAX is 4096 so it's unclean for me why we have >>>>>> problems with 2048 bytes file. >>>>>> >>>>>> We probably should check our reference build platform. >>>>> The purpose of this change is to revert back to the same behavior >>>>> as it >>>>> was before the fix for 6348631 where we didn't have any path >>>>> limitation >>>>> in os::open() and os::stat() functions. >>>>> >>>>> But yes, you are right. We have the following in sys/param.h and >>>>> linux/limits.h for the maximum allowed path length on linux platforms: >>>>> #define PATH_MAX 4096 /* # chars in a path name including >>>>> nul */ >>>>> #define MAXPATHLEN PATH_MAX >>>>> >>>>> and MAXPATHLEN is also used in os_linux.cpp. So, if we have to insert >>>>> the path limitation in os::open() and os::stat(), we should be using >>>>> MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH defined >>>>> and to a different value than MAXPATHLEN which is inconsistent with >>>>> the >>>>> linux definition? >>>>> >>>>>> 2. >>>>>> >>>>>> Test could be a pure java. >>>>> Ok, will do. >>>>> >>>>> Thanks, >>>>> Poonam >>>>>> -Dmitry >>>>>> >>>>>> On 2014-03-21 16:52, Poonam Bajaj wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Review request for: >>>>>>> JDK-7119643: It is >>>>>>> not possible to read files with a path longer than 2048 characters >>>>>>> >>>>>>> Problem and Fix: This bug is a regression from 6u29 and exists >>>>>>> only on >>>>>>> Linux platform. With the fix for 6348631, a limit of MAX_PATH >>>>>>> (2K) got >>>>>>> introduced on the file path length in the os::open() and os::stat() >>>>>>> functions in os_linux.cpp. These changes remove that limit. These >>>>>>> changes also add a regression test case to check that the files >>>>>>> having >>>>>>> path longer than 2048 are read without any error. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >>>>>>> >>>>>>> This fix needs to go into 9, 8u, 7u and 6u. >>>>>>> >>>>>>> Thanks, >>>>>>> Poonam >>>>>>> >>>> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From staffan.larsen at oracle.com Tue Mar 25 07:31:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 25 Mar 2014 08:31:02 +0100 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM Message-ID: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> attachListener_solaris.cpp calls atoi() and then checks errno to see if any errors occurred. The problem is that atoi() does not set errno, so some old value of errno is checked which sometimes causes the function to fail. The fix is to replace atoi() with strtol() which does set errno. But errno is only set if an error occurred and not set to 0 in case of success. Thus, I set errno to 0 before calling strtol() and check the value afterwards. Verified with a JPRT run. webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8038296 Thanks, /Staffan From serguei.spitsyn at oracle.com Tue Mar 25 08:19:02 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 25 Mar 2014 01:19:02 -0700 Subject: RFR(XS): 8036666: JVMTI GetObjectMonitorUsage does not return correct recursion count In-Reply-To: <02D5D45C1F8DB848A7AE20E80EE61A5C398147F8@DEWDFEMB20C.global.corp.sap> References: <02D5D45C1F8DB848A7AE20E80EE61A5C39811793@DEWDFEMB20C.global.corp.sap> <53199213.5010708@oracle.com> <531D631B.3050708@oracle.com> <531ECE5D.1070303@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398129D1@DEWDFEMB20C.global.corp.sap> <1A067EB6-FCD6-49FB-BA11-BBA83CF6F341@oracle.com> <531F6323.1010109@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39812EC9@DEWDFEMB20C.global.corp.sap> <53209A8A.6070601@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C39813076@DEWDFEMB20C.global.corp.sap> <532770A7.3080705@oracle.com> <02D5D45C1F8DB848A7AE20E80EE61A5C398147F8@DEWDFEMB20C.global.corp.sap> Message-ID: <53313BF6.2050100@oracle.com> Hi Axel, Sorry for the delay, I was out and busy last week. Dmitry noted that you moved the fix to the incorrect place and asked me to double-check it. I think, Dmitry is right. He asked to move the code after the line 1017 so that the moved fragment will be inside the 'if' statement started at the line: 1003 if (owning_thread != NULL) { But in the webrev the code was moved after the line 1019 which seems to be incorrect. Could you, please, double check this and confirm that you are agree with this? Otherwise, please, provide some explanation why you think this webrev is correct. Thanks! Serguei On 3/19/14 1:05 AM, Siebenborn, Axel wrote: > Hi Dmitri, > Thank you for the review. > You're right, the code gets cleaner this way. > New webrev: > http://www.sapjvm.com/as/webrevs/8036666_3/ > Thanks, > Axel > > On 17.03.2014 23:01, Dmitry Samersoff wrote: >> Axel, >> >> The changes it self looks good for me. >> >> But it looks like the owning_thread is always NULL if >> owner is NULL, so we can safely move this code >> to ll.1017 and join two identical ifs together. >> >> Also comment on ll. 1019 is misleading, could you remove it? >> >> -Dmitry >> >> On 2014-03-13 12:19, Siebenborn, Axel wrote: >>> Hi Serguei, >>> new webrev: >>> http://www.sapjvm.com/as/webrevs/8036666_2/ >>> I should review my own changes more carefully. >>> Sorry for that. >>> Thanks, >>> Axel >>> >>> >>> >>> On 12.03.2014 18:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Axel, >>>> >>>> Thank you for the changes! It looks good, but one more place need a >>>> fix (expected must be 4 now): >>>> >>>> 230 if (recursionCount != 4) { 231 throw new >>>> AssertionError("recursions: expected 3, but was " + recursionCount); >>>> 232 } >>>> >>>> >>>> Thanks, Serguei >>>> >>>> >>>> On 3/12/14 8:21 AM, Siebenborn, Axel wrote: >>>>> Hi Serguei, I created a new webrev: >>>>> >>>>> http://www.sapjvm.com/as/webrevs/8036666_1/ >>>>> >>>>> I incorporated your suggestions and moved the test files. >>>>> >>>>> Thanks, Axel >>>>> >>>>> >>>>> On 11.03.2014 20:25, serguei.spitsyn at oracle.com wrote: >>>>>> On 3/11/14 12:05 PM, Staffan Larsen wrote: >>>>>>> On 11 mar 2014, at 16:48, Siebenborn, Axel >>>>>>> > >>>>>>> wrote: >>>>>>>> Hi Seguei, I still can't upload files to the cr.openjdk >>>>>>>> server. Meanwhile, I use our server for the new webrev: >>>>>>>> >>>>>>>> http://www.sapjvm.com/as/webrevs/8036666/ >>>>>>>> >>>>>>>> Thanks, Axel >>>>>>>> >>>>>>>> Comments inline: >>>>>>>> >>>>>>>> On 11.03.2014 09:50,serguei.spitsyn at oracle.com >>>>>>>> wrote: >>>>>>>>> Hi Axel, >>>>>>>>> >>>>>>>>> The webrev link is resolvable now. Thank you for taking >>>>>>>>> care about your broken account on the cr.openjdk server! >>>>>>>>> >>>>>>>>> I have some comments on the test case ... >>>>>>>>> >>>>>>>>> - This is nice test, thank you for providing it! >>>>>>>>> >>>>>>>>> - The location of the test must be different as it is a >>>>>>>>> JVMTI test: test/serviceability/jvmti/8036666 instead of >>>>>>>>> test/runtime/8036666 >>>>>>>> I moved the test. >>>>>>> Tests should avoid the bug number in the name or path and >>>>>>> instead use a descriptive name. See this page for some >>>>>>> background: >>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Naming+HotSpot+JTReg+Tests >>> The test files have already descriptive names. >>>>>> So, it would be enough to remove the bug number from the path. >>>>>> Sorry, I had to catch it too in the first place. >>>>>> >>>>>> Thanks, Serguei >>>>>>> Thanks, /Staffan >>>>>>>>> RecursiveObjectLock,java: >>>>>>>>> >>>>>>>>> - A suggestion to add a synchronized method (say, >>>>>>>>> nestedLock3) into the chain of calls started from the >>>>>>>>> testMethod. In order to do so, the class >>>>>>>>> RecursiveObjectLock needs to extend the ALock class. And >>>>>>>>> the this object needs to be used in the synchronized >>>>>>>>> statements and for wait()? What do you think about such >>>>>>>>> test enhancement for better coverage? >>>>>>>> In order to have a synchronized method in the call chain, I >>>>>>>> synchronize on the "this" object. >>>>>>>>> GetObjectLockCount.java: >>>>>>>>> >>>>>>>>> - The comment line 283 seems to be obsolete as the "param >>>>>>>>> out" is not present anymore: >>>>>>>>> >>>>>>>>> 283 * @param out Stream to copy to >>>>>>>>> >>>>>>>>> >>>>>>>>> - Could you, please, add e.printStackTrace() into the catch >>>>>>>>> statements at the lines 232 and 300? >>>>>>>>> >>>>>>>>> - A question: It seems the errThread and outThread are >>>>>>>>> started a little bit late. Would it be better to start them >>>>>>>>> earlier, or it was intentional? >>>>>>>> You're right! I moved to code up. >>>>>>>>> Some minor style-related comments (I hope, it is easy to >>>>>>>>> fix this before push): - Unneeded extra empty lines: >>>>>>>>> 149, 174-175, 244 - A space is missed before the '{': >>>>>>>>> 180, 242, 243, 246 - Unneeded extra space after and before >>>>>>>>> the "(": 235, 297 - The curly brackets '{' do not follow >>>>>>>>> the common style: 142, 144 >>>>>>>> I hope I fixed them all and added no new style violations. Do >>>>>>>> you have a tool to check this? >>>>>>>>> We still need another reviewer for this fix. I'm ready to >>>>>>>>> be a sponsor for it. >>>>>>>>> >>>>>>>>> Thanks, Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 3/10/14 12:00 AM, serguei.spitsyn at oracle.com >>>>>>>>> wrote: >>>>>>>>>> Hi Axel, >>>>>>>>>> >>>>>>>>>> The webrev link does not work now. I'll check it again >>>>>>>>>> tomorrow. >>>>>>>>>> >>>>>>>>>> Thanks, Serguei >>>>>>>>>> >>>>>>>>>> On 3/7/14 1:32 AM, serguei.spitsyn at oracle.com >>>>>>>>>> wrote: >>>>>>>>>>> Hi Axel, >>>>>>>>>>> >>>>>>>>>>> Thank you for fixing this issue. I'm reviewing it. It >>>>>>>>>>> looks good in general, but a little bit more time is >>>>>>>>>>> needed to look at the tests. >>>>>>>>>>> >>>>>>>>>>> Do you need a sponsor for pushing? >>>>>>>>>>> >>>>>>>>>>> Thanks, Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 3/6/14 12:08 AM, Siebenborn, Axel wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> could I have a review for the following change? >>>>>>>>>>>> >>>>>>>>>>>> The recursive lock count for an object is not >>>>>>>>>>>> correct, in cases, where a monitor is inflated after >>>>>>>>>>>> recursive lightweight locks. In this case, the >>>>>>>>>>>> recursion count is taken from the heavyweight >>>>>>>>>>>> monitor, represented by the class ObjectMonitor. >>>>>>>>>>>> ObjectMonitor::_recursions is the number of times >>>>>>>>>>>> ObjectMonitor::enter() was called to acquire the lock >>>>>>>>>>>> minus 1. This counter does not include the recursions >>>>>>>>>>>> of lightweight locks, that happen before inflating >>>>>>>>>>>> the monitor and is not equal to the recursion count >>>>>>>>>>>> from a Java source level point of view. >>>>>>>>>>>> >>>>>>>>>>>> I added a test to the webrev to reproduce the >>>>>>>>>>>> problem. >>>>>>>>>>>> >>>>>>>>>>>> The suggested fix is to call count_locked_objects, >>>>>>>>>>>> even if there's a heavyweight monitor and get the >>>>>>>>>>>> recursion count by iterating the vframes. >>>>>>>>>>>> >>>>>>>>>>>> Bug: >>>>>>>>>>>> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036666 >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~asiebenborn/8036666/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>> Axel >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.eriksson at oracle.com Tue Mar 25 09:55:42 2014 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 25 Mar 2014 10:55:42 +0100 Subject: RFR: JDK-8033696: "assert(thread != NULL) failed: just checking" due to Thread::current() and JNI pthread interaction In-Reply-To: <53151A83.1090106@oracle.com> References: <52F8FC95.5090608@oracle.com> <530E4B1C.2070201@oracle.com> <530F122F.1090107@oracle.com> <530F23DE.8010008@oracle.com> <530F30C1.7070601@oracle.com> <53151A83.1090106@oracle.com> Message-ID: <5331529E.8090209@oracle.com> Hi, Could I get some eyes on this new webrev? Thanks, Andreas On 2014-03-04 01:12, Andreas Eriksson wrote: > That output was because the VMThread didn't reset it's TLS before > exiting (presumably since the VM is shutting down anyway). > This meant that the thread pointer destructor was run until the > pthread implementation gave up. > I added code that sets the thread pointer to NULL before exiting the > VMThread, ensuring the thread pointer destructor is never called for > the exiting VMThread. > > A new updated webrev can be found here: > http://cr.openjdk.java.net/~aeriksso/8033696/webrev.01/ > > I also removed the bug reference from the comments, since I got the > feeling that it's usually discouraged. > > Thanks, > Andreas > > On 2014-02-27 13:34, Andreas Eriksson wrote: >> Oh, sorry, I misread your mail. >> >> I will look into the pthread output from java -version. >> >> Thread 80103f400 has exited with leftover thread-specific data after 4 >> destructor iterations >> >> Thanks, >> Andreas >> >> On 2014-02-27 12:39, Dmitry Samersoff wrote: >>> Andreas, >>> >>> I's not growing - always only two threads. >>> >>> -Dmitry >>> >>> On 2014-02-27 14:23, Andreas Eriksson wrote: >>>> Thanks Dmitry. >>>> >>>> There are no crashes, only an assert that is hit if running with a >>>> debug >>>> build. >>>> Otherwise the active threads keep growing, like you are seeing. >>>> >>>> It is worrying that they keep growing with the patch as well. >>>> I will have to look at it and see what can be done. >>>> >>>> Regards, >>>> Andreas >>>> >>>> On 2014-02-26 21:14, Dmitry Samersoff wrote: >>>>> Andreas, >>>>> >>>>> With JDK7 I didn't observe any crash with or without your patch. >>>>> Without the patch the number of active threads constantly grows, >>>>> with patch it remains the same. >>>>> >>>>> >>>>> uname -a >>>>> FreeBSD samersoff.net 9.2-RELEASE FreeBSD 9.2-RELEASE #1: Thu Jan 2 >>>>> 02:15:13 MSK 2014 dms at minext:/sys/amd64/compile/MIRCAT amd64 >>>>> >>>>> >>>>> With patch: >>>>> >>>>> #java -version >>>>> >>>>> openjdk version "1.7.0_45" >>>>> OpenJDK Runtime Environment (build 1.7.0_45-b18) >>>>> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) >>>>> Thread 80103f400 has exited with leftover thread-specific data >>>>> after 4 >>>>> destructor iterations >>>>> >>>>> #$JAVA_HOME/bin/java -Djava.library.path=$NATIVE >>>>> com.test.callback.App >>>>> >>>>> Java callback: native thread: 34376799232, java thread: Thread-391, 2 >>>>> active threads >>>>> Successfully detached native thread 0x801045400 >>>>> Deleting callback >>>>> >>>>> >>>>> Without patch: >>>>> >>>>> #/opt/openjdk7/bin/java -version >>>>> >>>>> openjdk version "1.7.0_25" >>>>> OpenJDK Runtime Environment (build 1.7.0_25-b15) >>>>> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode) >>>>> >>>>> #/opt/openjdk7/bin/java -Djava.library.path=$NATIVE >>>>> com.test.callback.App >>>>> >>>>> Java callback: native thread: 34376788992, java thread: >>>>> Thread-402, 404 >>>>> active threads >>>>> Successfully detached native thread 0x801042c00 >>>>> Deleting callback >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-02-10 20:21, Andreas Eriksson wrote: >>>>>> Hi, >>>>>> >>>>>> Could I please get reviews for this change. >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696 >>>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/ >>>>>> Mail discussion: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> JNI code is using pthread_key_create with a destructor to detach the >>>>>> thread from the JVM when the thread is exiting. >>>>>> For some flavors of Linux and BSD the JVM is also using the >>>>>> pthread_key_create, to store the Thread::current() value in a thread >>>>>> local storage. >>>>>> Since the thread local storage containing the thread pointer is >>>>>> erased >>>>>> (by pthread) before the JNI destructor runs, we run >>>>>> detachCurrentThread >>>>>> on a thread that has NULL as current thread. >>>>>> This fix uses a destructor for the thread pointer that restores the >>>>>> value, so that the JNI destructor can run detachCurrentThread >>>>>> successfully. >>>>>> More info in JBS. >>>>>> >>>>>> Testing: >>>>>> Native code regtest attached to JBS tested on Linux, but not on Mac >>>>>> since I don't have access to one. >>>>>> JPRT ran without a problem. >>>>>> >>>>>> Regards, >>>>>> Andreas >>> >> > From david.holmes at oracle.com Tue Mar 25 10:06:40 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Mar 2014 20:06:40 +1000 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <53312560.7080207@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> <532F9E8B.9020807@oracle.com> <53302181.9070204@oracle.com> <53302261.4@oracle.com> <53302DEB.8080508@oracle.com> <53310231.5070207@oracle.com> <53312560.7080207@oracle.com> Message-ID: <53315530.8040300@oracle.com> On 25/03/2014 4:42 PM, Dmitry Samersoff wrote: > Poonam, > > Your proposal looks good for me. Thank you for doing it. I concur. It is a good compromise to allow forward progress. Thanks, David > > On 2014-03-25 08:12, Poonam Bajaj wrote: >> Hi David, Dmitry, >> >> I understand both the concerns: >> - By using MAXPATHLEN which is defined as 4096 bytes, we would be >> allocating 4KB stack buffers where they are currently 2KB. >> - By removing the path length check in these functions we open the risk >> of stack overflow errors by creating large buffers on the stack as the >> user input may be unreasonably large. >> >> How about I just remove the path length check in os::open() for this bug >> where we are not creating any stack buffers based on the path input >> given by the user, and leave os::stat() as it is where a path buffer is >> created on the stack based on the user input. This bug only requires to >> remove the limitation while opening the files and the change in >> os::open() would fix that. >> >> I will file another bug to take care of the inconsistent use of >> MAXPATHLEN and MAX_PATH in os_linux.cpp file. >> >> Let me know your thoughts. > > -Dmitry > > > >> >> Thanks, >> Poonam >> >> On 3/24/2014 6:36 PM, Dmitry Samersoff wrote: >>> David, >>> >>>> The issue here is to remove the internal limitation. We can't just >>>> make the replacement you suggest because we will suddenly be >>>> allocating 4KB stack buffers where they were previously 2KB. That is >>>> bound to break something. >>> I share your concern but what we have today[1] is not acceptable. We >>> have to make decision and either go with our own constant MAX_PATH (2*k) >>> with clear justification why we don't follow rest of the linux or >>> use one of system constants: MAXPATHLEN or PAH_MAX. >>> >>> But impact of this cleanup have to be carefully evaluated and probably >>> out of scope of this CR. >>> >>> *As for proposed changes*: >>> >>> I'm against of dynamic allocation in stack based on user input - it can >>> lead to stack overflow in some cases and cause intermittent failures >>> that very hard to debug. >>> >>> So we should either change this value to MAXPATHLEN and hope that >>> testing catch all problems or postpone the changes to complete and >>> careful cleanup. >>> >>> [1] >>> >>> jaja:vm#grep -n PATH_MAX os_linux.cpp >>> >>> 2619: char buf[PATH_MAX+1]; >>> >>> jaja:vm#grep -n MAXPATHLEN os_linux.cpp >>> >>> 379: char buf[MAXPATHLEN]; >>> 2310:static char saved_jvm_path[MAXPATHLEN] = {0}; >>> 2315: if (buflen< MAXPATHLEN) { >>> 2326: char dli_fname[MAXPATHLEN]; >>> 5977: char buf[MAXPATHLEN]; >>> 5978: char libmawtpath[MAXPATHLEN]; >>> >>> jaja:vm#grep -n MAX_PATH os_linux.cpp >>> >>> 110:#define MAX_PATH (2 * K) >>> 5025: char pathbuf[MAX_PATH]; >>> 5026: if (strlen(path)> MAX_PATH - 1) { >>> 5052: char buf[sizeof(struct dirent) + MAX_PATH]; >>> 5075: if (strlen(path)> MAX_PATH - 1) { >>> 5393: char filename[MAX_PATH]; >>> 5395: jio_snprintf(filename, MAX_PATH, PauseAtStartupFile); >>> 5397: jio_snprintf(filename, MAX_PATH, "./vm.paused.%d", >>> current_process_id()); >>> >>> -Dmitry >>> >>> On 2014-03-24 16:17, David Holmes wrote: >>>> Dmitry, >>>> >>>> On 24/03/2014 10:13 PM, Dmitry Samersoff wrote: >>>>> Poonam, >>>>> >>>>> As far as I understand, MAX_PATH is here for a while but later we start >>>>> using MAXPATHLEN. >>>>> >>>>> I would recommend to replace all usage of MAX_PATH and PATH_MAX >>>>> to MAXPATHLEN >>>> The issue here is to remove the internal limitation. We can't just make >>>> the replacement you suggest because we will suddenly be allocating 4KB >>>> stack buffers where they were previously 2KB. That is bound to break >>>> something. >>>> >>>> David >>>> >>>>> if you fill that these changes is go out of scope of JDK-7119643, >>>>> please >>>>> replace it inside os:stat() only to solve immediate needs and file a >>>>> separate CR to have it cleaned up. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-03-24 06:55, Poonam Bajaj wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: >>>>>>> Poonam, >>>>>>> >>>>>>> 1. >>>>>>> >>>>>>> MAXPATHLEN == PATH_MAX and it's a system constant that comes from >>>>>>> sys/param.h and linux/limits.h so current behavior of hotspot is >>>>>>> absolutely correct. >>>>>>> >>>>>>> Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so >>>>>>> this >>>>>>> patch makes hotspot behavior inconsistent. >>>>>>> >>>>>>> Typical value of PATH_MAX is 4096 so it's unclean for me why we have >>>>>>> problems with 2048 bytes file. >>>>>>> >>>>>>> We probably should check our reference build platform. >>>>>> The purpose of this change is to revert back to the same behavior >>>>>> as it >>>>>> was before the fix for 6348631 where we didn't have any path >>>>>> limitation >>>>>> in os::open() and os::stat() functions. >>>>>> >>>>>> But yes, you are right. We have the following in sys/param.h and >>>>>> linux/limits.h for the maximum allowed path length on linux platforms: >>>>>> #define PATH_MAX 4096 /* # chars in a path name including >>>>>> nul */ >>>>>> #define MAXPATHLEN PATH_MAX >>>>>> >>>>>> and MAXPATHLEN is also used in os_linux.cpp. So, if we have to insert >>>>>> the path limitation in os::open() and os::stat(), we should be using >>>>>> MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH defined >>>>>> and to a different value than MAXPATHLEN which is inconsistent with >>>>>> the >>>>>> linux definition? >>>>>> >>>>>>> 2. >>>>>>> >>>>>>> Test could be a pure java. >>>>>> Ok, will do. >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-03-21 16:52, Poonam Bajaj wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Review request for: >>>>>>>> JDK-7119643: It is >>>>>>>> not possible to read files with a path longer than 2048 characters >>>>>>>> >>>>>>>> Problem and Fix: This bug is a regression from 6u29 and exists >>>>>>>> only on >>>>>>>> Linux platform. With the fix for 6348631, a limit of MAX_PATH >>>>>>>> (2K) got >>>>>>>> introduced on the file path length in the os::open() and os::stat() >>>>>>>> functions in os_linux.cpp. These changes remove that limit. These >>>>>>>> changes also add a regression test case to check that the files >>>>>>>> having >>>>>>>> path longer than 2048 are read without any error. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >>>>>>>> >>>>>>>> This fix needs to go into 9, 8u, 7u and 6u. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Poonam >>>>>>>> >>>>> >>> > > From poonam.bajaj at oracle.com Tue Mar 25 11:03:10 2014 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Tue, 25 Mar 2014 16:33:10 +0530 Subject: Review Request JDK-7119643: It is not possible to read files with a path longer than 2048 characters In-Reply-To: <53315530.8040300@oracle.com> References: <532C3613.7030808@oracle.com> <532F33A8.3010105@oracle.com> <532F9E8B.9020807@oracle.com> <53302181.9070204@oracle.com> <53302261.4@oracle.com> <53302DEB.8080508@oracle.com> <53310231.5070207@oracle.com> <53312560.7080207@oracle.com> <53315530.8040300@oracle.com> Message-ID: <5331626E.8020304@oracle.com> Ok, thanks. I will try to convert the test to a pure java test case and will re-submit the review request. Thanks, Poonam On 3/25/2014 3:36 PM, David Holmes wrote: > On 25/03/2014 4:42 PM, Dmitry Samersoff wrote: >> Poonam, >> >> Your proposal looks good for me. Thank you for doing it. > > I concur. It is a good compromise to allow forward progress. > > Thanks, > David > >> >> On 2014-03-25 08:12, Poonam Bajaj wrote: >>> Hi David, Dmitry, >>> >>> I understand both the concerns: >>> - By using MAXPATHLEN which is defined as 4096 bytes, we would be >>> allocating 4KB stack buffers where they are currently 2KB. >>> - By removing the path length check in these functions we open the risk >>> of stack overflow errors by creating large buffers on the stack as the >>> user input may be unreasonably large. >>> >>> How about I just remove the path length check in os::open() for this >>> bug >>> where we are not creating any stack buffers based on the path input >>> given by the user, and leave os::stat() as it is where a path buffer is >>> created on the stack based on the user input. This bug only requires to >>> remove the limitation while opening the files and the change in >>> os::open() would fix that. >>> >>> I will file another bug to take care of the inconsistent use of >>> MAXPATHLEN and MAX_PATH in os_linux.cpp file. >>> >>> Let me know your thoughts. >> >> -Dmitry >> >> >> >>> >>> Thanks, >>> Poonam >>> >>> On 3/24/2014 6:36 PM, Dmitry Samersoff wrote: >>>> David, >>>> >>>>> The issue here is to remove the internal limitation. We can't just >>>>> make the replacement you suggest because we will suddenly be >>>>> allocating 4KB stack buffers where they were previously 2KB. That is >>>>> bound to break something. >>>> I share your concern but what we have today[1] is not acceptable. We >>>> have to make decision and either go with our own constant MAX_PATH >>>> (2*k) >>>> with clear justification why we don't follow rest of the linux or >>>> use one of system constants: MAXPATHLEN or PAH_MAX. >>>> >>>> But impact of this cleanup have to be carefully evaluated and probably >>>> out of scope of this CR. >>>> >>>> *As for proposed changes*: >>>> >>>> I'm against of dynamic allocation in stack based on user input - it >>>> can >>>> lead to stack overflow in some cases and cause intermittent failures >>>> that very hard to debug. >>>> >>>> So we should either change this value to MAXPATHLEN and hope that >>>> testing catch all problems or postpone the changes to complete and >>>> careful cleanup. >>>> >>>> [1] >>>> >>>> jaja:vm#grep -n PATH_MAX os_linux.cpp >>>> >>>> 2619: char buf[PATH_MAX+1]; >>>> >>>> jaja:vm#grep -n MAXPATHLEN os_linux.cpp >>>> >>>> 379: char buf[MAXPATHLEN]; >>>> 2310:static char saved_jvm_path[MAXPATHLEN] = {0}; >>>> 2315: if (buflen< MAXPATHLEN) { >>>> 2326: char dli_fname[MAXPATHLEN]; >>>> 5977: char buf[MAXPATHLEN]; >>>> 5978: char libmawtpath[MAXPATHLEN]; >>>> >>>> jaja:vm#grep -n MAX_PATH os_linux.cpp >>>> >>>> 110:#define MAX_PATH (2 * K) >>>> 5025: char pathbuf[MAX_PATH]; >>>> 5026: if (strlen(path)> MAX_PATH - 1) { >>>> 5052: char buf[sizeof(struct dirent) + MAX_PATH]; >>>> 5075: if (strlen(path)> MAX_PATH - 1) { >>>> 5393: char filename[MAX_PATH]; >>>> 5395: jio_snprintf(filename, MAX_PATH, PauseAtStartupFile); >>>> 5397: jio_snprintf(filename, MAX_PATH, "./vm.paused.%d", >>>> current_process_id()); >>>> >>>> -Dmitry >>>> >>>> On 2014-03-24 16:17, David Holmes wrote: >>>>> Dmitry, >>>>> >>>>> On 24/03/2014 10:13 PM, Dmitry Samersoff wrote: >>>>>> Poonam, >>>>>> >>>>>> As far as I understand, MAX_PATH is here for a while but later we >>>>>> start >>>>>> using MAXPATHLEN. >>>>>> >>>>>> I would recommend to replace all usage of MAX_PATH and PATH_MAX >>>>>> to MAXPATHLEN >>>>> The issue here is to remove the internal limitation. We can't just >>>>> make >>>>> the replacement you suggest because we will suddenly be allocating >>>>> 4KB >>>>> stack buffers where they were previously 2KB. That is bound to break >>>>> something. >>>>> >>>>> David >>>>> >>>>>> if you fill that these changes is go out of scope of JDK-7119643, >>>>>> please >>>>>> replace it inside os:stat() only to solve immediate needs and file a >>>>>> separate CR to have it cleaned up. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-03-24 06:55, Poonam Bajaj wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> On 3/24/2014 12:49 AM, Dmitry Samersoff wrote: >>>>>>>> Poonam, >>>>>>>> >>>>>>>> 1. >>>>>>>> >>>>>>>> MAXPATHLEN == PATH_MAX and it's a system constant that comes from >>>>>>>> sys/param.h and linux/limits.h so current behavior of hotspot is >>>>>>>> absolutely correct. >>>>>>>> >>>>>>>> Moreover, we uses MAXPATHLEN in many places in os_*.cpp files, so >>>>>>>> this >>>>>>>> patch makes hotspot behavior inconsistent. >>>>>>>> >>>>>>>> Typical value of PATH_MAX is 4096 so it's unclean for me why we >>>>>>>> have >>>>>>>> problems with 2048 bytes file. >>>>>>>> >>>>>>>> We probably should check our reference build platform. >>>>>>> The purpose of this change is to revert back to the same behavior >>>>>>> as it >>>>>>> was before the fix for 6348631 where we didn't have any path >>>>>>> limitation >>>>>>> in os::open() and os::stat() functions. >>>>>>> >>>>>>> But yes, you are right. We have the following in sys/param.h and >>>>>>> linux/limits.h for the maximum allowed path length on linux >>>>>>> platforms: >>>>>>> #define PATH_MAX 4096 /* # chars in a path name including >>>>>>> nul */ >>>>>>> #define MAXPATHLEN PATH_MAX >>>>>>> >>>>>>> and MAXPATHLEN is also used in os_linux.cpp. So, if we have to >>>>>>> insert >>>>>>> the path limitation in os::open() and os::stat(), we should be >>>>>>> using >>>>>>> MAXPATHLEN at all the places in os_linux.cpp. Why was MAX_PATH >>>>>>> defined >>>>>>> and to a different value than MAXPATHLEN which is inconsistent with >>>>>>> the >>>>>>> linux definition? >>>>>>> >>>>>>>> 2. >>>>>>>> >>>>>>>> Test could be a pure java. >>>>>>> Ok, will do. >>>>>>> >>>>>>> Thanks, >>>>>>> Poonam >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-03-21 16:52, Poonam Bajaj wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Review request for: >>>>>>>>> JDK-7119643: >>>>>>>>> It is >>>>>>>>> not possible to read files with a path longer than 2048 >>>>>>>>> characters >>>>>>>>> >>>>>>>>> Problem and Fix: This bug is a regression from 6u29 and exists >>>>>>>>> only on >>>>>>>>> Linux platform. With the fix for 6348631, a limit of MAX_PATH >>>>>>>>> (2K) got >>>>>>>>> introduced on the file path length in the os::open() and >>>>>>>>> os::stat() >>>>>>>>> functions in os_linux.cpp. These changes remove that limit. These >>>>>>>>> changes also add a regression test case to check that the files >>>>>>>>> having >>>>>>>>> path longer than 2048 are read without any error. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~poonam/7119643/webrev.00/ >>>>>>>>> >>>>>>>>> This fix needs to go into 9, 8u, 7u and 6u. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Poonam >>>>>>>>> >>>>>> >>>> >> >> From dmitry.samersoff at oracle.com Tue Mar 25 12:46:23 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 25 Mar 2014 16:46:23 +0400 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> Message-ID: <53317A9F.7050400@oracle.com> Staffan, strtol() sets errno in two cases - ERANGE if supplied value is less then LONG_MIN or greater than LONG_MAX EINVAL if supplied base is not supported. if you pass probe == 'bla', strtol just return 0 and errno will not be set. So I'm not sure that check for errno has any value here. One of possible way to check that supplied value is convertible to long is char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == probe) { // we can't convert supplied value return JNI_ERR; } -Dmitry On 2014-03-25 11:31, Staffan Larsen wrote: > attachListener_solaris.cpp calls atoi() and then checks errno to see if any errors occurred. The problem is that atoi() does not set errno, so some old value of errno is checked which sometimes causes the function to fail. > > The fix is to replace atoi() with strtol() which does set errno. But errno is only set if an error occurred and not set to 0 in case of success. Thus, I set errno to 0 before calling strtol() and check the value afterwards. > > Verified with a JPRT run. > > webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038296 > > Thanks, > /Staffan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mikhailo.seledtsov at oracle.com Tue Mar 25 13:22:01 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 25 Mar 2014 09:22:01 -0400 Subject: RFR (XS): JDK-8032222: [TESTBUG] runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with java.lang.RuntimeException In-Reply-To: <53308791.5090408@oracle.com> References: <53306AF7.1070403@oracle.com> <000401cf4789$d02c4e90$7084ebb0$@oracle.com> <53308791.5090408@oracle.com> Message-ID: <533182F9.5030907@oracle.com> Coleen, Christian, Thank you for the review. I have updated my changes with comments suggested by Christian, and will submit the change to my sponsor (Christian). Misha On 3/24/2014 3:29 PM, Mikhailo Seledtsov wrote: > Christian, > > I will clarify by saying "This test has been unstable for Mac OSx > (see JDK-8032222)" > > Thank you, > Misha > > On 3/24/2014 1:52 PM, Christian Tornqvist wrote: >> Hi Misha, >> >> Could you put a comment above your change explaining why this test is >> skipped for Mac OS? >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Mikhailo Seledtsov [mailto:mikhailo.seledtsov at oracle.com] >> Sent: Monday, March 24, 2014 1:27 PM >> To: hotspot-runtime-dev >> Cc: Zhengyu Gu; Christian T?rnqvist >> Subject: RFR (XS): JDK-8032222: [TESTBUG] >> runtime/SharedArchiveFile/CdsWriteError.java fails on Mac OS with >> java.lang.RuntimeException >> >> Please review the following small change to the test. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8032222 >> Webrev: http://cr.openjdk.java.net/~mseledtsov/8032222/webrev.00/ >> >> Testing: >> 1. Local testing: ran the test - sanity check >> 2. Executed the test via JPRT >> 2014-03-24-163056.mseledtsov.work01 >> >> > From staffan.larsen at oracle.com Tue Mar 25 13:35:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 25 Mar 2014 14:35:59 +0100 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <53317A9F.7050400@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> Message-ID: On 25 mar 2014, at 13:46, Dmitry Samersoff wrote: > Staffan, > > strtol() sets errno in two cases - > > ERANGE if supplied value is less then LONG_MIN or greater than LONG_MAX > EINVAL if supplied base is not supported. > > if you pass probe == 'bla', strtol just return 0 and errno will not be > set. So I'm not sure that check for errno has any value here. > > One of possible way to check that supplied value is convertible to long is > > char *eptr = probe; > strtol(probe, (char **)&eptr, 10); > if (eptr == probe) { > // we can't convert supplied value > return JNI_ERR; > } Yes, that will find problems when trying to convert something like ?bla?. It will not capture the case where the input string is a too large (or small) value (value < LONG_MIN or > LONG_MAX). To capture both cases it looks like we need something like: errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, 10); if (end == probe || errno) { return JNI_ERR; } /Staffan > > -Dmitry > > > On 2014-03-25 11:31, Staffan Larsen wrote: >> attachListener_solaris.cpp calls atoi() and then checks errno to see if any errors occurred. The problem is that atoi() does not set errno, so some old value of errno is checked which sometimes causes the function to fail. >> >> The fix is to replace atoi() with strtol() which does set errno. But errno is only set if an error occurred and not set to 0 in case of success. Thus, I set errno to 0 before calling strtol() and check the value afterwards. >> >> Verified with a JPRT run. >> >> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8038296 >> >> Thanks, >> /Staffan >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Tue Mar 25 13:37:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 25 Mar 2014 14:37:55 +0100 Subject: Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> <533075CE.40205@gmail.com> <60AA9737-22FB-4957-B3B8-EA4E3E6838AD@oracle.com> Message-ID: <20966E69-4795-406E-A120-7C751AB3A812@oracle.com> (Adding hotspot-runtime-dev since some changes are in hotspot code). On 25 mar 2014, at 14:20, Paul Sandoz wrote: > > On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: > >> >> On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: >> >>> We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied to one version of the JDK. This looks like old code that has not been cleaned up. >>> >> >> Thanks, yes, looks like we can clean this up and also remove the deprecated methods at the same time. >> > > Here are some preliminary webrevs to clean up unsafe and also remove all old, deprecated and monitor-related methods: > > http://cr.openjdk.java.net/~psandoz/jdk9/jdk-unsafe-cleanup/webrev/jdk.patch > > http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-cleanup/webrev/ > > Passes all tests i have thrown at it locally. > > There is some additional clean up that could be done to remove prefetch read/write intrinsics hooked up to older versions of Unsafe: > > do_intrinsic(_prefetchRead, sun_misc_Unsafe, prefetchRead_name, prefetch_signature, F_RN) \ > do_name( prefetchRead_name, "prefetchRead") \ > do_intrinsic(_prefetchWrite, sun_misc_Unsafe, prefetchWrite_name, prefetch_signature, F_RN) \ > do_name( prefetchWrite_name, "prefetchWrite") \ > do_intrinsic(_prefetchReadStatic, sun_misc_Unsafe, prefetchReadStatic_name, prefetch_signature, F_SN) \ > do_name( prefetchReadStatic_name, "prefetchReadStatic") \ > do_intrinsic(_prefetchWriteStatic, sun_misc_Unsafe, prefetchWriteStatic_name, prefetch_signature, F_SN) \ > do_name( prefetchWriteStatic_name, "prefetchWriteStatic") \ > > That will also require updates in various other files. I presume these prefetch methods are never used throughout the runtime? > > Paul. From daniel.daugherty at oracle.com Tue Mar 25 16:53:34 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Mar 2014 10:53:34 -0600 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) Message-ID: <5331B48E.5020705@oracle.com> Greetings, Mr Simms' fix for the following bug has been backported to JDK8u-hs-dev: 8028280 ParkEvent leak when running modified runThese which only loads classes https://bugs.openjdk.java.net/browse/JDK-8028280 which allows the JDK8u-hs-dev version of the fix for the following bug to be updated to match the JDK9-hs version: 8028073 race condition in ObjectMonitor implementation causing deadlocks https://bugs.openjdk.java.net/browse/JDK-8028073 This minor tweak is being done with the following bug: 8038274 update 8u fix for 8028073 now that 8028280 is backported to 8u https://bugs.openjdk.java.net/browse/JDK-8038274 Here is the webrev: http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, I'm looking for one sanity check (R)eviewer or reviewer from the original set of folks that reviewed 8028073: The JDK9 reviewers: dholmes, sspitsyn, dice, acorn The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes Because I'm paranoid, I'm running the same set of vm.quick testing Adhoc test jobs and StressMonitorWait testing that was done on the JDK9 and JDK8u versions of the fix. Thanks, in advance, for any comments, questions or suggestions. Dan From paul.sandoz at oracle.com Tue Mar 25 17:05:04 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 25 Mar 2014 18:05:04 +0100 Subject: Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration In-Reply-To: <20966E69-4795-406E-A120-7C751AB3A812@oracle.com> References: <5689350D-66BA-474F-9FB7-E008823FE220@oracle.com> <313D6EFC-5DA4-48A6-8544-C34D52960072@oracle.com> <533075CE.40205@gmail.com> <60AA9737-22FB-4957-B3B8-EA4E3E6838AD@oracle.com> <20966E69-4795-406E-A120-7C751AB3A812@oracle.com> Message-ID: <5DE5CF7A-5628-46E5-A44C-370076BEEF5C@oracle.com> On Mar 25, 2014, at 2:37 PM, Staffan Larsen wrote: > (Adding hotspot-runtime-dev since some changes are in hotspot code). > > > On 25 mar 2014, at 14:20, Paul Sandoz wrote: > >> >> On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: >> >>> >>> On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: >>> >>>> We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied to one version of the JDK. This looks like old code that has not been cleaned up. >>>> >>> >>> Thanks, yes, looks like we can clean this up and also remove the deprecated methods at the same time. >>> >> >> Here are some preliminary webrevs to clean up unsafe and also remove all old, deprecated and monitor-related methods: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/jdk-unsafe-cleanup/webrev/jdk.patch >> >> http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-cleanup/webrev/ >> >> Passes all tests i have thrown at it locally. >> >> There is some additional clean up that could be done to remove prefetch read/write intrinsics hooked up to older versions of Unsafe: >> >> do_intrinsic(_prefetchRead, sun_misc_Unsafe, prefetchRead_name, prefetch_signature, F_RN) \ >> do_name( prefetchRead_name, "prefetchRead") \ >> do_intrinsic(_prefetchWrite, sun_misc_Unsafe, prefetchWrite_name, prefetch_signature, F_RN) \ >> do_name( prefetchWrite_name, "prefetchWrite") \ >> do_intrinsic(_prefetchReadStatic, sun_misc_Unsafe, prefetchReadStatic_name, prefetch_signature, F_SN) \ >> do_name( prefetchReadStatic_name, "prefetchReadStatic") \ >> do_intrinsic(_prefetchWriteStatic, sun_misc_Unsafe, prefetchWriteStatic_name, prefetch_signature, F_SN) \ >> do_name( prefetchWriteStatic_name, "prefetchWriteStatic") \ >> >> That will also require updates in various other files. I presume these prefetch methods are never used throughout the runtime? >> Here is that removal: http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-prefetch-cleanup/webrev/ Again all tests i threw at it passed. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dmitry.samersoff at oracle.com Tue Mar 25 18:36:39 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 25 Mar 2014 22:36:39 +0400 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> Message-ID: <5331CCB7.4090206@oracle.com> Staffan, > Yes, that will find problems when trying to convert something like > ?bla?. It will not capture the case where the input string is a too > large (or small) value (value < LONG_MIN or > LONG_MAX). To capture > both cases it looks like we need something like: > errno = 0; > char* end; > int probe_typess = (int) strtol(probe, &end, 10); > if (end == probe || errno) { > return JNI_ERR; > } As probe_typess is positive and you are converting long to int It's be better to check value boundaries explicitly: char* end; long ptl = strtol(probe, &end, 10); if (end == probe || ptl < 0 || ptl > MAX_INT) { return JNI_ERR; } int probe_typess = (int) ptl; -Dmitry On 2014-03-25 17:35, Staffan Larsen wrote: > > On 25 mar 2014, at 13:46, Dmitry Samersoff > wrote: > >> Staffan, >> >> strtol() sets errno in two cases - >> >> ERANGE if supplied value is less then LONG_MIN or greater than >> LONG_MAX EINVAL if supplied base is not supported. >> >> if you pass probe == 'bla', strtol just return 0 and errno will not >> be set. So I'm not sure that check for errno has any value here. >> >> One of possible way to check that supplied value is convertible to >> long is >> >> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == >> probe) { // we can't convert supplied value return JNI_ERR; } > > Yes, that will find problems when trying to convert something like > ?bla?. It will not capture the case where the input string is a too > large (or small) value (value < LONG_MIN or > LONG_MAX). To capture > both cases it looks like we need something like: > > errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, > 10); if (end == probe || errno) { return JNI_ERR; } > > > /Staffan > >> >> -Dmitry >> >> >> On 2014-03-25 11:31, Staffan Larsen wrote: >>> attachListener_solaris.cpp calls atoi() and then checks errno to >>> see if any errors occurred. The problem is that atoi() does not >>> set errno, so some old value of errno is checked which sometimes >>> causes the function to fail. >>> >>> The fix is to replace atoi() with strtol() which does set errno. >>> But errno is only set if an error occurred and not set to 0 in >>> case of success. Thus, I set errno to 0 before calling strtol() >>> and check the value afterwards. >>> >>> Verified with a JPRT run. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: >>> https://bugs.openjdk.java.net/browse/JDK-8038296 >>> >>> Thanks, /Staffan >>> >> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me >> the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Tue Mar 25 22:03:13 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Mar 2014 16:03:13 -0600 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) In-Reply-To: <5331B48E.5020705@oracle.com> References: <5331B48E.5020705@oracle.com> Message-ID: <5331FD21.5020102@oracle.com> I put this in the bug report, but maybe putting it in the e-mail thread will make things easier: Daniel Daugherty added a comment - 2014-03-24 16:51 Here's the remaining diffs between the 8u-hs-dev and JDK9-hs versions of the file: $ diff src/share/vm/runtime/objectMonitor.cpp{,.jdk9-hs} 237c237 < // dequeue operation after acquisition (in the ::enter() epilog) and --- > // dequeue operation after acquisition (in the ::enter() epilogue) and 692c692 < // ST Responsible=null; MEMBAR (in enter epilog - here) --- > // ST Responsible=null; MEMBAR (in enter epilogue - here) 2058c2058 < // Slighty racy, but benign ... --- > // Slightly racy, but benign ... Anyone? :-) Dan On 3/25/14 10:53 AM, Daniel D. Daugherty wrote: > Greetings, > > Mr Simms' fix for the following bug has been backported to JDK8u-hs-dev: > > 8028280 ParkEvent leak when running modified runThese which only > loads classes > https://bugs.openjdk.java.net/browse/JDK-8028280 > > which allows the JDK8u-hs-dev version of the fix for the following bug > to be updated to match the JDK9-hs version: > > 8028073 race condition in ObjectMonitor implementation causing > deadlocks > https://bugs.openjdk.java.net/browse/JDK-8028073 > > This minor tweak is being done with the following bug: > > 8038274 update 8u fix for 8028073 now that 8028280 is backported > to 8u > https://bugs.openjdk.java.net/browse/JDK-8038274 > > Here is the webrev: > > http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ > > Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, > I'm looking for one sanity check (R)eviewer or reviewer from the > original set of folks that reviewed 8028073: > > The JDK9 reviewers: dholmes, sspitsyn, dice, acorn > The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes > > Because I'm paranoid, I'm running the same set of vm.quick testing > Adhoc test jobs and StressMonitorWait testing that was done on the > JDK9 and JDK8u versions of the fix. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > > From coleen.phillimore at oracle.com Tue Mar 25 22:05:38 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 25 Mar 2014 18:05:38 -0400 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) In-Reply-To: <5331FD21.5020102@oracle.com> References: <5331B48E.5020705@oracle.com> <5331FD21.5020102@oracle.com> Message-ID: <5331FDB2.1000708@oracle.com> this is fine. Coleen On 3/25/14 6:03 PM, Daniel D. Daugherty wrote: > I put this in the bug report, but maybe putting it in > the e-mail thread will make things easier: > > Daniel Daugherty added a comment - 2014-03-24 16:51 > Here's the remaining diffs between the 8u-hs-dev and JDK9-hs versions > of the file: > > $ diff src/share/vm/runtime/objectMonitor.cpp{,.jdk9-hs} > 237c237 > < // dequeue operation after acquisition (in the ::enter() epilog) and > --- > > // dequeue operation after acquisition (in the ::enter() epilogue) and > 692c692 > < // ST Responsible=null; MEMBAR (in enter epilog - here) > --- > > // ST Responsible=null; MEMBAR (in enter epilogue - here) > 2058c2058 > < // Slighty racy, but benign ... > --- > > // Slightly racy, but benign ... > > > Anyone? :-) > > Dan > > > On 3/25/14 10:53 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Mr Simms' fix for the following bug has been backported to JDK8u-hs-dev: >> >> 8028280 ParkEvent leak when running modified runThese which only >> loads classes >> https://bugs.openjdk.java.net/browse/JDK-8028280 >> >> which allows the JDK8u-hs-dev version of the fix for the following bug >> to be updated to match the JDK9-hs version: >> >> 8028073 race condition in ObjectMonitor implementation causing >> deadlocks >> https://bugs.openjdk.java.net/browse/JDK-8028073 >> >> This minor tweak is being done with the following bug: >> >> 8038274 update 8u fix for 8028073 now that 8028280 is backported >> to 8u >> https://bugs.openjdk.java.net/browse/JDK-8038274 >> >> Here is the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ >> >> Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, >> I'm looking for one sanity check (R)eviewer or reviewer from the >> original set of folks that reviewed 8028073: >> >> The JDK9 reviewers: dholmes, sspitsyn, dice, acorn >> The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes >> >> Because I'm paranoid, I'm running the same set of vm.quick testing >> Adhoc test jobs and StressMonitorWait testing that was done on the >> JDK9 and JDK8u versions of the fix. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> >> > From daniel.daugherty at oracle.com Tue Mar 25 22:15:33 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Mar 2014 16:15:33 -0600 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) In-Reply-To: <5331FDB2.1000708@oracle.com> References: <5331B48E.5020705@oracle.com> <5331FD21.5020102@oracle.com> <5331FDB2.1000708@oracle.com> Message-ID: <53320005.2010405@oracle.com> Thanks Coleen! Dan On 3/25/14 4:05 PM, Coleen Phillimore wrote: > this is fine. > Coleen > > On 3/25/14 6:03 PM, Daniel D. Daugherty wrote: >> I put this in the bug report, but maybe putting it in >> the e-mail thread will make things easier: >> >> Daniel Daugherty added a comment - 2014-03-24 16:51 >> Here's the remaining diffs between the 8u-hs-dev and JDK9-hs versions >> of the file: >> >> $ diff src/share/vm/runtime/objectMonitor.cpp{,.jdk9-hs} >> 237c237 >> < // dequeue operation after acquisition (in the ::enter() epilog) and >> --- >> > // dequeue operation after acquisition (in the ::enter() epilogue) and >> 692c692 >> < // ST Responsible=null; MEMBAR (in enter epilog - here) >> --- >> > // ST Responsible=null; MEMBAR (in enter epilogue - here) >> 2058c2058 >> < // Slighty racy, but benign ... >> --- >> > // Slightly racy, but benign ... >> >> >> Anyone? :-) >> >> Dan >> >> >> On 3/25/14 10:53 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Mr Simms' fix for the following bug has been backported to >>> JDK8u-hs-dev: >>> >>> 8028280 ParkEvent leak when running modified runThese which only >>> loads classes >>> https://bugs.openjdk.java.net/browse/JDK-8028280 >>> >>> which allows the JDK8u-hs-dev version of the fix for the following bug >>> to be updated to match the JDK9-hs version: >>> >>> 8028073 race condition in ObjectMonitor implementation causing >>> deadlocks >>> https://bugs.openjdk.java.net/browse/JDK-8028073 >>> >>> This minor tweak is being done with the following bug: >>> >>> 8038274 update 8u fix for 8028073 now that 8028280 is backported >>> to 8u >>> https://bugs.openjdk.java.net/browse/JDK-8038274 >>> >>> Here is the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ >>> >>> Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, >>> I'm looking for one sanity check (R)eviewer or reviewer from the >>> original set of folks that reviewed 8028073: >>> >>> The JDK9 reviewers: dholmes, sspitsyn, dice, acorn >>> The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes >>> >>> Because I'm paranoid, I'm running the same set of vm.quick testing >>> Adhoc test jobs and StressMonitorWait testing that was done on the >>> JDK9 and JDK8u versions of the fix. >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan >>> >>> >> > From serguei.spitsyn at oracle.com Tue Mar 25 22:37:09 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 25 Mar 2014 15:37:09 -0700 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) In-Reply-To: <53320005.2010405@oracle.com> References: <5331B48E.5020705@oracle.com> <5331FD21.5020102@oracle.com> <5331FDB2.1000708@oracle.com> <53320005.2010405@oracle.com> Message-ID: <53320515.80701@oracle.com> In case, you need extra review ... All looks good to me. Thanks, Serguei On 3/25/14 3:15 PM, Daniel D. Daugherty wrote: > Thanks Coleen! > > Dan > > > On 3/25/14 4:05 PM, Coleen Phillimore wrote: >> this is fine. >> Coleen >> >> On 3/25/14 6:03 PM, Daniel D. Daugherty wrote: >>> I put this in the bug report, but maybe putting it in >>> the e-mail thread will make things easier: >>> >>> Daniel Daugherty added a comment - 2014-03-24 16:51 >>> Here's the remaining diffs between the 8u-hs-dev and JDK9-hs >>> versions of the file: >>> >>> $ diff src/share/vm/runtime/objectMonitor.cpp{,.jdk9-hs} >>> 237c237 >>> < // dequeue operation after acquisition (in the ::enter() epilog) and >>> --- >>> > // dequeue operation after acquisition (in the ::enter() epilogue) >>> and >>> 692c692 >>> < // ST Responsible=null; MEMBAR (in enter epilog - here) >>> --- >>> > // ST Responsible=null; MEMBAR (in enter epilogue - here) >>> 2058c2058 >>> < // Slighty racy, but benign ... >>> --- >>> > // Slightly racy, but benign ... >>> >>> >>> Anyone? :-) >>> >>> Dan >>> >>> >>> On 3/25/14 10:53 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Mr Simms' fix for the following bug has been backported to >>>> JDK8u-hs-dev: >>>> >>>> 8028280 ParkEvent leak when running modified runThese which only >>>> loads classes >>>> https://bugs.openjdk.java.net/browse/JDK-8028280 >>>> >>>> which allows the JDK8u-hs-dev version of the fix for the following bug >>>> to be updated to match the JDK9-hs version: >>>> >>>> 8028073 race condition in ObjectMonitor implementation causing >>>> deadlocks >>>> https://bugs.openjdk.java.net/browse/JDK-8028073 >>>> >>>> This minor tweak is being done with the following bug: >>>> >>>> 8038274 update 8u fix for 8028073 now that 8028280 is >>>> backported to 8u >>>> https://bugs.openjdk.java.net/browse/JDK-8038274 >>>> >>>> Here is the webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ >>>> >>>> Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, >>>> I'm looking for one sanity check (R)eviewer or reviewer from the >>>> original set of folks that reviewed 8028073: >>>> >>>> The JDK9 reviewers: dholmes, sspitsyn, dice, acorn >>>> The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes >>>> >>>> Because I'm paranoid, I'm running the same set of vm.quick testing >>>> Adhoc test jobs and StressMonitorWait testing that was done on the >>>> JDK9 and JDK8u versions of the fix. >>>> >>>> Thanks, in advance, for any comments, questions or suggestions. >>>> >>>> Dan >>>> >>>> >>> >> > From daniel.daugherty at oracle.com Tue Mar 25 22:42:44 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Mar 2014 16:42:44 -0600 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) In-Reply-To: <53320515.80701@oracle.com> References: <5331B48E.5020705@oracle.com> <5331FD21.5020102@oracle.com> <5331FDB2.1000708@oracle.com> <53320005.2010405@oracle.com> <53320515.80701@oracle.com> Message-ID: <53320664.5000203@oracle.com> Extra eyes are always welcome! Thanks! The vm.quick Adhoc is already finished without any regressions... I'm just waiting for the 12 hour stress test runs to finish... Dan On 3/25/14 4:37 PM, serguei.spitsyn at oracle.com wrote: > In case, you need extra review ... > All looks good to me. > > Thanks, > Serguei > > On 3/25/14 3:15 PM, Daniel D. Daugherty wrote: >> Thanks Coleen! >> >> Dan >> >> >> On 3/25/14 4:05 PM, Coleen Phillimore wrote: >>> this is fine. >>> Coleen >>> >>> On 3/25/14 6:03 PM, Daniel D. Daugherty wrote: >>>> I put this in the bug report, but maybe putting it in >>>> the e-mail thread will make things easier: >>>> >>>> Daniel Daugherty added a comment - 2014-03-24 16:51 >>>> Here's the remaining diffs between the 8u-hs-dev and JDK9-hs >>>> versions of the file: >>>> >>>> $ diff src/share/vm/runtime/objectMonitor.cpp{,.jdk9-hs} >>>> 237c237 >>>> < // dequeue operation after acquisition (in the ::enter() epilog) and >>>> --- >>>> > // dequeue operation after acquisition (in the ::enter() >>>> epilogue) and >>>> 692c692 >>>> < // ST Responsible=null; MEMBAR (in enter epilog - here) >>>> --- >>>> > // ST Responsible=null; MEMBAR (in enter epilogue - here) >>>> 2058c2058 >>>> < // Slighty racy, but benign ... >>>> --- >>>> > // Slightly racy, but benign ... >>>> >>>> >>>> Anyone? :-) >>>> >>>> Dan >>>> >>>> >>>> On 3/25/14 10:53 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Mr Simms' fix for the following bug has been backported to >>>>> JDK8u-hs-dev: >>>>> >>>>> 8028280 ParkEvent leak when running modified runThese which only >>>>> loads classes >>>>> https://bugs.openjdk.java.net/browse/JDK-8028280 >>>>> >>>>> which allows the JDK8u-hs-dev version of the fix for the following >>>>> bug >>>>> to be updated to match the JDK9-hs version: >>>>> >>>>> 8028073 race condition in ObjectMonitor implementation causing >>>>> deadlocks >>>>> https://bugs.openjdk.java.net/browse/JDK-8028073 >>>>> >>>>> This minor tweak is being done with the following bug: >>>>> >>>>> 8038274 update 8u fix for 8028073 now that 8028280 is >>>>> backported to 8u >>>>> https://bugs.openjdk.java.net/browse/JDK-8038274 >>>>> >>>>> Here is the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ >>>>> >>>>> Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, >>>>> I'm looking for one sanity check (R)eviewer or reviewer from the >>>>> original set of folks that reviewed 8028073: >>>>> >>>>> The JDK9 reviewers: dholmes, sspitsyn, dice, acorn >>>>> The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes >>>>> >>>>> Because I'm paranoid, I'm running the same set of vm.quick testing >>>>> Adhoc test jobs and StressMonitorWait testing that was done on the >>>>> JDK9 and JDK8u versions of the fix. >>>>> >>>>> Thanks, in advance, for any comments, questions or suggestions. >>>>> >>>>> Dan >>>>> >>>>> >>>> >>> >> > From david.simms at oracle.com Wed Mar 26 08:51:19 2014 From: david.simms at oracle.com (David Simms) Date: Wed, 26 Mar 2014 09:51:19 +0100 Subject: RFR (XXS) 8037295: Add size_t versions of Atomic::add, dec, and inc Message-ID: <53329507.3080003@oracle.com> Gidday, Some folks have requested size_t type variants of Atomic add, dec and inc; to save on messy looking casts or using an inappropriate type. Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-8037295 Webrev: http://cr.openjdk.java.net/~dsimms/8037295/ Have searched for existing cases, most looked like a potential change in type size or requiring const (still needs cast), except for heapRegionRemSet.hpp where size_t was clearly the intended type. Testing: hotspot jtreg tests and "quick test list". Cheers /David Simms From david.holmes at oracle.com Wed Mar 26 09:23:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Mar 2014 19:23:06 +1000 Subject: RFR (XXS) 8037295: Add size_t versions of Atomic::add, dec, and inc In-Reply-To: <53329507.3080003@oracle.com> References: <53329507.3080003@oracle.com> Message-ID: <53329C7A.9000309@oracle.com> Hi David, On 26/03/2014 6:51 PM, David Simms wrote: > Gidday, > > Some folks have requested size_t type variants of Atomic add, dec and > inc; to save on messy looking casts or using an inappropriate type. > > Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-8037295 > > Webrev: http://cr.openjdk.java.net/~dsimms/8037295/ > > > Have searched for existing cases, most looked like a potential change in > type size or requiring const (still needs cast), except for > heapRegionRemSet.hpp where size_t was clearly the intended type. > > Testing: hotspot jtreg tests and "quick test list". This looks okay to me. Is there any reason not to provide xchg and cmpxchg size_t variants too? Thanks, David H. > Cheers > /David Simms > > > > From david.holmes at oracle.com Wed Mar 26 09:30:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Mar 2014 19:30:18 +1000 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) In-Reply-To: <5331B48E.5020705@oracle.com> References: <5331B48E.5020705@oracle.com> Message-ID: <53329E2A.1010603@oracle.com> Thanks Dan! Good to see this all in sync now. (pardon the pun :) ) David H. On 26/03/2014 2:53 AM, Daniel D. Daugherty wrote: > Greetings, > > Mr Simms' fix for the following bug has been backported to JDK8u-hs-dev: > > 8028280 ParkEvent leak when running modified runThese which only > loads classes > https://bugs.openjdk.java.net/browse/JDK-8028280 > > which allows the JDK8u-hs-dev version of the fix for the following bug > to be updated to match the JDK9-hs version: > > 8028073 race condition in ObjectMonitor implementation causing > deadlocks > https://bugs.openjdk.java.net/browse/JDK-8028073 > > This minor tweak is being done with the following bug: > > 8038274 update 8u fix for 8028073 now that 8028280 is backported to 8u > https://bugs.openjdk.java.net/browse/JDK-8038274 > > Here is the webrev: > > http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ > > Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, > I'm looking for one sanity check (R)eviewer or reviewer from the > original set of folks that reviewed 8028073: > > The JDK9 reviewers: dholmes, sspitsyn, dice, acorn > The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes > > Because I'm paranoid, I'm running the same set of vm.quick testing > Adhoc test jobs and StressMonitorWait testing that was done on the > JDK9 and JDK8u versions of the fix. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From david.holmes at oracle.com Wed Mar 26 09:38:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Mar 2014 19:38:09 +1000 Subject: RFR: JDK-8033696: "assert(thread != NULL) failed: just checking" due to Thread::current() and JNI pthread interaction In-Reply-To: <5331529E.8090209@oracle.com> References: <52F8FC95.5090608@oracle.com> <530E4B1C.2070201@oracle.com> <530F122F.1090107@oracle.com> <530F23DE.8010008@oracle.com> <530F30C1.7070601@oracle.com> <53151A83.1090106@oracle.com> <5331529E.8090209@oracle.com> Message-ID: <5332A001.3080203@oracle.com> Still seems okay to me. Thanks, David On 25/03/2014 7:55 PM, Andreas Eriksson wrote: > Hi, > > Could I get some eyes on this new webrev? > > Thanks, > Andreas > > On 2014-03-04 01:12, Andreas Eriksson wrote: >> That output was because the VMThread didn't reset it's TLS before >> exiting (presumably since the VM is shutting down anyway). >> This meant that the thread pointer destructor was run until the >> pthread implementation gave up. >> I added code that sets the thread pointer to NULL before exiting the >> VMThread, ensuring the thread pointer destructor is never called for >> the exiting VMThread. >> >> A new updated webrev can be found here: >> http://cr.openjdk.java.net/~aeriksso/8033696/webrev.01/ >> >> I also removed the bug reference from the comments, since I got the >> feeling that it's usually discouraged. >> >> Thanks, >> Andreas >> >> On 2014-02-27 13:34, Andreas Eriksson wrote: >>> Oh, sorry, I misread your mail. >>> >>> I will look into the pthread output from java -version. >>> >>> Thread 80103f400 has exited with leftover thread-specific data after 4 >>> destructor iterations >>> >>> Thanks, >>> Andreas >>> >>> On 2014-02-27 12:39, Dmitry Samersoff wrote: >>>> Andreas, >>>> >>>> I's not growing - always only two threads. >>>> >>>> -Dmitry >>>> >>>> On 2014-02-27 14:23, Andreas Eriksson wrote: >>>>> Thanks Dmitry. >>>>> >>>>> There are no crashes, only an assert that is hit if running with a >>>>> debug >>>>> build. >>>>> Otherwise the active threads keep growing, like you are seeing. >>>>> >>>>> It is worrying that they keep growing with the patch as well. >>>>> I will have to look at it and see what can be done. >>>>> >>>>> Regards, >>>>> Andreas >>>>> >>>>> On 2014-02-26 21:14, Dmitry Samersoff wrote: >>>>>> Andreas, >>>>>> >>>>>> With JDK7 I didn't observe any crash with or without your patch. >>>>>> Without the patch the number of active threads constantly grows, >>>>>> with patch it remains the same. >>>>>> >>>>>> >>>>>> uname -a >>>>>> FreeBSD samersoff.net 9.2-RELEASE FreeBSD 9.2-RELEASE #1: Thu Jan 2 >>>>>> 02:15:13 MSK 2014 dms at minext:/sys/amd64/compile/MIRCAT amd64 >>>>>> >>>>>> >>>>>> With patch: >>>>>> >>>>>> #java -version >>>>>> >>>>>> openjdk version "1.7.0_45" >>>>>> OpenJDK Runtime Environment (build 1.7.0_45-b18) >>>>>> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) >>>>>> Thread 80103f400 has exited with leftover thread-specific data >>>>>> after 4 >>>>>> destructor iterations >>>>>> >>>>>> #$JAVA_HOME/bin/java -Djava.library.path=$NATIVE >>>>>> com.test.callback.App >>>>>> >>>>>> Java callback: native thread: 34376799232, java thread: Thread-391, 2 >>>>>> active threads >>>>>> Successfully detached native thread 0x801045400 >>>>>> Deleting callback >>>>>> >>>>>> >>>>>> Without patch: >>>>>> >>>>>> #/opt/openjdk7/bin/java -version >>>>>> >>>>>> openjdk version "1.7.0_25" >>>>>> OpenJDK Runtime Environment (build 1.7.0_25-b15) >>>>>> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode) >>>>>> >>>>>> #/opt/openjdk7/bin/java -Djava.library.path=$NATIVE >>>>>> com.test.callback.App >>>>>> >>>>>> Java callback: native thread: 34376788992, java thread: >>>>>> Thread-402, 404 >>>>>> active threads >>>>>> Successfully detached native thread 0x801042c00 >>>>>> Deleting callback >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2014-02-10 20:21, Andreas Eriksson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please get reviews for this change. >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696 >>>>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/ >>>>>>> Mail discussion: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> JNI code is using pthread_key_create with a destructor to detach the >>>>>>> thread from the JVM when the thread is exiting. >>>>>>> For some flavors of Linux and BSD the JVM is also using the >>>>>>> pthread_key_create, to store the Thread::current() value in a thread >>>>>>> local storage. >>>>>>> Since the thread local storage containing the thread pointer is >>>>>>> erased >>>>>>> (by pthread) before the JNI destructor runs, we run >>>>>>> detachCurrentThread >>>>>>> on a thread that has NULL as current thread. >>>>>>> This fix uses a destructor for the thread pointer that restores the >>>>>>> value, so that the JNI destructor can run detachCurrentThread >>>>>>> successfully. >>>>>>> More info in JBS. >>>>>>> >>>>>>> Testing: >>>>>>> Native code regtest attached to JBS tested on Linux, but not on Mac >>>>>>> since I don't have access to one. >>>>>>> JPRT ran without a problem. >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>> >>> >> > From david.simms at oracle.com Wed Mar 26 09:55:04 2014 From: david.simms at oracle.com (David Simms) Date: Wed, 26 Mar 2014 10:55:04 +0100 Subject: RFR (XXS) 8037295: Add size_t versions of Atomic::add, dec, and inc In-Reply-To: <53329C7A.9000309@oracle.com> References: <53329507.3080003@oracle.com> <53329C7A.9000309@oracle.com> Message-ID: <5332A3F8.2060003@oracle.com> On 26/03/2014 10:23 a.m., David Holmes wrote: > > This looks okay to me. Is there any reason not to provide xchg and > cmpxchg size_t variants too? > > Thanks, > David H. > There seems to be only one currently valid use (task queue), but it still requires casting...then there's a requirement for some ugly macro to check if "size_t == unsigned int"...in which case we already have those variants, i.e.: +#if (UINT_MAX == SIZE_MAX) // size_t is an "unsigned int" +#define ATOMIC_SIZE_T_IS_UINT +#endif + +#ifndef ATOMIC_SIZE_T_IS_UINT // else we already have it + inline static size_t cmpxchg (size_t exchange_value, volatile size_t* dest, size_t compare_value); +#endif I didn't find this appealing (tried to see if templates made it better...but this was even worse), and therefore chickened out. Thanks for the review. /Mr. Simms From david.holmes at oracle.com Wed Mar 26 11:46:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Mar 2014 21:46:20 +1000 Subject: RFR (XXS) 8037295: Add size_t versions of Atomic::add, dec, and inc In-Reply-To: <5332A3F8.2060003@oracle.com> References: <53329507.3080003@oracle.com> <53329C7A.9000309@oracle.com> <5332A3F8.2060003@oracle.com> Message-ID: <5332BE0C.3030404@oracle.com> On 26/03/2014 7:55 PM, David Simms wrote: > On 26/03/2014 10:23 a.m., David Holmes wrote: >> >> This looks okay to me. Is there any reason not to provide xchg and >> cmpxchg size_t variants too? >> >> Thanks, >> David H. >> > > There seems to be only one currently valid use (task queue), but it > still requires casting...then there's a requirement for some ugly macro > to check if "size_t == unsigned int"...in which case we already have > those variants, i.e.: > > +#if (UINT_MAX == SIZE_MAX) // size_t is an "unsigned int" > +#define ATOMIC_SIZE_T_IS_UINT > +#endif > + > > +#ifndef ATOMIC_SIZE_T_IS_UINT // else we already have it > + inline static size_t cmpxchg (size_t exchange_value, volatile > size_t* dest, size_t compare_value); > +#endif > > I didn't find this appealing (tried to see if templates made it > better...but this was even worse), and therefore chickened out. Ah I'd missed the fact we already have a uint version that causes an overload conflict. These typedefs seems to cause more problems than they fix. Thanks, David > Thanks for the review. > /Mr. Simms From daniel.daugherty at oracle.com Wed Mar 26 13:10:31 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 26 Mar 2014 07:10:31 -0600 Subject: RFR(XXS) update 8u fix for 8028073 now that 8028280 is backported to 8u (8038274) In-Reply-To: <53329E2A.1010603@oracle.com> References: <5331B48E.5020705@oracle.com> <53329E2A.1010603@oracle.com> Message-ID: <5332D1C7.5070807@oracle.com> You're very welcome and groan... :-) Dan On 3/26/14 3:30 AM, David Holmes wrote: > Thanks Dan! Good to see this all in sync now. (pardon the pun :) ) > > David H. > > On 26/03/2014 2:53 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Mr Simms' fix for the following bug has been backported to JDK8u-hs-dev: >> >> 8028280 ParkEvent leak when running modified runThese which only >> loads classes >> https://bugs.openjdk.java.net/browse/JDK-8028280 >> >> which allows the JDK8u-hs-dev version of the fix for the following bug >> to be updated to match the JDK9-hs version: >> >> 8028073 race condition in ObjectMonitor implementation causing >> deadlocks >> https://bugs.openjdk.java.net/browse/JDK-8028073 >> >> This minor tweak is being done with the following bug: >> >> 8038274 update 8u fix for 8028073 now that 8028280 is backported >> to 8u >> https://bugs.openjdk.java.net/browse/JDK-8038274 >> >> Here is the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8038274-webrev/0-jdk8u-hs-dev/ >> >> Since this is effectively a backport from JDK9-hs -> JDK8u-hs-dev, >> I'm looking for one sanity check (R)eviewer or reviewer from the >> original set of folks that reviewed 8028073: >> >> The JDK9 reviewers: dholmes, sspitsyn, dice, acorn >> The JDK8u reviewers: rdurbin, acorn, sspitsyn, dsimms, dholmes >> >> Because I'm paranoid, I'm running the same set of vm.quick testing >> Adhoc test jobs and StressMonitorWait testing that was done on the >> JDK9 and JDK8u versions of the fix. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From kevin.walls at oracle.com Wed Mar 26 23:08:30 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 26 Mar 2014 23:08:30 +0000 Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a humanly readable format Message-ID: <53335DEE.3080805@oracle.com> Hi, I'd like to get a review of this change: It's adding a human-readable breakdown of the elapsed time, which is currently printed in raw seconds in the hs_err file (it's the last item printed). This is on behalf of Masato Yoshido who has worked on it. Further details below, including a method that was used for manual testing. bug: https://bugs.openjdk.java.net/browse/JDK-8026334 webrev: http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/ Many thanks, Kevin Masato [Change details] - Time format will change as follows: (from) elapsed time: %d seconds (to) elapsed time: %d seconds (%dd %dh %dm %ds) - The reason why I leave the original elapsed time format is: -- We don?t need to remove the original format. If we remove it, ones who want time information in seconds need to calculate from day-, hour-, minute- and second-parts. - There is no code doing exactly the same thing. Another code to which we might be able to apply calculation similar to this conversion is the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time in GC log is a floating point number, while the time in hs_err log is an integer since there is a problem when %f is used in printf on Linux platform (See comments in os::print_date_and_time function). Therefore, the same code as this cannot simply be share with GC log. [Test] (1) Tested only part of code of elapsed time calculation and printing. --- test_print_time.cpp --- #include #include #include void print_date_and_time(double t) { int eltime = (int)t; // elapsed time in seconds int eldays, elhours, elminutes, elseconds; // for printing elapsed time in a humanly readable format eldays = eltime / 86400; elhours = (eltime - eldays * 86400) / 3600; elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60; elseconds = (eltime - eldays * 86400 - elhours * 3600 - elminutes * 60); printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime, eldays, elhours, elminutes, elseconds); printf("\n"); } int main(int argc, char *argv[]) { print_date_and_time((double)86399); print_date_and_time((double)86400); print_date_and_time((double)86401); printf("\n"); print_date_and_time((double)86399.999); print_date_and_time((double)86400.999); print_date_and_time((double)86401.999); printf("\n"); print_date_and_time((double)(-86399)); print_date_and_time((double)(-86400)); print_date_and_time((double)(-86401)); printf("\n"); print_date_and_time((double)INT_MAX); print_date_and_time((double)(INT_MAX+1)); print_date_and_time((double)UINT_MAX); } --- --- Run the test program $ ./test_print_time elapsed time: 86399 seconds (0d 23h 59m 59s) elapsed time: 86400 seconds (1d 0h 0m 0s) elapsed time: 86401 seconds (1d 0h 0m 1s) elapsed time: 86399 seconds (0d 23h 59m 59s) elapsed time: 86400 seconds (1d 0h 0m 0s) elapsed time: 86401 seconds (1d 0h 0m 1s) elapsed time: -86399 seconds (0d -23h -59m -59s) elapsed time: -86400 seconds (-1d 0h 0m 0s) elapsed time: -86401 seconds (-1d 0h 0m -1s) elapsed time: 2147483647 seconds (24855d 3h 14m 7s) elapsed time: -2147483648 seconds (-24855d -3h -14m -8s) elapsed time: -2147483648 seconds (-24855d -3h -14m -8s) --- (2) Tested using a JNI program causing Segmentation Violation. Tested on the following platforms: solaris sparcv9 solaris x64 linux x86 linux x64 windows x86 windows x64 macosx x64 hs_err_pid.log file was successfully generated with expected ?elapsed time? line on each platform. --- TestCrash.java --- public class TestCrash { static { System.loadLibrary("testcrash"); } public static native void crash(); public static void main(String[] args) { try { Thread.sleep(61000); } catch (InterruptedException e) { e.printStackTrace(); } crash(); } } --- --- TestCrash.c --- #include #ifdef __cplusplus extern "C" { #endif /* * Class: TestCrash * Method: crash * Signature: ()V */ JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass cls) { const char *p = "Hello, world!"; *(char *)p = 'a'; } #ifdef __cplusplus } #endif --- Thanks and best regards, Masato From coleen.phillimore at oracle.com Wed Mar 26 23:44:38 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Mar 2014 19:44:38 -0400 Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a humanly readable format In-Reply-To: <53335DEE.3080805@oracle.com> References: <53335DEE.3080805@oracle.com> Message-ID: <53336666.2060909@oracle.com> Can you make these expressions into a variable for the calculations? IE. 86400 = seconds_in_a_day 3600 = seconds_in_an_hour 60 = seconds_in_a_minute and then have eldays * 86400 be something like day_seconds Thanks - it would be nice if these numbers only appear once each. Coleen On 3/26/14 7:08 PM, Kevin Walls wrote: > > Hi, > > I'd like to get a review of this change: > > It's adding a human-readable breakdown of the elapsed time, which is > currently printed in raw seconds in the hs_err file (it's the last > item printed). > > This is on behalf of Masato Yoshido who has worked on it. Further > details below, including a method that was used for manual testing. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8026334 > > webrev: > http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/ > > Many thanks, > Kevin > Masato > > > [Change details] > > - Time format will change as follows: > > (from) > elapsed time: %d seconds > > (to) > elapsed time: %d seconds (%dd %dh %dm %ds) > > - The reason why I leave the original elapsed time format is: > -- We don?t need to remove the original format. If we remove it, ones > who want time information in seconds need to calculate from day-, > hour-, minute- and second-parts. > > - There is no code doing exactly the same thing. Another code to which > we might be able to apply calculation similar to this conversion is > the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time > in GC log is a floating point number, while the time in hs_err log > is an integer since there is a problem when %f is used in printf > on Linux platform (See comments in os::print_date_and_time function). > Therefore, the same code as this cannot simply be share with GC log. > > > [Test] > > (1) Tested only part of code of elapsed time calculation and printing. > > --- test_print_time.cpp --- > #include > #include > #include > > void print_date_and_time(double t) { > int eltime = (int)t; // elapsed time in seconds > int eldays, elhours, elminutes, elseconds; // for printing elapsed > time in a humanly readable format > eldays = eltime / 86400; > elhours = (eltime - eldays * 86400) / 3600; > elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60; > elseconds = (eltime - eldays * 86400 - elhours * 3600 - elminutes * > 60); > printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime, eldays, > elhours, elminutes, elseconds); > printf("\n"); > } > > int main(int argc, char *argv[]) { > print_date_and_time((double)86399); > print_date_and_time((double)86400); > print_date_and_time((double)86401); > printf("\n"); > > print_date_and_time((double)86399.999); > print_date_and_time((double)86400.999); > print_date_and_time((double)86401.999); > printf("\n"); > > print_date_and_time((double)(-86399)); > print_date_and_time((double)(-86400)); > print_date_and_time((double)(-86401)); > printf("\n"); > > print_date_and_time((double)INT_MAX); > print_date_and_time((double)(INT_MAX+1)); > print_date_and_time((double)UINT_MAX); > } > --- > > --- Run the test program > $ ./test_print_time > elapsed time: 86399 seconds (0d 23h 59m 59s) > elapsed time: 86400 seconds (1d 0h 0m 0s) > elapsed time: 86401 seconds (1d 0h 0m 1s) > > elapsed time: 86399 seconds (0d 23h 59m 59s) > elapsed time: 86400 seconds (1d 0h 0m 0s) > elapsed time: 86401 seconds (1d 0h 0m 1s) > > elapsed time: -86399 seconds (0d -23h -59m -59s) > elapsed time: -86400 seconds (-1d 0h 0m 0s) > elapsed time: -86401 seconds (-1d 0h 0m -1s) > > elapsed time: 2147483647 seconds (24855d 3h 14m 7s) > elapsed time: -2147483648 seconds (-24855d -3h -14m -8s) > elapsed time: -2147483648 seconds (-24855d -3h -14m -8s) > --- > > > (2) Tested using a JNI program causing Segmentation Violation. > Tested on the following platforms: > solaris sparcv9 > solaris x64 > linux x86 > linux x64 > windows x86 > windows x64 > macosx x64 > hs_err_pid.log file was successfully generated with expected > ?elapsed time? line on each platform. > > > --- TestCrash.java --- > public class TestCrash { > static { > System.loadLibrary("testcrash"); > } > > public static native void crash(); > > public static void main(String[] args) { > try { > Thread.sleep(61000); > } catch (InterruptedException e) { > e.printStackTrace(); > } > crash(); > } > } > --- > > --- TestCrash.c --- > #include > > #ifdef __cplusplus > extern "C" { > #endif > /* > * Class: TestCrash > * Method: crash > * Signature: ()V > */ > JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass cls) { > const char *p = "Hello, world!"; > *(char *)p = 'a'; > } > > #ifdef __cplusplus > } > #endif > --- > > > Thanks and best regards, > Masato > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Mar 27 07:55:40 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 27 Mar 2014 08:55:40 +0100 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <5331CCB7.4090206@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com> Message-ID: <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> Here is an updated webrev which incorporates Dmitry?s feedback: http://cr.openjdk.java.net/~sla/8038296/webrev.01/ Thanks, /Staffan On 25 mar 2014, at 19:36, Dmitry Samersoff wrote: > Staffan, > >> Yes, that will find problems when trying to convert something like >> ?bla?. It will not capture the case where the input string is a too >> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >> both cases it looks like we need something like: >> errno = 0; >> char* end; >> int probe_typess = (int) strtol(probe, &end, 10); >> if (end == probe || errno) { >> return JNI_ERR; >> } > > As probe_typess is positive and you are converting long to int > It's be better to check value boundaries explicitly: > > char* end; > long ptl = strtol(probe, &end, 10); > if (end == probe || ptl < 0 || ptl > MAX_INT) { > return JNI_ERR; > } > > int probe_typess = (int) ptl; > > > -Dmitry > > > On 2014-03-25 17:35, Staffan Larsen wrote: >> >> On 25 mar 2014, at 13:46, Dmitry Samersoff >> wrote: >> >>> Staffan, >>> >>> strtol() sets errno in two cases - >>> >>> ERANGE if supplied value is less then LONG_MIN or greater than >>> LONG_MAX EINVAL if supplied base is not supported. >>> >>> if you pass probe == 'bla', strtol just return 0 and errno will not >>> be set. So I'm not sure that check for errno has any value here. >>> >>> One of possible way to check that supplied value is convertible to >>> long is >>> >>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == >>> probe) { // we can't convert supplied value return JNI_ERR; } >> >> Yes, that will find problems when trying to convert something like >> ?bla?. It will not capture the case where the input string is a too >> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >> both cases it looks like we need something like: >> >> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, >> 10); if (end == probe || errno) { return JNI_ERR; } >> >> >> /Staffan >> >>> >>> -Dmitry >>> >>> >>> On 2014-03-25 11:31, Staffan Larsen wrote: >>>> attachListener_solaris.cpp calls atoi() and then checks errno to >>>> see if any errors occurred. The problem is that atoi() does not >>>> set errno, so some old value of errno is checked which sometimes >>>> causes the function to fail. >>>> >>>> The fix is to replace atoi() with strtol() which does set errno. >>>> But errno is only set if an error occurred and not set to 0 in >>>> case of success. Thus, I set errno to 0 before calling strtol() >>>> and check the value afterwards. >>>> >>>> Verified with a JPRT run. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8038296 >>>> >>>> Thanks, /Staffan >>>> >>> >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>> Russia * I would love to change the world, but they won't give me >>> the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Mar 27 08:12:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 27 Mar 2014 12:12:18 +0400 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com> <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> Message-ID: <5333DD62.9020601@oracle.com> Staffan, Looks good for me! -Dmitry On 2014-03-27 11:55, Staffan Larsen wrote: > Here is an updated webrev which incorporates Dmitry?s feedback: > > http://cr.openjdk.java.net/~sla/8038296/webrev.01/ > > Thanks, > /Staffan > > On 25 mar 2014, at 19:36, Dmitry Samersoff wrote: > >> Staffan, >> >>> Yes, that will find problems when trying to convert something like >>> ?bla?. It will not capture the case where the input string is a too >>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>> both cases it looks like we need something like: >>> errno = 0; >>> char* end; >>> int probe_typess = (int) strtol(probe, &end, 10); >>> if (end == probe || errno) { >>> return JNI_ERR; >>> } >> >> As probe_typess is positive and you are converting long to int >> It's be better to check value boundaries explicitly: >> >> char* end; >> long ptl = strtol(probe, &end, 10); >> if (end == probe || ptl < 0 || ptl > MAX_INT) { >> return JNI_ERR; >> } >> >> int probe_typess = (int) ptl; >> >> >> -Dmitry >> >> >> On 2014-03-25 17:35, Staffan Larsen wrote: >>> >>> On 25 mar 2014, at 13:46, Dmitry Samersoff >>> wrote: >>> >>>> Staffan, >>>> >>>> strtol() sets errno in two cases - >>>> >>>> ERANGE if supplied value is less then LONG_MIN or greater than >>>> LONG_MAX EINVAL if supplied base is not supported. >>>> >>>> if you pass probe == 'bla', strtol just return 0 and errno will not >>>> be set. So I'm not sure that check for errno has any value here. >>>> >>>> One of possible way to check that supplied value is convertible to >>>> long is >>>> >>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == >>>> probe) { // we can't convert supplied value return JNI_ERR; } >>> >>> Yes, that will find problems when trying to convert something like >>> ?bla?. It will not capture the case where the input string is a too >>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>> both cases it looks like we need something like: >>> >>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, >>> 10); if (end == probe || errno) { return JNI_ERR; } >>> >>> >>> /Staffan >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-25 11:31, Staffan Larsen wrote: >>>>> attachListener_solaris.cpp calls atoi() and then checks errno to >>>>> see if any errors occurred. The problem is that atoi() does not >>>>> set errno, so some old value of errno is checked which sometimes >>>>> causes the function to fail. >>>>> >>>>> The fix is to replace atoi() with strtol() which does set errno. >>>>> But errno is only set if an error occurred and not set to 0 in >>>>> case of success. Thus, I set errno to 0 before calling strtol() >>>>> and check the value afterwards. >>>>> >>>>> Verified with a JPRT run. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8038296 >>>>> >>>>> Thanks, /Staffan >>>>> >>>> >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>> Russia * I would love to change the world, but they won't give me >>>> the sources. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mikhailo.seledtsov at oracle.com Thu Mar 27 19:34:36 2014 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 27 Mar 2014 15:34:36 -0400 Subject: RFR (M): JDK-8038587: [TESTBUG] Create CDS tests to exercise region sizes and classlist Message-ID: <53347D4C.4070406@oracle.com> Please review these 3 new CDS tests, an ongoing effort in implementation of the CDS test specification. JBS: https://bugs.openjdk.java.net/browse/JDK-8038587 Webrev: http://cr.openjdk.java.net/~mseledtsov/8038587/webrev.00/ Testing: Local testing on multiple platforms JPRT to exercise the added tests: 2014-03-27-184953.mseledtsov.cds (PASS) These tests found 2 bugs, and one potential issue Thank you, Misha From christian.tornqvist at oracle.com Thu Mar 27 20:33:05 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 27 Mar 2014 16:33:05 -0400 Subject: RFR(S): 8007890 - [TESTBUG] JcmdWithNMTDisabled.java fails when invoked with NMT explicitly turned on Message-ID: <06af01cf49fb$c28886e0$479994a0$@oracle.com> Small workaround since our test systems explicitly turns on NMT for a test that doesn't expect NMT to be on, simply wrapped the test in another layer of process creation. Bug is unfortunately not publicly visible: https://bugs.openjdk.java.net/browse/JDK-8007890 Webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Mar 27 20:44:37 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 27 Mar 2014 16:44:37 -0400 Subject: RFR(S): 8007890 - [TESTBUG] JcmdWithNMTDisabled.java fails when invoked with NMT explicitly turned on In-Reply-To: <06af01cf49fb$c28886e0$479994a0$@oracle.com> References: <06af01cf49fb$c28886e0$479994a0$@oracle.com> Message-ID: <53348DB5.8000708@oracle.com> Looks good. Coleen On 3/27/14 4:33 PM, Christian Tornqvist wrote: > > Small workaround since our test systems explicitly turns on NMT for a > test that doesn't expect NMT to be on, simply wrapped the test in > another layer of process creation. > > Bug is unfortunately not publicly visible: > > https://bugs.openjdk.java.net/browse/JDK-8007890 > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ > > > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Mar 27 21:07:48 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 27 Mar 2014 15:07:48 -0600 Subject: RFR(S): 8007890 - [TESTBUG] JcmdWithNMTDisabled.java fails when invoked with NMT explicitly turned on In-Reply-To: <06af01cf49fb$c28886e0$479994a0$@oracle.com> References: <06af01cf49fb$c28886e0$479994a0$@oracle.com> Message-ID: <53349324.2010401@oracle.com> On 3/27/14 2:33 PM, Christian Tornqvist wrote: > > Small workaround since our test systems explicitly turns on NMT for a > test that doesn't expect NMT to be on, simply wrapped the test in > another layer of process creation. > > Bug is unfortunately not publicly visible: > > https://bugs.openjdk.java.net/browse/JDK-8007890 > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ > > test/runtime/NMT/JcmdWithNMTDisabled.java Do you want a comment in there stating that you are intentionally isolating this test from options passed in by the test harness. Otherwise, someone else might come along after grep'ing for TESTVMOPTS or one of the other "magic" options and "fix" it. Thumbs up! Dan > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.tornqvist at oracle.com Thu Mar 27 21:31:57 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 27 Mar 2014 17:31:57 -0400 Subject: RFR(S): 8007890 - [TESTBUG] JcmdWithNMTDisabled.java fails when invoked with NMT explicitly turned on In-Reply-To: <53349324.2010401@oracle.com> References: <06af01cf49fb$c28886e0$479994a0$@oracle.com> <53349324.2010401@oracle.com> Message-ID: <06d301cf4a03$fbcb3670$f361a350$@oracle.com> Thanks for the reviews! I've added a comment to the test explaining why not passing on arguments from the parent VM is a deliberate choice. Thanks, Christian From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Thursday, March 27, 2014 5:08 PM To: Christian Tornqvist Cc: 'hotspot-runtime-dev' Subject: Re: RFR(S): 8007890 - [TESTBUG] JcmdWithNMTDisabled.java fails when invoked with NMT explicitly turned on On 3/27/14 2:33 PM, Christian Tornqvist wrote: Small workaround since our test systems explicitly turns on NMT for a test that doesn't expect NMT to be on, simply wrapped the test in another layer of process creation. Bug is unfortunately not publicly visible: https://bugs.openjdk.java.net/browse/JDK-8007890 Webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ test/runtime/NMT/JcmdWithNMTDisabled.java Do you want a comment in there stating that you are intentionally isolating this test from options passed in by the test harness. Otherwise, someone else might come along after grep'ing for TESTVMOPTS or one of the other "magic" options and "fix" it. Thumbs up! Dan Thanks, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhengyu.gu at oracle.com Thu Mar 27 23:05:23 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 27 Mar 2014 19:05:23 -0400 Subject: RFR(S): 8007890 - [TESTBUG] JcmdWithNMTDisabled.java fails when invoked with NMT explicitly turned on In-Reply-To: <06af01cf49fb$c28886e0$479994a0$@oracle.com> References: <06af01cf49fb$c28886e0$479994a0$@oracle.com> Message-ID: <5334AEB3.7040105@oracle.com> Good to me. -Zhengyu On 3/27/2014 4:33 PM, Christian Tornqvist wrote: > > Small workaround since our test systems explicitly turns on NMT for a > test that doesn't expect NMT to be on, simply wrapped the test in > another layer of process creation. > > Bug is unfortunately not publicly visible: > > https://bugs.openjdk.java.net/browse/JDK-8007890 > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/ > > > Thanks, > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Mar 28 06:21:40 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Mar 2014 23:21:40 -0700 Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException: Command failed in target VM In-Reply-To: <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com> <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> Message-ID: <533514F4.8050906@oracle.com> On 3/27/14 12:55 AM, Staffan Larsen wrote: > Here is an updated webrev which incorporates Dmitry?s feedback: > > http://cr.openjdk.java.net/~sla/8038296/webrev.01/ It looks good. The only suggestion is to initialize the 'end': char* end; Not sure what value is better to use for initialization. Probably, end = probe would work Ok. Thanks, Serguei > > Thanks, > /Staffan > > On 25 mar 2014, at 19:36, Dmitry Samersoff wrote: > >> Staffan, >> >>> Yes, that will find problems when trying to convert something like >>> ?bla?. It will not capture the case where the input string is a too >>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>> both cases it looks like we need something like: >>> errno = 0; >>> char* end; >>> int probe_typess = (int) strtol(probe, &end, 10); >>> if (end == probe || errno) { >>> return JNI_ERR; >>> } >> As probe_typess is positive and you are converting long to int >> It's be better to check value boundaries explicitly: >> >> char* end; >> long ptl = strtol(probe, &end, 10); >> if (end == probe || ptl < 0 || ptl > MAX_INT) { >> return JNI_ERR; >> } >> >> int probe_typess = (int) ptl; >> >> >> -Dmitry >> >> >> On 2014-03-25 17:35, Staffan Larsen wrote: >>> On 25 mar 2014, at 13:46, Dmitry Samersoff >>> wrote: >>> >>>> Staffan, >>>> >>>> strtol() sets errno in two cases - >>>> >>>> ERANGE if supplied value is less then LONG_MIN or greater than >>>> LONG_MAX EINVAL if supplied base is not supported. >>>> >>>> if you pass probe == 'bla', strtol just return 0 and errno will not >>>> be set. So I'm not sure that check for errno has any value here. >>>> >>>> One of possible way to check that supplied value is convertible to >>>> long is >>>> >>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr == >>>> probe) { // we can't convert supplied value return JNI_ERR; } >>> Yes, that will find problems when trying to convert something like >>> ?bla?. It will not capture the case where the input string is a too >>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture >>> both cases it looks like we need something like: >>> >>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end, >>> 10); if (end == probe || errno) { return JNI_ERR; } >>> >>> >>> /Staffan >>> >>>> -Dmitry >>>> >>>> >>>> On 2014-03-25 11:31, Staffan Larsen wrote: >>>>> attachListener_solaris.cpp calls atoi() and then checks errno to >>>>> see if any errors occurred. The problem is that atoi() does not >>>>> set errno, so some old value of errno is checked which sometimes >>>>> causes the function to fail. >>>>> >>>>> The fix is to replace atoi() with strtol() which does set errno. >>>>> But errno is only set if an error occurred and not set to 0 in >>>>> case of success. Thus, I set errno to 0 before calling strtol() >>>>> and check the value afterwards. >>>>> >>>>> Verified with a JPRT run. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8038296 >>>>> >>>>> Thanks, /Staffan >>>>> >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>>> Russia * I would love to change the world, but they won't give me >>>> the sources. >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Mon Mar 31 03:27:25 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Mar 2014 13:27:25 +1000 Subject: XS RFR: 8016039: jvm.lib is missing from export list unless building server Message-ID: <5338E09D.5000509@oracle.com> http://cr.openjdk.java.net/~dholmes/8016039/webrev/ Trivial fix just moves the export declaration out of the "server" block so that it is always exported. Pushing to jdk9/hs-rt with a planned backport to 8u Thanks, David From staffan.larsen at oracle.com Mon Mar 31 09:35:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 31 Mar 2014 11:35:32 +0200 Subject: XS RFR: 8016039: jvm.lib is missing from export list unless building server In-Reply-To: <5338E09D.5000509@oracle.com> References: <5338E09D.5000509@oracle.com> Message-ID: <45D14726-6832-440E-84E6-F79B58883752@oracle.com> Looks good! Thanks, /Staffan On 31 mar 2014, at 05:27, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8016039/webrev/ > > Trivial fix just moves the export declaration out of the "server" block so that it is always exported. > > Pushing to jdk9/hs-rt with a planned backport to 8u > > Thanks, > David From frederic.parain at oracle.com Mon Mar 31 12:25:27 2014 From: frederic.parain at oracle.com (frederic parain) Date: Mon, 31 Mar 2014 14:25:27 +0200 Subject: RFR: 8038473 Remove support for old T1 libthread Message-ID: <53395EB7.1000108@oracle.com> Greetings, Back in Solaris 8 days, the JVM used a thread library called T1. In Solaris 9, a new thread library, called T2, was added to Solaris. The JVM code was extended to be able to use either the T1 libthread or the T2 libthread. Since Solaris 10, T2 is the default thread library and the T1 libthread is not part of Solaris anymore, all its APIs are wrappers around T2 APIs. This changeset removes the support for the T1 libthread and the workarounds put in VM code to deal with some T1 issues. Note: the minimal requirement for JDK9 is Solaris 10u9. CR: https://bugs.openjdk.java.net/browse/JDK-8038473 Webrev: http://cr.openjdk.java.net/~fparain/8038473/webrev.00/ Thank you, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From serguei.spitsyn at oracle.com Mon Mar 31 17:23:36 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 31 Mar 2014 10:23:36 -0700 Subject: XS RFR: 8016039: jvm.lib is missing from export list unless building server In-Reply-To: <5338E09D.5000509@oracle.com> References: <5338E09D.5000509@oracle.com> Message-ID: <5339A498.5030709@oracle.com> It looks good. Thanks, Serguei On 3/30/14 8:27 PM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8016039/webrev/ > > Trivial fix just moves the export declaration out of the "server" > block so that it is always exported. > > Pushing to jdk9/hs-rt with a planned backport to 8u > > Thanks, > David From lois.foltan at oracle.com Mon Mar 31 17:25:37 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 31 Mar 2014 13:25:37 -0400 Subject: RFR (M) JDK-8033150: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults Message-ID: <5339A511.7000202@oracle.com> Hi, Please review the following fix: Webrev: http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/ Bug: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults https://bugs.openjdk.java.net/browse/JDK-8033150 Summary of fix: During default method processing, determine_target(), is responsible for making decisions on whether to create and add an overpass method to the current class for issues that have been encountered during the walk of the default methods. The routine defaultMethods.cpp/has_matching_static() helped determine this decision by looking within the current class for a static method that should be preferred during method resolution over an overpass method being created. However, has_matching_static() did not continue to look for a static method in current class' superclasses which JDK-8033150 exposed. After looking at the code more closely, the has _matching_static() concept is being moved out out of default method processing and into method resolution processing. The primary reason for this is to allow default method processing to match method selection where statics are and should be ignored. According to JVMS, static methods should only be preferred over an overpass method at method and interface method resolution time. To enable method resolution to potentially find a static method over an overpass method, a new parameter "ignore_overpass" was added to InstanceKlass::uncached_lookup_method(). It has the affect of indicating to find_method_index() to ignore overpass methods and continue the search in case a static method of the same name and signature is present in the current class or its superclasses. Tests: - jtreg hotspot/test/*, JDK java.lang & java.util, vm.quick.testlist, JCK lang & vm, defmeth tests - Test will be added to the defmeth test system Thank you, Lois From kmcguigan at twitter.com Mon Mar 31 18:08:24 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Mon, 31 Mar 2014 14:08:24 -0400 Subject: RFR (M) JDK-8033150: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults In-Reply-To: <5339A511.7000202@oracle.com> References: <5339A511.7000202@oracle.com> Message-ID: Hi Lois, I think that looks good. I like it much better than doing the static method check in the default method processing. My only suggestion is that it would be nice to encode new parameter to uncached_lookup_method to be some sort of enum instead of a boolean, so that it is obvious from the call-site what the behavior should be (having just "false" in the parameter list requires you to reference back to the declaration to figure out what that "false" means). So instead of: uncached_lookup_method(field_name, field_sig, false); It'd be: uncached_lookup_method(field_name, field_sig, NORMAL); or uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS); (or something like that -- I'm no good at names). -- - Keith On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan wrote: > Hi, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/ > > Bug: invokestatic: IncompatibleClassChangeError trying to invoke static > method from a parent in presence of conflicting defaults > https://bugs.openjdk.java.net/browse/JDK-8033150 > > Summary of fix: > During default method processing, determine_target(), is responsible for > making decisions on whether > to create and add an overpass method to the current class for issues that > have been encountered during the walk > of the default methods. The routine defaultMethods.cpp/has_matching_static() > helped determine this > decision by looking within the current class for a static method that > should be preferred during method > resolution over an overpass method being created. However, > has_matching_static() did not continue to > look for a static method in current class' superclasses which JDK-8033150 > exposed. > > After looking at the code more closely, the has _matching_static() concept > is being moved out out of default > method processing and into method resolution processing. The primary > reason for this is to allow > default method processing to match method selection where statics are and > should be ignored. According > to JVMS, static methods should only be preferred over an overpass method > at method and interface > method resolution time. To enable method resolution to potentially find a > static method over an overpass > method, a new parameter "ignore_overpass" was added to > InstanceKlass::uncached_lookup_method(). > It has the affect of indicating to find_method_index() to ignore overpass > methods and continue the search > in case a static method of the same name and signature is present in the > current class or its superclasses. > > Tests: > - jtreg hotspot/test/*, JDK java.lang & java.util, vm.quick.testlist, > JCK lang & vm, defmeth tests > - Test will be added to the defmeth test system > > Thank you, > Lois > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lois.foltan at oracle.com Mon Mar 31 19:51:06 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 31 Mar 2014 15:51:06 -0400 Subject: RFR (M) JDK-8033150: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults In-Reply-To: References: <5339A511.7000202@oracle.com> Message-ID: <5339C72A.8040405@oracle.com> On 3/31/2014 2:08 PM, Keith McGuigan wrote: > Hi Lois, > > I think that looks good. I like it much better than doing the static > method check in the default method processing. > My only suggestion is that it would be nice to encode new parameter to > uncached_lookup_method to be some sort of enum instead of a boolean, > so that it is obvious from the call-site what the behavior should be > (having just "false" in the parameter list requires you to reference > back to the declaration to figure out what that "false" means). > > So instead of: > uncached_lookup_method(field_name, field_sig, false); > It'd be: > uncached_lookup_method(field_name, field_sig, NORMAL); or > uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS); > > (or something like that -- I'm no good at names). Thank you Keith. Good suggestion. I will implement and repost an updated webrev for review. Lois > > -- > - Keith > > > On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan > wrote: > > Hi, > > Please review the following fix: > > Webrev: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/ > > > Bug: invokestatic: IncompatibleClassChangeError trying to invoke > static method from a parent in presence of conflicting defaults > https://bugs.openjdk.java.net/browse/JDK-8033150 > > Summary of fix: > During default method processing, determine_target(), is > responsible for making decisions on whether > to create and add an overpass method to the current class for > issues that have been encountered during the walk > of the default methods. The routine > defaultMethods.cpp/has_matching_static() helped determine this > decision by looking within the current class for a static method > that should be preferred during method > resolution over an overpass method being created. However, > has_matching_static() did not continue to > look for a static method in current class' superclasses which > JDK-8033150 exposed. > > After looking at the code more closely, the has _matching_static() > concept is being moved out out of default > method processing and into method resolution processing. The > primary reason for this is to allow > default method processing to match method selection where statics > are and should be ignored. According > to JVMS, static methods should only be preferred over an overpass > method at method and interface > method resolution time. To enable method resolution to > potentially find a static method over an overpass > method, a new parameter "ignore_overpass" was added to > InstanceKlass::uncached_lookup_method(). > It has the affect of indicating to find_method_index() to ignore > overpass methods and continue the search > in case a static method of the same name and signature is present > in the current class or its superclasses. > > Tests: > - jtreg hotspot/test/*, JDK java.lang & java.util, > vm.quick.testlist, JCK lang & vm, defmeth tests > - Test will be added to the defmeth test system > > Thank you, > Lois > > -------------- next part -------------- An HTML attachment was scrubbed... URL: