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: