From dmitry.dmitriev at oracle.com Wed Jul 1 12:49:08 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 1 Jul 2015 15:49:08 +0300
Subject: RFR (S): 8129786: Buffer overrun when passing long not existing
option in JDK 9
Message-ID: <5593E1C4.8020702@oracle.com>
Hello,
Please review this small fix and new test. Also, I need a sponsor for
this fix, who can push it.
In this fix logic for stripped_argname was put into "if (arg_len <=
BUFLEN)" statement. stripped_argname is used only to check is option is
newly obsolete. Since valid VM option should be not bigger than 255
characters(BUFLEN value), then obsolete_jvm_flags contains only options
with strlen <= BUFLEN.
Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
Tested: JPRT(with new test), hotspot all & vm.quick
Thanks,
Dmitry
From daniel.daugherty at oracle.com Wed Jul 1 13:49:50 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 01 Jul 2015 07:49:50 -0600
Subject: RFR (S): 8129786: Buffer overrun when passing long not existing
option in JDK 9
In-Reply-To: <5593E1C4.8020702@oracle.com>
References: <5593E1C4.8020702@oracle.com>
Message-ID: <5593EFFE.10302@oracle.com>
> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
src/share/vm/runtime/arguments.cpp
L840: if (arg_len <= BUFLEN) {
Please add a comment. Perhaps:
// Only make the obsolete check for valid arguments.
L843: strncpy(stripped_argname, argname, arg_len);
L844: stripped_argname[arg_len] = '\0'; //strncpy doesn't null
terminate.
This is not due to your change but this comment isn't quite right.
Perhaps:
stripped_argname[arg_len] = '\0'; // strncpy may not null
terminate.
strncpy() null terminates if the length of 'argname' is
less than arg_len. Also added one more space after ';'
and added a space after '//'.
L847: char version[256];
Can you change this '256' to BUFLEN+1 also?
test/runtime/CommandLine/TestLongUnrecognizedVMOption.java
L27: * @summary Verify that JVM correctly process very long
unregnized VM option
Typo: 'process' -> 'processes'
Typo: 'unregnized' -> 'unrecognized'
L29: * @modules java.management
Why this module?
L49: extra blank line at the end; jcheck may not like this
Thumbs up. I don't need to see another webrev if you
decide to fix these minor nits.
Dan
On 7/1/15 6:49 AM, Dmitry Dmitriev wrote:
> Hello,
>
> Please review this small fix and new test. Also, I need a sponsor for
> this fix, who can push it.
>
> In this fix logic for stripped_argname was put into "if (arg_len <=
> BUFLEN)" statement. stripped_argname is used only to check is option
> is newly obsolete. Since valid VM option should be not bigger than 255
> characters(BUFLEN value), then obsolete_jvm_flags contains only
> options with strlen <= BUFLEN.
>
> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
> Tested: JPRT(with new test), hotspot all & vm.quick
>
> Thanks,
> Dmitry
From claes.redestad at oracle.com Wed Jul 1 14:54:55 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 01 Jul 2015 16:54:55 +0200
Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9
incompatible with MakeClasslist tool
Message-ID: <5593FF3F.2040501@oracle.com>
Hi,
please review this rewrite/cleanup of the MakeClasslist tool to operate
on the output of
-XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder.
Since the tool
became rather trivial I opted to write it in nashorn-compliant
javascript to streamline
the usage.
Bug: https://bugs.openjdk.java.net/browse/JDK-8081589
Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02
A number of undocumented/unused tests were removed and an outdated
README was
incorporated into the tool source itself, among other things clarifying
that the checksum
needs to be calculated and added to the classlist before checking it
into the workspace.
I've asked around about how to go about adding tests for standalone
tools like these, but
didn't come up with a good answer. If someone insists I add a small test
to this I'd hope
there's some insight into how best to do that (shell-based jtreg test?)
Thanks!
/Claes
From dmitry.dmitriev at oracle.com Wed Jul 1 16:38:53 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 1 Jul 2015 19:38:53 +0300
Subject: RFR (S): 8129786: Buffer overrun when passing long not existing
option in JDK 9
In-Reply-To: <5593EFFE.10302@oracle.com>
References: <5593E1C4.8020702@oracle.com> <5593EFFE.10302@oracle.com>
Message-ID: <5594179D.7030607@oracle.com>
Hello Dan,
Thank you for review! Updated webrev:
http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.01/
Please see my comments inline.
Regards,
Dmitry
On 01.07.2015 16:49, Daniel D. Daugherty wrote:
> > Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>
> src/share/vm/runtime/arguments.cpp
> L840: if (arg_len <= BUFLEN) {
> Please add a comment. Perhaps:
>
> // Only make the obsolete check for valid arguments.
Done!
>
> L843: strncpy(stripped_argname, argname, arg_len);
> L844: stripped_argname[arg_len] = '\0'; //strncpy doesn't null
> terminate.
> This is not due to your change but this comment isn't quite
> right.
> Perhaps:
>
> stripped_argname[arg_len] = '\0'; // strncpy may not null
> terminate.
>
> strncpy() null terminates if the length of 'argname' is
> less than arg_len. Also added one more space after ';'
> and added a space after '//'.
Done!
>
> L847: char version[256];
> Can you change this '256' to BUFLEN+1 also?
I prefer to leave it as is, because there are no relationship between
'version' and BUFLEN. BUFLEN is used for parsing options, thus I use it
for stripped_argname. But I think it will be better not to use it for
'version'.
>
> test/runtime/CommandLine/TestLongUnrecognizedVMOption.java
> L27: * @summary Verify that JVM correctly process very long
> unregnized VM option
> Typo: 'process' -> 'processes'
> Typo: 'unregnized' -> 'unrecognized'
>
Done!
> L29: * @modules java.management
> Why this module?
I got this dependency from script which used to find dependencies of
test code.
>
> L49: extra blank line at the end; jcheck may not like this
>
Done!
> Thumbs up. I don't need to see another webrev if you
> decide to fix these minor nits.
>
> Dan
>
>
> On 7/1/15 6:49 AM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review this small fix and new test. Also, I need a sponsor for
>> this fix, who can push it.
>>
>> In this fix logic for stripped_argname was put into "if (arg_len <=
>> BUFLEN)" statement. stripped_argname is used only to check is option
>> is newly obsolete. Since valid VM option should be not bigger than
>> 255 characters(BUFLEN value), then obsolete_jvm_flags contains only
>> options with strlen <= BUFLEN.
>>
>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
>> Tested: JPRT(with new test), hotspot all & vm.quick
>>
>> Thanks,
>> Dmitry
From daniel.daugherty at oracle.com Wed Jul 1 16:42:51 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 01 Jul 2015 10:42:51 -0600
Subject: RFR (S): 8129786: Buffer overrun when passing long not existing
option in JDK 9
In-Reply-To: <5594179D.7030607@oracle.com>
References: <5593E1C4.8020702@oracle.com> <5593EFFE.10302@oracle.com>
<5594179D.7030607@oracle.com>
Message-ID: <5594188B.1060107@oracle.com>
On 7/1/15 10:38 AM, Dmitry Dmitriev wrote:
> Hello Dan,
>
> Thank you for review! Updated webrev:
> http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.01/
>
> Please see my comments inline.
>
> Regards,
> Dmitry
>
> On 01.07.2015 16:49, Daniel D. Daugherty wrote:
>> > Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>
>> src/share/vm/runtime/arguments.cpp
>> L840: if (arg_len <= BUFLEN) {
>> Please add a comment. Perhaps:
>>
>> // Only make the obsolete check for valid arguments.
> Done!
>>
>> L843: strncpy(stripped_argname, argname, arg_len);
>> L844: stripped_argname[arg_len] = '\0'; //strncpy doesn't
>> null terminate.
>> This is not due to your change but this comment isn't quite
>> right.
>> Perhaps:
>>
>> stripped_argname[arg_len] = '\0'; // strncpy may not
>> null terminate.
>>
>> strncpy() null terminates if the length of 'argname' is
>> less than arg_len. Also added one more space after ';'
>> and added a space after '//'.
> Done!
>>
>> L847: char version[256];
>> Can you change this '256' to BUFLEN+1 also?
> I prefer to leave it as is, because there are no relationship between
> 'version' and BUFLEN. BUFLEN is used for parsing options, thus I use
> it for stripped_argname. But I think it will be better not to use it
> for 'version'.
Is there some constant hanging around that is appropriate?
A literal '256' is just bugging me... :-)
>
>>
>> test/runtime/CommandLine/TestLongUnrecognizedVMOption.java
>> L27: * @summary Verify that JVM correctly process very long
>> unregnized VM option
>> Typo: 'process' -> 'processes'
>> Typo: 'unregnized' -> 'unrecognized'
>>
> Done!
>> L29: * @modules java.management
>> Why this module?
> I got this dependency from script which used to find dependencies of
> test code.
OK, but why? I see nothing in this test that requires the
java.management module...
Dan
>>
>> L49: extra blank line at the end; jcheck may not like this
>>
> Done!
>> Thumbs up. I don't need to see another webrev if you
>> decide to fix these minor nits.
>>
>> Dan
>>
>>
>> On 7/1/15 6:49 AM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review this small fix and new test. Also, I need a sponsor
>>> for this fix, who can push it.
>>>
>>> In this fix logic for stripped_argname was put into "if (arg_len <=
>>> BUFLEN)" statement. stripped_argname is used only to check is option
>>> is newly obsolete. Since valid VM option should be not bigger than
>>> 255 characters(BUFLEN value), then obsolete_jvm_flags contains only
>>> options with strlen <= BUFLEN.
>>>
>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
>>> Tested: JPRT(with new test), hotspot all & vm.quick
>>>
>>> Thanks,
>>> Dmitry
>
From dmitry.dmitriev at oracle.com Wed Jul 1 16:49:50 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 1 Jul 2015 19:49:50 +0300
Subject: RFR (S): 8129786: Buffer overrun when passing long not existing
option in JDK 9
In-Reply-To: <5594188B.1060107@oracle.com>
References: <5593E1C4.8020702@oracle.com> <5593EFFE.10302@oracle.com>
<5594179D.7030607@oracle.com> <5594188B.1060107@oracle.com>
Message-ID: <55941A2E.4000408@oracle.com>
On 01.07.2015 19:42, Daniel D. Daugherty wrote:
>
> On 7/1/15 10:38 AM, Dmitry Dmitriev wrote:
>> Hello Dan,
>>
>> Thank you for review! Updated webrev:
>> http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.01/
>>
>> Please see my comments inline.
>>
>> Regards,
>> Dmitry
>>
>> On 01.07.2015 16:49, Daniel D. Daugherty wrote:
>>> > Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>
>>> src/share/vm/runtime/arguments.cpp
>>> L840: if (arg_len <= BUFLEN) {
>>> Please add a comment. Perhaps:
>>>
>>> // Only make the obsolete check for valid arguments.
>> Done!
>>>
>>> L843: strncpy(stripped_argname, argname, arg_len);
>>> L844: stripped_argname[arg_len] = '\0'; //strncpy doesn't
>>> null terminate.
>>> This is not due to your change but this comment isn't quite
>>> right.
>>> Perhaps:
>>>
>>> stripped_argname[arg_len] = '\0'; // strncpy may not
>>> null terminate.
>>>
>>> strncpy() null terminates if the length of 'argname' is
>>> less than arg_len. Also added one more space after ';'
>>> and added a space after '//'.
>> Done!
>>>
>>> L847: char version[256];
>>> Can you change this '256' to BUFLEN+1 also?
>> I prefer to leave it as is, because there are no relationship between
>> 'version' and BUFLEN. BUFLEN is used for parsing options, thus I use
>> it for stripped_argname. But I think it will be better not to use it
>> for 'version'.
>
> Is there some constant hanging around that is appropriate?
> A literal '256' is just bugging me... :-)
Yes, I agree with you :) But I don't see any of them around.
>
>
>>
>>>
>>> test/runtime/CommandLine/TestLongUnrecognizedVMOption.java
>>> L27: * @summary Verify that JVM correctly process very long
>>> unregnized VM option
>>> Typo: 'process' -> 'processes'
>>> Typo: 'unregnized' -> 'unrecognized'
>>>
>> Done!
>>> L29: * @modules java.management
>>> Why this module?
>> I got this dependency from script which used to find dependencies of
>> test code.
>
> OK, but why? I see nothing in this test that requires the
> java.management module...
I think that because jdk.test.lib.ProcessTools is depends on
java.management and this leads to the test dependency.
Thank you,
Dmitry
>
> Dan
>
>
>>>
>>> L49: extra blank line at the end; jcheck may not like this
>>>
>> Done!
>>> Thumbs up. I don't need to see another webrev if you
>>> decide to fix these minor nits.
>>>
>>> Dan
>>>
>>>
>>> On 7/1/15 6:49 AM, Dmitry Dmitriev wrote:
>>>> Hello,
>>>>
>>>> Please review this small fix and new test. Also, I need a sponsor
>>>> for this fix, who can push it.
>>>>
>>>> In this fix logic for stripped_argname was put into "if (arg_len <=
>>>> BUFLEN)" statement. stripped_argname is used only to check is
>>>> option is newly obsolete. Since valid VM option should be not
>>>> bigger than 255 characters(BUFLEN value), then obsolete_jvm_flags
>>>> contains only options with strlen <= BUFLEN.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
>>>> Tested: JPRT(with new test), hotspot all & vm.quick
>>>>
>>>> Thanks,
>>>> Dmitry
>>
>
From daniel.daugherty at oracle.com Wed Jul 1 16:51:17 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 01 Jul 2015 10:51:17 -0600
Subject: RFR (S): 8129786: Buffer overrun when passing long not existing
option in JDK 9
In-Reply-To: <55941A2E.4000408@oracle.com>
References: <5593E1C4.8020702@oracle.com> <5593EFFE.10302@oracle.com>
<5594179D.7030607@oracle.com> <5594188B.1060107@oracle.com>
<55941A2E.4000408@oracle.com>
Message-ID: <55941A85.5030009@oracle.com>
On 7/1/15 10:49 AM, Dmitry Dmitriev wrote:
> On 01.07.2015 19:42, Daniel D. Daugherty wrote:
>>
>> On 7/1/15 10:38 AM, Dmitry Dmitriev wrote:
>>> Hello Dan,
>>>
>>> Thank you for review! Updated webrev:
>>> http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.01/
>>>
>>> Please see my comments inline.
>>>
>>> Regards,
>>> Dmitry
>>>
>>> On 01.07.2015 16:49, Daniel D. Daugherty wrote:
>>>> > Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>>
>>>> src/share/vm/runtime/arguments.cpp
>>>> L840: if (arg_len <= BUFLEN) {
>>>> Please add a comment. Perhaps:
>>>>
>>>> // Only make the obsolete check for valid arguments.
>>> Done!
>>>>
>>>> L843: strncpy(stripped_argname, argname, arg_len);
>>>> L844: stripped_argname[arg_len] = '\0'; //strncpy doesn't
>>>> null terminate.
>>>> This is not due to your change but this comment isn't quite
>>>> right.
>>>> Perhaps:
>>>>
>>>> stripped_argname[arg_len] = '\0'; // strncpy may not
>>>> null terminate.
>>>>
>>>> strncpy() null terminates if the length of 'argname' is
>>>> less than arg_len. Also added one more space after ';'
>>>> and added a space after '//'.
>>> Done!
>>>>
>>>> L847: char version[256];
>>>> Can you change this '256' to BUFLEN+1 also?
>>> I prefer to leave it as is, because there are no relationship
>>> between 'version' and BUFLEN. BUFLEN is used for parsing options,
>>> thus I use it for stripped_argname. But I think it will be better
>>> not to use it for 'version'.
>>
>> Is there some constant hanging around that is appropriate?
>> A literal '256' is just bugging me... :-)
> Yes, I agree with you :) But I don't see any of them around.
OK...
>>
>>
>>>
>>>>
>>>> test/runtime/CommandLine/TestLongUnrecognizedVMOption.java
>>>> L27: * @summary Verify that JVM correctly process very long
>>>> unregnized VM option
>>>> Typo: 'process' -> 'processes'
>>>> Typo: 'unregnized' -> 'unrecognized'
>>>>
>>> Done!
>>>> L29: * @modules java.management
>>>> Why this module?
>>> I got this dependency from script which used to find dependencies of
>>> test code.
>>
>> OK, but why? I see nothing in this test that requires the
>> java.management module...
> I think that because jdk.test.lib.ProcessTools is depends on
> java.management and this leads to the test dependency.
OK... that makes sense.
Dan
>
> Thank you,
> Dmitry
>>
>> Dan
>>
>>
>>>>
>>>> L49: extra blank line at the end; jcheck may not like this
>>>>
>>> Done!
>>>> Thumbs up. I don't need to see another webrev if you
>>>> decide to fix these minor nits.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 7/1/15 6:49 AM, Dmitry Dmitriev wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this small fix and new test. Also, I need a sponsor
>>>>> for this fix, who can push it.
>>>>>
>>>>> In this fix logic for stripped_argname was put into "if (arg_len
>>>>> <= BUFLEN)" statement. stripped_argname is used only to check is
>>>>> option is newly obsolete. Since valid VM option should be not
>>>>> bigger than 255 characters(BUFLEN value), then obsolete_jvm_flags
>>>>> contains only options with strlen <= BUFLEN.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
>>>>> Tested: JPRT(with new test), hotspot all & vm.quick
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>
>>
>
From ioi.lam at oracle.com Wed Jul 1 20:44:06 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 01 Jul 2015 13:44:06 -0700
Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9
incompatible with MakeClasslist tool
In-Reply-To: <5593FF3F.2040501@oracle.com>
References: <5593FF3F.2040501@oracle.com>
Message-ID: <55945116.20102@oracle.com>
Claes,
The changes look good to me. It's nice to replace a large amount of Java
code with a simple script.
How about doing the line splitting like this:
var classes = readFully(arg).replace(/[\r\n]+/g, "\n").split("\n")
That way it will be able to handle an input file that have a mixture of
newline characters (e.g., if someone has edited a Unix text file on a
Windows editor).
Thanks
- Ioi
On 7/1/15 7:54 AM, Claes Redestad wrote:
> Hi,
>
> please review this rewrite/cleanup of the MakeClasslist tool to
> operate on the output of
> -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder.
> Since the tool
> became rather trivial I opted to write it in nashorn-compliant
> javascript to streamline
> the usage.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8081589
> Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02
>
> A number of undocumented/unused tests were removed and an outdated
> README was
> incorporated into the tool source itself, among other things
> clarifying that the checksum
> needs to be calculated and added to the classlist before checking it
> into the workspace.
>
> I've asked around about how to go about adding tests for standalone
> tools like these, but
> didn't come up with a good answer. If someone insists I add a small
> test to this I'd hope
> there's some insight into how best to do that (shell-based jtreg test?)
>
> Thanks!
>
> /Claes
From coleen.phillimore at oracle.com Thu Jul 2 00:11:34 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 01 Jul 2015 20:11:34 -0400
Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9
incompatible with MakeClasslist tool
In-Reply-To: <5593FF3F.2040501@oracle.com>
References: <5593FF3F.2040501@oracle.com>
Message-ID: <559481B6.8060302@oracle.com>
Does this mean that -XX:+TraceClassLoadingPreorder is not needed anymore?
thanks,
Coleen
On 7/1/15 10:54 AM, Claes Redestad wrote:
> Hi,
>
> please review this rewrite/cleanup of the MakeClasslist tool to
> operate on the output of
> -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder.
> Since the tool
> became rather trivial I opted to write it in nashorn-compliant
> javascript to streamline
> the usage.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8081589
> Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02
>
> A number of undocumented/unused tests were removed and an outdated
> README was
> incorporated into the tool source itself, among other things
> clarifying that the checksum
> needs to be calculated and added to the classlist before checking it
> into the workspace.
>
> I've asked around about how to go about adding tests for standalone
> tools like these, but
> didn't come up with a good answer. If someone insists I add a small
> test to this I'd hope
> there's some insight into how best to do that (shell-based jtreg test?)
>
> Thanks!
>
> /Claes
From ioi.lam at oracle.com Thu Jul 2 00:15:03 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 01 Jul 2015 17:15:03 -0700
Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9
incompatible with MakeClasslist tool
In-Reply-To: <559481B6.8060302@oracle.com>
References: <5593FF3F.2040501@oracle.com> <559481B6.8060302@oracle.com>
Message-ID: <55948287.9090808@oracle.com>
I still use it for other class loading analysis.
-XX:+TraceClassLoading always prints the super class first, before
printing the sub class. -XX:+TraceClassLoadingPreorder is the only way
to see whether the super class or the sub class was requested first.
- Ioi
On 7/1/15 5:11 PM, Coleen Phillimore wrote:
>
> Does this mean that -XX:+TraceClassLoadingPreorder is not needed anymore?
> thanks,
> Coleen
>
> On 7/1/15 10:54 AM, Claes Redestad wrote:
>> Hi,
>>
>> please review this rewrite/cleanup of the MakeClasslist tool to
>> operate on the output of
>> -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder.
>> Since the tool
>> became rather trivial I opted to write it in nashorn-compliant
>> javascript to streamline
>> the usage.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081589
>> Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02
>>
>> A number of undocumented/unused tests were removed and an outdated
>> README was
>> incorporated into the tool source itself, among other things
>> clarifying that the checksum
>> needs to be calculated and added to the classlist before checking it
>> into the workspace.
>>
>> I've asked around about how to go about adding tests for standalone
>> tools like these, but
>> didn't come up with a good answer. If someone insists I add a small
>> test to this I'd hope
>> there's some insight into how best to do that (shell-based jtreg test?)
>>
>> Thanks!
>>
>> /Claes
>
From david.holmes at oracle.com Thu Jul 2 03:09:06 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Jul 2015 13:09:06 +1000
Subject: RFR (S): 8129786: Buffer overrun when passing long not existing
option in JDK 9
In-Reply-To: <5594179D.7030607@oracle.com>
References: <5593E1C4.8020702@oracle.com> <5593EFFE.10302@oracle.com>
<5594179D.7030607@oracle.com>
Message-ID: <5594AB52.1090109@oracle.com>
Hi Dmitry,
Looks good to me. If you prepare the changeset and send it to me I'll do
the JPRT submit for you.
Thanks,
David
On 2/07/2015 2:38 AM, Dmitry Dmitriev wrote:
> Hello Dan,
>
> Thank you for review! Updated webrev:
> http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.01/
>
> Please see my comments inline.
>
> Regards,
> Dmitry
>
> On 01.07.2015 16:49, Daniel D. Daugherty wrote:
>> > Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>
>> src/share/vm/runtime/arguments.cpp
>> L840: if (arg_len <= BUFLEN) {
>> Please add a comment. Perhaps:
>>
>> // Only make the obsolete check for valid arguments.
> Done!
>>
>> L843: strncpy(stripped_argname, argname, arg_len);
>> L844: stripped_argname[arg_len] = '\0'; //strncpy doesn't null
>> terminate.
>> This is not due to your change but this comment isn't quite
>> right.
>> Perhaps:
>>
>> stripped_argname[arg_len] = '\0'; // strncpy may not null
>> terminate.
>>
>> strncpy() null terminates if the length of 'argname' is
>> less than arg_len. Also added one more space after ';'
>> and added a space after '//'.
> Done!
>>
>> L847: char version[256];
>> Can you change this '256' to BUFLEN+1 also?
> I prefer to leave it as is, because there are no relationship between
> 'version' and BUFLEN. BUFLEN is used for parsing options, thus I use it
> for stripped_argname. But I think it will be better not to use it for
> 'version'.
>
>>
>> test/runtime/CommandLine/TestLongUnrecognizedVMOption.java
>> L27: * @summary Verify that JVM correctly process very long
>> unregnized VM option
>> Typo: 'process' -> 'processes'
>> Typo: 'unregnized' -> 'unrecognized'
>>
> Done!
>> L29: * @modules java.management
>> Why this module?
> I got this dependency from script which used to find dependencies of
> test code.
>>
>> L49: extra blank line at the end; jcheck may not like this
>>
> Done!
>> Thumbs up. I don't need to see another webrev if you
>> decide to fix these minor nits.
>>
>> Dan
>>
>>
>> On 7/1/15 6:49 AM, Dmitry Dmitriev wrote:
>>> Hello,
>>>
>>> Please review this small fix and new test. Also, I need a sponsor for
>>> this fix, who can push it.
>>>
>>> In this fix logic for stripped_argname was put into "if (arg_len <=
>>> BUFLEN)" statement. stripped_argname is used only to check is option
>>> is newly obsolete. Since valid VM option should be not bigger than
>>> 255 characters(BUFLEN value), then obsolete_jvm_flags contains only
>>> options with strlen <= BUFLEN.
>>>
>>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8129786/webrev.00/
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8129786
>>> Tested: JPRT(with new test), hotspot all & vm.quick
>>>
>>> Thanks,
>>> Dmitry
>
From david.buck at oracle.com Thu Jul 2 10:46:37 2015
From: david.buck at oracle.com (david buck)
Date: Thu, 02 Jul 2015 19:46:37 +0900
Subject: RFR [8u65]: 8072147: Preloading libjsig.dylib causes deadlock when
signal() is called
Message-ID: <5595168D.5050700@oracle.com>
Hi!
This is a request for review of the jdk8 backport of 8072147. As the gcc
version used to build jdk8 does not directly support thread-local
storage, I had to rewrite parts of the fix to use the pthreads
thread-specific data API (pthread_(get/set)specific and friends). Hence
the need for review, as opposed to simple approval.
Bug: https://bugs.openjdk.java.net/browse/jdk-8072147
Webrev: http://cr.openjdk.java.net/~dbuck/8072147/webrev.jdk8.02/
JDK9 Changeset:
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/660fa1b69f63
Review thread for JDK9 fix:
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-June/015282.html
I have tested the fix both manually and via JPRT.
Cheers,
-Buck
From daniel.daugherty at oracle.com Thu Jul 2 13:14:22 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 02 Jul 2015 07:14:22 -0600
Subject: RFR [8u65]: 8072147: Preloading libjsig.dylib causes deadlock
when signal() is called
In-Reply-To: <5595168D.5050700@oracle.com>
References: <5595168D.5050700@oracle.com>
Message-ID: <5595392E.6010306@oracle.com>
> Webrev: http://cr.openjdk.java.net/~dbuck/8072147/webrev.jdk8.02/
src/os/bsd/vm/jsig.c
No comments.
Thumbs up. Thanks for including all the links for the JDK9 version.
Made the review much easier.
Dan
On 7/2/15 4:46 AM, david buck wrote:
> Hi!
>
> This is a request for review of the jdk8 backport of 8072147. As the
> gcc version used to build jdk8 does not directly support thread-local
> storage, I had to rewrite parts of the fix to use the pthreads
> thread-specific data API (pthread_(get/set)specific and friends).
> Hence the need for review, as opposed to simple approval.
>
> Bug: https://bugs.openjdk.java.net/browse/jdk-8072147
> Webrev: http://cr.openjdk.java.net/~dbuck/8072147/webrev.jdk8.02/
> JDK9 Changeset:
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/660fa1b69f63
> Review thread for JDK9 fix:
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-June/015282.html
>
> I have tested the fix both manually and via JPRT.
>
> Cheers,
> -Buck
From david.holmes at oracle.com Thu Jul 2 13:22:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Jul 2015 23:22:25 +1000
Subject: RFR [8u65]: 8072147: Preloading libjsig.dylib causes deadlock
when signal() is called
In-Reply-To: <5595168D.5050700@oracle.com>
References: <5595168D.5050700@oracle.com>
Message-ID: <55953B11.8020903@oracle.com>
Hi David,
On 2/07/2015 8:46 PM, david buck wrote:
> Hi!
>
> This is a request for review of the jdk8 backport of 8072147. As the gcc
> version used to build jdk8 does not directly support thread-local
> storage, I had to rewrite parts of the fix to use the pthreads
> thread-specific data API (pthread_(get/set)specific and friends). Hence
> the need for review, as opposed to simple approval.
>
> Bug: https://bugs.openjdk.java.net/browse/jdk-8072147
> Webrev: http://cr.openjdk.java.net/~dbuck/8072147/webrev.jdk8.02/
> JDK9 Changeset:
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/660fa1b69f63
> Review thread for JDK9 fix:
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-June/015282.html
>
>
> I have tested the fix both manually and via JPRT.
This looks good to me.
Note current pushes to 8u-dev are being flagged for 8u66 not 8u65. :)
Thanks,
David
> Cheers,
> -Buck
From karen.kinnear at oracle.com Thu Jul 2 13:47:45 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 2 Jul 2015 09:47:45 -0400
Subject: RFR [8u65]: 8072147: Preloading libjsig.dylib causes deadlock
when signal() is called
In-Reply-To: <5595168D.5050700@oracle.com>
References: <5595168D.5050700@oracle.com>
Message-ID: <0F61DCD5-1CE3-4322-A6C0-2D137105FA07@oracle.com>
David,
Looks good.
Thank you for the check_status macro, that makes the code much easier to read. And I appreciate
you checking for system call errors.
Thank you for manually running the runtime signal tests before we have fixed the blocking bugs for them.
thanks,
Karen
On Jul 2, 2015, at 6:46 AM, david buck wrote:
> Hi!
>
> This is a request for review of the jdk8 backport of 8072147. As the gcc version used to build jdk8 does not directly support thread-local storage, I had to rewrite parts of the fix to use the pthreads thread-specific data API (pthread_(get/set)specific and friends). Hence the need for review, as opposed to simple approval.
>
> Bug: https://bugs.openjdk.java.net/browse/jdk-8072147
> Webrev: http://cr.openjdk.java.net/~dbuck/8072147/webrev.jdk8.02/
> JDK9 Changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/660fa1b69f63
> Review thread for JDK9 fix: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-June/015282.html
>
> I have tested the fix both manually and via JPRT.
>
> Cheers,
> -Buck
From claes.redestad at oracle.com Thu Jul 2 14:12:10 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 02 Jul 2015 16:12:10 +0200
Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9
incompatible with MakeClasslist tool
In-Reply-To: <55945116.20102@oracle.com>
References: <5593FF3F.2040501@oracle.com> <55945116.20102@oracle.com>
Message-ID: <559546BA.30701@oracle.com>
Hi Ioi,
On 2015-07-01 22:44, Ioi Lam wrote:
> Claes,
>
> The changes look good to me. It's nice to replace a large amount of
> Java code with a simple script.
>
> How about doing the line splitting like this:
>
> var classes = readFully(arg).replace(/[\r\n]+/g, "\n").split("\n")
>
> That way it will be able to handle an input file that have a mixture
> of newline characters (e.g., if someone has edited a Unix text file on
> a Windows editor).
Sure thing, this also makes the script more concise:
http://cr.openjdk.java.net/~redestad/8081589/webrev.03/
Thanks!
/Claes
>
> Thanks
> - Ioi
>
> On 7/1/15 7:54 AM, Claes Redestad wrote:
>> Hi,
>>
>> please review this rewrite/cleanup of the MakeClasslist tool to
>> operate on the output of
>> -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder.
>> Since the tool
>> became rather trivial I opted to write it in nashorn-compliant
>> javascript to streamline
>> the usage.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081589
>> Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02
>>
>> A number of undocumented/unused tests were removed and an outdated
>> README was
>> incorporated into the tool source itself, among other things
>> clarifying that the checksum
>> needs to be calculated and added to the classlist before checking it
>> into the workspace.
>>
>> I've asked around about how to go about adding tests for standalone
>> tools like these, but
>> didn't come up with a good answer. If someone insists I add a small
>> test to this I'd hope
>> there's some insight into how best to do that (shell-based jtreg test?)
>>
>> Thanks!
>>
>> /Claes
>
From ioi.lam at oracle.com Thu Jul 2 18:07:58 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 02 Jul 2015 11:07:58 -0700
Subject: RFR: 8081589: Output of -XX:+TraceClassLoadingPreorder in JDK9
incompatible with MakeClasslist tool
In-Reply-To: <559546BA.30701@oracle.com>
References: <5593FF3F.2040501@oracle.com> <55945116.20102@oracle.com>
<559546BA.30701@oracle.com>
Message-ID: <55957DFE.2050300@oracle.com>
Looks good!
Thanks
- Ioi
On 7/2/15 7:12 AM, Claes Redestad wrote:
> Hi Ioi,
>
> On 2015-07-01 22:44, Ioi Lam wrote:
>> Claes,
>>
>> The changes look good to me. It's nice to replace a large amount of
>> Java code with a simple script.
>>
>> How about doing the line splitting like this:
>>
>> var classes = readFully(arg).replace(/[\r\n]+/g, "\n").split("\n")
>>
>> That way it will be able to handle an input file that have a mixture
>> of newline characters (e.g., if someone has edited a Unix text file
>> on a Windows editor).
>
> Sure thing, this also makes the script more concise:
>
> http://cr.openjdk.java.net/~redestad/8081589/webrev.03/
>
> Thanks!
>
> /Claes
>
>>
>> Thanks
>> - Ioi
>>
>> On 7/1/15 7:54 AM, Claes Redestad wrote:
>>> Hi,
>>>
>>> please review this rewrite/cleanup of the MakeClasslist tool to
>>> operate on the output of
>>> -XX:DumpLoadedClassList rather than -XX:+TraceClassLoadingPreorder.
>>> Since the tool
>>> became rather trivial I opted to write it in nashorn-compliant
>>> javascript to streamline
>>> the usage.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081589
>>> Webrev: http://cr.openjdk.java.net/~redestad/8081589/webrev.02
>>>
>>> A number of undocumented/unused tests were removed and an outdated
>>> README was
>>> incorporated into the tool source itself, among other things
>>> clarifying that the checksum
>>> needs to be calculated and added to the classlist before checking it
>>> into the workspace.
>>>
>>> I've asked around about how to go about adding tests for standalone
>>> tools like these, but
>>> didn't come up with a good answer. If someone insists I add a small
>>> test to this I'd hope
>>> there's some insight into how best to do that (shell-based jtreg test?)
>>>
>>> Thanks!
>>>
>>> /Claes
>>
>
From ioi.lam at oracle.com Thu Jul 2 20:58:48 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Thu, 02 Jul 2015 13:58:48 -0700
Subject: RFR (S) 8129355 - [TESTBUG] FragmentMetaspaceSimple.java fails with
ClassNotFoundException: test.Empty
Message-ID: <5595A608.2060307@oracle.com>
Please review a small fix:
http://cr.openjdk.java.net/~iklam/8129355-frag-metaspace-testbug-v1/
Bug: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with
java.lang.ClassNotFoundException: test.Empty
https://bugs.openjdk.java.net/browse/JDK-8129355
Cause of failure:
The test case is intended to stress the HotSpot metaspace allocation
code, for 80 seconds,
by repeatedly loading many instances of a simple class named
"test.Empty".
In the failing version, each class is loaded by a new
URLClassLoader instance. So each time
when a class is loaded, the file system is accessed to read the
bytes of the class. So
inadvertently, this test has also become a stress test for the file
system.
On some of our embedded test machines, the file system may be
misbehaving and would fail
to read the Empty.class file on rare occasions. This causes the
test failure reported
by 8129355.
Summary of fix:
My fix is to not to use URLClassLoader. Instead, read Empty.class
only once, and store the
contents into a byte buffer. This buffer will be used to define
every instance of the Empty
class.
While this fix does not address the root cause of the failure (file
system issue in some
test machines), it will reduce the noise in our nightly tests.
Also, now that the file system is accessed much less frequently, we
can run many more iterations
so we can stress the metaspace more, which is the real intent of
this test.
Now it runs for about 80 million iterations on a fast PC and 5
million iterations on an
embedded box.
Tests:
Since the new version causes more stress in metaspace, I wanted to
make sure it doesn't cause
any new failures related to metaspace. So I used the "RBT" tool to
run the test 50 times
on 8 platforms:
linux-arm64, linux-i586, linux-x64, macosx-x64,
solaris-sparcv9, solaris-x64, windows-i586, windows-x64
for both product and fast debug builds. I also ran the test on
32-bit ARM for 12 hours (700+ runs)
and saw no failure.
Thanks
- Ioi
From mikhailo.seledtsov at oracle.com Thu Jul 2 21:36:58 2015
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Thu, 02 Jul 2015 14:36:58 -0700
Subject: RFR (S) 8129355 - [TESTBUG] FragmentMetaspaceSimple.java fails
with ClassNotFoundException: test.Empty
In-Reply-To: <5595A608.2060307@oracle.com>
References: <5595A608.2060307@oracle.com>
Message-ID: <5595AEFA.6020508@oracle.com>
Hi Ioi,
Changes look good to me.
This is a great optimization idea for this testcase, to load class
from buffer instead of a file.
And thank you for thorough testing of the fix.
Misha
On 7/2/2015 1:58 PM, Ioi Lam wrote:
> Please review a small fix:
>
> http://cr.openjdk.java.net/~iklam/8129355-frag-metaspace-testbug-v1/
>
> Bug: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with
> java.lang.ClassNotFoundException: test.Empty
>
> https://bugs.openjdk.java.net/browse/JDK-8129355
>
> Cause of failure:
>
> The test case is intended to stress the HotSpot metaspace allocation
> code, for 80 seconds,
> by repeatedly loading many instances of a simple class named
> "test.Empty".
>
> In the failing version, each class is loaded by a new
> URLClassLoader instance. So each time
> when a class is loaded, the file system is accessed to read the
> bytes of the class. So
> inadvertently, this test has also become a stress test for the
> file system.
>
> On some of our embedded test machines, the file system may be
> misbehaving and would fail
> to read the Empty.class file on rare occasions. This causes the
> test failure reported
> by 8129355.
>
> Summary of fix:
>
> My fix is to not to use URLClassLoader. Instead, read Empty.class
> only once, and store the
> contents into a byte buffer. This buffer will be used to define
> every instance of the Empty
> class.
>
> While this fix does not address the root cause of the failure
> (file system issue in some
> test machines), it will reduce the noise in our nightly tests.
>
> Also, now that the file system is accessed much less frequently,
> we can run many more iterations
> so we can stress the metaspace more, which is the real intent of
> this test.
>
> Now it runs for about 80 million iterations on a fast PC and 5
> million iterations on an
> embedded box.
>
> Tests:
>
> Since the new version causes more stress in metaspace, I wanted to
> make sure it doesn't cause
> any new failures related to metaspace. So I used the "RBT" tool to
> run the test 50 times
> on 8 platforms:
>
> linux-arm64, linux-i586, linux-x64, macosx-x64,
> solaris-sparcv9, solaris-x64, windows-i586, windows-x64
>
> for both product and fast debug builds. I also ran the test on
> 32-bit ARM for 12 hours (700+ runs)
> and saw no failure.
>
> Thanks
> - Ioi
From coleen.phillimore at oracle.com Fri Jul 3 00:22:36 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 2 Jul 2015 20:22:36 -0400
Subject: RFR (S) 8129355 - [TESTBUG] FragmentMetaspaceSimple.java fails
with ClassNotFoundException: test.Empty
In-Reply-To: <5595AEFA.6020508@oracle.com>
References: <5595A608.2060307@oracle.com> <5595AEFA.6020508@oracle.com>
Message-ID: <2A5171B1-6D26-4ECB-9916-F47C04D183A4@oracle.com>
This looks like a good fix to me also.
Coleen
Sent from my iPhone
> On Jul 2, 2015, at 5:36 PM, Mikhailo Seledtsov wrote:
>
> Hi Ioi,
>
> Changes look good to me.
> This is a great optimization idea for this testcase, to load class from buffer instead of a file.
>
> And thank you for thorough testing of the fix.
>
> Misha
>
>> On 7/2/2015 1:58 PM, Ioi Lam wrote:
>> Please review a small fix:
>>
>> http://cr.openjdk.java.net/~iklam/8129355-frag-metaspace-testbug-v1/
>>
>> Bug: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty
>>
>> https://bugs.openjdk.java.net/browse/JDK-8129355
>>
>> Cause of failure:
>>
>> The test case is intended to stress the HotSpot metaspace allocation code, for 80 seconds,
>> by repeatedly loading many instances of a simple class named "test.Empty".
>>
>> In the failing version, each class is loaded by a new URLClassLoader instance. So each time
>> when a class is loaded, the file system is accessed to read the bytes of the class. So
>> inadvertently, this test has also become a stress test for the file system.
>>
>> On some of our embedded test machines, the file system may be misbehaving and would fail
>> to read the Empty.class file on rare occasions. This causes the test failure reported
>> by 8129355.
>>
>> Summary of fix:
>>
>> My fix is to not to use URLClassLoader. Instead, read Empty.class only once, and store the
>> contents into a byte buffer. This buffer will be used to define every instance of the Empty
>> class.
>>
>> While this fix does not address the root cause of the failure (file system issue in some
>> test machines), it will reduce the noise in our nightly tests.
>>
>> Also, now that the file system is accessed much less frequently, we can run many more iterations
>> so we can stress the metaspace more, which is the real intent of this test.
>>
>> Now it runs for about 80 million iterations on a fast PC and 5 million iterations on an
>> embedded box.
>>
>> Tests:
>>
>> Since the new version causes more stress in metaspace, I wanted to make sure it doesn't cause
>> any new failures related to metaspace. So I used the "RBT" tool to run the test 50 times
>> on 8 platforms:
>>
>> linux-arm64, linux-i586, linux-x64, macosx-x64,
>> solaris-sparcv9, solaris-x64, windows-i586, windows-x64
>>
>> for both product and fast debug builds. I also ran the test on 32-bit ARM for 12 hours (700+ runs)
>> and saw no failure.
>>
>> Thanks
>> - Ioi
>
From alexander.vorobyev at oracle.com Fri Jul 3 16:12:45 2015
From: alexander.vorobyev at oracle.com (alexander vorobyev)
Date: Fri, 03 Jul 2015 19:12:45 +0300
Subject: [8u65] Request for approval: backport of JDK-8007890
In-Reply-To: <558F1F4B.7040706@oracle.com>
References: <542E8041.1010101@oracle.com> <558D5430.7040209@oracle.com>
<558F1F4B.7040706@oracle.com>
Message-ID: <5596B47D.8090104@oracle.com>
Hi David,
It is too late for 8u60, I guess. So I decided to fix it in 8u65. And in
this case it should be jdk8u-cpu repository.
Maybe it is possible to target to 8u66? To which repository can I push
it in this case (considering that jdk8u/hs-dev is not accepting any change)?
Thanks
On 28-Jun-15 1:10 AM, David Holmes wrote:
> Hi Alexander,
>
> Why is this targeted to 8u65 and where do you propose to push it?
> jdk8u/hs-dev is not accepting any changes at the moment.
>
> Thanks,
> David
>
> On 26/06/2015 11:31 PM, alexander vorobyev wrote:
>>
>> Hi All,
>>
>> I would like to backport fix for JDK-8007890 to 8u65.
>>
>> Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890
>> Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/
>>
>> Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e
>> Review thread for original
>> fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html
>>
>>
>>
>> testing: jprt
>>
>> Thanks,
>> Alexander
>>
>>
>>
From david.holmes at oracle.com Fri Jul 3 23:27:38 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 4 Jul 2015 09:27:38 +1000
Subject: [8u65] Request for approval: backport of JDK-8007890
In-Reply-To: <5596B47D.8090104@oracle.com>
References: <542E8041.1010101@oracle.com> <558D5430.7040209@oracle.com>
<558F1F4B.7040706@oracle.com> <5596B47D.8090104@oracle.com>
Message-ID: <55971A6A.9060205@oracle.com>
On 4/07/2015 2:12 AM, alexander vorobyev wrote:
> Hi David,
>
> It is too late for 8u60, I guess. So I decided to fix it in 8u65. And in
> this case it should be jdk8u-cpu repository.
>
> Maybe it is possible to target to 8u66? To which repository can I push
> it in this case (considering that jdk8u/hs-dev is not accepting any
> change)?
jdk8u/hs-dev is now accepting changes for 8u66.
Cheers,
David
> Thanks
>
>
> On 28-Jun-15 1:10 AM, David Holmes wrote:
>> Hi Alexander,
>>
>> Why is this targeted to 8u65 and where do you propose to push it?
>> jdk8u/hs-dev is not accepting any changes at the moment.
>>
>> Thanks,
>> David
>>
>> On 26/06/2015 11:31 PM, alexander vorobyev wrote:
>>>
>>> Hi All,
>>>
>>> I would like to backport fix for JDK-8007890 to 8u65.
>>>
>>> Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890
>>> Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/
>>>
>>> Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e
>>> Review thread for original
>>> fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html
>>>
>>>
>>>
>>> testing: jprt
>>>
>>> Thanks,
>>> Alexander
>>>
>>>
>>>
>
From daniel.daugherty at oracle.com Sat Jul 4 00:11:28 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Jul 2015 18:11:28 -0600
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <555A4678.7020308@oracle.com>
References: <555A4678.7020308@oracle.com>
Message-ID: <559724B0.6000507@oracle.com>
Greetings,
I've updated the patch for Contended Locking fast notify bucket
based on David H's and Karen's comments.
This work is being tracked by the following bug ID:
JDK-8075171 Contended Locking fast notify bucket
https://bugs.openjdk.java.net/browse/JDK-8075171
Here is the webrev URL:
http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
Here is the JEP link:
https://bugs.openjdk.java.net/browse/JDK-8046133
Testing:
- RBT vm.quick batches (in process)
- JPRT test jobs
- MonitorWaitNotifyStresser micro-benchmark (in process)
- CallTimerGrid stress testing (in process)
The changes in this round are in only four of the files:
src/share/vm/opto/runtime.cpp
- deleted comment about hashCode() that belongs in a different bucket
src/share/vm/runtime/objectMonitor.cpp
- add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
- cleanup recheck interval code
- ObjectMonitor::INotify() return type is now "void"
- delete duplicate comments, clarify/rewrite some comments
src/share/vm/runtime/objectMonitor.hpp
- ObjectMonitor::INotify() return type is now "void"
src/share/vm/runtime/synchronizer.cpp
- clarify/rewrite comments, add additional comments
- cleanup variables in ObjectSynchronizer::quick_notify
- refactor loop to be more clear
- delete unused enum MaximumRecheckInterval
The easiest way to review the delta is to download the two patch
files and compare them in something like jfilemerge:
http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
Dan
On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I have the Contended Locking fast notify bucket ready for review.
>
> The code changes in this bucket are the final piece in the triad
> of {fast-enter, fast-exit, fast-notify} changes. There are no
> macro assembler changes in this bucket (yeah!), but there are
> code review cleanups motivated by comments on other buckets, e.g.,
> changing variables like 'Tally' -> 'tally'.
>
> This work is being tracked by the following bug ID:
>
> JDK-8075171 Contended Locking fast notify bucket
> https://bugs.openjdk.java.net/browse/JDK-8075171
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>
> Here is the JEP link:
>
> https://bugs.openjdk.java.net/browse/JDK-8046133
>
> Testing:
>
> - Aurora Adhoc RT/SVC baseline batch
> - JPRT test jobs
> - MonitorWaitNotifyStresser micro-benchmark (in process)
> - CallTimerGrid stress testing (in process)
> - Aurora performance testing:
> - out of the box for the "promotion" and 32-bit server configs
> - heavy weight monitors for the "promotion" and 32-bit server configs
> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
> (in process)
>
> The hang somehow introduced by the "fast enter" bucket is still
> unresolved, but progress is being made. That work is being tracked
> by the following bug:
>
> JDK-8077392 Stream fork/join tasks occasionally fail to complete
> https://bugs.openjdk.java.net/browse/JDK-8077392
>
> You'll see a change that re-enables the "fast enter" bucket in this
> webrev, but that change will not be pushed when we're done with the
> review of this bucket unless JDK-8077392 is resolved.
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Gory details about the changes are below...
>
> Dan
>
>
> 8075171 summary of changes:
>
> src/share/vm/classfile/vmSymbols.hpp
> - Add do_intrinsic() entries for _notify and _notifyAll
>
> src/share/vm/opto/library_call.cpp
> - Add optional inline_notify() that is controlled by new
> '-XX:[+-]InlineNotify' option
>
> src/share/vm/opto/runtime.cpp
> src/share/vm/opto/runtime.hpp
> - Add OptoRuntime::monitor_notify_C() and
> OptoRuntime::monitor_notifyAll_C() functions to support
> the new "fast notify" code paths
> - Add new OptoRuntime::monitor_notify_Type() to support
> the above two new functions
>
> src/share/vm/runtime/globals.hpp
> - Add '-XX:[+-]InlineNotify' option; default option value is
> enabled (true)
>
> src/share/vm/runtime/objectMonitor.cpp
> src/share/vm/runtime/objectMonitor.hpp
> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
> into wrappers that call the new ObjectMonitor::INotify()
> - Add new ObjectMonitor::INotify() to reduce code duplication
> between "notify" and "notifyAll" code paths
>
> src/share/vm/runtime/sharedRuntime.cpp
> - Temporarily re-enable the "fast enter" optimization in order
> to do performance testing. JDK-8077392 is still unresolved,
> but progress is being made.
>
> src/share/vm/runtime/synchronizer.cpp
> src/share/vm/runtime/synchronizer.hpp
> - Add ObjectSynchronizer::quick_notify() that implements the
> new "fast notify" code paths
> - The new code handles a couple of special cases where the
> "notify" can be done without the heavy weight slow-path
> (thread state transitions and other baggage)
>
>
From daniel.daugherty at oracle.com Sat Jul 4 00:14:16 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 03 Jul 2015 18:14:16 -0600
Subject: RFR(S) 8077392 inspired thread dump improvements, comment, additions,
new diagnostics (8130448)
Message-ID: <55972558.6060905@oracle.com>
Greetings,
The hunt for the following bug:
JDK-8077392 Stream fork/join tasks occasionally fail to complete
and David C's work on the following bug:
JDK-8069412 Locks need better debug-printing support
have inspired additional thread dump improvements, comment additions
to some Java monitor code and some new diagnostic options.
This work is being tracked by the following bug ID:
JDK-8130448 8077392 inspired thread dump improvements, comment
additions, new diagnostics
https://bugs.openjdk.java.net/browse/JDK-8130448
Here is the webrev URL:
http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
Testing:
- RBT vm.quick batches (in process)
- JPRT test jobs
Thanks, in advance, for any comments, questions or suggestions.
Gory details about the changes are below...
Dan
8130448 summary of changes:
src/cpu/x86/vm/macroAssembler_x86.cpp
- comment additions for the assembly code
src/share/vm/oops/markOop.cpp
- has_monitor() has to be checked before is_locked() since
the has_monitor() bits are a superset of the is_locked() bits
- code style fixes
src/share/vm/runtime/globals.hpp
- add VerboseStackTrace diagnostic option
- add GuaranteeOnMonitorMismatch diagnostic option
- add JavaThreadExitReleasesMonitors product option;
this is the Java equivalent of JNIDetachReleasesMonitors
src/share/vm/runtime/objectMonitor.cpp
- delete unused ObjectMonitor::try_enter()
- fix assert wording
src/share/vm/runtime/objectMonitor.hpp
- delete unused ObjectMonitor::try_enter()
src/share/vm/runtime/synchronizer.cpp
- add GuaranteeOnMonitorMismatch support with some
diagnostic output
src/share/vm/runtime/thread.cpp
- add JavaThreadExitReleasesMonitors support
src/share/vm/runtime/vframe.cpp
- clarify existing comments
- add comments to clarify what "waiting on" means
- add line to show when we are "waiting on", but
there are no locals available (previously we were
"waiting on" silently)
- add support for "waiting to relock" which can happen
for any of the monitors and not just the top monitor
- switch mark->print_on() verbose output to new
VerboseStackTrace switch; thread dumps are not enabled
with a specific switch so the '-XX:+Verbose' model of
being a modifier for another option does not fit
From david.holmes at oracle.com Mon Jul 6 04:32:51 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Jul 2015 14:32:51 +1000
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <559724B0.6000507@oracle.com>
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
Message-ID: <559A04F3.3060702@oracle.com>
Thanks Dan! No further comments from me.
David
On 4/07/2015 10:11 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> I've updated the patch for Contended Locking fast notify bucket
> based on David H's and Karen's comments.
>
> This work is being tracked by the following bug ID:
>
> JDK-8075171 Contended Locking fast notify bucket
> https://bugs.openjdk.java.net/browse/JDK-8075171
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>
> Here is the JEP link:
>
> https://bugs.openjdk.java.net/browse/JDK-8046133
>
> Testing:
>
> - RBT vm.quick batches (in process)
> - JPRT test jobs
> - MonitorWaitNotifyStresser micro-benchmark (in process)
> - CallTimerGrid stress testing (in process)
>
>
> The changes in this round are in only four of the files:
>
> src/share/vm/opto/runtime.cpp
>
> - deleted comment about hashCode() that belongs in a different bucket
>
> src/share/vm/runtime/objectMonitor.cpp
>
> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
> - cleanup recheck interval code
> - ObjectMonitor::INotify() return type is now "void"
> - delete duplicate comments, clarify/rewrite some comments
>
> src/share/vm/runtime/objectMonitor.hpp
>
> - ObjectMonitor::INotify() return type is now "void"
>
> src/share/vm/runtime/synchronizer.cpp
>
> - clarify/rewrite comments, add additional comments
> - cleanup variables in ObjectSynchronizer::quick_notify
> - refactor loop to be more clear
> - delete unused enum MaximumRecheckInterval
>
> The easiest way to review the delta is to download the two patch
> files and compare them in something like jfilemerge:
>
> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
>
> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>
>
> Dan
>
>
> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I have the Contended Locking fast notify bucket ready for review.
>>
>> The code changes in this bucket are the final piece in the triad
>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>> macro assembler changes in this bucket (yeah!), but there are
>> code review cleanups motivated by comments on other buckets, e.g.,
>> changing variables like 'Tally' -> 'tally'.
>>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8075171 Contended Locking fast notify bucket
>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>
>> Here is the JEP link:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>
>> Testing:
>>
>> - Aurora Adhoc RT/SVC baseline batch
>> - JPRT test jobs
>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>> - CallTimerGrid stress testing (in process)
>> - Aurora performance testing:
>> - out of the box for the "promotion" and 32-bit server configs
>> - heavy weight monitors for the "promotion" and 32-bit server configs
>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>> (in process)
>>
>> The hang somehow introduced by the "fast enter" bucket is still
>> unresolved, but progress is being made. That work is being tracked
>> by the following bug:
>>
>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>
>> You'll see a change that re-enables the "fast enter" bucket in this
>> webrev, but that change will not be pushed when we're done with the
>> review of this bucket unless JDK-8077392 is resolved.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Gory details about the changes are below...
>>
>> Dan
>>
>>
>> 8075171 summary of changes:
>>
>> src/share/vm/classfile/vmSymbols.hpp
>> - Add do_intrinsic() entries for _notify and _notifyAll
>>
>> src/share/vm/opto/library_call.cpp
>> - Add optional inline_notify() that is controlled by new
>> '-XX:[+-]InlineNotify' option
>>
>> src/share/vm/opto/runtime.cpp
>> src/share/vm/opto/runtime.hpp
>> - Add OptoRuntime::monitor_notify_C() and
>> OptoRuntime::monitor_notifyAll_C() functions to support
>> the new "fast notify" code paths
>> - Add new OptoRuntime::monitor_notify_Type() to support
>> the above two new functions
>>
>> src/share/vm/runtime/globals.hpp
>> - Add '-XX:[+-]InlineNotify' option; default option value is
>> enabled (true)
>>
>> src/share/vm/runtime/objectMonitor.cpp
>> src/share/vm/runtime/objectMonitor.hpp
>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>> into wrappers that call the new ObjectMonitor::INotify()
>> - Add new ObjectMonitor::INotify() to reduce code duplication
>> between "notify" and "notifyAll" code paths
>>
>> src/share/vm/runtime/sharedRuntime.cpp
>> - Temporarily re-enable the "fast enter" optimization in order
>> to do performance testing. JDK-8077392 is still unresolved,
>> but progress is being made.
>>
>> src/share/vm/runtime/synchronizer.cpp
>> src/share/vm/runtime/synchronizer.hpp
>> - Add ObjectSynchronizer::quick_notify() that implements the
>> new "fast notify" code paths
>> - The new code handles a couple of special cases where the
>> "notify" can be done without the heavy weight slow-path
>> (thread state transitions and other baggage)
>>
>>
>
From david.holmes at oracle.com Mon Jul 6 06:43:35 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Jul 2015 16:43:35 +1000
Subject: RFR(S) 8077392 inspired thread dump improvements, comment,
additions, new diagnostics (8130448)
In-Reply-To: <55972558.6060905@oracle.com>
References: <55972558.6060905@oracle.com>
Message-ID: <559A2397.2010409@oracle.com>
Hi Dan,
Metacomment: Could I suggest that in a RFR your subject line has the
form : , rather than (bugid) - especially
when the synopsis actually starts with a bug id :) Thanks.
Mostly okay but some major concerns around the can of worms that
JavaThreadExitReleasesMonitors opens up.
On 4/07/2015 10:14 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> The hunt for the following bug:
>
> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>
> and David C's work on the following bug:
>
> JDK-8069412 Locks need better debug-printing support
>
> have inspired additional thread dump improvements, comment additions
> to some Java monitor code and some new diagnostic options.
src/cpu/x86/vm/macroAssembler_x86.cpp
1821 // update _owner from from BasicLock to thread
Typo: from from
2091 // the placeholder value. If that didn't work, then another
2092 // grabbed the lock so we're done (and exit was a success).
another -> another thread ?
2201 // If that didn't work, then another grabbed the lock
2202 // so we're done (and exit was a success).
another -> another thread ?
---
src/share/vm/oops/markOop.cpp
40 st->print("NULL"); // this should not happen
Shouldn't that be an assert or guarantee in that case? Or at a minimum
print something like: "NULL (but you should never see this!)"
42 BasicLock * bl = (BasicLock *) mon->owner();
What information has told us this is a BasicLock* not a Thread* ? But as
all you do is print bl why not just p2i(mon->owner()) ?
---
src/share/vm/runtime/globals.hpp
JavaThreadExitReleasesMonitors has me perplexed. The JNI DetachThread
case seems to be a concession to badly written code that fails to
release locks on error paths. The equivalent for a Java thread would
again involve lock acquisition via JNI. But I don't recall ever seeing a
bug report or RFE related to this. What seems to have motivated this new
flag is the potential for a broken VM to actually leave the monitor
locked (e.g. because compiled code failed to do the unlock on all
paths). To address that I'd be inclined to simply have a guarantee in
the Java thread exit path, rather than a flag to do the clean up and
another flag to control a guarantee. I don't think two new command-line
options (has this gone through CCC yet?) are justified.
Also note that allowing for JVM induced missing unlocks is something
that can affect JNI attached threads as well as regular Java threads.
I'll take this up in discussing thread.cpp below.
That aside, the comment, which was modelled on the JNI DetachThread
variant, does not really work in this case:
2801 "JavaThread exit() releases monitors owned by thread")
\
JavaThread is not a programming concept but an internal JVM abstraction.
I would suggest something like:
"Java thread termination releases monitors unexpectedly still owned by
thread"
---
src/share/vm/runtime/objectMonitor.cpp
src/share/vm/runtime/objectMonitor.hpp
No comments
---
src/share/vm/runtime/synchronizer.cpp
If we find the unexpected locked monitor it would be useful to see more
Java level information about the Thread (in the non-detaching case) and
the object that is locked.
---
src/share/vm/runtime/thread.cpp
As noted previously JNI attached threads can also be affected by JVM
induced locking bugs. So the comment block:
1804 // 6282335 JNI DetachCurrentThread spec states that all Java monitors
1805 // held by this thread must be released. A detach operation must
only
1806 // get here if there are no Java frames on the stack. Therefore, any
1807 // owned monitors at this point MUST be JNI-acquired monitors
which are
1808 // pre-inflated and in the monitor cache.
is not strictly correct as it is presuming a correctly operating JVM.
Further the logic now applied:
1816 if ((exit_type == jni_detach && JNIDetachReleasesMonitors) ||
1817 JavaThreadExitReleasesMonitors) {
is also not "correct" because if we have JavaThreadExitReleasesMonitors
true while JNIDetachReleasesMonitors is false, we will in fact release
any JNI acquired monitors because we can't make the distinction. Given
we can't make the distinction I don't see any way for these separate
flags to actually work well together. As I said above I'm more inclined
to just add a guarantee to the non-detach case, than add two new flags.
(Even though this means there won't be detection for such bugs when JNI
attached threads encounter them - including the main thread :( ).
As I said this has me perplexed. :(
---
src/share/vm/runtime/vframe.cpp
170 // It would be nice to distinguish between "waiting on" and
171 // "waited on". Currently, "waiting on" here with a
172 // java.lang.Thread.State == "WAITING (on object monitor)"
173 // earlier in the output means that the monitor has not yet been
174 // notified and java.lang.Thread.State == "BLOCKED (on object
175 // monitor)" earlier in the output means that the monitor has
176 // been notified and the thread is blocked on reentry.
That's a very long sentence that can be quite difficult to parse and
could probably be reworded to describe how the output should be
interpreted eg:
// If earlier in the output we reported java.lang.Thread.State ==
// "WAITING (on object monitor)" and now we report "waited on", then
// we are still waiting for notification [or timeout?]. Otherwise if
// we earlier reported java.lang.Thread.State == "BLOCKED (on object
// monitor)", then we are actually waiting to reacquire the monitor
// lock. At this level we can't distinguish the two cases to report
// "waited on" rather than "waiting on" for the second case.
I wonder if we can prod deeper into VM state to try and make the
distinction?
184 } else {
185 st->print_cr("\t- %s ", wait_state);
The concept of "locals" is confusing here. Isn't the "local" in this
case just the object that we have waited upon? In which case we should
say "no object reference available". Though I would have thought/hoped
there must be a way to find the object reference even in a compiled frame?
195 // Print out all monitors that we have locked, are trying to lock
196 // or are trying to relock after a wait().
that makes it sound like there are three cases when really a "relock" is
just a specific case of lock. I would suggest:
// Print out all monitors that we have locked, or are trying to
// lock, including re-locking when returning from a wait().
252 lock_state = "waiting to relock";
I prefer "waiting to re-lock in wait()", if that isn't too long.
Otherwise "relock" needs to be a concept people are familiar with.
260 if (VerboseStackTrace && mark != NULL) {
261 st->print("\t- lockbits=");
262 mark->print_on(st);
This really doesn't seem to warrant a new diagnostic flag, regardless of
whether we think applying -XX:+Verbose is a good fit or not.
Thanks,
David
-------
> This work is being tracked by the following bug ID:
>
> JDK-8130448 8077392 inspired thread dump improvements, comment
> additions, new diagnostics
> https://bugs.openjdk.java.net/browse/JDK-8130448
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>
> Testing:
>
> - RBT vm.quick batches (in process)
> - JPRT test jobs
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Gory details about the changes are below...
>
> Dan
>
> 8130448 summary of changes:
>
> src/cpu/x86/vm/macroAssembler_x86.cpp
> - comment additions for the assembly code
>
> src/share/vm/oops/markOop.cpp
> - has_monitor() has to be checked before is_locked() since
> the has_monitor() bits are a superset of the is_locked() bits
> - code style fixes
>
> src/share/vm/runtime/globals.hpp
> - add VerboseStackTrace diagnostic option
> - add GuaranteeOnMonitorMismatch diagnostic option
> - add JavaThreadExitReleasesMonitors product option;
> this is the Java equivalent of JNIDetachReleasesMonitors
>
> src/share/vm/runtime/objectMonitor.cpp
> - delete unused ObjectMonitor::try_enter()
> - fix assert wording
>
> src/share/vm/runtime/objectMonitor.hpp
> - delete unused ObjectMonitor::try_enter()
>
> src/share/vm/runtime/synchronizer.cpp
> - add GuaranteeOnMonitorMismatch support with some
> diagnostic output
>
> src/share/vm/runtime/thread.cpp
> - add JavaThreadExitReleasesMonitors support
>
> src/share/vm/runtime/vframe.cpp
> - clarify existing comments
> - add comments to clarify what "waiting on" means
> - add line to show when we are "waiting on", but
> there are no locals available (previously we were
> "waiting on" silently)
> - add support for "waiting to relock" which can happen
> for any of the monitors and not just the top monitor
> - switch mark->print_on() verbose output to new
> VerboseStackTrace switch; thread dumps are not enabled
> with a specific switch so the '-XX:+Verbose' model of
> being a modifier for another option does not fit
From daniel.daugherty at oracle.com Mon Jul 6 13:20:49 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 06 Jul 2015 07:20:49 -0600
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <559A04F3.3060702@oracle.com>
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
<559A04F3.3060702@oracle.com>
Message-ID: <559A80B1.5050708@oracle.com>
David,
Thanks for the re-review!
Dan
On 7/5/15 10:32 PM, David Holmes wrote:
> Thanks Dan! No further comments from me.
>
> David
>
> On 4/07/2015 10:11 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I've updated the patch for Contended Locking fast notify bucket
>> based on David H's and Karen's comments.
>>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8075171 Contended Locking fast notify bucket
>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>>
>> Here is the JEP link:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>
>> Testing:
>>
>> - RBT vm.quick batches (in process)
>> - JPRT test jobs
>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>> - CallTimerGrid stress testing (in process)
>>
>>
>> The changes in this round are in only four of the files:
>>
>> src/share/vm/opto/runtime.cpp
>>
>> - deleted comment about hashCode() that belongs in a different bucket
>>
>> src/share/vm/runtime/objectMonitor.cpp
>>
>> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
>> - cleanup recheck interval code
>> - ObjectMonitor::INotify() return type is now "void"
>> - delete duplicate comments, clarify/rewrite some comments
>>
>> src/share/vm/runtime/objectMonitor.hpp
>>
>> - ObjectMonitor::INotify() return type is now "void"
>>
>> src/share/vm/runtime/synchronizer.cpp
>>
>> - clarify/rewrite comments, add additional comments
>> - cleanup variables in ObjectSynchronizer::quick_notify
>> - refactor loop to be more clear
>> - delete unused enum MaximumRecheckInterval
>>
>> The easiest way to review the delta is to download the two patch
>> files and compare them in something like jfilemerge:
>>
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
>>
>>
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>>
>>
>>
>> Dan
>>
>>
>> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I have the Contended Locking fast notify bucket ready for review.
>>>
>>> The code changes in this bucket are the final piece in the triad
>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>> macro assembler changes in this bucket (yeah!), but there are
>>> code review cleanups motivated by comments on other buckets, e.g.,
>>> changing variables like 'Tally' -> 'tally'.
>>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8075171 Contended Locking fast notify bucket
>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>
>>> Here is the JEP link:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>
>>> Testing:
>>>
>>> - Aurora Adhoc RT/SVC baseline batch
>>> - JPRT test jobs
>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>> - CallTimerGrid stress testing (in process)
>>> - Aurora performance testing:
>>> - out of the box for the "promotion" and 32-bit server configs
>>> - heavy weight monitors for the "promotion" and 32-bit server configs
>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>> (in process)
>>>
>>> The hang somehow introduced by the "fast enter" bucket is still
>>> unresolved, but progress is being made. That work is being tracked
>>> by the following bug:
>>>
>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>
>>> You'll see a change that re-enables the "fast enter" bucket in this
>>> webrev, but that change will not be pushed when we're done with the
>>> review of this bucket unless JDK-8077392 is resolved.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>>
>>> 8075171 summary of changes:
>>>
>>> src/share/vm/classfile/vmSymbols.hpp
>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>
>>> src/share/vm/opto/library_call.cpp
>>> - Add optional inline_notify() that is controlled by new
>>> '-XX:[+-]InlineNotify' option
>>>
>>> src/share/vm/opto/runtime.cpp
>>> src/share/vm/opto/runtime.hpp
>>> - Add OptoRuntime::monitor_notify_C() and
>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>> the new "fast notify" code paths
>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>> the above two new functions
>>>
>>> src/share/vm/runtime/globals.hpp
>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>> enabled (true)
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>> src/share/vm/runtime/objectMonitor.hpp
>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>> into wrappers that call the new ObjectMonitor::INotify()
>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>> between "notify" and "notifyAll" code paths
>>>
>>> src/share/vm/runtime/sharedRuntime.cpp
>>> - Temporarily re-enable the "fast enter" optimization in order
>>> to do performance testing. JDK-8077392 is still unresolved,
>>> but progress is being made.
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>> src/share/vm/runtime/synchronizer.hpp
>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>> new "fast notify" code paths
>>> - The new code handles a couple of special cases where the
>>> "notify" can be done without the heavy weight slow-path
>>> (thread state transitions and other baggage)
>>>
>>>
>>
From daniel.daugherty at oracle.com Mon Jul 6 20:47:41 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 06 Jul 2015 14:47:41 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559A2397.2010409@oracle.com>
References: <55972558.6060905@oracle.com> <559A2397.2010409@oracle.com>
Message-ID: <559AE96D.6010508@oracle.com>
On 7/6/15 12:43 AM, David Holmes wrote:
> Hi Dan,
>
> Metacomment: Could I suggest that in a RFR your subject line has the
> form : , rather than (bugid) - especially
> when the synopsis actually starts with a bug id :) Thanks.
Yup that bug synopsis is/was a mess:
Changed the synopsis line to :
thread dump improvements, comment additions, new diagnostics
inspired by 8077392
Also updated the e-mail thread subject line to your suggested format.
Will try to remember to switch to that style in the future.
> Mostly okay but some major concerns around the can of worms that
> JavaThreadExitReleasesMonitors opens up.
This is Java monitors so "can of worms" is familiar! :-)
>
> On 4/07/2015 10:14 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> The hunt for the following bug:
>>
>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>
>> and David C's work on the following bug:
>>
>> JDK-8069412 Locks need better debug-printing support
>>
>> have inspired additional thread dump improvements, comment additions
>> to some Java monitor code and some new diagnostic options.
>
> src/cpu/x86/vm/macroAssembler_x86.cpp
>
> 1821 // update _owner from from BasicLock to thread
>
> Typo: from from
Will fix.
> 2091 // the placeholder value. If that didn't work, then another
> 2092 // grabbed the lock so we're done (and exit was a success).
>
> another -> another thread ?
Yes, "another thread" is better. Will fix.
> 2201 // If that didn't work, then another grabbed the lock
> 2202 // so we're done (and exit was a success).
>
> another -> another thread ?
Yes, "another thread" is better. Will fix.
> ---
>
> src/share/vm/oops/markOop.cpp
>
> 40 st->print("NULL"); // this should not happen
>
> Shouldn't that be an assert or guarantee in that case? Or at a minimum
> print something like: "NULL (but you should never see this!)"
This is a relocated line from David C's change:
old 49: st->print("monitor=NULL");
I simply added a comment to it. I don't think I like the idea of the
thread dump code assert()'ing or guarantee()'ing because there might
be other useful info that would have been printed after the assert()
or guarantee() failure.
I do like the idea of changing the message to:
40: st->print("NULL (this should never be seen!)");
> 42 BasicLock * bl = (BasicLock *) mon->owner();
>
> What information has told us this is a BasicLock* not a Thread* ? But
> as all you do is print bl why not just p2i(mon->owner()) ?
Again, this is a relocated line from David C's change:
old 51: BasicLock * bl = (BasicLock *) mon->owner();
I'm going to guess that David C had some other code in there before
that needed/assumed that the field is a "BasicLock *", but that code
didn't make it into his final version.
I will drop the 'bl' local and update the p2i() call to use
mon->owner() directly.
> ---
>
> src/share/vm/runtime/globals.hpp
>
> JavaThreadExitReleasesMonitors has me perplexed. The JNI DetachThread
> case seems to be a concession to badly written code that fails to
> release locks on error paths.
I don't think I would call the JNIDetachReleasesMonitors case a concession
to badly written JNI code. 6282335 is very clear that this code was added
to meet the JNI spec. The JNI spec words might be considered a concession...
http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#DetachCurrentThread
> DetachCurrentThread
>
> jint DetachCurrentThread(JavaVM *vm);
>
> Detaches the current thread from a Java VM. All Java monitors
> held by this thread are released. All Java threads waiting for
> this thread to die are notified.
>
> The main thread can be detached from the VM.
> The equivalent for a Java thread would again involve lock acquisition
> via JNI. But I don't recall ever seeing a bug report or RFE related to
> this. What seems to have motivated this new flag is the potential for
> a broken VM to actually leave the monitor locked (e.g. because
> compiled code failed to do the unlock on all paths).
8077392 and bugs like it are exactly the reason for adding these
two options.
JavaThreadExitReleasesMonitors is added to provide a work around
until the underlying bug or bugs are fixed. This option is targeted
at folks that are chasing their own bugs and don't care about this
one.
GuaranteeOnMonitorMismatch is added to help hunt 8077392 specifically
and to sanity check for similar issues generally. I can see using the
two options in combination with existing test suites as a stress test
for the Java monitor subsystem.
> To address that I'd be inclined to simply have a guarantee in the Java
> thread exit path, rather than a flag to do the clean up and another
> flag to control a guarantee.
The check for an unexited Java monitor is not cheap.
The existing check under the JNIDetachReleasesMonitors flag is
positioned to only affect threads using JNI DetachCurrentThread()
and that cost is justified as part of meeting the JNI spec.
Adding the unexited Java monitor check to all exiting Java
threads should not be done lightly due to the cost. If the
VM is functioning correctly, then why impose this cost on
all exiting Java threads?
> I don't think two new command-line options (has this gone through CCC
> yet?) are justified.
No, this has not gone through CCC yet. My preference is to get
code review feedback (like this) before submitting a CCC.
I suppose I could have simply added more sub-options to the
existing Java monitor subsystem knobs and switches, but it
seemed to make sense to model JavaThreadExitReleasesMonitors
on the existing JNIDetachReleasesMonitors.
> Also note that allowing for JVM induced missing unlocks is something
> that can affect JNI attached threads as well as regular Java threads.
> I'll take this up in discussing thread.cpp below.
>
> That aside, the comment, which was modelled on the JNI DetachThread
> variant, does not really work in this case:
>
> 2801 "JavaThread exit() releases monitors owned by thread")
> \
>
> JavaThread is not a programming concept but an internal JVM
> abstraction. I would suggest something like:
>
> "Java thread termination releases monitors unexpectedly still owned by
> thread"
I'll switch to your description text if we end up keeping the
new options.
> ---
>
> src/share/vm/runtime/objectMonitor.cpp
> src/share/vm/runtime/objectMonitor.hpp
>
> No comments
>
> ---
>
> src/share/vm/runtime/synchronizer.cpp
>
> If we find the unexpected locked monitor it would be useful to see
> more Java level information about the Thread (in the non-detaching
> case) and the object that is locked.
I can probably steal some code from the thread dump side to
give us more info about the Object associated with the Java
monitor...
> ---
>
> src/share/vm/runtime/thread.cpp
>
> As noted previously JNI attached threads can also be affected by JVM
> induced locking bugs. So the comment block:
>
> 1804 // 6282335 JNI DetachCurrentThread spec states that all Java
> monitors
> 1805 // held by this thread must be released. A detach operation
> must only
> 1806 // get here if there are no Java frames on the stack.
> Therefore, any
> 1807 // owned monitors at this point MUST be JNI-acquired monitors
> which are
> 1808 // pre-inflated and in the monitor cache.
>
> is not strictly correct as it is presuming a correctly operating JVM.
I actually disagree with the last two sentences in that comment block,
but I didn't have a good rewrite in mind. I'll think about it more.
> Further the logic now applied:
>
> 1816 if ((exit_type == jni_detach && JNIDetachReleasesMonitors) ||
> 1817 JavaThreadExitReleasesMonitors) {
>
> is also not "correct" because if we have
> JavaThreadExitReleasesMonitors true while JNIDetachReleasesMonitors is
> false, we will in fact release any JNI acquired monitors because we
> can't make the distinction.
I don't think JNIDetachReleasesMonitors only has to deal with JNI-acquired
monitors and I don't think that JavaThreadExitReleasesMonitors only has to
deal with Java code acquired monitors. I see these options as applying to
"how you got to the Java thread exit path" and not applying to "what needs
to be cleaned up".
I see JNIDetachReleasesMonitors as a way of cleaning up unexited Java
monitors when we're executing the JNI DetachCurrentThread() code path.
I don't really care why the Java monitors are unexited... and I think
the spec wording is clear that all unexited Java monitors are cleaned
up... not just JNI-acquired monitors.
I see JavaThreadExitReleasesMonitors as a way of cleaning up unexited
Java monitors in any code path where we are exiting the Java thread. I see
JavaThreadExitReleasesMonitors as a superset of JNIDetachReleasesMonitors.
> Given we can't make the distinction I don't see any way for these
> separate flags to actually work well together.
I think they work well together when JavaThreadExitReleasesMonitors
is seen as a superset of JNIDetachReleasesMonitors. Of course, that
hinges on my opinion that JNIDetachReleasesMonitors applies to any
unexited Java monitor and not just JNI-acquired Java monitors.
> As I said above I'm more inclined to just add a guarantee to the
> non-detach case, than add two new flags. (Even though this means there
> won't be detection for such bugs when JNI attached threads encounter
> them - including the main thread :( ).
I really don't want to add this check to all Java thread exit
paths since it is expensive.
> As I said this has me perplexed. :(
Hopefully, I've explained it better now.
> ---
>
> src/share/vm/runtime/vframe.cpp
>
> 170 // It would be nice to distinguish between "waiting on" and
> 171 // "waited on". Currently, "waiting on" here with a
> 172 // java.lang.Thread.State == "WAITING (on object monitor)"
> 173 // earlier in the output means that the monitor has not yet
> been
> 174 // notified and java.lang.Thread.State == "BLOCKED (on object
> 175 // monitor)" earlier in the output means that the monitor has
> 176 // been notified and the thread is blocked on reentry.
>
> That's a very long sentence that can be quite difficult to parse and
> could probably be reworded to describe how the output should be
> interpreted eg:
>
> // If earlier in the output we reported java.lang.Thread.State ==
> // "WAITING (on object monitor)" and now we report "waited on", then
> // we are still waiting for notification [or timeout?]. Otherwise if
> // we earlier reported java.lang.Thread.State == "BLOCKED (on object
> // monitor)", then we are actually waiting to reacquire the monitor
> // lock. At this level we can't distinguish the two cases to report
> // "waited on" rather than "waiting on" for the second case.
I'll take a look at rewriting the comment and may just take your
version entirely.
> I wonder if we can prod deeper into VM state to try and make the
> distinction?
I played around with doing just that, but it seems like the M&M
code that fetches similar state probes the state stored in the
java.lang.Thread object. I didn't want to go there.
>
> 184 } else {
> 185 st->print_cr("\t- %s ", wait_state);
>
> The concept of "locals" is confusing here. Isn't the "local" in this
> case just the object that we have waited upon? In which case we should
> say "no object reference available".
I got the phrase "locals" from the compiler code that was trying to
decode the object reference. I can change to "no object reference
available".
I definitely want to say _something_ here. The existing code is just silent.
> Though I would have thought/hoped there must be a way to find the
> object reference even in a compiled frame?
Yes, if you deopt... I didn't want to go there.
> 195 // Print out all monitors that we have locked, are trying to lock
> 196 // or are trying to relock after a wait().
>
> that makes it sound like there are three cases when really a "relock"
> is just a specific case of lock. I would suggest:
>
> // Print out all monitors that we have locked, or are trying to
> // lock, including re-locking when returning from a wait().
Making it more clear that the "re-locking" is coming from "wait()"
is an improvement. I'll fix this.
> 252 lock_state = "waiting to relock";
>
> I prefer "waiting to re-lock in wait()", if that isn't too long.
> Otherwise "relock" needs to be a concept people are familiar with.
I like "waiting to re-lock in wait()".
> 260 if (VerboseStackTrace && mark != NULL) {
> 261 st->print("\t- lockbits=");
> 262 mark->print_on(st);
>
> This really doesn't seem to warrant a new diagnostic flag, regardless
> of whether we think applying -XX:+Verbose is a good fit or not.
I suspect that David C didn't want to change the default output format
and neither do I. We have some tests that try to parse out specific
things from thread dumps to verify certain bug fixes and we don't want
to break those. I'm thinking of the "duplicate owner" bug fix that we
fixed in thread dumps, but I can't pull up the bug ID (yet)...
Thanks for the thorough review. I have to say that I wasn't expecting
much comment on this review at all. :-)
Dan
>
> Thanks,
> David
> -------
>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8130448 8077392 inspired thread dump improvements, comment
>> additions, new diagnostics
>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>
>> Testing:
>>
>> - RBT vm.quick batches (in process)
>> - JPRT test jobs
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Gory details about the changes are below...
>>
>> Dan
>>
>> 8130448 summary of changes:
>>
>> src/cpu/x86/vm/macroAssembler_x86.cpp
>> - comment additions for the assembly code
>>
>> src/share/vm/oops/markOop.cpp
>> - has_monitor() has to be checked before is_locked() since
>> the has_monitor() bits are a superset of the is_locked() bits
>> - code style fixes
>>
>> src/share/vm/runtime/globals.hpp
>> - add VerboseStackTrace diagnostic option
>> - add GuaranteeOnMonitorMismatch diagnostic option
>> - add JavaThreadExitReleasesMonitors product option;
>> this is the Java equivalent of JNIDetachReleasesMonitors
>>
>> src/share/vm/runtime/objectMonitor.cpp
>> - delete unused ObjectMonitor::try_enter()
>> - fix assert wording
>>
>> src/share/vm/runtime/objectMonitor.hpp
>> - delete unused ObjectMonitor::try_enter()
>>
>> src/share/vm/runtime/synchronizer.cpp
>> - add GuaranteeOnMonitorMismatch support with some
>> diagnostic output
>>
>> src/share/vm/runtime/thread.cpp
>> - add JavaThreadExitReleasesMonitors support
>>
>> src/share/vm/runtime/vframe.cpp
>> - clarify existing comments
>> - add comments to clarify what "waiting on" means
>> - add line to show when we are "waiting on", but
>> there are no locals available (previously we were
>> "waiting on" silently)
>> - add support for "waiting to relock" which can happen
>> for any of the monitors and not just the top monitor
>> - switch mark->print_on() verbose output to new
>> VerboseStackTrace switch; thread dumps are not enabled
>> with a specific switch so the '-XX:+Verbose' model of
>> being a modifier for another option does not fit
From coleen.phillimore at oracle.com Mon Jul 6 21:00:48 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 06 Jul 2015 17:00:48 -0400
Subject: Runtime command-line deprecation (Was Re: RFR: 8066821(S) Enhance
command line processing to manage deprecating and obsoleting -XX
command line arguments
In-Reply-To: <87B07B03-3423-4738-9617-0C7B72A74A6E@oracle.com>
References: <54B44661.8070007@oracle.com>
<54B84E91.1050708@oracle.com> <54D15A0B.6030501@oracle.com>
<87B07B03-3423-4738-9617-0C7B72A74A6E@oracle.com>
Message-ID: <559AEC80.3010907@oracle.com>
Hi,
I'm happy for more clarity in the process of removing command line
arguments. I have some questions and comments below.
On 6/26/15 4:09 PM, Karen Kinnear wrote:
> Derek,
>
> I am really glad you are looking into this. I expanded this to the runtime folks in case many of them have not yet seen this.
> Mary just forwarded this and I believe you haven't checked it in yet, so perhaps still time to discuss and make sure
> we all are together on the deprecation policy.
>
> The runtime team was discussing at staff this week how we handle deprecating jvm command-line options as
> we are looking to do more clean up in the future.
>
> So our internal change control process classifies our exported interfaces into three categories:
> External: command-line flags e.g. -verbose:gc, -Xmx, ...
> This includes any commercial flags
> Private: -XX flags documented (e.g. performance tuning or troubleshooting)
> I would assume this would include -XX product, experimental flags and manageable flags
> Internal: undocumented -XX flags
> I would assume this would include -XX develop and diagnostic flags
>
> (please correct me if my assumptions are wrong folks)
This is a good categorization. Although I think there's some grey area
between External and Private, where some XX options are so commonly used
they should be considered External. Some of the GC options may fall
into this category like UseParNewGC.
>
> The way I understand that we handle private -XX options today is a 2-step removal: (obsolete_jvm_flags - where the
> release number is in a table and could be undefined)
>
> Using your helpful taxonomy from https://bugs.openjdk.java.net/browse/JDK-806682:
>
> Today: private -XX options use 2-step removal (obsolete_jvm_flags)
> release 1: Deprecate & Obsolete - warn about the option but do nothing with it (we can remove all code that supports it)
> release 2: Dead - unrecognized
> - the point of the 2-step is to give customers time to modify any scripts they use
>
> I believe we have very rarely removed External flags - since customers, licensees, etc. may expect them.
>
> Mini-proposal:
> 1) I would recommend that we add a future set of changes to add consistent handling for the External flags -
> so that they would follow a three-step removal:
> release 1: Deprecate & Handle - warn and keep supporting
> release 2: Deprecate & Obsolete - warn and do nothing
> release 3: Dead - unrecognized
>
> 2) For the Internal flags - I think it would be kindest to customers and not a huge amount of additional work if
> we were to follow the Private model of using a 2 step.
>
> 3) leave the Private flags with the current 2-step removal
Yes, this reflects our current model.
>
> 4) add support for aliasing - for any of them
> So that if you are doing aliasing, you would follow the model you are adding
> release 1: Deprecated & Handled - i.e. warn and still support (and set the information for the new alias)
> release 2: Dead - unrecognized
>
> 5) Could we possibly take the two flags that followed a different model already, i.e. moving to
> Deprecated & Handled and handle those as mistakes rather than part of a new general model?
So this is my question which is around the code review in question.
Note, Derek, can you resend the RFR to hotspot-dev at openjdk.java.net so
it gets to all of us (even the compiler team may want to share in the
mechanism).
Why are UseParNewGC and MaxGCMinorPauseMillis deprecated and handled and
not deprecated and obsolete? I don't actually see why have the
distinction here?
Did these flags follow the deprecation procedure below? Why not just
make them obsolete, why have this other mechanism? I may be asking the
same question as Karen.
I think the aliased flags could have a deprecate and handle model (where
handle == alias) in which case you only need one table for the aliased
flags, and you need to keep them in globals.hpp so they're parsed properly.
>
> Or do you think we will see more cases other than aliasing in which we would want to
> release 1: Deprecate & Handle and then release 2: Dead
> rather than release 1: Deprecate & Obsolete and then 2: Dead
> or rather than a 3 step like the External option proposal above?
I think for the aliased flags you want the first option here
(deprecate&handle), right? But that's only because you need to keep the
option in globals.hpp so it parses correctly, otherwise the second
option (deprecate&obsolete) would be the preference?
The options in the GC that are being deprecated and handled have had
warnings about them for a while, so making them obsolete doesn't feel
too soon.
Also, I agree with Kim's comment below that your comment lines are too
long. My fonts are too big to have windows this wide.
thanks,
Coleen
>
> thanks,
> Karen
>
> p.s. Note that all of the deprecation needs to
> 1) work with licensee engineering to ensure we give licensee's a head's up and get feedback
> 2) file a change control request
>
> - we try to do these both as bulk requests to reduce the processing overhead.
>
> p.p.s. Details
>
> 1. Do the warnings print today or are they silent? Just want to make sure we are conscious of how
> those are handled if any of this moves to the new unified logging mechanism for which the new default
> for "warning" level is to print.
>
> 2. "will likely be removed in a future release"? If we have already set the release it will be removed - is this a bit
> vague or did I not read closely enough?
>
>
>
> On Feb 3, 2015, at 6:30 PM, Derek White wrote:
>
>> Request for review (again):
>>
>> - Updated with Kim's suggestion.
>> - Stopped double-printing warnings in some cases.
>> - Initial caps on warning() messages.
>>
>> Webrev: http://cr.openjdk.java.net/~drwhite/8066821/webrev.04/
>> CR: https://bugs.openjdk.java.net/browse/JDK-8066821
>> Tests: jtreg, jprt
>>
>> Thanks for looking!
>>
>> - Derek
>>
>> On 1/28/15 3:47 PM, Kim Barrett wrote:
>>> On Jan 15, 2015, at 6:34 PM, Derek White wrote:
>>>> Hi All,
>>>>
>>>> I need another review, especially someone from runtime. Coleen, do you want crack at it or can you forward as needed?
>>>>
>>>> Another version for review:
>>>> http://cr.openjdk.java.net/~drwhite/8066821/webrev.01
>>> I noticed a bunch of formatting changes that were in the previous
>>> webrev have been eliminated in the .01 webrev. Since I was going to
>>> comment or complain about at least some of them, I have no objection
>>> to having them backed out.
>>>
>>> This is not a complete review; I've only gotten part way through the
>>> first file! Unfortunately, I'm swamped with other things right now
>>> and don't seem to be making progress toward finishing. So here's what
>>> I've got so far.
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 132 int len = (int)strlen(name);
>>>
>>> Pre-existing issue.
>>>
>>> Why is this using int and casting to int, rather than just using
>>> size_t? The return type for strlen is size_t, as is the argument for
>>> strncmp where len is used, and the other use of len also can/should be
>>> size_t.
>>>
>>> [I only noticed this because an earlier webrev tweaked the formatting
>>> of this line.]
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 235 const char* spec_vendor = "Sun Microsystems Inc.";
>>> 236 uint32_t spec_version = 0;
>>>
>>> Dead initializers; the variables are immediately reassigned new
>>> values.
>>>
>>> This is a pre-existing defect that I wouldn't have even noticed had
>>> the enum for bufsz not been reformatted in a previous webrev. (How's
>>> that for a lesson in being lazy. :-)
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 253 * -XX arguments are usually defined in globals.hpp, globals_.hpp, globals_.hpp, _globals.hpp, or _globals.hpp.
>>>
>>> Rather than "are usually defined in" I think better would be something
>>> like "are defined several places, such as".
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 251 * -XX argument processing:
>>>
>>> While the Hotspot style guidelines explicitly don't specify a line
>>> length limit, I find lines that are long enough that they don't fit in
>>> one side of a side-by-side webrev on a reasonable-sized landscape
>>> monitor with a font size I can read without having to scroll the frame
>>> back and forth to be pretty annoying.
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 419 if (((strncmp(flag_status.name, s, len) == 0) &&
>>> 420 (strlen(s) == len)) ||
>>> 421 ((s[0] == '+' || s[0] == '-') &&
>>> 422 (strncmp(flag_status.name, &s[1], len) == 0) &&
>>> 423 (strlen(&s[1]) == len))) {
>>>
>>> Pre-existing issue.
>>>
>>> The calls to strlen and comparisons to len on lines 420 and 423 could
>>> be replaced with
>>>
>>> 420: s[len] == '\0'
>>>
>>> 423: s[len+1] == '\0'
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 449 size_t len = strlen(flag_status.alias_name);
>>> 450 if (((strncmp(flag_status.alias_name, flag_name, len) == 0) &&
>>> 451 (strlen(flag_name) == len))) {
>>>
>>> There is no point to using strlen() and strncmp() here. Just use
>>> strcmp(), e.g.
>>>
>>> if (strcmp(flag_status.alias_name, flag_name) == 0) {
>>>
>>> http://stackoverflow.com/questions/14885000/does-strlen-in-a-strncmp-expression-defeat-the-purpose-of-using-strncmp-ov
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 412 int i = 0;
>>> 413 assert(version != NULL, "Must provide a version buffer");
>>> 414 while (special_table[i].name != NULL) {
>>> ...
>>> 432 i++;
>>>
>>> Pre-existing issue.
>>>
>>> More readable would be to use a for-loop, e.g.
>>>
>>> for (size_t i = 0; special_table[i].name != NULL; ++i) {
>>> ...
>>> }
>>>
>>> size_t is a better type for i too.
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/runtime/arguments.cpp
>>> 446 int i = 0;
>>> 447 while (aliased_jvm_flags[i].alias_name != NULL) {
>>> ...
>>> 454 i++;
>>>
>>> As above, a for-loop would be more readable.
>>>
>>> ------------------------------------------------------------------------------
>>>
From david.holmes at oracle.com Tue Jul 7 07:11:38 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Jul 2015 17:11:38 +1000
Subject: RFR(S) 8130448: thread dump improvements, comment, additions, new
diagnostics inspired by 8077392
In-Reply-To: <559AE96D.6010508@oracle.com>
References: <55972558.6060905@oracle.com> <559A2397.2010409@oracle.com>
<559AE96D.6010508@oracle.com>
Message-ID: <559B7BAA.8070705@oracle.com>
Hi Dan,
Top posting as I'm lazy and running late :)
Okay ... I'm still uneasy about adding two additional flags for the
"release monitors on exit" situation. I hear what you are saying about
the cost of the monitor check - I had thought we kept easy access to the
set of monitors owned by a thread but it seems not, so trawling the
global monitor list is indeed an expensive operation. :( So okay but I
don't like it :)
I also take your point about viewing the new flag as a superset of the
JNI-detach case. That's fair enough, but of course that aspect needs to
be documented.
I was left unclear about your position on the VerboseStackTrace. I agree
the new output was likely put under a flag to avoid disturbing existing
output formats. But I don't see that it warrants its own flag - to me
using Verbose okay (though the fact it is a develop flag is limiting).
Thanks,
David
On 7/07/2015 6:47 AM, Daniel D. Daugherty wrote:
> On 7/6/15 12:43 AM, David Holmes wrote:
>> Hi Dan,
>>
>> Metacomment: Could I suggest that in a RFR your subject line has the
>> form : , rather than (bugid) - especially
>> when the synopsis actually starts with a bug id :) Thanks.
>
> Yup that bug synopsis is/was a mess:
>
> Changed the synopsis line to :
>
> thread dump improvements, comment additions, new diagnostics
> inspired by 8077392
>
> Also updated the e-mail thread subject line to your suggested format.
> Will try to remember to switch to that style in the future.
>
>
>> Mostly okay but some major concerns around the can of worms that
>> JavaThreadExitReleasesMonitors opens up.
>
> This is Java monitors so "can of worms" is familiar! :-)
>
>
>>
>> On 4/07/2015 10:14 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> The hunt for the following bug:
>>>
>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>
>>> and David C's work on the following bug:
>>>
>>> JDK-8069412 Locks need better debug-printing support
>>>
>>> have inspired additional thread dump improvements, comment additions
>>> to some Java monitor code and some new diagnostic options.
>>
>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>
>> 1821 // update _owner from from BasicLock to thread
>>
>> Typo: from from
>
> Will fix.
>
>
>> 2091 // the placeholder value. If that didn't work, then another
>> 2092 // grabbed the lock so we're done (and exit was a success).
>>
>> another -> another thread ?
>
> Yes, "another thread" is better. Will fix.
>
>
>> 2201 // If that didn't work, then another grabbed the lock
>> 2202 // so we're done (and exit was a success).
>>
>> another -> another thread ?
>
> Yes, "another thread" is better. Will fix.
>
>
>> ---
>>
>> src/share/vm/oops/markOop.cpp
>>
>> 40 st->print("NULL"); // this should not happen
>>
>> Shouldn't that be an assert or guarantee in that case? Or at a minimum
>> print something like: "NULL (but you should never see this!)"
>
> This is a relocated line from David C's change:
>
> old 49: st->print("monitor=NULL");
>
> I simply added a comment to it. I don't think I like the idea of the
> thread dump code assert()'ing or guarantee()'ing because there might
> be other useful info that would have been printed after the assert()
> or guarantee() failure.
>
> I do like the idea of changing the message to:
>
> 40: st->print("NULL (this should never be seen!)");
>
>
>> 42 BasicLock * bl = (BasicLock *) mon->owner();
>>
>> What information has told us this is a BasicLock* not a Thread* ? But
>> as all you do is print bl why not just p2i(mon->owner()) ?
>
> Again, this is a relocated line from David C's change:
>
> old 51: BasicLock * bl = (BasicLock *) mon->owner();
>
> I'm going to guess that David C had some other code in there before
> that needed/assumed that the field is a "BasicLock *", but that code
> didn't make it into his final version.
>
> I will drop the 'bl' local and update the p2i() call to use
> mon->owner() directly.
>
>
>> ---
>>
>> src/share/vm/runtime/globals.hpp
>>
>> JavaThreadExitReleasesMonitors has me perplexed. The JNI DetachThread
>> case seems to be a concession to badly written code that fails to
>> release locks on error paths.
>
> I don't think I would call the JNIDetachReleasesMonitors case a concession
> to badly written JNI code. 6282335 is very clear that this code was added
> to meet the JNI spec. The JNI spec words might be considered a
> concession...
>
> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#DetachCurrentThread
>
>
> > DetachCurrentThread
> >
> > jint DetachCurrentThread(JavaVM *vm);
> >
> > Detaches the current thread from a Java VM. All Java monitors
> > held by this thread are released. All Java threads waiting for
> > this thread to die are notified.
> >
> > The main thread can be detached from the VM.
>
>
>
>> The equivalent for a Java thread would again involve lock acquisition
>> via JNI. But I don't recall ever seeing a bug report or RFE related to
>> this. What seems to have motivated this new flag is the potential for
>> a broken VM to actually leave the monitor locked (e.g. because
>> compiled code failed to do the unlock on all paths).
>
> 8077392 and bugs like it are exactly the reason for adding these
> two options.
>
> JavaThreadExitReleasesMonitors is added to provide a work around
> until the underlying bug or bugs are fixed. This option is targeted
> at folks that are chasing their own bugs and don't care about this
> one.
>
> GuaranteeOnMonitorMismatch is added to help hunt 8077392 specifically
> and to sanity check for similar issues generally. I can see using the
> two options in combination with existing test suites as a stress test
> for the Java monitor subsystem.
>
>
>> To address that I'd be inclined to simply have a guarantee in the Java
>> thread exit path, rather than a flag to do the clean up and another
>> flag to control a guarantee.
>
> The check for an unexited Java monitor is not cheap.
>
> The existing check under the JNIDetachReleasesMonitors flag is
> positioned to only affect threads using JNI DetachCurrentThread()
> and that cost is justified as part of meeting the JNI spec.
>
> Adding the unexited Java monitor check to all exiting Java
> threads should not be done lightly due to the cost. If the
> VM is functioning correctly, then why impose this cost on
> all exiting Java threads?
>
>
>> I don't think two new command-line options (has this gone through CCC
>> yet?) are justified.
>
> No, this has not gone through CCC yet. My preference is to get
> code review feedback (like this) before submitting a CCC.
>
> I suppose I could have simply added more sub-options to the
> existing Java monitor subsystem knobs and switches, but it
> seemed to make sense to model JavaThreadExitReleasesMonitors
> on the existing JNIDetachReleasesMonitors.
>
>
>> Also note that allowing for JVM induced missing unlocks is something
>> that can affect JNI attached threads as well as regular Java threads.
>> I'll take this up in discussing thread.cpp below.
>>
>> That aside, the comment, which was modelled on the JNI DetachThread
>> variant, does not really work in this case:
>>
>> 2801 "JavaThread exit() releases monitors owned by thread")
>> \
>>
>> JavaThread is not a programming concept but an internal JVM
>> abstraction. I would suggest something like:
>>
>> "Java thread termination releases monitors unexpectedly still owned by
>> thread"
>
> I'll switch to your description text if we end up keeping the
> new options.
>
>
>> ---
>>
>> src/share/vm/runtime/objectMonitor.cpp
>> src/share/vm/runtime/objectMonitor.hpp
>>
>> No comments
>>
>> ---
>>
>> src/share/vm/runtime/synchronizer.cpp
>>
>> If we find the unexpected locked monitor it would be useful to see
>> more Java level information about the Thread (in the non-detaching
>> case) and the object that is locked.
>
> I can probably steal some code from the thread dump side to
> give us more info about the Object associated with the Java
> monitor...
>
>
>> ---
>>
>> src/share/vm/runtime/thread.cpp
>>
>> As noted previously JNI attached threads can also be affected by JVM
>> induced locking bugs. So the comment block:
>>
>> 1804 // 6282335 JNI DetachCurrentThread spec states that all Java
>> monitors
>> 1805 // held by this thread must be released. A detach operation
>> must only
>> 1806 // get here if there are no Java frames on the stack.
>> Therefore, any
>> 1807 // owned monitors at this point MUST be JNI-acquired monitors
>> which are
>> 1808 // pre-inflated and in the monitor cache.
>>
>> is not strictly correct as it is presuming a correctly operating JVM.
>
> I actually disagree with the last two sentences in that comment block,
> but I didn't have a good rewrite in mind. I'll think about it more.
>
>
>
>> Further the logic now applied:
>>
>> 1816 if ((exit_type == jni_detach && JNIDetachReleasesMonitors) ||
>> 1817 JavaThreadExitReleasesMonitors) {
>>
>> is also not "correct" because if we have
>> JavaThreadExitReleasesMonitors true while JNIDetachReleasesMonitors is
>> false, we will in fact release any JNI acquired monitors because we
>> can't make the distinction.
>
> I don't think JNIDetachReleasesMonitors only has to deal with JNI-acquired
> monitors and I don't think that JavaThreadExitReleasesMonitors only has to
> deal with Java code acquired monitors. I see these options as applying to
> "how you got to the Java thread exit path" and not applying to "what needs
> to be cleaned up".
>
> I see JNIDetachReleasesMonitors as a way of cleaning up unexited Java
> monitors when we're executing the JNI DetachCurrentThread() code path.
> I don't really care why the Java monitors are unexited... and I think
> the spec wording is clear that all unexited Java monitors are cleaned
> up... not just JNI-acquired monitors.
>
> I see JavaThreadExitReleasesMonitors as a way of cleaning up unexited
> Java monitors in any code path where we are exiting the Java thread. I see
> JavaThreadExitReleasesMonitors as a superset of JNIDetachReleasesMonitors.
>
>
>> Given we can't make the distinction I don't see any way for these
>> separate flags to actually work well together.
>
> I think they work well together when JavaThreadExitReleasesMonitors
> is seen as a superset of JNIDetachReleasesMonitors. Of course, that
> hinges on my opinion that JNIDetachReleasesMonitors applies to any
> unexited Java monitor and not just JNI-acquired Java monitors.
>
>
>> As I said above I'm more inclined to just add a guarantee to the
>> non-detach case, than add two new flags. (Even though this means there
>> won't be detection for such bugs when JNI attached threads encounter
>> them - including the main thread :( ).
>
> I really don't want to add this check to all Java thread exit
> paths since it is expensive.
>
>
>> As I said this has me perplexed. :(
>
> Hopefully, I've explained it better now.
>
>
>> ---
>>
>> src/share/vm/runtime/vframe.cpp
>>
>> 170 // It would be nice to distinguish between "waiting on" and
>> 171 // "waited on". Currently, "waiting on" here with a
>> 172 // java.lang.Thread.State == "WAITING (on object monitor)"
>> 173 // earlier in the output means that the monitor has not yet
>> been
>> 174 // notified and java.lang.Thread.State == "BLOCKED (on object
>> 175 // monitor)" earlier in the output means that the monitor has
>> 176 // been notified and the thread is blocked on reentry.
>>
>> That's a very long sentence that can be quite difficult to parse and
>> could probably be reworded to describe how the output should be
>> interpreted eg:
>>
>> // If earlier in the output we reported java.lang.Thread.State ==
>> // "WAITING (on object monitor)" and now we report "waited on", then
>> // we are still waiting for notification [or timeout?]. Otherwise if
>> // we earlier reported java.lang.Thread.State == "BLOCKED (on object
>> // monitor)", then we are actually waiting to reacquire the monitor
>> // lock. At this level we can't distinguish the two cases to report
>> // "waited on" rather than "waiting on" for the second case.
>
> I'll take a look at rewriting the comment and may just take your
> version entirely.
>
>
>> I wonder if we can prod deeper into VM state to try and make the
>> distinction?
>
> I played around with doing just that, but it seems like the M&M
> code that fetches similar state probes the state stored in the
> java.lang.Thread object. I didn't want to go there.
>
>
>>
>> 184 } else {
>> 185 st->print_cr("\t- %s ", wait_state);
>>
>> The concept of "locals" is confusing here. Isn't the "local" in this
>> case just the object that we have waited upon? In which case we should
>> say "no object reference available".
>
> I got the phrase "locals" from the compiler code that was trying to
> decode the object reference. I can change to "no object reference
> available".
> I definitely want to say _something_ here. The existing code is just
> silent.
>
>
>> Though I would have thought/hoped there must be a way to find the
>> object reference even in a compiled frame?
>
> Yes, if you deopt... I didn't want to go there.
>
>
>> 195 // Print out all monitors that we have locked, are trying to lock
>> 196 // or are trying to relock after a wait().
>>
>> that makes it sound like there are three cases when really a "relock"
>> is just a specific case of lock. I would suggest:
>>
>> // Print out all monitors that we have locked, or are trying to
>> // lock, including re-locking when returning from a wait().
>
> Making it more clear that the "re-locking" is coming from "wait()"
> is an improvement. I'll fix this.
>
>
>> 252 lock_state = "waiting to relock";
>>
>> I prefer "waiting to re-lock in wait()", if that isn't too long.
>> Otherwise "relock" needs to be a concept people are familiar with.
>
> I like "waiting to re-lock in wait()".
>
>
>> 260 if (VerboseStackTrace && mark != NULL) {
>> 261 st->print("\t- lockbits=");
>> 262 mark->print_on(st);
>>
>> This really doesn't seem to warrant a new diagnostic flag, regardless
>> of whether we think applying -XX:+Verbose is a good fit or not.
>
> I suspect that David C didn't want to change the default output format
> and neither do I. We have some tests that try to parse out specific
> things from thread dumps to verify certain bug fixes and we don't want
> to break those. I'm thinking of the "duplicate owner" bug fix that we
> fixed in thread dumps, but I can't pull up the bug ID (yet)...
>
> Thanks for the thorough review. I have to say that I wasn't expecting
> much comment on this review at all. :-)
>
>
> Dan
>
>
>>
>> Thanks,
>> David
>> -------
>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>> additions, new diagnostics
>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>
>>> Testing:
>>>
>>> - RBT vm.quick batches (in process)
>>> - JPRT test jobs
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>> 8130448 summary of changes:
>>>
>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>> - comment additions for the assembly code
>>>
>>> src/share/vm/oops/markOop.cpp
>>> - has_monitor() has to be checked before is_locked() since
>>> the has_monitor() bits are a superset of the is_locked() bits
>>> - code style fixes
>>>
>>> src/share/vm/runtime/globals.hpp
>>> - add VerboseStackTrace diagnostic option
>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>> - add JavaThreadExitReleasesMonitors product option;
>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>> - delete unused ObjectMonitor::try_enter()
>>> - fix assert wording
>>>
>>> src/share/vm/runtime/objectMonitor.hpp
>>> - delete unused ObjectMonitor::try_enter()
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>> - add GuaranteeOnMonitorMismatch support with some
>>> diagnostic output
>>>
>>> src/share/vm/runtime/thread.cpp
>>> - add JavaThreadExitReleasesMonitors support
>>>
>>> src/share/vm/runtime/vframe.cpp
>>> - clarify existing comments
>>> - add comments to clarify what "waiting on" means
>>> - add line to show when we are "waiting on", but
>>> there are no locals available (previously we were
>>> "waiting on" silently)
>>> - add support for "waiting to relock" which can happen
>>> for any of the monitors and not just the top monitor
>>> - switch mark->print_on() verbose output to new
>>> VerboseStackTrace switch; thread dumps are not enabled
>>> with a specific switch so the '-XX:+Verbose' model of
>>> being a modifier for another option does not fit
>
From daniel.daugherty at oracle.com Tue Jul 7 17:28:45 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 07 Jul 2015 11:28:45 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559B7BAA.8070705@oracle.com>
References: <55972558.6060905@oracle.com> <559A2397.2010409@oracle.com>
<559AE96D.6010508@oracle.com> <559B7BAA.8070705@oracle.com>
Message-ID: <559C0C4D.8090504@oracle.com>
On 7/7/15 1:11 AM, David Holmes wrote:
> Hi Dan,
>
> Top posting as I'm lazy and running late :)
No problem with the top posting. It makes your remaining
concerns earlier to see and address.
> Okay ... I'm still uneasy about adding two additional flags for the
> "release monitors on exit" situation. I hear what you are saying about
> the cost of the monitor check - I had thought we kept easy access to
> the set of monitors owned by a thread but it seems not, so trawling
> the global monitor list is indeed an expensive operation. :( So okay
> but I don't like it :)
Since JavaThreadExitReleasesMonitors and GuaranteeOnMonitorMismatch
are targeted at finding/working around bugs in the Java Monitor
implementation, I'm going to take a look at moving the flag support
down into Java Monitor subsystem's implementation specific options.
That will get the options out of the global space and they won't
have to be counted against the "cap and trade" limit :-)
> I also take your point about viewing the new flag as a superset of the
> JNI-detach case. That's fair enough, but of course that aspect needs
> to be documented.
I'm starting to wonder why we have the 'JNIDetachReleasesMonitors'
option at all. Is there a good reason to be able to turn off this
piece of code?
> I was left unclear about your position on the VerboseStackTrace. I
> agree the new output was likely put under a flag to avoid disturbing
> existing output formats. But I don't see that it warrants its own flag
> - to me using Verbose okay (though the fact it is a develop flag is
> limiting).
Thanks for reminding me that '-XX:+Verbose' is a develop flag.
That's another reason for not using that flag. Combined with
the fact that '-XX:+Verbose' is considered a modifier to other
flags and thread dumps aren't enabled/triggered by a flag means
(to me anyway) that '-XX:+Verbose' is still not a good match.
However, I have a vague memory that the Java Monitor subsystem
has its own "verbose" flag. I'll take a look at switching to
that...
Will be working on the next round...
Dan
>
> Thanks,
> David
>
> On 7/07/2015 6:47 AM, Daniel D. Daugherty wrote:
>> On 7/6/15 12:43 AM, David Holmes wrote:
>>> Hi Dan,
>>>
>>> Metacomment: Could I suggest that in a RFR your subject line has the
>>> form : , rather than (bugid) - especially
>>> when the synopsis actually starts with a bug id :) Thanks.
>>
>> Yup that bug synopsis is/was a mess:
>>
>> Changed the synopsis line to :
>>
>> thread dump improvements, comment additions, new diagnostics
>> inspired by 8077392
>>
>> Also updated the e-mail thread subject line to your suggested format.
>> Will try to remember to switch to that style in the future.
>>
>>
>>> Mostly okay but some major concerns around the can of worms that
>>> JavaThreadExitReleasesMonitors opens up.
>>
>> This is Java monitors so "can of worms" is familiar! :-)
>>
>>
>>>
>>> On 4/07/2015 10:14 AM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> The hunt for the following bug:
>>>>
>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>
>>>> and David C's work on the following bug:
>>>>
>>>> JDK-8069412 Locks need better debug-printing support
>>>>
>>>> have inspired additional thread dump improvements, comment additions
>>>> to some Java monitor code and some new diagnostic options.
>>>
>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>
>>> 1821 // update _owner from from BasicLock to thread
>>>
>>> Typo: from from
>>
>> Will fix.
>>
>>
>>> 2091 // the placeholder value. If that didn't work, then another
>>> 2092 // grabbed the lock so we're done (and exit was a success).
>>>
>>> another -> another thread ?
>>
>> Yes, "another thread" is better. Will fix.
>>
>>
>>> 2201 // If that didn't work, then another grabbed the lock
>>> 2202 // so we're done (and exit was a success).
>>>
>>> another -> another thread ?
>>
>> Yes, "another thread" is better. Will fix.
>>
>>
>>> ---
>>>
>>> src/share/vm/oops/markOop.cpp
>>>
>>> 40 st->print("NULL"); // this should not happen
>>>
>>> Shouldn't that be an assert or guarantee in that case? Or at a minimum
>>> print something like: "NULL (but you should never see this!)"
>>
>> This is a relocated line from David C's change:
>>
>> old 49: st->print("monitor=NULL");
>>
>> I simply added a comment to it. I don't think I like the idea of the
>> thread dump code assert()'ing or guarantee()'ing because there might
>> be other useful info that would have been printed after the assert()
>> or guarantee() failure.
>>
>> I do like the idea of changing the message to:
>>
>> 40: st->print("NULL (this should never be seen!)");
>>
>>
>>> 42 BasicLock * bl = (BasicLock *) mon->owner();
>>>
>>> What information has told us this is a BasicLock* not a Thread* ? But
>>> as all you do is print bl why not just p2i(mon->owner()) ?
>>
>> Again, this is a relocated line from David C's change:
>>
>> old 51: BasicLock * bl = (BasicLock *) mon->owner();
>>
>> I'm going to guess that David C had some other code in there before
>> that needed/assumed that the field is a "BasicLock *", but that code
>> didn't make it into his final version.
>>
>> I will drop the 'bl' local and update the p2i() call to use
>> mon->owner() directly.
>>
>>
>>> ---
>>>
>>> src/share/vm/runtime/globals.hpp
>>>
>>> JavaThreadExitReleasesMonitors has me perplexed. The JNI DetachThread
>>> case seems to be a concession to badly written code that fails to
>>> release locks on error paths.
>>
>> I don't think I would call the JNIDetachReleasesMonitors case a
>> concession
>> to badly written JNI code. 6282335 is very clear that this code was
>> added
>> to meet the JNI spec. The JNI spec words might be considered a
>> concession...
>>
>> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#DetachCurrentThread
>>
>>
>>
>> > DetachCurrentThread
>> >
>> > jint DetachCurrentThread(JavaVM *vm);
>> >
>> > Detaches the current thread from a Java VM. All Java monitors
>> > held by this thread are released. All Java threads waiting for
>> > this thread to die are notified.
>> >
>> > The main thread can be detached from the VM.
>>
>>
>>
>>> The equivalent for a Java thread would again involve lock acquisition
>>> via JNI. But I don't recall ever seeing a bug report or RFE related to
>>> this. What seems to have motivated this new flag is the potential for
>>> a broken VM to actually leave the monitor locked (e.g. because
>>> compiled code failed to do the unlock on all paths).
>>
>> 8077392 and bugs like it are exactly the reason for adding these
>> two options.
>>
>> JavaThreadExitReleasesMonitors is added to provide a work around
>> until the underlying bug or bugs are fixed. This option is targeted
>> at folks that are chasing their own bugs and don't care about this
>> one.
>>
>> GuaranteeOnMonitorMismatch is added to help hunt 8077392 specifically
>> and to sanity check for similar issues generally. I can see using the
>> two options in combination with existing test suites as a stress test
>> for the Java monitor subsystem.
>>
>>
>>> To address that I'd be inclined to simply have a guarantee in the Java
>>> thread exit path, rather than a flag to do the clean up and another
>>> flag to control a guarantee.
>>
>> The check for an unexited Java monitor is not cheap.
>>
>> The existing check under the JNIDetachReleasesMonitors flag is
>> positioned to only affect threads using JNI DetachCurrentThread()
>> and that cost is justified as part of meeting the JNI spec.
>>
>> Adding the unexited Java monitor check to all exiting Java
>> threads should not be done lightly due to the cost. If the
>> VM is functioning correctly, then why impose this cost on
>> all exiting Java threads?
>>
>>
>>> I don't think two new command-line options (has this gone through CCC
>>> yet?) are justified.
>>
>> No, this has not gone through CCC yet. My preference is to get
>> code review feedback (like this) before submitting a CCC.
>>
>> I suppose I could have simply added more sub-options to the
>> existing Java monitor subsystem knobs and switches, but it
>> seemed to make sense to model JavaThreadExitReleasesMonitors
>> on the existing JNIDetachReleasesMonitors.
>>
>>
>>> Also note that allowing for JVM induced missing unlocks is something
>>> that can affect JNI attached threads as well as regular Java threads.
>>> I'll take this up in discussing thread.cpp below.
>>>
>>> That aside, the comment, which was modelled on the JNI DetachThread
>>> variant, does not really work in this case:
>>>
>>> 2801 "JavaThread exit() releases monitors owned by thread")
>>> \
>>>
>>> JavaThread is not a programming concept but an internal JVM
>>> abstraction. I would suggest something like:
>>>
>>> "Java thread termination releases monitors unexpectedly still owned by
>>> thread"
>>
>> I'll switch to your description text if we end up keeping the
>> new options.
>>
>>
>>> ---
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>> src/share/vm/runtime/objectMonitor.hpp
>>>
>>> No comments
>>>
>>> ---
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>>
>>> If we find the unexpected locked monitor it would be useful to see
>>> more Java level information about the Thread (in the non-detaching
>>> case) and the object that is locked.
>>
>> I can probably steal some code from the thread dump side to
>> give us more info about the Object associated with the Java
>> monitor...
>>
>>
>>> ---
>>>
>>> src/share/vm/runtime/thread.cpp
>>>
>>> As noted previously JNI attached threads can also be affected by JVM
>>> induced locking bugs. So the comment block:
>>>
>>> 1804 // 6282335 JNI DetachCurrentThread spec states that all Java
>>> monitors
>>> 1805 // held by this thread must be released. A detach operation
>>> must only
>>> 1806 // get here if there are no Java frames on the stack.
>>> Therefore, any
>>> 1807 // owned monitors at this point MUST be JNI-acquired monitors
>>> which are
>>> 1808 // pre-inflated and in the monitor cache.
>>>
>>> is not strictly correct as it is presuming a correctly operating JVM.
>>
>> I actually disagree with the last two sentences in that comment block,
>> but I didn't have a good rewrite in mind. I'll think about it more.
>>
>>
>>
>>> Further the logic now applied:
>>>
>>> 1816 if ((exit_type == jni_detach && JNIDetachReleasesMonitors) ||
>>> 1817 JavaThreadExitReleasesMonitors) {
>>>
>>> is also not "correct" because if we have
>>> JavaThreadExitReleasesMonitors true while JNIDetachReleasesMonitors is
>>> false, we will in fact release any JNI acquired monitors because we
>>> can't make the distinction.
>>
>> I don't think JNIDetachReleasesMonitors only has to deal with
>> JNI-acquired
>> monitors and I don't think that JavaThreadExitReleasesMonitors only
>> has to
>> deal with Java code acquired monitors. I see these options as
>> applying to
>> "how you got to the Java thread exit path" and not applying to "what
>> needs
>> to be cleaned up".
>>
>> I see JNIDetachReleasesMonitors as a way of cleaning up unexited Java
>> monitors when we're executing the JNI DetachCurrentThread() code path.
>> I don't really care why the Java monitors are unexited... and I think
>> the spec wording is clear that all unexited Java monitors are cleaned
>> up... not just JNI-acquired monitors.
>>
>> I see JavaThreadExitReleasesMonitors as a way of cleaning up unexited
>> Java monitors in any code path where we are exiting the Java thread.
>> I see
>> JavaThreadExitReleasesMonitors as a superset of
>> JNIDetachReleasesMonitors.
>>
>>
>>> Given we can't make the distinction I don't see any way for these
>>> separate flags to actually work well together.
>>
>> I think they work well together when JavaThreadExitReleasesMonitors
>> is seen as a superset of JNIDetachReleasesMonitors. Of course, that
>> hinges on my opinion that JNIDetachReleasesMonitors applies to any
>> unexited Java monitor and not just JNI-acquired Java monitors.
>>
>>
>>> As I said above I'm more inclined to just add a guarantee to the
>>> non-detach case, than add two new flags. (Even though this means there
>>> won't be detection for such bugs when JNI attached threads encounter
>>> them - including the main thread :( ).
>>
>> I really don't want to add this check to all Java thread exit
>> paths since it is expensive.
>>
>>
>>> As I said this has me perplexed. :(
>>
>> Hopefully, I've explained it better now.
>>
>>
>>> ---
>>>
>>> src/share/vm/runtime/vframe.cpp
>>>
>>> 170 // It would be nice to distinguish between "waiting on" and
>>> 171 // "waited on". Currently, "waiting on" here with a
>>> 172 // java.lang.Thread.State == "WAITING (on object monitor)"
>>> 173 // earlier in the output means that the monitor has not yet
>>> been
>>> 174 // notified and java.lang.Thread.State == "BLOCKED (on object
>>> 175 // monitor)" earlier in the output means that the monitor has
>>> 176 // been notified and the thread is blocked on reentry.
>>>
>>> That's a very long sentence that can be quite difficult to parse and
>>> could probably be reworded to describe how the output should be
>>> interpreted eg:
>>>
>>> // If earlier in the output we reported java.lang.Thread.State ==
>>> // "WAITING (on object monitor)" and now we report "waited on", then
>>> // we are still waiting for notification [or timeout?]. Otherwise if
>>> // we earlier reported java.lang.Thread.State == "BLOCKED (on object
>>> // monitor)", then we are actually waiting to reacquire the monitor
>>> // lock. At this level we can't distinguish the two cases to report
>>> // "waited on" rather than "waiting on" for the second case.
>>
>> I'll take a look at rewriting the comment and may just take your
>> version entirely.
>>
>>
>>> I wonder if we can prod deeper into VM state to try and make the
>>> distinction?
>>
>> I played around with doing just that, but it seems like the M&M
>> code that fetches similar state probes the state stored in the
>> java.lang.Thread object. I didn't want to go there.
>>
>>
>>>
>>> 184 } else {
>>> 185 st->print_cr("\t- %s ", wait_state);
>>>
>>> The concept of "locals" is confusing here. Isn't the "local" in this
>>> case just the object that we have waited upon? In which case we should
>>> say "no object reference available".
>>
>> I got the phrase "locals" from the compiler code that was trying to
>> decode the object reference. I can change to "no object reference
>> available".
>> I definitely want to say _something_ here. The existing code is just
>> silent.
>>
>>
>>> Though I would have thought/hoped there must be a way to find the
>>> object reference even in a compiled frame?
>>
>> Yes, if you deopt... I didn't want to go there.
>>
>>
>>> 195 // Print out all monitors that we have locked, are trying to lock
>>> 196 // or are trying to relock after a wait().
>>>
>>> that makes it sound like there are three cases when really a "relock"
>>> is just a specific case of lock. I would suggest:
>>>
>>> // Print out all monitors that we have locked, or are trying to
>>> // lock, including re-locking when returning from a wait().
>>
>> Making it more clear that the "re-locking" is coming from "wait()"
>> is an improvement. I'll fix this.
>>
>>
>>> 252 lock_state = "waiting to relock";
>>>
>>> I prefer "waiting to re-lock in wait()", if that isn't too long.
>>> Otherwise "relock" needs to be a concept people are familiar with.
>>
>> I like "waiting to re-lock in wait()".
>>
>>
>>> 260 if (VerboseStackTrace && mark != NULL) {
>>> 261 st->print("\t- lockbits=");
>>> 262 mark->print_on(st);
>>>
>>> This really doesn't seem to warrant a new diagnostic flag, regardless
>>> of whether we think applying -XX:+Verbose is a good fit or not.
>>
>> I suspect that David C didn't want to change the default output format
>> and neither do I. We have some tests that try to parse out specific
>> things from thread dumps to verify certain bug fixes and we don't want
>> to break those. I'm thinking of the "duplicate owner" bug fix that we
>> fixed in thread dumps, but I can't pull up the bug ID (yet)...
>>
>> Thanks for the thorough review. I have to say that I wasn't expecting
>> much comment on this review at all. :-)
>>
>>
>> Dan
>>
>>
>>>
>>> Thanks,
>>> David
>>> -------
>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>> additions, new diagnostics
>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>
>>>> Testing:
>>>>
>>>> - RBT vm.quick batches (in process)
>>>> - JPRT test jobs
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Gory details about the changes are below...
>>>>
>>>> Dan
>>>>
>>>> 8130448 summary of changes:
>>>>
>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>> - comment additions for the assembly code
>>>>
>>>> src/share/vm/oops/markOop.cpp
>>>> - has_monitor() has to be checked before is_locked() since
>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>> - code style fixes
>>>>
>>>> src/share/vm/runtime/globals.hpp
>>>> - add VerboseStackTrace diagnostic option
>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>> - add JavaThreadExitReleasesMonitors product option;
>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>> - delete unused ObjectMonitor::try_enter()
>>>> - fix assert wording
>>>>
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>> - delete unused ObjectMonitor::try_enter()
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>> - add GuaranteeOnMonitorMismatch support with some
>>>> diagnostic output
>>>>
>>>> src/share/vm/runtime/thread.cpp
>>>> - add JavaThreadExitReleasesMonitors support
>>>>
>>>> src/share/vm/runtime/vframe.cpp
>>>> - clarify existing comments
>>>> - add comments to clarify what "waiting on" means
>>>> - add line to show when we are "waiting on", but
>>>> there are no locals available (previously we were
>>>> "waiting on" silently)
>>>> - add support for "waiting to relock" which can happen
>>>> for any of the monitors and not just the top monitor
>>>> - switch mark->print_on() verbose output to new
>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>> with a specific switch so the '-XX:+Verbose' model of
>>>> being a modifier for another option does not fit
>>
From david.holmes at oracle.com Tue Jul 7 23:18:57 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 8 Jul 2015 09:18:57 +1000
Subject: [8u65] Request for approval: backport of JDK-8007890
In-Reply-To: <55971A6A.9060205@oracle.com>
References: <542E8041.1010101@oracle.com> <558D5430.7040209@oracle.com>
<558F1F4B.7040706@oracle.com> <5596B47D.8090104@oracle.com>
<55971A6A.9060205@oracle.com>
Message-ID: <559C5E61.5000605@oracle.com>
Hi Alexander,
I approve this for backport to jdk8u/hs-dev (8u66).
Thanks,
David
On 4/07/2015 9:27 AM, David Holmes wrote:
> On 4/07/2015 2:12 AM, alexander vorobyev wrote:
>> Hi David,
>>
>> It is too late for 8u60, I guess. So I decided to fix it in 8u65. And in
>> this case it should be jdk8u-cpu repository.
>>
>> Maybe it is possible to target to 8u66? To which repository can I push
>> it in this case (considering that jdk8u/hs-dev is not accepting any
>> change)?
>
> jdk8u/hs-dev is now accepting changes for 8u66.
>
> Cheers,
> David
>
>> Thanks
>>
>>
>> On 28-Jun-15 1:10 AM, David Holmes wrote:
>>> Hi Alexander,
>>>
>>> Why is this targeted to 8u65 and where do you propose to push it?
>>> jdk8u/hs-dev is not accepting any changes at the moment.
>>>
>>> Thanks,
>>> David
>>>
>>> On 26/06/2015 11:31 PM, alexander vorobyev wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I would like to backport fix for JDK-8007890 to 8u65.
>>>>
>>>> Bug id:https://bugs.openjdk.java.net/browse/JDK-8007890
>>>> Webrev:http://cr.openjdk.java.net/~ctornqvi/webrev/8007890/webrev.00/
>>>>
>>>> Changeset:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e865e9584e0e
>>>> Review thread for original
>>>> fix:http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-March/011228.html
>>>>
>>>>
>>>>
>>>>
>>>> testing: jprt
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>>
>>>>
>>
From jeremymanson at google.com Wed Jul 8 00:00:26 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Tue, 7 Jul 2015 17:00:26 -0700
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To:
References:
<554839B4.3020800@oracle.com>
Message-ID:
No love? Is there a code owner here I should pester more directly?
Jeremy
On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
wrote:
> As usual with Google patches, they are in use locally. This one has been
> stable for a while without complaints. Please sponsor.
>
> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson
> wrote:
>
>> All this talk about IgnoreUnrecognizedVMOptions reminded me that this
>> review is still outstanding. Any takers?
>>
>> Jeremy
>>
>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson
>> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for taking a look.
>>>
>>> On Mon, May 4, 2015 at 8:32 PM, David Holmes
>>> wrote:
>>>
>>>> Hi Jeremy,
>>>>
>>>> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>>>>
>>>>> Not sure who might be willing to sponsor this. David? You did the
>>>>> last
>>>>> one. :)
>>>>>
>>>>
>>>> Might be a while before I can get to it. I did have a quick look (and
>>>> will need a longer one).
>>>
>>>
>>> I understand. I'm just happy it's possible to upstream this stuff at
>>> all[1].
>>>
>>> [1] With the eternal caveat that I'd be happier if we didn't *have* to
>>> go through you folks, but we've learned to live with it.
>>>
>>>
>>>
>>>> Context: A number of command line options are not settable via
>>>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>>>
>>>>> - PrintVMOptions
>>>>>
>>>>
>>>> So you have changed the semantics of this to print out the options from
>>>> the command-line and each of the two env vars. Seems reasonable but may be
>>>> better to know which option came from where as we can now see the same
>>>> option (or conflicting variants thereof) multiple times.
>>>>
>>>
>>> I'd be happy to do this. Any preferred syntax? Does someone actually
>>> own this feature?
>>>
>>> I'm unclear what the current processing order is for the different
>>>> sources of options, and whether the changes affect that order?
>>>>
>>>
>>> Nope. I go through sad contortions to keep the processing order the
>>> same. It's JAVA_TOOL_OPTIONS, then command line, then _JAVA_OPTIONS. See
>>> lines 2549-2567.
>>>
>>>
>>>>
>>>> - IgnoreUnrecognizedVMOptions
>>>>> - PrintFlagsInitial
>>>>>
>>>>
>>>> Unclear what "initial" actually means - is it the default?
>>>
>>>
>>> More or less. If you stick, for example, IgnoreUnrecognizedVMOptions in
>>> there first, it will get printed out as "true". I haven't really changed
>>> the semantics here either - I've just added processing of the envvars.
>>>
>>> - NativeMemoryTracking
>>>>> - PrintFlagsWithComments
>>>>>
>>>>> This is because these flags have to be processed before processing
>>>>> other
>>>>> flags, and no one ever bothered to do that for the flags coming from
>>>>> environment variables. This patch fixes that problem.
>>>>>
>>>>> I have a test, but it is a modification to a JDK test instead of a HS
>>>>> test,
>>>>> so it can go in separately (I guess).
>>>>>
>>>>
>>>> They can be pushed together to different repos in the same forest.
>>>>
>>>
>>> Okay. Here's the test change:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>>
>>>
>>>> As I said I'll have to get back to this. And hopefully someone else in
>>>> runtime will take a good look as well ;-)
>>>>
>>>
>>> I'd be happy to toss it over to whomever owns this, if anyone. Thanks!
>>>
>>> Jeremy
>>>
>>>
>>>
>>>>
>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>>>
>>>>> Jeremy
>>>>>
>>>>>
>>>
>>
>
From harold.seigel at oracle.com Wed Jul 8 12:16:45 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 08 Jul 2015 08:16:45 -0400
Subject: RFR(XS) 8130183: InnerClasses: VM permits wrong inner_class_info_index
value of zero
Message-ID: <559D14AD.7000303@oracle.com>
Hi,
Please review this small change to fix bug JDK-8130183. The JVM allows
the InnerClasses attributes inner_class_info_index to have the value of
zero. This violates JVM-Spec 8. See
http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.6.
The fix ensures that the inner_class_info_index is non-zero and is a
valid index into the constant pool.
Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130183/
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130183
The fix was tested with JCL Lang and VM tests, the UTE quick and
split_verifier tests, and the hotspot, java/io, java/lang, and java/util
JTreg tests.
Thanks, Harold
From lois.foltan at oracle.com Wed Jul 8 12:53:47 2015
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 08 Jul 2015 08:53:47 -0400
Subject: RFR(XS) 8130183: InnerClasses: VM permits wrong
inner_class_info_index value of zero
In-Reply-To: <559D14AD.7000303@oracle.com>
References: <559D14AD.7000303@oracle.com>
Message-ID: <559D1D5B.7090206@oracle.com>
Looks good.
Lois
On 7/8/2015 8:16 AM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix bug JDK-8130183. The JVM
> allows the InnerClasses attributes inner_class_info_index to have the
> value of zero. This violates JVM-Spec 8. See
> http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.6.
>
> The fix ensures that the inner_class_info_index is non-zero and is a
> valid index into the constant pool.
>
> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130183/
>
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130183
>
> The fix was tested with JCL Lang and VM tests, the UTE quick and
> split_verifier tests, and the hotspot, java/io, java/lang, and
> java/util JTreg tests.
>
> Thanks, Harold
From harold.seigel at oracle.com Wed Jul 8 12:55:21 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 08 Jul 2015 08:55:21 -0400
Subject: RFR(XS) 8130183: InnerClasses: VM permits wrong
inner_class_info_index value of zero
In-Reply-To: <559D1D5B.7090206@oracle.com>
References: <559D14AD.7000303@oracle.com> <559D1D5B.7090206@oracle.com>
Message-ID: <559D1DB9.4050809@oracle.com>
Thanks for the review!
Harold
On 7/8/2015 8:53 AM, Lois Foltan wrote:
> Looks good.
> Lois
>
> On 7/8/2015 8:16 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix bug JDK-8130183. The JVM
>> allows the InnerClasses attributes inner_class_info_index to have the
>> value of zero. This violates JVM-Spec 8. See
>> http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.6.
>>
>> The fix ensures that the inner_class_info_index is non-zero and is a
>> valid index into the constant pool.
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130183/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130183
>>
>> The fix was tested with JCL Lang and VM tests, the UTE quick and
>> split_verifier tests, and the hotspot, java/io, java/lang, and
>> java/util JTreg tests.
>>
>> Thanks, Harold
>
From coleen.phillimore at oracle.com Wed Jul 8 13:19:56 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 08 Jul 2015 09:19:56 -0400
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To:
References: <554839B4.3020800@oracle.com>
Message-ID: <559D237C.2060702@oracle.com>
I'll sponsor it but can you repost the RFR?
There has been a fair bit of work to command line processing lately so
I'd like to have the others look at it too. Have you merged this up
with the latest version of hs-rt repository and were there conflicts?
Also, have you looked at the RFR:
"Open code review for 8061999 Enhance VM option parsing to allow options
to be specified"
and are there conflicts with this?
The hotspot change looks good to me.
http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
"UseCerealGC" LOL
Can you use a different option than PrintOopAddress in this test? I
don't know why this command line option exists or would be useful for,
and seems to be a good candidate for removal. If you need a valid
argument, that is unlikely to go away, TraceExceptions would be good.
Thanks,
Coleen
On 7/7/15 8:00 PM, Jeremy Manson wrote:
> No love? Is there a code owner here I should pester more directly?
>
> Jeremy
>
> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
> wrote:
>
>> As usual with Google patches, they are in use locally. This one has been
>> stable for a while without complaints. Please sponsor.
>>
>> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson
>> wrote:
>>
>>> All this talk about IgnoreUnrecognizedVMOptions reminded me that this
>>> review is still outstanding. Any takers?
>>>
>>> Jeremy
>>>
>>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson
>>> wrote:
>>>
>>>> Hi David,
>>>>
>>>> Thanks for taking a look.
>>>>
>>>> On Mon, May 4, 2015 at 8:32 PM, David Holmes
>>>> wrote:
>>>>
>>>>> Hi Jeremy,
>>>>>
>>>>> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>>>>>
>>>>>> Not sure who might be willing to sponsor this. David? You did the
>>>>>> last
>>>>>> one. :)
>>>>>>
>>>>> Might be a while before I can get to it. I did have a quick look (and
>>>>> will need a longer one).
>>>>
>>>> I understand. I'm just happy it's possible to upstream this stuff at
>>>> all[1].
>>>>
>>>> [1] With the eternal caveat that I'd be happier if we didn't *have* to
>>>> go through you folks, but we've learned to live with it.
>>>>
>>>>
>>>>
>>>>> Context: A number of command line options are not settable via
>>>>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>>>>
>>>>>> - PrintVMOptions
>>>>>>
>>>>> So you have changed the semantics of this to print out the options from
>>>>> the command-line and each of the two env vars. Seems reasonable but may be
>>>>> better to know which option came from where as we can now see the same
>>>>> option (or conflicting variants thereof) multiple times.
>>>>>
>>>> I'd be happy to do this. Any preferred syntax? Does someone actually
>>>> own this feature?
>>>>
>>>> I'm unclear what the current processing order is for the different
>>>>> sources of options, and whether the changes affect that order?
>>>>>
>>>> Nope. I go through sad contortions to keep the processing order the
>>>> same. It's JAVA_TOOL_OPTIONS, then command line, then _JAVA_OPTIONS. See
>>>> lines 2549-2567.
>>>>
>>>>
>>>>> - IgnoreUnrecognizedVMOptions
>>>>>> - PrintFlagsInitial
>>>>>>
>>>>> Unclear what "initial" actually means - is it the default?
>>>>
>>>> More or less. If you stick, for example, IgnoreUnrecognizedVMOptions in
>>>> there first, it will get printed out as "true". I haven't really changed
>>>> the semantics here either - I've just added processing of the envvars.
>>>>
>>>> - NativeMemoryTracking
>>>>>> - PrintFlagsWithComments
>>>>>>
>>>>>> This is because these flags have to be processed before processing
>>>>>> other
>>>>>> flags, and no one ever bothered to do that for the flags coming from
>>>>>> environment variables. This patch fixes that problem.
>>>>>>
>>>>>> I have a test, but it is a modification to a JDK test instead of a HS
>>>>>> test,
>>>>>> so it can go in separately (I guess).
>>>>>>
>>>>> They can be pushed together to different repos in the same forest.
>>>>>
>>>> Okay. Here's the test change:
>>>>
>>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>>>
>>>>
>>>>> As I said I'll have to get back to this. And hopefully someone else in
>>>>> runtime will take a good look as well ;-)
>>>>>
>>>> I'd be happy to toss it over to whomever owns this, if anyone. Thanks!
>>>>
>>>> Jeremy
>>>>
>>>>
>>>>
>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>>>>
>>>>>> Jeremy
>>>>>>
>>>>>>
From harold.seigel at oracle.com Wed Jul 8 13:32:22 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 08 Jul 2015 09:32:22 -0400
Subject: RFR(XS) 8130669: VM prohibits methods with return values
Message-ID: <559D2666.5010209@oracle.com>
Hi,
Please review this small change to fix bug JDK-8130669. The JVM
incorrectly throws ClassFormatError exceptions for non-void methods
named . But, the JVM Spec 8 says that such methods
should be ignored. See
http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9
for details.
The fix changes the JVM to, in this case, only throw ClassFormatError
exceptions for non-void methods.
Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
The fix was tested with JCK Lang and VM tests, the UTE quick and
split_verifier tests, and the hotspot, java/io, java/lang, and java/util
JTreg tests.
Thanks, Harold
From karen.kinnear at oracle.com Wed Jul 8 16:07:29 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 8 Jul 2015 12:07:29 -0400
Subject: RFR(XS) 8130183: InnerClasses: VM permits wrong
inner_class_info_index value of zero
In-Reply-To: <559D14AD.7000303@oracle.com>
References: <559D14AD.7000303@oracle.com>
Message-ID: <47D48089-A6A5-41A7-9C03-11AE9167C66A@oracle.com>
Harold,
The code looks good.
Does this also catch the anonymous/local class with zero inner_class_info_index - i.e. did you run the other examples attached to the bug?
thanks,
Karen
On Jul 8, 2015, at 8:16 AM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix bug JDK-8130183. The JVM allows the InnerClasses attributes inner_class_info_index to have the value of zero. This violates JVM-Spec 8. See http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.6.
>
> The fix ensures that the inner_class_info_index is non-zero and is a valid index into the constant pool.
>
> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130183/
>
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130183
>
> The fix was tested with JCL Lang and VM tests, the UTE quick and split_verifier tests, and the hotspot, java/io, java/lang, and java/util JTreg tests.
>
> Thanks, Harold
From karen.kinnear at oracle.com Wed Jul 8 16:41:51 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 8 Jul 2015 12:41:51 -0400
Subject: RFR(XS) 8130669: VM prohibits methods with return values
In-Reply-To: <559D2666.5010209@oracle.com>
References: <559D2666.5010209@oracle.com>
Message-ID: <0E7D8DDC-044C-4DA0-B638-4538D97ECB1B@oracle.com>
Harold,
I like your code changes and your tests.
One small comment:
1. verifier.cpp around line 2849 - could you possibly fix the comment - it says
"Class file parser verifies that methods with '<' have void return"
-- we only check now which is what that logic cares about
thanks,
Karen
On Jul 8, 2015, at 9:32 AM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix bug JDK-8130669. The JVM incorrectly throws ClassFormatError exceptions for non-void methods named . But, the JVM Spec 8 says that such methods should be ignored. See http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9 for details.
>
> The fix changes the JVM to, in this case, only throw ClassFormatError exceptions for non-void methods.
>
> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
>
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
>
> The fix was tested with JCK Lang and VM tests, the UTE quick and split_verifier tests, and the hotspot, java/io, java/lang, and java/util JTreg tests.
>
> Thanks, Harold
From harold.seigel at oracle.com Wed Jul 8 16:52:30 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 08 Jul 2015 12:52:30 -0400
Subject: RFR(XS) 8130183: InnerClasses: VM permits wrong
inner_class_info_index value of zero
In-Reply-To: <47D48089-A6A5-41A7-9C03-11AE9167C66A@oracle.com>
References: <559D14AD.7000303@oracle.com>
<47D48089-A6A5-41A7-9C03-11AE9167C66A@oracle.com>
Message-ID: <559D554E.80802@oracle.com>
Hi Karen,
Thanks for the review. I did run all four examples attached to the bug
and they all correctly throw ClassFormatError exceptions for the
inner_class_info_index being zero.
Harold
On 7/8/2015 12:07 PM, Karen Kinnear wrote:
> Harold,
>
> The code looks good.
>
> Does this also catch the anonymous/local class with zero inner_class_info_index - i.e. did you run the other examples attached to the bug?
>
> thanks,
> Karen
>
> On Jul 8, 2015, at 8:16 AM, harold seigel wrote:
>
>> Hi,
>>
>> Please review this small change to fix bug JDK-8130183. The JVM allows the InnerClasses attributes inner_class_info_index to have the value of zero. This violates JVM-Spec 8. See http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.6.
>>
>> The fix ensures that the inner_class_info_index is non-zero and is a valid index into the constant pool.
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130183/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130183
>>
>> The fix was tested with JCL Lang and VM tests, the UTE quick and split_verifier tests, and the hotspot, java/io, java/lang, and java/util JTreg tests.
>>
>> Thanks, Harold
From harold.seigel at oracle.com Wed Jul 8 16:58:43 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 08 Jul 2015 12:58:43 -0400
Subject: RFR(XS) 8130669: VM prohibits methods with return values
In-Reply-To: <0E7D8DDC-044C-4DA0-B638-4538D97ECB1B@oracle.com>
References: <559D2666.5010209@oracle.com>
<0E7D8DDC-044C-4DA0-B638-4538D97ECB1B@oracle.com>
Message-ID: <559D56C2.2050907@oracle.com>
Hi Karen,
Thanks for the review and catching that comment. I'll update it.
Harold
On 7/8/2015 12:41 PM, Karen Kinnear wrote:
> Harold,
>
> I like your code changes and your tests.
>
> One small comment:
> 1. verifier.cpp around line 2849 - could you possibly fix the comment - it says
> "Class file parser verifies that methods with '<' have void return"
> -- we only check now which is what that logic cares about
>
> thanks,
> Karen
>
>
> On Jul 8, 2015, at 9:32 AM, harold seigel wrote:
>
>> Hi,
>>
>> Please review this small change to fix bug JDK-8130669. The JVM incorrectly throws ClassFormatError exceptions for non-void methods named . But, the JVM Spec 8 says that such methods should be ignored. See http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9 for details.
>>
>> The fix changes the JVM to, in this case, only throw ClassFormatError exceptions for non-void methods.
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
>>
>> The fix was tested with JCK Lang and VM tests, the UTE quick and split_verifier tests, and the hotspot, java/io, java/lang, and java/util JTreg tests.
>>
>> Thanks, Harold
From karen.kinnear at oracle.com Wed Jul 8 16:58:41 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 8 Jul 2015 12:58:41 -0400
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <557F6786.6030808@oracle.com>
References: <555A4678.7020308@oracle.com> <556417AF.8050203@oracle.com>
<557F6786.6030808@oracle.com>
Message-ID:
Dan,
I don't know if you created rfes or not for the potential ideas.
What I did when I cleaned this up earlier was move them to a wiki page
http://j2se.us.oracle.com/web/bin/view/HotspotRuntime/SyncFutures
So we could create rfes when we thought we might be actually adopting the ideas.
This is linked off of the runtime brainstorming page in the contended locking section:
https://wiki.se.oracle.com/display/JPG/JVM+Runtime+Brainstorming
Feel free to modify either of those pages with new ideas.
hope this helps,
Karen
On Jun 15, 2015, at 8:02 PM, Daniel D. Daugherty wrote:
> On 5/26/15 12:50 AM, David Holmes wrote:
>> Hi Dan,
>>
>> Sorry for the delay on this. And thanks for the detailed explanation of the changes.
>
> Sorry for the delay in responding to your review. It didn't make sense
> (to me) to move forward with this bucket while the regression introduced
> by the "fast enter" bucket (JDK-8077392) remained in such an unknown
> state. While still unresolved, much is known about JDK-8077392 and I
> feel more comfortable about moving forward with the "fast notify"
> bucket (JDK-8075171).
>
>
>> Overall looks good only a couple of nits. :)
>
> Thanks!
>
>
>> See below ...
>
> As usual, replies are embedded below.
>
>
>>
>> On 19/05/2015 6:07 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I have the Contended Locking fast notify bucket ready for review.
>>>
>>> The code changes in this bucket are the final piece in the triad
>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>> macro assembler changes in this bucket (yeah!), but there are
>>> code review cleanups motivated by comments on other buckets, e.g.,
>>> changing variables like 'Tally' -> 'tally'.
>>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8075171 Contended Locking fast notify bucket
>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>
>>> Here is the JEP link:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>
>>> Testing:
>>>
>>> - Aurora Adhoc RT/SVC baseline batch
>>> - JPRT test jobs
>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>> - CallTimerGrid stress testing (in process)
>>> - Aurora performance testing:
>>> - out of the box for the "promotion" and 32-bit server configs
>>> - heavy weight monitors for the "promotion" and 32-bit server configs
>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>> (in process)
>>>
>>> The hang somehow introduced by the "fast enter" bucket is still
>>> unresolved, but progress is being made. That work is being tracked
>>> by the following bug:
>>>
>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>
>>> You'll see a change that re-enables the "fast enter" bucket in this
>>> webrev, but that change will not be pushed when we're done with the
>>> review of this bucket unless JDK-8077392 is resolved.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>>
>>> 8075171 summary of changes:
>>>
>>> src/share/vm/classfile/vmSymbols.hpp
>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>
>> Ok
>>
>>> src/share/vm/opto/library_call.cpp
>>> - Add optional inline_notify() that is controlled by new
>>> '-XX:[+-]InlineNotify' option
>>
>> Ok
>>
>>> src/share/vm/opto/runtime.cpp
>>> src/share/vm/opto/runtime.hpp
>>> - Add OptoRuntime::monitor_notify_C() and
>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>> the new "fast notify" code paths
>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>> the above two new functions
>>
>> Ok
>>
>>> src/share/vm/runtime/globals.hpp
>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>> enabled (true)
>>
>> Ok
>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>> src/share/vm/runtime/objectMonitor.hpp
>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>> into wrappers that call the new ObjectMonitor::INotify()
>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>> between "notify" and "notifyAll" code paths
>>
>> Why does INotify return int ?
>
> I'm going to guess that this is a left-over from an earlier version of
> the refactor of ObjectMonitor::notify() and ObjectMonitor::notifyAll().
> I will change it to return 'void'.
>
>
>> The soliloquy starting:
>>
>> 1762 // Consider: a non-uncommon synchronization bug is to use notify() when notifyAll()
>>
>> seems somewhat out of context without some option to turn notify into notifyAll,
>
> The prefix of "Consider:" in a comment marks an idea that we should
> consider implementing. We're thinking about moving these ideas into
> RFE's in order to improve the readability of the code as it stands
> today.
>
>
>> or apply the MinimumWait.
>
> The '-XX:SyncFlags=1' option causes all park() operations to use a small
> timer value so it is a good way to check for lost unpark() operations.
> 'MinimumWait' doesn't exist as anything other than comments. I suspect
> that it was superseded by RecheckInterval and MaximumRecheckInterval.
> I'll look at fixing those comments.
>
>
>> Further a lost wakeup need not imply incorrect use of notify rather than notifyAll so there are really two different debugging techniques being described.
>
> I don't think the new comment block is trying to say that the only
> source for a "lost wakeup" bug is due to the use of notify() when
> notifyAll() is more appropriate. I'll see if I can tweak the wording
> a little to make it clear that the use of notify() when notifyAll()
> is more appropriate is just an example.
>
>
>>
>>> src/share/vm/runtime/sharedRuntime.cpp
>>> - Temporarily re-enable the "fast enter" optimization in order
>>> to do performance testing. JDK-8077392 is still unresolved,
>>> but progress is being made.
>>
>> Ok
>>
>>> src/share/vm/runtime/synchronizer.cpp
>>> src/share/vm/runtime/synchronizer.hpp
>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>> new "fast notify" code paths
>>
>> The comment block starting:
>>
>> 150 // An interesting optimization is to have the JIT recognize the following
>>
>> seems to be an other soliloquy. While interesting I initially thought it was describing what quick_notify was doing - which it isn't. Maybe that commentary belongs somewhere in the compiler code where the intrinsification is being done?
>
> L150-L155 should have been marked with a "Consider:" tag. This
> one screams to be moved into an RFE.
>
>
>> The 'All' parameter to quick_notify should be 'all'.
>
> Yes and the 'Self' parameter should be 'self'. I thought I had
> fixed those for all new functions. Guess not. :-(
>
>
>> The comment block at lines 176 - 180 should be moved prior to line 171, because the check at 171 is the "not biased" case, and the check at 174 is the "owned by caller" case.
>
> 165 if (mark->has_locker() && Self->is_lock_owned((address)mark->locker())) {
>
> The if-block starting at line 165 is the stack locked case.
>
> 171 if (mark->has_monitor()) {
>
> The if-block starting at L171 is the inflated monitor case.
>
> 174 if (mon->owner() != Self) return false;
>
> The if-statement on L174 is the ownership sanity check for the
> notify/notifyAll operation. This shouldn't happen because a
> thread that doesn't own the Java Monitor should not call notify()
> or notifyAll() on it, but we take the slow path in order to
> provide a better failure mode.
>
> The biased locking case actually hits here:
>
> 201 return false; // revert to slow-path
>
>
> I think I need to rip out much of the comment from L176-L180 and
> maybe move some of it elsewhere.
>
>
>> This loop:
>>
>> 188 for (;;) {
>> 189 if (mon->first_waiter() == NULL) break;
>> 190 mon->INotify(Self);
>> 191 ++tally;
>> 192 if (!All) break;
>> 193 }
>>
>> would be a bit cleaner to me if written:
>>
>> do {
>> mon->INotify(Self);
>> ++tally;
>> } while (mon->first_waiter() != NULL && All);
>
> Since that loop is protected by an initial first_waiter() check:
>
> 181 if (mon->first_waiter() != NULL) {
>
> I concur that your loop is better. I'll fix it.
>
> Thanks for your review! And again, sorry about the delay in responding.
>
> Dan
>
>
>>
>> Thanks,
>> David
>>
>>> - The new code handles a couple of special cases where the
>>> "notify" can be done without the heavy weight slow-path
>>> (thread state transitions and other baggage)
>
From daniel.daugherty at oracle.com Wed Jul 8 17:25:47 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 08 Jul 2015 11:25:47 -0600
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To:
References: <555A4678.7020308@oracle.com> <556417AF.8050203@oracle.com>
<557F6786.6030808@oracle.com>
Message-ID: <559D5D1B.8080009@oracle.com>
Karen,
No new RFEs filed yet as part of this bucket (8075171).
I think the migration of ideas and what-ifs needs to happen
under another bug fix. We also need to figure out where to
move this stuff. The wikis you mention below are Oracle
internal so I don't think those are a good place to land
content that is currently in OpenJDK.
Dan
On 7/8/15 10:58 AM, Karen Kinnear wrote:
> Dan,
>
> I don't know if you created rfes or not for the potential ideas.
>
> What I did when I cleaned this up earlier was move them to a wiki page
> http://j2se.us.oracle.com/web/bin/view/HotspotRuntime/SyncFutures
>
> So we could create rfes when we thought we might be actually adopting the ideas.
>
> This is linked off of the runtime brainstorming page in the contended locking section:
> https://wiki.se.oracle.com/display/JPG/JVM+Runtime+Brainstorming
>
> Feel free to modify either of those pages with new ideas.
>
> hope this helps,
> Karen
>
> On Jun 15, 2015, at 8:02 PM, Daniel D. Daugherty wrote:
>
>> On 5/26/15 12:50 AM, David Holmes wrote:
>>> Hi Dan,
>>>
>>> Sorry for the delay on this. And thanks for the detailed explanation of the changes.
>> Sorry for the delay in responding to your review. It didn't make sense
>> (to me) to move forward with this bucket while the regression introduced
>> by the "fast enter" bucket (JDK-8077392) remained in such an unknown
>> state. While still unresolved, much is known about JDK-8077392 and I
>> feel more comfortable about moving forward with the "fast notify"
>> bucket (JDK-8075171).
>>
>>
>>> Overall looks good only a couple of nits. :)
>> Thanks!
>>
>>
>>> See below ...
>> As usual, replies are embedded below.
>>
>>
>>> On 19/05/2015 6:07 AM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I have the Contended Locking fast notify bucket ready for review.
>>>>
>>>> The code changes in this bucket are the final piece in the triad
>>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>>> macro assembler changes in this bucket (yeah!), but there are
>>>> code review cleanups motivated by comments on other buckets, e.g.,
>>>> changing variables like 'Tally' -> 'tally'.
>>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8075171 Contended Locking fast notify bucket
>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>>
>>>> Here is the JEP link:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>
>>>> Testing:
>>>>
>>>> - Aurora Adhoc RT/SVC baseline batch
>>>> - JPRT test jobs
>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>> - CallTimerGrid stress testing (in process)
>>>> - Aurora performance testing:
>>>> - out of the box for the "promotion" and 32-bit server configs
>>>> - heavy weight monitors for the "promotion" and 32-bit server configs
>>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>>> (in process)
>>>>
>>>> The hang somehow introduced by the "fast enter" bucket is still
>>>> unresolved, but progress is being made. That work is being tracked
>>>> by the following bug:
>>>>
>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>>
>>>> You'll see a change that re-enables the "fast enter" bucket in this
>>>> webrev, but that change will not be pushed when we're done with the
>>>> review of this bucket unless JDK-8077392 is resolved.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Gory details about the changes are below...
>>>>
>>>> Dan
>>>>
>>>>
>>>> 8075171 summary of changes:
>>>>
>>>> src/share/vm/classfile/vmSymbols.hpp
>>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>> Ok
>>>
>>>> src/share/vm/opto/library_call.cpp
>>>> - Add optional inline_notify() that is controlled by new
>>>> '-XX:[+-]InlineNotify' option
>>> Ok
>>>
>>>> src/share/vm/opto/runtime.cpp
>>>> src/share/vm/opto/runtime.hpp
>>>> - Add OptoRuntime::monitor_notify_C() and
>>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>>> the new "fast notify" code paths
>>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>>> the above two new functions
>>> Ok
>>>
>>>> src/share/vm/runtime/globals.hpp
>>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>>> enabled (true)
>>> Ok
>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>>> into wrappers that call the new ObjectMonitor::INotify()
>>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>>> between "notify" and "notifyAll" code paths
>>> Why does INotify return int ?
>> I'm going to guess that this is a left-over from an earlier version of
>> the refactor of ObjectMonitor::notify() and ObjectMonitor::notifyAll().
>> I will change it to return 'void'.
>>
>>
>>> The soliloquy starting:
>>>
>>> 1762 // Consider: a non-uncommon synchronization bug is to use notify() when notifyAll()
>>>
>>> seems somewhat out of context without some option to turn notify into notifyAll,
>> The prefix of "Consider:" in a comment marks an idea that we should
>> consider implementing. We're thinking about moving these ideas into
>> RFE's in order to improve the readability of the code as it stands
>> today.
>>
>>
>>> or apply the MinimumWait.
>> The '-XX:SyncFlags=1' option causes all park() operations to use a small
>> timer value so it is a good way to check for lost unpark() operations.
>> 'MinimumWait' doesn't exist as anything other than comments. I suspect
>> that it was superseded by RecheckInterval and MaximumRecheckInterval.
>> I'll look at fixing those comments.
>>
>>
>>> Further a lost wakeup need not imply incorrect use of notify rather than notifyAll so there are really two different debugging techniques being described.
>> I don't think the new comment block is trying to say that the only
>> source for a "lost wakeup" bug is due to the use of notify() when
>> notifyAll() is more appropriate. I'll see if I can tweak the wording
>> a little to make it clear that the use of notify() when notifyAll()
>> is more appropriate is just an example.
>>
>>
>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>> - Temporarily re-enable the "fast enter" optimization in order
>>>> to do performance testing. JDK-8077392 is still unresolved,
>>>> but progress is being made.
>>> Ok
>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>> src/share/vm/runtime/synchronizer.hpp
>>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>>> new "fast notify" code paths
>>> The comment block starting:
>>>
>>> 150 // An interesting optimization is to have the JIT recognize the following
>>>
>>> seems to be an other soliloquy. While interesting I initially thought it was describing what quick_notify was doing - which it isn't. Maybe that commentary belongs somewhere in the compiler code where the intrinsification is being done?
>> L150-L155 should have been marked with a "Consider:" tag. This
>> one screams to be moved into an RFE.
>>
>>
>>> The 'All' parameter to quick_notify should be 'all'.
>> Yes and the 'Self' parameter should be 'self'. I thought I had
>> fixed those for all new functions. Guess not. :-(
>>
>>
>>> The comment block at lines 176 - 180 should be moved prior to line 171, because the check at 171 is the "not biased" case, and the check at 174 is the "owned by caller" case.
>> 165 if (mark->has_locker() && Self->is_lock_owned((address)mark->locker())) {
>>
>> The if-block starting at line 165 is the stack locked case.
>>
>> 171 if (mark->has_monitor()) {
>>
>> The if-block starting at L171 is the inflated monitor case.
>>
>> 174 if (mon->owner() != Self) return false;
>>
>> The if-statement on L174 is the ownership sanity check for the
>> notify/notifyAll operation. This shouldn't happen because a
>> thread that doesn't own the Java Monitor should not call notify()
>> or notifyAll() on it, but we take the slow path in order to
>> provide a better failure mode.
>>
>> The biased locking case actually hits here:
>>
>> 201 return false; // revert to slow-path
>>
>>
>> I think I need to rip out much of the comment from L176-L180 and
>> maybe move some of it elsewhere.
>>
>>
>>> This loop:
>>>
>>> 188 for (;;) {
>>> 189 if (mon->first_waiter() == NULL) break;
>>> 190 mon->INotify(Self);
>>> 191 ++tally;
>>> 192 if (!All) break;
>>> 193 }
>>>
>>> would be a bit cleaner to me if written:
>>>
>>> do {
>>> mon->INotify(Self);
>>> ++tally;
>>> } while (mon->first_waiter() != NULL && All);
>> Since that loop is protected by an initial first_waiter() check:
>>
>> 181 if (mon->first_waiter() != NULL) {
>>
>> I concur that your loop is better. I'll fix it.
>>
>> Thanks for your review! And again, sorry about the delay in responding.
>>
>> Dan
>>
>>
>>> Thanks,
>>> David
>>>
>>>> - The new code handles a couple of special cases where the
>>>> "notify" can be done without the heavy weight slow-path
>>>> (thread state transitions and other baggage)
From karen.kinnear at oracle.com Wed Jul 8 17:31:26 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 8 Jul 2015 13:31:26 -0400
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <557F678A.3010108@oracle.com>
References: <555A4678.7020308@oracle.com>
<4EF34946-A98A-4636-998E-6B38759EB2A0@oracle.com>
<557F678A.3010108@oracle.com>
Message-ID:
Dan,
On Jun 15, 2015, at 8:02 PM, Daniel D. Daugherty wrote:
> On 5/27/15 2:58 PM, Karen Kinnear wrote:
>> Dan,
>
> Sorry for the delay in responding to your review. It didn't make sense
> (to me) to move forward with this bucket while the regression introduced
> by the "fast enter" bucket (JDK-8077392) remained in such an unknown
> state. While still unresolved, much is known about JDK-8077392 and I
> feel more comfortable about moving forward with the "fast notify"
> bucket (JDK-8075171).
>
>
>> The code looks really good.
>
> Thanks!
>
>
>> Thank you for the detailed description and the
>> extensive testing.
>>
>> Two minor comments:
>> 1. objectMonitor.cpp ~ 1706 - after the else if (policy == 2)
>
> You didn't mention it, but there's a duplicated comment on
> L1706 and L1707; I'll fix that also.
>
>
>> - could you possibly move the iterator->TState = ObjectWaiter::TS_CXQ to before the if (List == NULL)/else?
>> - otherwise I think it is only set on the else
My bad - the TState is set to TS_ENTER above if policy != 4 - I missed that.
thanks,
Karen
>
> I think the existing code is correct:
>
> 1708 if (list == NULL) {
> 1709 iterator->_next = iterator->_prev = NULL;
> 1710 _EntryList = iterator;
> 1711 } else {
> 1712 iterator->TState = ObjectWaiter::TS_CXQ;
> 1713 for (;;) {
> 1714 ObjectWaiter * front = _cxq;
> 1715 iterator->_next = front;
> 1716 if (Atomic::cmpxchg_ptr(iterator, &_cxq, front) == front) {
> 1717 break;
> 1718 }
> 1719 }
>
> We set the TState to TS_CXQ on L1712 because we are prepending
> stuff from the _cxq on L1714-1716.
> In the if-block on L1708-1710, we aren't doing anything with
> _cxq so no need to change TState from its current value.
>
>
>>
>> 2. opto.runtime.cpp
>> lines 433-435 -- did you want the comment about intrinsifying hashCode()? My memory is we aren't picking up
>> those changes
>
> I've gone back and forth about leaving that comment there or
> moving it to the hashcode() bucket. We aren't picking up the
> hashcode() changes as part of this JEP. I'll go back to the
> original changes and see if I can remember why I put it in
> this bucket; at the time, I had a good reason... :-)
>
> Thanks for your review! And again, sorry about the delay in responding.
>
> Dan
>
>
>>
>> thanks,
>> Karen
>>
>>
>> On May 18, 2015, at 4:07 PM, Daniel D. Daugherty wrote:
>>
>>> Greetings,
>>>
>>> I have the Contended Locking fast notify bucket ready for review.
>>>
>>> The code changes in this bucket are the final piece in the triad
>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>> macro assembler changes in this bucket (yeah!), but there are
>>> code review cleanups motivated by comments on other buckets, e.g.,
>>> changing variables like 'Tally' -> 'tally'.
>>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8075171 Contended Locking fast notify bucket
>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>
>>> Here is the JEP link:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>
>>> Testing:
>>>
>>> - Aurora Adhoc RT/SVC baseline batch
>>> - JPRT test jobs
>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>> - CallTimerGrid stress testing (in process)
>>> - Aurora performance testing:
>>> - out of the box for the "promotion" and 32-bit server configs
>>> - heavy weight monitors for the "promotion" and 32-bit server configs
>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>> (in process)
>>>
>>> The hang somehow introduced by the "fast enter" bucket is still
>>> unresolved, but progress is being made. That work is being tracked
>>> by the following bug:
>>>
>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>
>>> You'll see a change that re-enables the "fast enter" bucket in this
>>> webrev, but that change will not be pushed when we're done with the
>>> review of this bucket unless JDK-8077392 is resolved.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>>
>>> 8075171 summary of changes:
>>>
>>> src/share/vm/classfile/vmSymbols.hpp
>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>
>>> src/share/vm/opto/library_call.cpp
>>> - Add optional inline_notify() that is controlled by new
>>> '-XX:[+-]InlineNotify' option
>>>
>>> src/share/vm/opto/runtime.cpp
>>> src/share/vm/opto/runtime.hpp
>>> - Add OptoRuntime::monitor_notify_C() and
>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>> the new "fast notify" code paths
>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>> the above two new functions
>>>
>>> src/share/vm/runtime/globals.hpp
>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>> enabled (true)
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>> src/share/vm/runtime/objectMonitor.hpp
>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>> into wrappers that call the new ObjectMonitor::INotify()
>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>> between "notify" and "notifyAll" code paths
>>>
>>> src/share/vm/runtime/sharedRuntime.cpp
>>> - Temporarily re-enable the "fast enter" optimization in order
>>> to do performance testing. JDK-8077392 is still unresolved,
>>> but progress is being made.
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>> src/share/vm/runtime/synchronizer.hpp
>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>> new "fast notify" code paths
>>> - The new code handles a couple of special cases where the
>>> "notify" can be done without the heavy weight slow-path
>>> (thread state transitions and other baggage)
>
From daniel.daugherty at oracle.com Wed Jul 8 17:52:23 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 08 Jul 2015 11:52:23 -0600
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To:
References: <555A4678.7020308@oracle.com>
<4EF34946-A98A-4636-998E-6B38759EB2A0@oracle.com>
<557F678A.3010108@oracle.com>
Message-ID: <559D6357.5000705@oracle.com>
Karen,
Thanks for closing the loop on this piece...
Last thing is the re-review when you get the chance...
Dan
On 7/8/15 11:31 AM, Karen Kinnear wrote:
> Dan,
>
> On Jun 15, 2015, at 8:02 PM, Daniel D. Daugherty wrote:
>
>> On 5/27/15 2:58 PM, Karen Kinnear wrote:
>>> Dan,
>> Sorry for the delay in responding to your review. It didn't make sense
>> (to me) to move forward with this bucket while the regression introduced
>> by the "fast enter" bucket (JDK-8077392) remained in such an unknown
>> state. While still unresolved, much is known about JDK-8077392 and I
>> feel more comfortable about moving forward with the "fast notify"
>> bucket (JDK-8075171).
>>
>>
>>> The code looks really good.
>> Thanks!
>>
>>
>>> Thank you for the detailed description and the
>>> extensive testing.
>>>
>>> Two minor comments:
>>> 1. objectMonitor.cpp ~ 1706 - after the else if (policy == 2)
>> You didn't mention it, but there's a duplicated comment on
>> L1706 and L1707; I'll fix that also.
>>
>>
>>> - could you possibly move the iterator->TState = ObjectWaiter::TS_CXQ to before the if (List == NULL)/else?
>>> - otherwise I think it is only set on the else
> My bad - the TState is set to TS_ENTER above if policy != 4 - I missed that.
>
> thanks,
> Karen
>> I think the existing code is correct:
>>
>> 1708 if (list == NULL) {
>> 1709 iterator->_next = iterator->_prev = NULL;
>> 1710 _EntryList = iterator;
>> 1711 } else {
>> 1712 iterator->TState = ObjectWaiter::TS_CXQ;
>> 1713 for (;;) {
>> 1714 ObjectWaiter * front = _cxq;
>> 1715 iterator->_next = front;
>> 1716 if (Atomic::cmpxchg_ptr(iterator, &_cxq, front) == front) {
>> 1717 break;
>> 1718 }
>> 1719 }
>>
>> We set the TState to TS_CXQ on L1712 because we are prepending
>> stuff from the _cxq on L1714-1716.
>> In the if-block on L1708-1710, we aren't doing anything with
>> _cxq so no need to change TState from its current value.
>>
>>
>>> 2. opto.runtime.cpp
>>> lines 433-435 -- did you want the comment about intrinsifying hashCode()? My memory is we aren't picking up
>>> those changes
>> I've gone back and forth about leaving that comment there or
>> moving it to the hashcode() bucket. We aren't picking up the
>> hashcode() changes as part of this JEP. I'll go back to the
>> original changes and see if I can remember why I put it in
>> this bucket; at the time, I had a good reason... :-)
>>
>> Thanks for your review! And again, sorry about the delay in responding.
>>
>> Dan
>>
>>
>>> thanks,
>>> Karen
>>>
>>>
>>> On May 18, 2015, at 4:07 PM, Daniel D. Daugherty wrote:
>>>
>>>> Greetings,
>>>>
>>>> I have the Contended Locking fast notify bucket ready for review.
>>>>
>>>> The code changes in this bucket are the final piece in the triad
>>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>>> macro assembler changes in this bucket (yeah!), but there are
>>>> code review cleanups motivated by comments on other buckets, e.g.,
>>>> changing variables like 'Tally' -> 'tally'.
>>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8075171 Contended Locking fast notify bucket
>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>>
>>>> Here is the JEP link:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>
>>>> Testing:
>>>>
>>>> - Aurora Adhoc RT/SVC baseline batch
>>>> - JPRT test jobs
>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>> - CallTimerGrid stress testing (in process)
>>>> - Aurora performance testing:
>>>> - out of the box for the "promotion" and 32-bit server configs
>>>> - heavy weight monitors for the "promotion" and 32-bit server configs
>>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>>> (in process)
>>>>
>>>> The hang somehow introduced by the "fast enter" bucket is still
>>>> unresolved, but progress is being made. That work is being tracked
>>>> by the following bug:
>>>>
>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>>
>>>> You'll see a change that re-enables the "fast enter" bucket in this
>>>> webrev, but that change will not be pushed when we're done with the
>>>> review of this bucket unless JDK-8077392 is resolved.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Gory details about the changes are below...
>>>>
>>>> Dan
>>>>
>>>>
>>>> 8075171 summary of changes:
>>>>
>>>> src/share/vm/classfile/vmSymbols.hpp
>>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>>
>>>> src/share/vm/opto/library_call.cpp
>>>> - Add optional inline_notify() that is controlled by new
>>>> '-XX:[+-]InlineNotify' option
>>>>
>>>> src/share/vm/opto/runtime.cpp
>>>> src/share/vm/opto/runtime.hpp
>>>> - Add OptoRuntime::monitor_notify_C() and
>>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>>> the new "fast notify" code paths
>>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>>> the above two new functions
>>>>
>>>> src/share/vm/runtime/globals.hpp
>>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>>> enabled (true)
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>>> into wrappers that call the new ObjectMonitor::INotify()
>>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>>> between "notify" and "notifyAll" code paths
>>>>
>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>> - Temporarily re-enable the "fast enter" optimization in order
>>>> to do performance testing. JDK-8077392 is still unresolved,
>>>> but progress is being made.
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>> src/share/vm/runtime/synchronizer.hpp
>>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>>> new "fast notify" code paths
>>>> - The new code handles a couple of special cases where the
>>>> "notify" can be done without the heavy weight slow-path
>>>> (thread state transitions and other baggage)
>
>
From karen.kinnear at oracle.com Wed Jul 8 17:53:54 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 8 Jul 2015 13:53:54 -0400
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <559724B0.6000507@oracle.com>
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
Message-ID: <59B99866-C9BB-46F8-87C3-7E6FA8122227@oracle.com>
Dan,
Looks good.
Only comment is -
In ObjectMonitor::INotify - lines 1668-1671
the default value of policy is "2"
-- which basically is "b" not "a" unless the EntryList is empty.
thanks,
Karen
On Jul 3, 2015, at 8:11 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I've updated the patch for Contended Locking fast notify bucket
> based on David H's and Karen's comments.
>
> This work is being tracked by the following bug ID:
>
> JDK-8075171 Contended Locking fast notify bucket
> https://bugs.openjdk.java.net/browse/JDK-8075171
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>
> Here is the JEP link:
>
> https://bugs.openjdk.java.net/browse/JDK-8046133
>
> Testing:
>
> - RBT vm.quick batches (in process)
> - JPRT test jobs
> - MonitorWaitNotifyStresser micro-benchmark (in process)
> - CallTimerGrid stress testing (in process)
>
>
> The changes in this round are in only four of the files:
>
> src/share/vm/opto/runtime.cpp
>
> - deleted comment about hashCode() that belongs in a different bucket
>
> src/share/vm/runtime/objectMonitor.cpp
>
> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
> - cleanup recheck interval code
> - ObjectMonitor::INotify() return type is now "void"
> - delete duplicate comments, clarify/rewrite some comments
>
> src/share/vm/runtime/objectMonitor.hpp
>
> - ObjectMonitor::INotify() return type is now "void"
>
> src/share/vm/runtime/synchronizer.cpp
>
> - clarify/rewrite comments, add additional comments
> - cleanup variables in ObjectSynchronizer::quick_notify
> - refactor loop to be more clear
> - delete unused enum MaximumRecheckInterval
>
> The easiest way to review the delta is to download the two patch
> files and compare them in something like jfilemerge:
>
> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>
> Dan
>
>
> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I have the Contended Locking fast notify bucket ready for review.
>>
>> The code changes in this bucket are the final piece in the triad
>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>> macro assembler changes in this bucket (yeah!), but there are
>> code review cleanups motivated by comments on other buckets, e.g.,
>> changing variables like 'Tally' -> 'tally'.
>>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8075171 Contended Locking fast notify bucket
>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>
>> Here is the JEP link:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>
>> Testing:
>>
>> - Aurora Adhoc RT/SVC baseline batch
>> - JPRT test jobs
>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>> - CallTimerGrid stress testing (in process)
>> - Aurora performance testing:
>> - out of the box for the "promotion" and 32-bit server configs
>> - heavy weight monitors for the "promotion" and 32-bit server configs
>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>> (in process)
>>
>> The hang somehow introduced by the "fast enter" bucket is still
>> unresolved, but progress is being made. That work is being tracked
>> by the following bug:
>>
>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>
>> You'll see a change that re-enables the "fast enter" bucket in this
>> webrev, but that change will not be pushed when we're done with the
>> review of this bucket unless JDK-8077392 is resolved.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Gory details about the changes are below...
>>
>> Dan
>>
>>
>> 8075171 summary of changes:
>>
>> src/share/vm/classfile/vmSymbols.hpp
>> - Add do_intrinsic() entries for _notify and _notifyAll
>>
>> src/share/vm/opto/library_call.cpp
>> - Add optional inline_notify() that is controlled by new
>> '-XX:[+-]InlineNotify' option
>>
>> src/share/vm/opto/runtime.cpp
>> src/share/vm/opto/runtime.hpp
>> - Add OptoRuntime::monitor_notify_C() and
>> OptoRuntime::monitor_notifyAll_C() functions to support
>> the new "fast notify" code paths
>> - Add new OptoRuntime::monitor_notify_Type() to support
>> the above two new functions
>>
>> src/share/vm/runtime/globals.hpp
>> - Add '-XX:[+-]InlineNotify' option; default option value is
>> enabled (true)
>>
>> src/share/vm/runtime/objectMonitor.cpp
>> src/share/vm/runtime/objectMonitor.hpp
>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>> into wrappers that call the new ObjectMonitor::INotify()
>> - Add new ObjectMonitor::INotify() to reduce code duplication
>> between "notify" and "notifyAll" code paths
>>
>> src/share/vm/runtime/sharedRuntime.cpp
>> - Temporarily re-enable the "fast enter" optimization in order
>> to do performance testing. JDK-8077392 is still unresolved,
>> but progress is being made.
>>
>> src/share/vm/runtime/synchronizer.cpp
>> src/share/vm/runtime/synchronizer.hpp
>> - Add ObjectSynchronizer::quick_notify() that implements the
>> new "fast notify" code paths
>> - The new code handles a couple of special cases where the
>> "notify" can be done without the heavy weight slow-path
>> (thread state transitions and other baggage)
>>
>>
>
From daniel.daugherty at oracle.com Wed Jul 8 18:06:31 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 08 Jul 2015 12:06:31 -0600
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <59B99866-C9BB-46F8-87C3-7E6FA8122227@oracle.com>
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
<59B99866-C9BB-46F8-87C3-7E6FA8122227@oracle.com>
Message-ID: <559D66A7.6040902@oracle.com>
On 7/8/15 11:53 AM, Karen Kinnear wrote:
> Dan,
>
> Looks good.
>
> Only comment is -
>
> In ObjectMonitor::INotify - lines 1668-1671
> the default value of policy is "2"
> -- which basically is "b" not "a" unless the EntryList is empty.
Nice catch! For folks on the alias that don't have this code
tattooed on the inside of their eyelids. This is the relevant code:
src/share/vm/runtime/objectMonitor.cpp:
136 static int Knob_MoveNotifyee = 2; // notify() -
disposition of notifyee
1659 void ObjectMonitor::INotify(Thread * Self) {
1660 const int policy = Knob_MoveNotifyee;
1668 // Disposition - what might we do with iterator ?
1669 // a. add it directly to the EntryList - either tail or head.
1670 // b. push it onto the front of the _cxq.
1671 // For now we use (a).
1710 } else if (policy == 2) { // prepend to cxq
I will update the comment.
Dan
>
> thanks,
> Karen
>
> On Jul 3, 2015, at 8:11 PM, Daniel D. Daugherty wrote:
>
>> Greetings,
>>
>> I've updated the patch for Contended Locking fast notify bucket
>> based on David H's and Karen's comments.
>>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8075171 Contended Locking fast notify bucket
>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>>
>> Here is the JEP link:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>
>> Testing:
>>
>> - RBT vm.quick batches (in process)
>> - JPRT test jobs
>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>> - CallTimerGrid stress testing (in process)
>>
>>
>> The changes in this round are in only four of the files:
>>
>> src/share/vm/opto/runtime.cpp
>>
>> - deleted comment about hashCode() that belongs in a different bucket
>>
>> src/share/vm/runtime/objectMonitor.cpp
>>
>> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
>> - cleanup recheck interval code
>> - ObjectMonitor::INotify() return type is now "void"
>> - delete duplicate comments, clarify/rewrite some comments
>>
>> src/share/vm/runtime/objectMonitor.hpp
>>
>> - ObjectMonitor::INotify() return type is now "void"
>>
>> src/share/vm/runtime/synchronizer.cpp
>>
>> - clarify/rewrite comments, add additional comments
>> - cleanup variables in ObjectSynchronizer::quick_notify
>> - refactor loop to be more clear
>> - delete unused enum MaximumRecheckInterval
>>
>> The easiest way to review the delta is to download the two patch
>> files and compare them in something like jfilemerge:
>>
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>>
>> Dan
>>
>>
>> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I have the Contended Locking fast notify bucket ready for review.
>>>
>>> The code changes in this bucket are the final piece in the triad
>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>> macro assembler changes in this bucket (yeah!), but there are
>>> code review cleanups motivated by comments on other buckets, e.g.,
>>> changing variables like 'Tally' -> 'tally'.
>>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8075171 Contended Locking fast notify bucket
>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>
>>> Here is the JEP link:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>
>>> Testing:
>>>
>>> - Aurora Adhoc RT/SVC baseline batch
>>> - JPRT test jobs
>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>> - CallTimerGrid stress testing (in process)
>>> - Aurora performance testing:
>>> - out of the box for the "promotion" and 32-bit server configs
>>> - heavy weight monitors for the "promotion" and 32-bit server configs
>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>> (in process)
>>>
>>> The hang somehow introduced by the "fast enter" bucket is still
>>> unresolved, but progress is being made. That work is being tracked
>>> by the following bug:
>>>
>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>
>>> You'll see a change that re-enables the "fast enter" bucket in this
>>> webrev, but that change will not be pushed when we're done with the
>>> review of this bucket unless JDK-8077392 is resolved.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>>
>>> 8075171 summary of changes:
>>>
>>> src/share/vm/classfile/vmSymbols.hpp
>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>
>>> src/share/vm/opto/library_call.cpp
>>> - Add optional inline_notify() that is controlled by new
>>> '-XX:[+-]InlineNotify' option
>>>
>>> src/share/vm/opto/runtime.cpp
>>> src/share/vm/opto/runtime.hpp
>>> - Add OptoRuntime::monitor_notify_C() and
>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>> the new "fast notify" code paths
>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>> the above two new functions
>>>
>>> src/share/vm/runtime/globals.hpp
>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>> enabled (true)
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>> src/share/vm/runtime/objectMonitor.hpp
>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>> into wrappers that call the new ObjectMonitor::INotify()
>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>> between "notify" and "notifyAll" code paths
>>>
>>> src/share/vm/runtime/sharedRuntime.cpp
>>> - Temporarily re-enable the "fast enter" optimization in order
>>> to do performance testing. JDK-8077392 is still unresolved,
>>> but progress is being made.
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>> src/share/vm/runtime/synchronizer.hpp
>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>> new "fast notify" code paths
>>> - The new code handles a couple of special cases where the
>>> "notify" can be done without the heavy weight slow-path
>>> (thread state transitions and other baggage)
>>>
>>>
From karen.kinnear at oracle.com Wed Jul 8 19:26:33 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 8 Jul 2015 15:26:33 -0400
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <5591EABE.6030301@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5588EA9F.3020001@oracle.com>
<725f7631-425d-4918-8a92-230005d5b5ec@default>
<558A1AE7.6010607@oracle.com>
<224EF327-B898-4DAC-9343-4FE238604276@oracle.com>
<558AD8AD.6020009@oracle.com> <558AF2AB.7040407@oracle.com>
<558B8B45.4060307@oracle.com> <558BA1CC.6040100@oracle.com>
<558BA53E.1010600@oracle.com> <558C312F.4070606@oracle.com>
<558CEB04.5040905@oracle.com> <558D9423.1010903@oracle.com>
<5591EABE.6030301@oracle.com>
Message-ID: <99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
David,
It is true that this option will not handle options that are targeted at the java
launcher. And we should make that very clear in documentation - perhaps even spelling
out which options are handled by the java launcher. Worth double-checking that
with Kumar.
There is another rfe going in for the launcher itself - which is JDK-8027634.
That will cover options to the java launcher as well as to the vm and jdk via @argfiles, they same
way apparently javac handles long command-lines today.
Unfortunately that option only works for the specific launchers that support it.
For folks who embed the jvm in their own applications, e.g. other language users,
the new vm option allows them to pass in arguments to the jvm (and then up to the jdk)
which the java launcher changes doesn't make possible.
It might make sense as we figure out how to document this, to document the java
launcher @argfiles as the usual approach for customers running java.
And to document the new VM option explicitly for those who have their own launchers
and call JNI_CreateJavaVM?
Ron & Dmitry,
A couple of test requests (you may already have these, I didn't see a code review out for 8073331)
1) tests with a jni launcher that calls JNI_CreateJavaVM
2) is there a maximum length to the options read in from the file?
Also - Dmitry - can you please share your tests for this option with Henry Jen - he may want to modify them
for tests for the java @argfiles.
And we'll want to test the two new options together :-)
thanks,
Karen
On Jun 29, 2015, at 9:02 PM, David Holmes wrote:
> On 27/06/2015 4:04 AM, Daniel D. Daugherty wrote:
>> On 6/26/15 12:02 AM, David Holmes wrote:
>>> On 26/06/2015 2:49 AM, Daniel D. Daugherty wrote:
>>>> On 6/25/15 12:52 AM, David Holmes wrote:
>>>>> On 25/06/2015 4:38 PM, Dmitry Dmitriev wrote:
>>>>>> Hello David,
>>>>>>
>>>>>> I mean that we can define "-Dmy.property=value" inside VM Option file.
>>>>>
>>>>> Okay - that isn't necessarily a good thing. This is blurring the
>>>>> division of responsibility between the launcher and the VM when it
>>>>> comes to argument processing. I don't see why a VM option file should
>>>>> need to handle -Dxxx arguments - that suggests a need for a more
>>>>> general command-file approach processed by the launcher.
>>>>
>>>> Hmmm... The above makes it sound like you think only the launcher
>>>> handles '-DXXX' options.
>>>
>>> No I'm aware that some properties get passed through specifically for
>>> the VM to act upon (though arguably that was a bad decision back in
>>> the day and the launcher could have used the properties to set VM
>>> specific options); and also that the VM will set some properties for
>>> the launcher and also JDK libs to act upon. This highlights just how
>>> messy property processing is. By allowing properties to be set in a
>>> VMOption file you are increasing the level of mess - in particular if
>>> a property is examined by the launcher before it creates the VM, then
>>> that property can not be specified in the VMOptions file. So now you
>>> have something that will often work but for some special cases won't
>>> work.
>>
>> Two things:
>>
>> 1)
>>
>> > in particular if a property is examined by the launcher before it
>> > creates the VM, then that property can not be specified in the
>> > VMOptions file.
>>
>> The new support for the '-XX:VMOptionsFile=foo' option simply
>> provides another path to get options into our wonderfully
>> complicated options processing mechanism. It uses the same
>> processing path as the existing VM cmd line options mechanism
>> so it has the same capabilities (and pitfalls) as that
>> mechanism.
>
> I don't quite see it that way. It isn't at all obvious to anyone what options on a long complex command-line get handled by whom and when. Anything in the VMOptions file will be invisible to the launcher, but that won't be obvious either.
>
>> If there is an option that must be handled by the launcher,
>> then that option cannot be specified on the cmd line (as
>> passed by the JNI invoke stuff). The new VMOptions file
>> support is similarly limited. This same limitation applies
>> to any other means of invoking the JVM without using our
>> launcher. Nothing new here.
>
> Your use of "cmd line" is confusing me here. The "cmd line" is what the user types in their shell and can contain any option. What options you can pass via the JNI invocation API is quite different to a command-line. I agree the VMOptions file is akin to the options you could pass via the invocation API to be processed only by the VM.
>
>> I believe Ron's write-up discusses launcher only options and
>> when he returns next week he should be able to attach that
>> document to the bug report.
>>
>> 2)
>>
>> > the VM will set some properties for the launcher and also
>> > JDK libs to act upon
>>
>> I can see how the VM can set properties for the JDK libs
>> and that is exactly what supporting the -Dfoo stuff is all
>> about, but how/where is the VM setting properties for the
>> launcher?
>
> Sorry my mistake. I was mis-remembering what we do to force headless mode in some cases. But the launcher isn't involved in that. The launcher can't see properties set by the VM (unless it uses JNI to access the Java level data structures).
>
>>
>>>
>>> Just makes me wonder whether this is something that should be handled
>>> by the VM or by the launcher. Or (dare I say it) even by a shell
>>> script. ;-)
>>
>> At least one version of Ron's write-up talked about where
>> to put this new mechanism between the launcher and the
>> VM... We'll have to see what the current draft says...
>>
>> Shell script? Bite your tongue! :-)
>
> :)
>
> Cheers,
> David
>
>
>> Dan
>>
>>
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>> That is not correct... Here's the current
>>>> code:
>>>>
>>>> src/share/vm/runtime/arguments.cpp
>>>>
>>>> 2691 // -D
>>>> 2692 } else if (match_option(option, "-D", &tail)) {
>>>> 2693 const char* value;
>>>> 2694 if (match_option(option, "-Djava.endorsed.dirs=",
>>>> &value) &&
>>>> 2695 *value!= '\0' && strcmp(value, "\"\"") != 0) {
>>>> 2696 // abort if -Djava.endorsed.dirs is set
>>>> 2697 jio_fprintf(defaultStream::output_stream(),
>>>> 2698 "-Djava.endorsed.dirs=%s is not supported. Endorsed
>>>> standards
>>>> and standalone APIs\n"
>>>> 2699 "in modular form will be supported via the concept of
>>>> upgradea
>>>> ble modules.\n", value);
>>>> 2700 return JNI_EINVAL;
>>>> 2701 }
>>>> 2702 if (match_option(option, "-Djava.ext.dirs=", &value) &&
>>>> 2703 *value != '\0' && strcmp(value, "\"\"") != 0) {
>>>> 2704 // abort if -Djava.ext.dirs is set
>>>> 2705 jio_fprintf(defaultStream::output_stream(),
>>>> 2706 "-Djava.ext.dirs=%s is not supported. Use -classpath
>>>> instead.
>>>> \n", value);
>>>> 2707 return JNI_EINVAL;
>>>> 2708 }
>>>> 2709
>>>> 2710 if (!add_property(tail)) {
>>>> 2711 return JNI_ENOMEM;
>>>> 2712 }
>>>> 2713 // Out of the box management support
>>>> 2714 if (match_option(option, "-Dcom.sun.management",
>>>> &tail)) {
>>>> 2715 #if INCLUDE_MANAGEMENT
>>>> 2716 if (FLAG_SET_CMDLINE(bool, ManagementServer, true) !=
>>>> Flag::SUCC
>>>> ESS) {
>>>> 2717 return JNI_EINVAL;
>>>> 2718 }
>>>> 2719 #else
>>>> 2720 jio_fprintf(defaultStream::output_stream(),
>>>> 2721 "-Dcom.sun.management is not supported in this
>>>> VM.\n");
>>>> 2722 return JNI_ERR;
>>>> 2723 #endif
>>>> 2724 }
>>>>
>>>>
>>>> L2710 is where we add a property that is not already
>>>> handled by special logic above that.
>>>>
>>>> $ java -showversion -XX:+PrintVMOptions -Dmy.property="This is my
>>>> special property." DumpMyProperty
>>>> VM option '+PrintVMOptions'
>>>> java version "1.9.0-ea"
>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>
>>>> my.property=This is my special property.
>>>>
>>>>
>>>> In the above example, the "my.property" Java property is parsed
>>>> by the above code in the VM. The launcher doesn't care about this
>>>> particular property.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Dmitry
>>>>>>
>>>>>> On 25.06.2015 8:01, David Holmes wrote:
>>>>>>> On 25/06/2015 4:10 AM, Dmitry Dmitriev wrote:
>>>>>>>> Hello Dan,
>>>>>>>> I just want to add following: new VM Options file feature allow to
>>>>>>>> define property inside option file.
>>>>>>>
>>>>>>> What do you mean by that?
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dmitry
>>>>>>>>
>>>>>>>> On 24.06.2015 19:19, Daniel D. Daugherty wrote:
>>>>>>>>> On 6/23/15 10:43 PM, John Rose wrote:
>>>>>>>>>> On Jun 23, 2015, at 7:50 PM, David Holmes
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>> On 24/06/2015 3:43 AM, Ron Durbin wrote:
>>>>>>>>>>>> David,
>>>>>>>>>>>>
>>>>>>>>>>>> The '-XX:Flags' option was considered during the research phase
>>>>>>>>>>>> of this project and was rejected because of its limitations. The
>>>>>>>>>>>> '-XX:Flags' option only works for boolean flag options and it
>>>>>>>>>>>> uses a different syntax for the options than the command line.
>>>>>>>>>>>> For example, '-XX:+UseSerialGC' would be specified as
>>>>>>>>>>>> '+UseSerialGC'
>>>>>>>>>>>> in the '-XX:Flags' option file.
>>>>>>>>>>> I'm a little surprised the Flags option wasn't extended to cover
>>>>>>>>>>> these additional requirements. But presumably it should now be
>>>>>>>>>>> deprecated as we (again presumably) don't want to have two
>>>>>>>>>>> mechanisms for doing this.
>>>>>>>>>> I thought the Flags option used to handle any command line
>>>>>>>>>> options,
>>>>>>>>>> and like David I'm surprised the right answer is to get rid of it
>>>>>>>>>> and
>>>>>>>>>> make a new option that does what I think the Flags option
>>>>>>>>>> should be
>>>>>>>>>> doing.
>>>>>>>>>>
>>>>>>>>>> ? John
>>>>>>>>>
>>>>>>>>> Greetings,
>>>>>>>>>
>>>>>>>>> Ron is out of the office until next week so I'll provide a little
>>>>>>>>> bit of background...
>>>>>>>>>
>>>>>>>>> Ron has a detailed write-up documenting all the research that he
>>>>>>>>> did on the various command line option mechanisms. We had planned
>>>>>>>>> to attach that write-up to the bug report, but we dropped the ball
>>>>>>>>> (Sorry Mary!) After Ron returns, we'll make a final editing pass
>>>>>>>>> on the document and attach it to the bug report.
>>>>>>>>>
>>>>>>>>> I fleshed out the '-XX:Flags' test cases that Ron posted earlier
>>>>>>>>> in the thread:
>>>>>>>>>
>>>>>>>>> $ more flags.input.*::::::::::::::
>>>>>>>>> flags.input.boolean
>>>>>>>>> ::::::::::::::
>>>>>>>>> +UseSerialGC
>>>>>>>>> ::::::::::::::
>>>>>>>>> flags.input.ccstr
>>>>>>>>> ::::::::::::::
>>>>>>>>> ErrorFile=my_error_file
>>>>>>>>> ::::::::::::::
>>>>>>>>> flags.input.uintx
>>>>>>>>> ::::::::::::::
>>>>>>>>> MinRAMFraction=8
>>>>>>>>>
>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.boolean -version
>>>>>>>>> VM option '+UseSerialGC'
>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>> VM option 'Flags=flags.input.boolean'
>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>
>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.ccstr -version
>>>>>>>>> VM option 'ErrorFile=my_error_file'
>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>> VM option 'Flags=flags.input.ccstr'
>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>
>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.uintx -version
>>>>>>>>> VM option 'MinRAMFraction=8'
>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>> VM option 'Flags=flags.input.uintx'
>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It looks like the '-XX:Flags' option does work for 'bool', 'uintx'
>>>>>>>>> and 'ccstr' options. Clearly Ron and I didn't remember the exact
>>>>>>>>> reason that he ruled out using the '-XX:Flags' option. This part
>>>>>>>>> of the review thread will have to be resolved after Ron returns.
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>
>>>>>>
>>>>
>>
From ioi.lam at oracle.com Wed Jul 8 19:46:20 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 08 Jul 2015 12:46:20 -0700
Subject: RFR(XS) 8130669: VM prohibits methods with return values
In-Reply-To: <559D2666.5010209@oracle.com>
References: <559D2666.5010209@oracle.com>
Message-ID: <559D7E0C.6030102@oracle.com>
Hi Harold,
Is there any reason why the ignoredClinit needs to be written in a jcod
file and not a jasm file? jasm files would be a lot easier to read and
maintain than jcod.
Thanks
- Ioi
On 7/8/15 6:32 AM, harold seigel wrote:
> Hi,
>
> Please review this small change to fix bug JDK-8130669. The JVM
> incorrectly throws ClassFormatError exceptions for non-void methods
> named . But, the JVM Spec 8 says that such methods
> should be ignored. See
> http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9
> for details.
>
> The fix changes the JVM to, in this case, only throw ClassFormatError
> exceptions for non-void methods.
>
> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
>
> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
>
> The fix was tested with JCK Lang and VM tests, the UTE quick and
> split_verifier tests, and the hotspot, java/io, java/lang, and
> java/util JTreg tests.
>
> Thanks, Harold
From harold.seigel at oracle.com Wed Jul 8 19:49:28 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 08 Jul 2015 15:49:28 -0400
Subject: RFR(XS) 8130669: VM prohibits methods with return values
In-Reply-To: <559D7E0C.6030102@oracle.com>
References: <559D2666.5010209@oracle.com> <559D7E0C.6030102@oracle.com>
Message-ID: <559D7EC8.8000005@oracle.com>
Hi Ioi,
I'll rewrite it in .jasm. I just took the .jcod test from the test case
attached to the bug.
Thanks, Harold
On 7/8/2015 3:46 PM, Ioi Lam wrote:
> Hi Harold,
>
> Is there any reason why the ignoredClinit needs to be written in a
> jcod file and not a jasm file? jasm files would be a lot easier to
> read and maintain than jcod.
>
> Thanks
> - Ioi
>
> On 7/8/15 6:32 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix bug JDK-8130669. The JVM
>> incorrectly throws ClassFormatError exceptions for non-void methods
>> named . But, the JVM Spec 8 says that such methods
>> should be ignored. See
>> http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9 for
>> details.
>>
>> The fix changes the JVM to, in this case, only throw ClassFormatError
>> exceptions for non-void methods.
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
>>
>> The fix was tested with JCK Lang and VM tests, the UTE quick and
>> split_verifier tests, and the hotspot, java/io, java/lang, and
>> java/util JTreg tests.
>>
>> Thanks, Harold
>
From harold.seigel at oracle.com Wed Jul 8 20:08:37 2015
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 08 Jul 2015 16:08:37 -0400
Subject: RFR(XS) 8130669: VM prohibits methods with return values
In-Reply-To: <559D7E0C.6030102@oracle.com>
References: <559D2666.5010209@oracle.com> <559D7E0C.6030102@oracle.com>
Message-ID: <559D8345.5060709@oracle.com>
Hi Ioi,
Here's an updated webrev with ignoredClinit as a .jasm file. Please let
me know if it looks okay.
http://cr.openjdk.java.net/~hseigel/bug_8130669.1/
Thanks, Harold
On 7/8/2015 3:46 PM, Ioi Lam wrote:
> Hi Harold,
>
> Is there any reason why the ignoredClinit needs to be written in a
> jcod file and not a jasm file? jasm files would be a lot easier to
> read and maintain than jcod.
>
> Thanks
> - Ioi
>
> On 7/8/15 6:32 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this small change to fix bug JDK-8130669. The JVM
>> incorrectly throws ClassFormatError exceptions for non-void methods
>> named . But, the JVM Spec 8 says that such methods
>> should be ignored. See
>> http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9 for
>> details.
>>
>> The fix changes the JVM to, in this case, only throw ClassFormatError
>> exceptions for non-void methods.
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
>>
>> The fix was tested with JCK Lang and VM tests, the UTE quick and
>> split_verifier tests, and the hotspot, java/io, java/lang, and
>> java/util JTreg tests.
>>
>> Thanks, Harold
>
From dmitry.dmitriev at oracle.com Wed Jul 8 20:29:58 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Wed, 8 Jul 2015 23:29:58 +0300
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5588EA9F.3020001@oracle.com>
<725f7631-425d-4918-8a92-230005d5b5ec@default>
<558A1AE7.6010607@oracle.com>
<224EF327-B898-4DAC-9343-4FE238604276@oracle.com>
<558AD8AD.6020009@oracle.com> <558AF2AB.7040407@oracle.com>
<558B8B45.4060307@oracle.com> <558BA1CC.6040100@oracle.com>
<558BA53E.1010600@oracle.com> <558C312F.4070606@oracle.com>
<558CEB04.5040905@oracle.com> <558D9423.1010903@oracle.com>
<5591EABE.6030301@oracle.com>
<99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
Message-ID: <559D8846.7060803@oracle.com>
Hello Karen,
On 08.07.2015 22:26, Karen Kinnear wrote:
> David,
>
> It is true that this option will not handle options that are targeted at the java
> launcher. And we should make that very clear in documentation - perhaps even spelling
> out which options are handled by the java launcher. Worth double-checking that
> with Kumar.
>
> There is another rfe going in for the launcher itself - which is JDK-8027634.
> That will cover options to the java launcher as well as to the vm and jdk via @argfiles, they same
> way apparently javac handles long command-lines today.
>
> Unfortunately that option only works for the specific launchers that support it.
> For folks who embed the jvm in their own applications, e.g. other language users,
> the new vm option allows them to pass in arguments to the jvm (and then up to the jdk)
> which the java launcher changes doesn't make possible.
>
> It might make sense as we figure out how to document this, to document the java
> launcher @argfiles as the usual approach for customers running java.
>
> And to document the new VM option explicitly for those who have their own launchers
> and call JNI_CreateJavaVM?
>
> Ron & Dmitry,
>
> A couple of test requests (you may already have these, I didn't see a code review out for 8073331)
> 1) tests with a jni launcher that calls JNI_CreateJavaVM
No, I don't have such test, because I don't think from that point of
view. I will think about that.
> 2) is there a maximum length to the options read in from the file?
The current implemented limitations are following: only one VM option
file can be specified, maximum size of the file is 1024 bytes, up to 64
VM options
>
> Also - Dmitry - can you please share your tests for this option with Henry Jen - he may want to modify them
> for tests for the java @argfiles.
>
> And we'll want to test the two new options together :-)
Yes, sure. I will contact with Henry and share tests.
Thanks,
Dmitry
>
> thanks,
> Karen
>
> On Jun 29, 2015, at 9:02 PM, David Holmes wrote:
>
>> On 27/06/2015 4:04 AM, Daniel D. Daugherty wrote:
>>> On 6/26/15 12:02 AM, David Holmes wrote:
>>>> On 26/06/2015 2:49 AM, Daniel D. Daugherty wrote:
>>>>> On 6/25/15 12:52 AM, David Holmes wrote:
>>>>>> On 25/06/2015 4:38 PM, Dmitry Dmitriev wrote:
>>>>>>> Hello David,
>>>>>>>
>>>>>>> I mean that we can define "-Dmy.property=value" inside VM Option file.
>>>>>> Okay - that isn't necessarily a good thing. This is blurring the
>>>>>> division of responsibility between the launcher and the VM when it
>>>>>> comes to argument processing. I don't see why a VM option file should
>>>>>> need to handle -Dxxx arguments - that suggests a need for a more
>>>>>> general command-file approach processed by the launcher.
>>>>> Hmmm... The above makes it sound like you think only the launcher
>>>>> handles '-DXXX' options.
>>>> No I'm aware that some properties get passed through specifically for
>>>> the VM to act upon (though arguably that was a bad decision back in
>>>> the day and the launcher could have used the properties to set VM
>>>> specific options); and also that the VM will set some properties for
>>>> the launcher and also JDK libs to act upon. This highlights just how
>>>> messy property processing is. By allowing properties to be set in a
>>>> VMOption file you are increasing the level of mess - in particular if
>>>> a property is examined by the launcher before it creates the VM, then
>>>> that property can not be specified in the VMOptions file. So now you
>>>> have something that will often work but for some special cases won't
>>>> work.
>>> Two things:
>>>
>>> 1)
>>>
>>>> in particular if a property is examined by the launcher before it
>>>> creates the VM, then that property can not be specified in the
>>>> VMOptions file.
>>> The new support for the '-XX:VMOptionsFile=foo' option simply
>>> provides another path to get options into our wonderfully
>>> complicated options processing mechanism. It uses the same
>>> processing path as the existing VM cmd line options mechanism
>>> so it has the same capabilities (and pitfalls) as that
>>> mechanism.
>> I don't quite see it that way. It isn't at all obvious to anyone what options on a long complex command-line get handled by whom and when. Anything in the VMOptions file will be invisible to the launcher, but that won't be obvious either.
>>
>>> If there is an option that must be handled by the launcher,
>>> then that option cannot be specified on the cmd line (as
>>> passed by the JNI invoke stuff). The new VMOptions file
>>> support is similarly limited. This same limitation applies
>>> to any other means of invoking the JVM without using our
>>> launcher. Nothing new here.
>> Your use of "cmd line" is confusing me here. The "cmd line" is what the user types in their shell and can contain any option. What options you can pass via the JNI invocation API is quite different to a command-line. I agree the VMOptions file is akin to the options you could pass via the invocation API to be processed only by the VM.
>>
>>> I believe Ron's write-up discusses launcher only options and
>>> when he returns next week he should be able to attach that
>>> document to the bug report.
>>>
>>> 2)
>>>
>>>> the VM will set some properties for the launcher and also
>>>> JDK libs to act upon
>>> I can see how the VM can set properties for the JDK libs
>>> and that is exactly what supporting the -Dfoo stuff is all
>>> about, but how/where is the VM setting properties for the
>>> launcher?
>> Sorry my mistake. I was mis-remembering what we do to force headless mode in some cases. But the launcher isn't involved in that. The launcher can't see properties set by the VM (unless it uses JNI to access the Java level data structures).
>>
>>>> Just makes me wonder whether this is something that should be handled
>>>> by the VM or by the launcher. Or (dare I say it) even by a shell
>>>> script. ;-)
>>> At least one version of Ron's write-up talked about where
>>> to put this new mechanism between the launcher and the
>>> VM... We'll have to see what the current draft says...
>>>
>>> Shell script? Bite your tongue! :-)
>> :)
>>
>> Cheers,
>> David
>>
>>
>>> Dan
>>>
>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>> That is not correct... Here's the current
>>>>> code:
>>>>>
>>>>> src/share/vm/runtime/arguments.cpp
>>>>>
>>>>> 2691 // -D
>>>>> 2692 } else if (match_option(option, "-D", &tail)) {
>>>>> 2693 const char* value;
>>>>> 2694 if (match_option(option, "-Djava.endorsed.dirs=",
>>>>> &value) &&
>>>>> 2695 *value!= '\0' && strcmp(value, "\"\"") != 0) {
>>>>> 2696 // abort if -Djava.endorsed.dirs is set
>>>>> 2697 jio_fprintf(defaultStream::output_stream(),
>>>>> 2698 "-Djava.endorsed.dirs=%s is not supported. Endorsed
>>>>> standards
>>>>> and standalone APIs\n"
>>>>> 2699 "in modular form will be supported via the concept of
>>>>> upgradea
>>>>> ble modules.\n", value);
>>>>> 2700 return JNI_EINVAL;
>>>>> 2701 }
>>>>> 2702 if (match_option(option, "-Djava.ext.dirs=", &value) &&
>>>>> 2703 *value != '\0' && strcmp(value, "\"\"") != 0) {
>>>>> 2704 // abort if -Djava.ext.dirs is set
>>>>> 2705 jio_fprintf(defaultStream::output_stream(),
>>>>> 2706 "-Djava.ext.dirs=%s is not supported. Use -classpath
>>>>> instead.
>>>>> \n", value);
>>>>> 2707 return JNI_EINVAL;
>>>>> 2708 }
>>>>> 2709
>>>>> 2710 if (!add_property(tail)) {
>>>>> 2711 return JNI_ENOMEM;
>>>>> 2712 }
>>>>> 2713 // Out of the box management support
>>>>> 2714 if (match_option(option, "-Dcom.sun.management",
>>>>> &tail)) {
>>>>> 2715 #if INCLUDE_MANAGEMENT
>>>>> 2716 if (FLAG_SET_CMDLINE(bool, ManagementServer, true) !=
>>>>> Flag::SUCC
>>>>> ESS) {
>>>>> 2717 return JNI_EINVAL;
>>>>> 2718 }
>>>>> 2719 #else
>>>>> 2720 jio_fprintf(defaultStream::output_stream(),
>>>>> 2721 "-Dcom.sun.management is not supported in this
>>>>> VM.\n");
>>>>> 2722 return JNI_ERR;
>>>>> 2723 #endif
>>>>> 2724 }
>>>>>
>>>>>
>>>>> L2710 is where we add a property that is not already
>>>>> handled by special logic above that.
>>>>>
>>>>> $ java -showversion -XX:+PrintVMOptions -Dmy.property="This is my
>>>>> special property." DumpMyProperty
>>>>> VM option '+PrintVMOptions'
>>>>> java version "1.9.0-ea"
>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>
>>>>> my.property=This is my special property.
>>>>>
>>>>>
>>>>> In the above example, the "my.property" Java property is parsed
>>>>> by the above code in the VM. The launcher doesn't care about this
>>>>> particular property.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>>
>>>>>>> On 25.06.2015 8:01, David Holmes wrote:
>>>>>>>> On 25/06/2015 4:10 AM, Dmitry Dmitriev wrote:
>>>>>>>>> Hello Dan,
>>>>>>>>> I just want to add following: new VM Options file feature allow to
>>>>>>>>> define property inside option file.
>>>>>>>> What do you mean by that?
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dmitry
>>>>>>>>>
>>>>>>>>> On 24.06.2015 19:19, Daniel D. Daugherty wrote:
>>>>>>>>>> On 6/23/15 10:43 PM, John Rose wrote:
>>>>>>>>>>> On Jun 23, 2015, at 7:50 PM, David Holmes
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On 24/06/2015 3:43 AM, Ron Durbin wrote:
>>>>>>>>>>>>> David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The '-XX:Flags' option was considered during the research phase
>>>>>>>>>>>>> of this project and was rejected because of its limitations. The
>>>>>>>>>>>>> '-XX:Flags' option only works for boolean flag options and it
>>>>>>>>>>>>> uses a different syntax for the options than the command line.
>>>>>>>>>>>>> For example, '-XX:+UseSerialGC' would be specified as
>>>>>>>>>>>>> '+UseSerialGC'
>>>>>>>>>>>>> in the '-XX:Flags' option file.
>>>>>>>>>>>> I'm a little surprised the Flags option wasn't extended to cover
>>>>>>>>>>>> these additional requirements. But presumably it should now be
>>>>>>>>>>>> deprecated as we (again presumably) don't want to have two
>>>>>>>>>>>> mechanisms for doing this.
>>>>>>>>>>> I thought the Flags option used to handle any command line
>>>>>>>>>>> options,
>>>>>>>>>>> and like David I'm surprised the right answer is to get rid of it
>>>>>>>>>>> and
>>>>>>>>>>> make a new option that does what I think the Flags option
>>>>>>>>>>> should be
>>>>>>>>>>> doing.
>>>>>>>>>>>
>>>>>>>>>>> ? John
>>>>>>>>>> Greetings,
>>>>>>>>>>
>>>>>>>>>> Ron is out of the office until next week so I'll provide a little
>>>>>>>>>> bit of background...
>>>>>>>>>>
>>>>>>>>>> Ron has a detailed write-up documenting all the research that he
>>>>>>>>>> did on the various command line option mechanisms. We had planned
>>>>>>>>>> to attach that write-up to the bug report, but we dropped the ball
>>>>>>>>>> (Sorry Mary!) After Ron returns, we'll make a final editing pass
>>>>>>>>>> on the document and attach it to the bug report.
>>>>>>>>>>
>>>>>>>>>> I fleshed out the '-XX:Flags' test cases that Ron posted earlier
>>>>>>>>>> in the thread:
>>>>>>>>>>
>>>>>>>>>> $ more flags.input.*::::::::::::::
>>>>>>>>>> flags.input.boolean
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> +UseSerialGC
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> flags.input.ccstr
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> ErrorFile=my_error_file
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> flags.input.uintx
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> MinRAMFraction=8
>>>>>>>>>>
>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.boolean -version
>>>>>>>>>> VM option '+UseSerialGC'
>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>> VM option 'Flags=flags.input.boolean'
>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>
>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.ccstr -version
>>>>>>>>>> VM option 'ErrorFile=my_error_file'
>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>> VM option 'Flags=flags.input.ccstr'
>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>
>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.uintx -version
>>>>>>>>>> VM option 'MinRAMFraction=8'
>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>> VM option 'Flags=flags.input.uintx'
>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It looks like the '-XX:Flags' option does work for 'bool', 'uintx'
>>>>>>>>>> and 'ccstr' options. Clearly Ron and I didn't remember the exact
>>>>>>>>>> reason that he ruled out using the '-XX:Flags' option. This part
>>>>>>>>>> of the review thread will have to be resolved after Ron returns.
>>>>>>>>>>
>>>>>>>>>> Dan
From karen.kinnear at oracle.com Wed Jul 8 20:35:10 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 8 Jul 2015 16:35:10 -0400
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <559D8846.7060803@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5588EA9F.3020001@oracle.com>
<725f7631-425d-4918-8a92-230005d5b5ec@default>
<558A1AE7.6010607@oracle.com>
<224EF327-B898-4DAC-9343-4FE238604276@oracle.com>
<558AD8AD.6020009@oracle.com> <558AF2AB.7040407@oracle.com>
<558B8B45.4060307@oracle.com> <558BA1CC.6040100@oracle.com>
<558BA53E.1010600@oracle.com> <558C312F.4070606@oracle.com>
<558CEB04.5040905@oracle.com> <558D9423.1010903@oracle.com>
<5591EABE.6030301@oracle.com>
<99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
<559D8846.7060803@oracle.com>
Message-ID: <1F03563A-C8C5-4B08-8DDC-34A89785DE44@oracle.com>
Many thanks Dmitry!
Karen
On Jul 8, 2015, at 4:29 PM, Dmitry Dmitriev wrote:
> Hello Karen,
>
> On 08.07.2015 22:26, Karen Kinnear wrote:
>> David,
>>
>> It is true that this option will not handle options that are targeted at the java
>> launcher. And we should make that very clear in documentation - perhaps even spelling
>> out which options are handled by the java launcher. Worth double-checking that
>> with Kumar.
>>
>> There is another rfe going in for the launcher itself - which is JDK-8027634.
>> That will cover options to the java launcher as well as to the vm and jdk via @argfiles, they same
>> way apparently javac handles long command-lines today.
>>
>> Unfortunately that option only works for the specific launchers that support it.
>> For folks who embed the jvm in their own applications, e.g. other language users,
>> the new vm option allows them to pass in arguments to the jvm (and then up to the jdk)
>> which the java launcher changes doesn't make possible.
>>
>> It might make sense as we figure out how to document this, to document the java
>> launcher @argfiles as the usual approach for customers running java.
>>
>> And to document the new VM option explicitly for those who have their own launchers
>> and call JNI_CreateJavaVM?
>>
>> Ron & Dmitry,
>>
>> A couple of test requests (you may already have these, I didn't see a code review out for 8073331)
>> 1) tests with a jni launcher that calls JNI_CreateJavaVM
> No, I don't have such test, because I don't think from that point of view. I will think about that.
>> 2) is there a maximum length to the options read in from the file?
> The current implemented limitations are following: only one VM option file can be specified, maximum size of the file is 1024 bytes, up to 64 VM options
>>
>> Also - Dmitry - can you please share your tests for this option with Henry Jen - he may want to modify them
>> for tests for the java @argfiles.
>>
>> And we'll want to test the two new options together :-)
> Yes, sure. I will contact with Henry and share tests.
>
> Thanks,
> Dmitry
>
>>
>> thanks,
>> Karen
>>
>> On Jun 29, 2015, at 9:02 PM, David Holmes wrote:
>>
>>> On 27/06/2015 4:04 AM, Daniel D. Daugherty wrote:
>>>> On 6/26/15 12:02 AM, David Holmes wrote:
>>>>> On 26/06/2015 2:49 AM, Daniel D. Daugherty wrote:
>>>>>> On 6/25/15 12:52 AM, David Holmes wrote:
>>>>>>> On 25/06/2015 4:38 PM, Dmitry Dmitriev wrote:
>>>>>>>> Hello David,
>>>>>>>>
>>>>>>>> I mean that we can define "-Dmy.property=value" inside VM Option file.
>>>>>>> Okay - that isn't necessarily a good thing. This is blurring the
>>>>>>> division of responsibility between the launcher and the VM when it
>>>>>>> comes to argument processing. I don't see why a VM option file should
>>>>>>> need to handle -Dxxx arguments - that suggests a need for a more
>>>>>>> general command-file approach processed by the launcher.
>>>>>> Hmmm... The above makes it sound like you think only the launcher
>>>>>> handles '-DXXX' options.
>>>>> No I'm aware that some properties get passed through specifically for
>>>>> the VM to act upon (though arguably that was a bad decision back in
>>>>> the day and the launcher could have used the properties to set VM
>>>>> specific options); and also that the VM will set some properties for
>>>>> the launcher and also JDK libs to act upon. This highlights just how
>>>>> messy property processing is. By allowing properties to be set in a
>>>>> VMOption file you are increasing the level of mess - in particular if
>>>>> a property is examined by the launcher before it creates the VM, then
>>>>> that property can not be specified in the VMOptions file. So now you
>>>>> have something that will often work but for some special cases won't
>>>>> work.
>>>> Two things:
>>>>
>>>> 1)
>>>>
>>>>> in particular if a property is examined by the launcher before it
>>>>> creates the VM, then that property can not be specified in the
>>>>> VMOptions file.
>>>> The new support for the '-XX:VMOptionsFile=foo' option simply
>>>> provides another path to get options into our wonderfully
>>>> complicated options processing mechanism. It uses the same
>>>> processing path as the existing VM cmd line options mechanism
>>>> so it has the same capabilities (and pitfalls) as that
>>>> mechanism.
>>> I don't quite see it that way. It isn't at all obvious to anyone what options on a long complex command-line get handled by whom and when. Anything in the VMOptions file will be invisible to the launcher, but that won't be obvious either.
>>>
>>>> If there is an option that must be handled by the launcher,
>>>> then that option cannot be specified on the cmd line (as
>>>> passed by the JNI invoke stuff). The new VMOptions file
>>>> support is similarly limited. This same limitation applies
>>>> to any other means of invoking the JVM without using our
>>>> launcher. Nothing new here.
>>> Your use of "cmd line" is confusing me here. The "cmd line" is what the user types in their shell and can contain any option. What options you can pass via the JNI invocation API is quite different to a command-line. I agree the VMOptions file is akin to the options you could pass via the invocation API to be processed only by the VM.
>>>
>>>> I believe Ron's write-up discusses launcher only options and
>>>> when he returns next week he should be able to attach that
>>>> document to the bug report.
>>>>
>>>> 2)
>>>>
>>>>> the VM will set some properties for the launcher and also
>>>>> JDK libs to act upon
>>>> I can see how the VM can set properties for the JDK libs
>>>> and that is exactly what supporting the -Dfoo stuff is all
>>>> about, but how/where is the VM setting properties for the
>>>> launcher?
>>> Sorry my mistake. I was mis-remembering what we do to force headless mode in some cases. But the launcher isn't involved in that. The launcher can't see properties set by the VM (unless it uses JNI to access the Java level data structures).
>>>
>>>>> Just makes me wonder whether this is something that should be handled
>>>>> by the VM or by the launcher. Or (dare I say it) even by a shell
>>>>> script. ;-)
>>>> At least one version of Ron's write-up talked about where
>>>> to put this new mechanism between the launcher and the
>>>> VM... We'll have to see what the current draft says...
>>>>
>>>> Shell script? Bite your tongue! :-)
>>> :)
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>> Dan
>>>>
>>>>
>>>>> Cheers,
>>>>> David
>>>>> -----
>>>>>
>>>>>> That is not correct... Here's the current
>>>>>> code:
>>>>>>
>>>>>> src/share/vm/runtime/arguments.cpp
>>>>>>
>>>>>> 2691 // -D
>>>>>> 2692 } else if (match_option(option, "-D", &tail)) {
>>>>>> 2693 const char* value;
>>>>>> 2694 if (match_option(option, "-Djava.endorsed.dirs=",
>>>>>> &value) &&
>>>>>> 2695 *value!= '\0' && strcmp(value, "\"\"") != 0) {
>>>>>> 2696 // abort if -Djava.endorsed.dirs is set
>>>>>> 2697 jio_fprintf(defaultStream::output_stream(),
>>>>>> 2698 "-Djava.endorsed.dirs=%s is not supported. Endorsed
>>>>>> standards
>>>>>> and standalone APIs\n"
>>>>>> 2699 "in modular form will be supported via the concept of
>>>>>> upgradea
>>>>>> ble modules.\n", value);
>>>>>> 2700 return JNI_EINVAL;
>>>>>> 2701 }
>>>>>> 2702 if (match_option(option, "-Djava.ext.dirs=", &value) &&
>>>>>> 2703 *value != '\0' && strcmp(value, "\"\"") != 0) {
>>>>>> 2704 // abort if -Djava.ext.dirs is set
>>>>>> 2705 jio_fprintf(defaultStream::output_stream(),
>>>>>> 2706 "-Djava.ext.dirs=%s is not supported. Use -classpath
>>>>>> instead.
>>>>>> \n", value);
>>>>>> 2707 return JNI_EINVAL;
>>>>>> 2708 }
>>>>>> 2709
>>>>>> 2710 if (!add_property(tail)) {
>>>>>> 2711 return JNI_ENOMEM;
>>>>>> 2712 }
>>>>>> 2713 // Out of the box management support
>>>>>> 2714 if (match_option(option, "-Dcom.sun.management",
>>>>>> &tail)) {
>>>>>> 2715 #if INCLUDE_MANAGEMENT
>>>>>> 2716 if (FLAG_SET_CMDLINE(bool, ManagementServer, true) !=
>>>>>> Flag::SUCC
>>>>>> ESS) {
>>>>>> 2717 return JNI_EINVAL;
>>>>>> 2718 }
>>>>>> 2719 #else
>>>>>> 2720 jio_fprintf(defaultStream::output_stream(),
>>>>>> 2721 "-Dcom.sun.management is not supported in this
>>>>>> VM.\n");
>>>>>> 2722 return JNI_ERR;
>>>>>> 2723 #endif
>>>>>> 2724 }
>>>>>>
>>>>>>
>>>>>> L2710 is where we add a property that is not already
>>>>>> handled by special logic above that.
>>>>>>
>>>>>> $ java -showversion -XX:+PrintVMOptions -Dmy.property="This is my
>>>>>> special property." DumpMyProperty
>>>>>> VM option '+PrintVMOptions'
>>>>>> java version "1.9.0-ea"
>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>
>>>>>> my.property=This is my special property.
>>>>>>
>>>>>>
>>>>>> In the above example, the "my.property" Java property is parsed
>>>>>> by the above code in the VM. The launcher doesn't care about this
>>>>>> particular property.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dmitry
>>>>>>>>
>>>>>>>> On 25.06.2015 8:01, David Holmes wrote:
>>>>>>>>> On 25/06/2015 4:10 AM, Dmitry Dmitriev wrote:
>>>>>>>>>> Hello Dan,
>>>>>>>>>> I just want to add following: new VM Options file feature allow to
>>>>>>>>>> define property inside option file.
>>>>>>>>> What do you mean by that?
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dmitry
>>>>>>>>>>
>>>>>>>>>> On 24.06.2015 19:19, Daniel D. Daugherty wrote:
>>>>>>>>>>> On 6/23/15 10:43 PM, John Rose wrote:
>>>>>>>>>>>> On Jun 23, 2015, at 7:50 PM, David Holmes
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 24/06/2015 3:43 AM, Ron Durbin wrote:
>>>>>>>>>>>>>> David,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The '-XX:Flags' option was considered during the research phase
>>>>>>>>>>>>>> of this project and was rejected because of its limitations. The
>>>>>>>>>>>>>> '-XX:Flags' option only works for boolean flag options and it
>>>>>>>>>>>>>> uses a different syntax for the options than the command line.
>>>>>>>>>>>>>> For example, '-XX:+UseSerialGC' would be specified as
>>>>>>>>>>>>>> '+UseSerialGC'
>>>>>>>>>>>>>> in the '-XX:Flags' option file.
>>>>>>>>>>>>> I'm a little surprised the Flags option wasn't extended to cover
>>>>>>>>>>>>> these additional requirements. But presumably it should now be
>>>>>>>>>>>>> deprecated as we (again presumably) don't want to have two
>>>>>>>>>>>>> mechanisms for doing this.
>>>>>>>>>>>> I thought the Flags option used to handle any command line
>>>>>>>>>>>> options,
>>>>>>>>>>>> and like David I'm surprised the right answer is to get rid of it
>>>>>>>>>>>> and
>>>>>>>>>>>> make a new option that does what I think the Flags option
>>>>>>>>>>>> should be
>>>>>>>>>>>> doing.
>>>>>>>>>>>>
>>>>>>>>>>>> ? John
>>>>>>>>>>> Greetings,
>>>>>>>>>>>
>>>>>>>>>>> Ron is out of the office until next week so I'll provide a little
>>>>>>>>>>> bit of background...
>>>>>>>>>>>
>>>>>>>>>>> Ron has a detailed write-up documenting all the research that he
>>>>>>>>>>> did on the various command line option mechanisms. We had planned
>>>>>>>>>>> to attach that write-up to the bug report, but we dropped the ball
>>>>>>>>>>> (Sorry Mary!) After Ron returns, we'll make a final editing pass
>>>>>>>>>>> on the document and attach it to the bug report.
>>>>>>>>>>>
>>>>>>>>>>> I fleshed out the '-XX:Flags' test cases that Ron posted earlier
>>>>>>>>>>> in the thread:
>>>>>>>>>>>
>>>>>>>>>>> $ more flags.input.*::::::::::::::
>>>>>>>>>>> flags.input.boolean
>>>>>>>>>>> ::::::::::::::
>>>>>>>>>>> +UseSerialGC
>>>>>>>>>>> ::::::::::::::
>>>>>>>>>>> flags.input.ccstr
>>>>>>>>>>> ::::::::::::::
>>>>>>>>>>> ErrorFile=my_error_file
>>>>>>>>>>> ::::::::::::::
>>>>>>>>>>> flags.input.uintx
>>>>>>>>>>> ::::::::::::::
>>>>>>>>>>> MinRAMFraction=8
>>>>>>>>>>>
>>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.boolean -version
>>>>>>>>>>> VM option '+UseSerialGC'
>>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>>> VM option 'Flags=flags.input.boolean'
>>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>>
>>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.ccstr -version
>>>>>>>>>>> VM option 'ErrorFile=my_error_file'
>>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>>> VM option 'Flags=flags.input.ccstr'
>>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>>
>>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.uintx -version
>>>>>>>>>>> VM option 'MinRAMFraction=8'
>>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>>> VM option 'Flags=flags.input.uintx'
>>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It looks like the '-XX:Flags' option does work for 'bool', 'uintx'
>>>>>>>>>>> and 'ccstr' options. Clearly Ron and I didn't remember the exact
>>>>>>>>>>> reason that he ruled out using the '-XX:Flags' option. This part
>>>>>>>>>>> of the review thread will have to be resolved after Ron returns.
>>>>>>>>>>>
>>>>>>>>>>> Dan
>
From ioi.lam at oracle.com Wed Jul 8 20:59:06 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 08 Jul 2015 13:59:06 -0700
Subject: RFR(XS) 8130669: VM prohibits methods with return values
In-Reply-To: <559D8345.5060709@oracle.com>
References: <559D2666.5010209@oracle.com> <559D7E0C.6030102@oracle.com>
<559D8345.5060709@oracle.com>
Message-ID: <559D8F1A.1000803@oracle.com>
Looks good to me. Thanks
- Ioi
On 7/8/15 1:08 PM, harold seigel wrote:
> Hi Ioi,
>
> Here's an updated webrev with ignoredClinit as a .jasm file. Please
> let me know if it looks okay.
>
> http://cr.openjdk.java.net/~hseigel/bug_8130669.1/
>
> Thanks, Harold
>
> On 7/8/2015 3:46 PM, Ioi Lam wrote:
>> Hi Harold,
>>
>> Is there any reason why the ignoredClinit needs to be written in a
>> jcod file and not a jasm file? jasm files would be a lot easier to
>> read and maintain than jcod.
>>
>> Thanks
>> - Ioi
>>
>> On 7/8/15 6:32 AM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this small change to fix bug JDK-8130669. The JVM
>>> incorrectly throws ClassFormatError exceptions for non-void methods
>>> named . But, the JVM Spec 8 says that such methods
>>> should be ignored. See
>>> http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9
>>> for details.
>>>
>>> The fix changes the JVM to, in this case, only throw
>>> ClassFormatError exceptions for non-void methods.
>>>
>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
>>>
>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
>>>
>>> The fix was tested with JCK Lang and VM tests, the UTE quick and
>>> split_verifier tests, and the hotspot, java/io, java/lang, and
>>> java/util JTreg tests.
>>>
>>> Thanks, Harold
>>
>
From daniel.daugherty at oracle.com Wed Jul 8 21:33:02 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 08 Jul 2015 15:33:02 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <55972558.6060905@oracle.com>
References: <55972558.6060905@oracle.com>
Message-ID: <559D970E.7000905@oracle.com>
Greetings,
I've updated this patch based on David H's comments along with
some additional cleanup.
This work is being tracked by the following bug ID:
JDK-8130448 8077392 inspired thread dump improvements, comment
additions, new diagnostics
https://bugs.openjdk.java.net/browse/JDK-8130448
Here is the webrev URL:
http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
The easiest way to review the delta is to download the two patch
files and compare them in something like jfilemerge:
http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
Testing:
- Aurora Adhoc RT/SVC nightly batches (in process)
- JPRT test jobs
Thanks, in advance, for any comments, questions or suggestions.
Gory details about the changes are below...
Dan
Changes between CR0 and CR1 are:
src/cpu/x86/vm/macroAssembler_x86.cpp
- fix comment typos, clarify comment wording
src/share/vm/oops/markOop.cpp
- clarify output messages
- get rid of confusing local variable
src/share/vm/runtime/globals.hpp
- drop VerboseStackTrace, GuaranteeOnMonitorMismatch
and JavaThreadExitReleasesMonitors options
- there are no longer changes to this file
src/share/vm/runtime/objectMonitor.cpp
- add ObjectMonitor::Knob_ExitRelease suboption to replace
JavaThreadExitReleasesMonitors
- add ObjectMonitor::Knob_VerifyMatch suboption to replace
GuaranteeOnMonitorMismatch
- cleanup messy logging:
- switch from '::printf()' -> 'tty->print_cr()'
- switch from '::fflush()' -> 'tty->flush()'
src/share/vm/runtime/objectMonitor.hpp
- add ObjectMonitor::Knob_ExitRelease suboption
- add ObjectMonitor::Knob_VerifyMatch suboption
- cleanup messy logging
src/share/vm/runtime/synchronizer.cpp
- cleanup messy logging
- switch from GuaranteeOnMonitorMismatch to
ObjectMonitor::Knob_VerifyMatch
- add diagnostic information about the locked object
when ReleaseJavaMonitorsClosure::do_monitor() finds
a problem
src/share/vm/runtime/thread.cpp
- clarify comments
- switch from JavaThreadExitReleasesMonitors to
ObjectMonitor::Knob_ExitRelease
src/share/vm/runtime/vframe.cpp
- print_locked_object_class_name() is now public
- clarify comments
- clarify output messages
- switch from VerboseStackTrace to the already existing
ObjectMonitor::Knob_Verbose
src/share/vm/runtime/vframe.hpp
- print_locked_object_class_name() is now public
On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> The hunt for the following bug:
>
> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>
> and David C's work on the following bug:
>
> JDK-8069412 Locks need better debug-printing support
>
> have inspired additional thread dump improvements, comment additions
> to some Java monitor code and some new diagnostic options.
>
> This work is being tracked by the following bug ID:
>
> JDK-8130448 8077392 inspired thread dump improvements, comment
> additions, new diagnostics
> https://bugs.openjdk.java.net/browse/JDK-8130448
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>
> Testing:
>
> - RBT vm.quick batches (in process)
> - JPRT test jobs
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Gory details about the changes are below...
>
> Dan
>
> 8130448 summary of changes:
>
> src/cpu/x86/vm/macroAssembler_x86.cpp
> - comment additions for the assembly code
>
> src/share/vm/oops/markOop.cpp
> - has_monitor() has to be checked before is_locked() since
> the has_monitor() bits are a superset of the is_locked() bits
> - code style fixes
>
> src/share/vm/runtime/globals.hpp
> - add VerboseStackTrace diagnostic option
> - add GuaranteeOnMonitorMismatch diagnostic option
> - add JavaThreadExitReleasesMonitors product option;
> this is the Java equivalent of JNIDetachReleasesMonitors
>
> src/share/vm/runtime/objectMonitor.cpp
> - delete unused ObjectMonitor::try_enter()
> - fix assert wording
>
> src/share/vm/runtime/objectMonitor.hpp
> - delete unused ObjectMonitor::try_enter()
>
> src/share/vm/runtime/synchronizer.cpp
> - add GuaranteeOnMonitorMismatch support with some
> diagnostic output
>
> src/share/vm/runtime/thread.cpp
> - add JavaThreadExitReleasesMonitors support
>
> src/share/vm/runtime/vframe.cpp
> - clarify existing comments
> - add comments to clarify what "waiting on" means
> - add line to show when we are "waiting on", but
> there are no locals available (previously we were
> "waiting on" silently)
> - add support for "waiting to relock" which can happen
> for any of the monitors and not just the top monitor
> - switch mark->print_on() verbose output to new
> VerboseStackTrace switch; thread dumps are not enabled
> with a specific switch so the '-XX:+Verbose' model of
> being a modifier for another option does not fit
>
>
From daniel.daugherty at oracle.com Wed Jul 8 22:10:03 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 08 Jul 2015 16:10:03 -0600
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <559D66A7.6040902@oracle.com>
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
<59B99866-C9BB-46F8-87C3-7E6FA8122227@oracle.com>
<559D66A7.6040902@oracle.com>
Message-ID: <559D9FBB.6020503@oracle.com>
On 7/8/15 12:06 PM, Daniel D. Daugherty wrote:
> On 7/8/15 11:53 AM, Karen Kinnear wrote:
>> Dan,
>>
>> Looks good.
>>
>> Only comment is -
>>
>> In ObjectMonitor::INotify - lines 1668-1671
>> the default value of policy is "2"
>> -- which basically is "b" not "a" unless the EntryList is empty.
>
> Nice catch! For folks on the alias that don't have this code
> tattooed on the inside of their eyelids. This is the relevant code:
>
> src/share/vm/runtime/objectMonitor.cpp:
>
> 136 static int Knob_MoveNotifyee = 2; // notify() -
> disposition of notifyee
>
>
>
> 1659 void ObjectMonitor::INotify(Thread * Self) {
> 1660 const int policy = Knob_MoveNotifyee;
>
>
>
> 1668 // Disposition - what might we do with iterator ?
> 1669 // a. add it directly to the EntryList - either tail or head.
> 1670 // b. push it onto the front of the _cxq.
> 1671 // For now we use (a).
>
>
>
> 1710 } else if (policy == 2) { // prepend to cxq
>
> I will update the comment.
Don't think this update is worth a new webrev so here
are the diffs instead:
$ diff src/share/vm/runtime/objectMonitor.cpp{.cr1,}
1669,1671c1669,1672
< // a. add it directly to the EntryList - either tail or head.
< // b. push it onto the front of the _cxq.
< // For now we use (a).
---
> // a. add it directly to the EntryList - either tail (policy == 1)
> // or head (policy == 0).
> // b. push it onto the front of the _cxq (policy == 2).
> // For now we use (b).
Thanks again for the catch!
Dan
>
> Dan
>
>
>>
>> thanks,
>> Karen
>>
>> On Jul 3, 2015, at 8:11 PM, Daniel D. Daugherty wrote:
>>
>>> Greetings,
>>>
>>> I've updated the patch for Contended Locking fast notify bucket
>>> based on David H's and Karen's comments.
>>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8075171 Contended Locking fast notify bucket
>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>>>
>>> Here is the JEP link:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>
>>> Testing:
>>>
>>> - RBT vm.quick batches (in process)
>>> - JPRT test jobs
>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>> - CallTimerGrid stress testing (in process)
>>>
>>>
>>> The changes in this round are in only four of the files:
>>>
>>> src/share/vm/opto/runtime.cpp
>>>
>>> - deleted comment about hashCode() that belongs in a different bucket
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>>
>>> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
>>> - cleanup recheck interval code
>>> - ObjectMonitor::INotify() return type is now "void"
>>> - delete duplicate comments, clarify/rewrite some comments
>>>
>>> src/share/vm/runtime/objectMonitor.hpp
>>>
>>> - ObjectMonitor::INotify() return type is now "void"
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>>
>>> - clarify/rewrite comments, add additional comments
>>> - cleanup variables in ObjectSynchronizer::quick_notify
>>> - refactor loop to be more clear
>>> - delete unused enum MaximumRecheckInterval
>>>
>>> The easiest way to review the delta is to download the two patch
>>> files and compare them in something like jfilemerge:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
>>>
>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>>>
>>>
>>> Dan
>>>
>>>
>>> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I have the Contended Locking fast notify bucket ready for review.
>>>>
>>>> The code changes in this bucket are the final piece in the triad
>>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>>> macro assembler changes in this bucket (yeah!), but there are
>>>> code review cleanups motivated by comments on other buckets, e.g.,
>>>> changing variables like 'Tally' -> 'tally'.
>>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8075171 Contended Locking fast notify bucket
>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>>
>>>> Here is the JEP link:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>
>>>> Testing:
>>>>
>>>> - Aurora Adhoc RT/SVC baseline batch
>>>> - JPRT test jobs
>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>> - CallTimerGrid stress testing (in process)
>>>> - Aurora performance testing:
>>>> - out of the box for the "promotion" and 32-bit server configs
>>>> - heavy weight monitors for the "promotion" and 32-bit server
>>>> configs
>>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>>> (in process)
>>>>
>>>> The hang somehow introduced by the "fast enter" bucket is still
>>>> unresolved, but progress is being made. That work is being tracked
>>>> by the following bug:
>>>>
>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>>
>>>> You'll see a change that re-enables the "fast enter" bucket in this
>>>> webrev, but that change will not be pushed when we're done with the
>>>> review of this bucket unless JDK-8077392 is resolved.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Gory details about the changes are below...
>>>>
>>>> Dan
>>>>
>>>>
>>>> 8075171 summary of changes:
>>>>
>>>> src/share/vm/classfile/vmSymbols.hpp
>>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>>
>>>> src/share/vm/opto/library_call.cpp
>>>> - Add optional inline_notify() that is controlled by new
>>>> '-XX:[+-]InlineNotify' option
>>>>
>>>> src/share/vm/opto/runtime.cpp
>>>> src/share/vm/opto/runtime.hpp
>>>> - Add OptoRuntime::monitor_notify_C() and
>>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>>> the new "fast notify" code paths
>>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>>> the above two new functions
>>>>
>>>> src/share/vm/runtime/globals.hpp
>>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>>> enabled (true)
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>>> into wrappers that call the new ObjectMonitor::INotify()
>>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>>> between "notify" and "notifyAll" code paths
>>>>
>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>> - Temporarily re-enable the "fast enter" optimization in order
>>>> to do performance testing. JDK-8077392 is still unresolved,
>>>> but progress is being made.
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>> src/share/vm/runtime/synchronizer.hpp
>>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>>> new "fast notify" code paths
>>>> - The new code handles a couple of special cases where the
>>>> "notify" can be done without the heavy weight slow-path
>>>> (thread state transitions and other baggage)
>>>>
>>>>
>
>
>
From david.holmes at oracle.com Thu Jul 9 05:06:45 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2015 15:06:45 +1000
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <559D8846.7060803@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5588EA9F.3020001@oracle.com>
<725f7631-425d-4918-8a92-230005d5b5ec@default>
<558A1AE7.6010607@oracle.com>
<224EF327-B898-4DAC-9343-4FE238604276@oracle.com>
<558AD8AD.6020009@oracle.com> <558AF2AB.7040407@oracle.com>
<558B8B45.4060307@oracle.com> <558BA1CC.6040100@oracle.com>
<558BA53E.1010600@oracle.com> <558C312F.4070606@oracle.com>
<558CEB04.5040905@oracle.com> <558D9423.1010903@oracle.com>
<5591EABE.6030301@oracle.com>
<99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
<559D8846.7060803@oracle.com>
Message-ID: <559E0165.3040902@oracle.com>
On 9/07/2015 6:29 AM, Dmitry Dmitriev wrote:
> On 08.07.2015 22:26, Karen Kinnear wrote:
>> 2) is there a maximum length to the options read in from the file?
> The current implemented limitations are following: only one VM option
> file can be specified, maximum size of the file is 1024 bytes, up to 64
> VM options
That seems extremely limiting. Why should there be a maximum size, why
can't you just read the file line by line and keep processing until it
is all read ??
Thanks,
David
From david.holmes at oracle.com Thu Jul 9 05:13:48 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2015 15:13:48 +1000
Subject: RFR(S) 8130448: thread dump improvements, comment, additions, new
diagnostics inspired by 8077392
In-Reply-To: <559C0C4D.8090504@oracle.com>
References: <55972558.6060905@oracle.com> <559A2397.2010409@oracle.com>
<559AE96D.6010508@oracle.com> <559B7BAA.8070705@oracle.com>
<559C0C4D.8090504@oracle.com>
Message-ID: <559E030C.8010603@oracle.com>
On 8/07/2015 3:28 AM, Daniel D. Daugherty wrote:
> On 7/7/15 1:11 AM, David Holmes wrote:
>> Hi Dan,
>>
>> Top posting as I'm lazy and running late :)
>
> No problem with the top posting. It makes your remaining
> concerns earlier to see and address.
>
>
>> Okay ... I'm still uneasy about adding two additional flags for the
>> "release monitors on exit" situation. I hear what you are saying about
>> the cost of the monitor check - I had thought we kept easy access to
>> the set of monitors owned by a thread but it seems not, so trawling
>> the global monitor list is indeed an expensive operation. :( So okay
>> but I don't like it :)
>
> Since JavaThreadExitReleasesMonitors and GuaranteeOnMonitorMismatch
> are targeted at finding/working around bugs in the Java Monitor
> implementation, I'm going to take a look at moving the flag support
> down into Java Monitor subsystem's implementation specific options.
> That will get the options out of the global space and they won't
> have to be counted against the "cap and trade" limit :-)
>
>
>> I also take your point about viewing the new flag as a superset of the
>> JNI-detach case. That's fair enough, but of course that aspect needs
>> to be documented.
>
> I'm starting to wonder why we have the 'JNIDetachReleasesMonitors'
> option at all. Is there a good reason to be able to turn off this
> piece of code?
My recollection is that hotspot did not implement that part of the spec.
Simply switching the behaviour with no way to restore the original
behaviour could break existing apps. Hence a flag, on by default.
Of course by now apps should be spec compliant themselves so this seems
a flag that should itself be deprecated in 9 and targetted for removal
in 10. (That will help with the 'conservation of flags' problem :) ).
>
>
>> I was left unclear about your position on the VerboseStackTrace. I
>> agree the new output was likely put under a flag to avoid disturbing
>> existing output formats. But I don't see that it warrants its own flag
>> - to me using Verbose okay (though the fact it is a develop flag is
>> limiting).
>
> Thanks for reminding me that '-XX:+Verbose' is a develop flag.
> That's another reason for not using that flag. Combined with
> the fact that '-XX:+Verbose' is considered a modifier to other
> flags and thread dumps aren't enabled/triggered by a flag means
> (to me anyway) that '-XX:+Verbose' is still not a good match.
>
> However, I have a vague memory that the Java Monitor subsystem
> has its own "verbose" flag. I'll take a look at switching to
> that...
Okay
> Will be working on the next round...
Thanks,
David
> Dan
>
>
>
>>
>> Thanks,
>> David
>>
>> On 7/07/2015 6:47 AM, Daniel D. Daugherty wrote:
>>> On 7/6/15 12:43 AM, David Holmes wrote:
>>>> Hi Dan,
>>>>
>>>> Metacomment: Could I suggest that in a RFR your subject line has the
>>>> form : , rather than (bugid) - especially
>>>> when the synopsis actually starts with a bug id :) Thanks.
>>>
>>> Yup that bug synopsis is/was a mess:
>>>
>>> Changed the synopsis line to :
>>>
>>> thread dump improvements, comment additions, new diagnostics
>>> inspired by 8077392
>>>
>>> Also updated the e-mail thread subject line to your suggested format.
>>> Will try to remember to switch to that style in the future.
>>>
>>>
>>>> Mostly okay but some major concerns around the can of worms that
>>>> JavaThreadExitReleasesMonitors opens up.
>>>
>>> This is Java monitors so "can of worms" is familiar! :-)
>>>
>>>
>>>>
>>>> On 4/07/2015 10:14 AM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> The hunt for the following bug:
>>>>>
>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>>
>>>>> and David C's work on the following bug:
>>>>>
>>>>> JDK-8069412 Locks need better debug-printing support
>>>>>
>>>>> have inspired additional thread dump improvements, comment additions
>>>>> to some Java monitor code and some new diagnostic options.
>>>>
>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>
>>>> 1821 // update _owner from from BasicLock to thread
>>>>
>>>> Typo: from from
>>>
>>> Will fix.
>>>
>>>
>>>> 2091 // the placeholder value. If that didn't work, then another
>>>> 2092 // grabbed the lock so we're done (and exit was a success).
>>>>
>>>> another -> another thread ?
>>>
>>> Yes, "another thread" is better. Will fix.
>>>
>>>
>>>> 2201 // If that didn't work, then another grabbed the lock
>>>> 2202 // so we're done (and exit was a success).
>>>>
>>>> another -> another thread ?
>>>
>>> Yes, "another thread" is better. Will fix.
>>>
>>>
>>>> ---
>>>>
>>>> src/share/vm/oops/markOop.cpp
>>>>
>>>> 40 st->print("NULL"); // this should not happen
>>>>
>>>> Shouldn't that be an assert or guarantee in that case? Or at a minimum
>>>> print something like: "NULL (but you should never see this!)"
>>>
>>> This is a relocated line from David C's change:
>>>
>>> old 49: st->print("monitor=NULL");
>>>
>>> I simply added a comment to it. I don't think I like the idea of the
>>> thread dump code assert()'ing or guarantee()'ing because there might
>>> be other useful info that would have been printed after the assert()
>>> or guarantee() failure.
>>>
>>> I do like the idea of changing the message to:
>>>
>>> 40: st->print("NULL (this should never be seen!)");
>>>
>>>
>>>> 42 BasicLock * bl = (BasicLock *) mon->owner();
>>>>
>>>> What information has told us this is a BasicLock* not a Thread* ? But
>>>> as all you do is print bl why not just p2i(mon->owner()) ?
>>>
>>> Again, this is a relocated line from David C's change:
>>>
>>> old 51: BasicLock * bl = (BasicLock *) mon->owner();
>>>
>>> I'm going to guess that David C had some other code in there before
>>> that needed/assumed that the field is a "BasicLock *", but that code
>>> didn't make it into his final version.
>>>
>>> I will drop the 'bl' local and update the p2i() call to use
>>> mon->owner() directly.
>>>
>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/globals.hpp
>>>>
>>>> JavaThreadExitReleasesMonitors has me perplexed. The JNI DetachThread
>>>> case seems to be a concession to badly written code that fails to
>>>> release locks on error paths.
>>>
>>> I don't think I would call the JNIDetachReleasesMonitors case a
>>> concession
>>> to badly written JNI code. 6282335 is very clear that this code was
>>> added
>>> to meet the JNI spec. The JNI spec words might be considered a
>>> concession...
>>>
>>> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#DetachCurrentThread
>>>
>>>
>>>
>>> > DetachCurrentThread
>>> >
>>> > jint DetachCurrentThread(JavaVM *vm);
>>> >
>>> > Detaches the current thread from a Java VM. All Java monitors
>>> > held by this thread are released. All Java threads waiting for
>>> > this thread to die are notified.
>>> >
>>> > The main thread can be detached from the VM.
>>>
>>>
>>>
>>>> The equivalent for a Java thread would again involve lock acquisition
>>>> via JNI. But I don't recall ever seeing a bug report or RFE related to
>>>> this. What seems to have motivated this new flag is the potential for
>>>> a broken VM to actually leave the monitor locked (e.g. because
>>>> compiled code failed to do the unlock on all paths).
>>>
>>> 8077392 and bugs like it are exactly the reason for adding these
>>> two options.
>>>
>>> JavaThreadExitReleasesMonitors is added to provide a work around
>>> until the underlying bug or bugs are fixed. This option is targeted
>>> at folks that are chasing their own bugs and don't care about this
>>> one.
>>>
>>> GuaranteeOnMonitorMismatch is added to help hunt 8077392 specifically
>>> and to sanity check for similar issues generally. I can see using the
>>> two options in combination with existing test suites as a stress test
>>> for the Java monitor subsystem.
>>>
>>>
>>>> To address that I'd be inclined to simply have a guarantee in the Java
>>>> thread exit path, rather than a flag to do the clean up and another
>>>> flag to control a guarantee.
>>>
>>> The check for an unexited Java monitor is not cheap.
>>>
>>> The existing check under the JNIDetachReleasesMonitors flag is
>>> positioned to only affect threads using JNI DetachCurrentThread()
>>> and that cost is justified as part of meeting the JNI spec.
>>>
>>> Adding the unexited Java monitor check to all exiting Java
>>> threads should not be done lightly due to the cost. If the
>>> VM is functioning correctly, then why impose this cost on
>>> all exiting Java threads?
>>>
>>>
>>>> I don't think two new command-line options (has this gone through CCC
>>>> yet?) are justified.
>>>
>>> No, this has not gone through CCC yet. My preference is to get
>>> code review feedback (like this) before submitting a CCC.
>>>
>>> I suppose I could have simply added more sub-options to the
>>> existing Java monitor subsystem knobs and switches, but it
>>> seemed to make sense to model JavaThreadExitReleasesMonitors
>>> on the existing JNIDetachReleasesMonitors.
>>>
>>>
>>>> Also note that allowing for JVM induced missing unlocks is something
>>>> that can affect JNI attached threads as well as regular Java threads.
>>>> I'll take this up in discussing thread.cpp below.
>>>>
>>>> That aside, the comment, which was modelled on the JNI DetachThread
>>>> variant, does not really work in this case:
>>>>
>>>> 2801 "JavaThread exit() releases monitors owned by thread")
>>>> \
>>>>
>>>> JavaThread is not a programming concept but an internal JVM
>>>> abstraction. I would suggest something like:
>>>>
>>>> "Java thread termination releases monitors unexpectedly still owned by
>>>> thread"
>>>
>>> I'll switch to your description text if we end up keeping the
>>> new options.
>>>
>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>
>>>> No comments
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>>
>>>> If we find the unexpected locked monitor it would be useful to see
>>>> more Java level information about the Thread (in the non-detaching
>>>> case) and the object that is locked.
>>>
>>> I can probably steal some code from the thread dump side to
>>> give us more info about the Object associated with the Java
>>> monitor...
>>>
>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/thread.cpp
>>>>
>>>> As noted previously JNI attached threads can also be affected by JVM
>>>> induced locking bugs. So the comment block:
>>>>
>>>> 1804 // 6282335 JNI DetachCurrentThread spec states that all Java
>>>> monitors
>>>> 1805 // held by this thread must be released. A detach operation
>>>> must only
>>>> 1806 // get here if there are no Java frames on the stack.
>>>> Therefore, any
>>>> 1807 // owned monitors at this point MUST be JNI-acquired monitors
>>>> which are
>>>> 1808 // pre-inflated and in the monitor cache.
>>>>
>>>> is not strictly correct as it is presuming a correctly operating JVM.
>>>
>>> I actually disagree with the last two sentences in that comment block,
>>> but I didn't have a good rewrite in mind. I'll think about it more.
>>>
>>>
>>>
>>>> Further the logic now applied:
>>>>
>>>> 1816 if ((exit_type == jni_detach && JNIDetachReleasesMonitors) ||
>>>> 1817 JavaThreadExitReleasesMonitors) {
>>>>
>>>> is also not "correct" because if we have
>>>> JavaThreadExitReleasesMonitors true while JNIDetachReleasesMonitors is
>>>> false, we will in fact release any JNI acquired monitors because we
>>>> can't make the distinction.
>>>
>>> I don't think JNIDetachReleasesMonitors only has to deal with
>>> JNI-acquired
>>> monitors and I don't think that JavaThreadExitReleasesMonitors only
>>> has to
>>> deal with Java code acquired monitors. I see these options as
>>> applying to
>>> "how you got to the Java thread exit path" and not applying to "what
>>> needs
>>> to be cleaned up".
>>>
>>> I see JNIDetachReleasesMonitors as a way of cleaning up unexited Java
>>> monitors when we're executing the JNI DetachCurrentThread() code path.
>>> I don't really care why the Java monitors are unexited... and I think
>>> the spec wording is clear that all unexited Java monitors are cleaned
>>> up... not just JNI-acquired monitors.
>>>
>>> I see JavaThreadExitReleasesMonitors as a way of cleaning up unexited
>>> Java monitors in any code path where we are exiting the Java thread.
>>> I see
>>> JavaThreadExitReleasesMonitors as a superset of
>>> JNIDetachReleasesMonitors.
>>>
>>>
>>>> Given we can't make the distinction I don't see any way for these
>>>> separate flags to actually work well together.
>>>
>>> I think they work well together when JavaThreadExitReleasesMonitors
>>> is seen as a superset of JNIDetachReleasesMonitors. Of course, that
>>> hinges on my opinion that JNIDetachReleasesMonitors applies to any
>>> unexited Java monitor and not just JNI-acquired Java monitors.
>>>
>>>
>>>> As I said above I'm more inclined to just add a guarantee to the
>>>> non-detach case, than add two new flags. (Even though this means there
>>>> won't be detection for such bugs when JNI attached threads encounter
>>>> them - including the main thread :( ).
>>>
>>> I really don't want to add this check to all Java thread exit
>>> paths since it is expensive.
>>>
>>>
>>>> As I said this has me perplexed. :(
>>>
>>> Hopefully, I've explained it better now.
>>>
>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/vframe.cpp
>>>>
>>>> 170 // It would be nice to distinguish between "waiting on" and
>>>> 171 // "waited on". Currently, "waiting on" here with a
>>>> 172 // java.lang.Thread.State == "WAITING (on object monitor)"
>>>> 173 // earlier in the output means that the monitor has not yet
>>>> been
>>>> 174 // notified and java.lang.Thread.State == "BLOCKED (on object
>>>> 175 // monitor)" earlier in the output means that the monitor has
>>>> 176 // been notified and the thread is blocked on reentry.
>>>>
>>>> That's a very long sentence that can be quite difficult to parse and
>>>> could probably be reworded to describe how the output should be
>>>> interpreted eg:
>>>>
>>>> // If earlier in the output we reported java.lang.Thread.State ==
>>>> // "WAITING (on object monitor)" and now we report "waited on", then
>>>> // we are still waiting for notification [or timeout?]. Otherwise if
>>>> // we earlier reported java.lang.Thread.State == "BLOCKED (on object
>>>> // monitor)", then we are actually waiting to reacquire the monitor
>>>> // lock. At this level we can't distinguish the two cases to report
>>>> // "waited on" rather than "waiting on" for the second case.
>>>
>>> I'll take a look at rewriting the comment and may just take your
>>> version entirely.
>>>
>>>
>>>> I wonder if we can prod deeper into VM state to try and make the
>>>> distinction?
>>>
>>> I played around with doing just that, but it seems like the M&M
>>> code that fetches similar state probes the state stored in the
>>> java.lang.Thread object. I didn't want to go there.
>>>
>>>
>>>>
>>>> 184 } else {
>>>> 185 st->print_cr("\t- %s ", wait_state);
>>>>
>>>> The concept of "locals" is confusing here. Isn't the "local" in this
>>>> case just the object that we have waited upon? In which case we should
>>>> say "no object reference available".
>>>
>>> I got the phrase "locals" from the compiler code that was trying to
>>> decode the object reference. I can change to "no object reference
>>> available".
>>> I definitely want to say _something_ here. The existing code is just
>>> silent.
>>>
>>>
>>>> Though I would have thought/hoped there must be a way to find the
>>>> object reference even in a compiled frame?
>>>
>>> Yes, if you deopt... I didn't want to go there.
>>>
>>>
>>>> 195 // Print out all monitors that we have locked, are trying to lock
>>>> 196 // or are trying to relock after a wait().
>>>>
>>>> that makes it sound like there are three cases when really a "relock"
>>>> is just a specific case of lock. I would suggest:
>>>>
>>>> // Print out all monitors that we have locked, or are trying to
>>>> // lock, including re-locking when returning from a wait().
>>>
>>> Making it more clear that the "re-locking" is coming from "wait()"
>>> is an improvement. I'll fix this.
>>>
>>>
>>>> 252 lock_state = "waiting to relock";
>>>>
>>>> I prefer "waiting to re-lock in wait()", if that isn't too long.
>>>> Otherwise "relock" needs to be a concept people are familiar with.
>>>
>>> I like "waiting to re-lock in wait()".
>>>
>>>
>>>> 260 if (VerboseStackTrace && mark != NULL) {
>>>> 261 st->print("\t- lockbits=");
>>>> 262 mark->print_on(st);
>>>>
>>>> This really doesn't seem to warrant a new diagnostic flag, regardless
>>>> of whether we think applying -XX:+Verbose is a good fit or not.
>>>
>>> I suspect that David C didn't want to change the default output format
>>> and neither do I. We have some tests that try to parse out specific
>>> things from thread dumps to verify certain bug fixes and we don't want
>>> to break those. I'm thinking of the "duplicate owner" bug fix that we
>>> fixed in thread dumps, but I can't pull up the bug ID (yet)...
>>>
>>> Thanks for the thorough review. I have to say that I wasn't expecting
>>> much comment on this review at all. :-)
>>>
>>>
>>> Dan
>>>
>>>
>>>>
>>>> Thanks,
>>>> David
>>>> -------
>>>>
>>>>> This work is being tracked by the following bug ID:
>>>>>
>>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>>> additions, new diagnostics
>>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>>
>>>>> Here is the webrev URL:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>>
>>>>> Testing:
>>>>>
>>>>> - RBT vm.quick batches (in process)
>>>>> - JPRT test jobs
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Gory details about the changes are below...
>>>>>
>>>>> Dan
>>>>>
>>>>> 8130448 summary of changes:
>>>>>
>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>> - comment additions for the assembly code
>>>>>
>>>>> src/share/vm/oops/markOop.cpp
>>>>> - has_monitor() has to be checked before is_locked() since
>>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>>> - code style fixes
>>>>>
>>>>> src/share/vm/runtime/globals.hpp
>>>>> - add VerboseStackTrace diagnostic option
>>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>>> - add JavaThreadExitReleasesMonitors product option;
>>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>> - delete unused ObjectMonitor::try_enter()
>>>>> - fix assert wording
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>
>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>> - add GuaranteeOnMonitorMismatch support with some
>>>>> diagnostic output
>>>>>
>>>>> src/share/vm/runtime/thread.cpp
>>>>> - add JavaThreadExitReleasesMonitors support
>>>>>
>>>>> src/share/vm/runtime/vframe.cpp
>>>>> - clarify existing comments
>>>>> - add comments to clarify what "waiting on" means
>>>>> - add line to show when we are "waiting on", but
>>>>> there are no locals available (previously we were
>>>>> "waiting on" silently)
>>>>> - add support for "waiting to relock" which can happen
>>>>> for any of the monitors and not just the top monitor
>>>>> - switch mark->print_on() verbose output to new
>>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>>> with a specific switch so the '-XX:+Verbose' model of
>>>>> being a modifier for another option does not fit
>>>
>
From david.holmes at oracle.com Thu Jul 9 06:34:57 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2015 16:34:57 +1000
Subject: RFR(S) 8130448: thread dump improvements, comment, additions, new
diagnostics inspired by 8077392
In-Reply-To: <559D970E.7000905@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
Message-ID: <559E1611.2070803@oracle.com>
Hi Dan,
On 9/07/2015 7:33 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> I've updated this patch based on David H's comments along with
> some additional cleanup.
So to address the high-level changes:
- Use ObjectMonitor::Knob_Verbose as the verbosity flag for printing the
lockbits in the stack dump. Okay - though I do wonder why the
SyncVerbose flag also exists?
- Use ObjectMonitor::Knob_ExitRelease to control whether Java threads
are checked for locked monitors when they exit
- Use ObjectMonitor::Knob_VerifyMatch to control whether finding a
locked (hence unmatched) monitor causes an abort
That seems like a good way to work within the existing mechanism for
customizing the sync logic - and no new global options (though SQE will
still need tests for using these knobs I think).
Some specific comments below ...
> This work is being tracked by the following bug ID:
>
> JDK-8130448 8077392 inspired thread dump improvements, comment
> additions, new diagnostics
> https://bugs.openjdk.java.net/browse/JDK-8130448
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
src/share/vm/runtime/objectMonitor.cpp
2393 if (Knob_ReportSettings && v != NULL) {
2394 tty->print_cr("INFO: SyncKnob: %s %d(%d)", Key, rslt, Default) ;
2395 tty->flush();
2396 }
I suspect these were not tty using because this might get called before
the tty has been initialized - but I can't see how that might arise (nor
can I be certain it can't).
Ditto for similar changes throughout.
---
src/share/vm/runtime/synchronizer.cpp
1648 void do_monitor(ObjectMonitor* mid) {
1649 if (mid->owner() == THREAD) {
1650 if (ObjectMonitor::Knob_VerifyMatch != 0) {
1651 Handle obj((oop) mid->object());
1652 tty->print("INFO: unexpected locked object:");
1653 javaVFrame::print_locked_object_class_name(tty, obj, "locked");
1654 }
1655 guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
1656 err_msg("exiting JavaThread=" INTPTR_FORMAT
1657 " unexpectedly owns ObjectMonitor="
INTPTR_FORMAT,
1658 THREAD, mid));
1659 (void)mid->complete_exit(CHECK);
1660 }
1661 }
Took me a while to figure out the expected control flow here. Doesn't
the above simplify to:
void do_monitor(ObjectMonitor* mid) {
if (mid->owner() == THREAD) {
if (ObjectMonitor::Knob_VerifyMatch != 0) {
Handle obj((oop) mid->object());
tty->print("INFO: unexpected locked object:");
javaVFrame::print_locked_object_class_name(tty, obj, "locked");
fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
" unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
THREAD, mid));
}
(void)mid->complete_exit(CHECK);
}
}
?
Thanks,
David
>
> The easiest way to review the delta is to download the two patch
> files and compare them in something like jfilemerge:
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>
>
> Testing:
>
> - Aurora Adhoc RT/SVC nightly batches (in process)
> - JPRT test jobs
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Gory details about the changes are below...
>
> Dan
>
> Changes between CR0 and CR1 are:
>
> src/cpu/x86/vm/macroAssembler_x86.cpp
>
> - fix comment typos, clarify comment wording
>
> src/share/vm/oops/markOop.cpp
>
> - clarify output messages
> - get rid of confusing local variable
>
> src/share/vm/runtime/globals.hpp
>
> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
> and JavaThreadExitReleasesMonitors options
> - there are no longer changes to this file
>
> src/share/vm/runtime/objectMonitor.cpp
>
> - add ObjectMonitor::Knob_ExitRelease suboption to replace
> JavaThreadExitReleasesMonitors
> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
> GuaranteeOnMonitorMismatch
> - cleanup messy logging:
> - switch from '::printf()' -> 'tty->print_cr()'
> - switch from '::fflush()' -> 'tty->flush()'
>
> src/share/vm/runtime/objectMonitor.hpp
>
> - add ObjectMonitor::Knob_ExitRelease suboption
> - add ObjectMonitor::Knob_VerifyMatch suboption
> - cleanup messy logging
>
> src/share/vm/runtime/synchronizer.cpp
>
> - cleanup messy logging
> - switch from GuaranteeOnMonitorMismatch to
> ObjectMonitor::Knob_VerifyMatch
> - add diagnostic information about the locked object
> when ReleaseJavaMonitorsClosure::do_monitor() finds
> a problem
>
> src/share/vm/runtime/thread.cpp
>
> - clarify comments
> - switch from JavaThreadExitReleasesMonitors to
> ObjectMonitor::Knob_ExitRelease
>
> src/share/vm/runtime/vframe.cpp
>
> - print_locked_object_class_name() is now public
> - clarify comments
> - clarify output messages
> - switch from VerboseStackTrace to the already existing
> ObjectMonitor::Knob_Verbose
>
> src/share/vm/runtime/vframe.hpp
>
> - print_locked_object_class_name() is now public
>
>
> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> The hunt for the following bug:
>>
>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>
>> and David C's work on the following bug:
>>
>> JDK-8069412 Locks need better debug-printing support
>>
>> have inspired additional thread dump improvements, comment additions
>> to some Java monitor code and some new diagnostic options.
>>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8130448 8077392 inspired thread dump improvements, comment
>> additions, new diagnostics
>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>
>> Testing:
>>
>> - RBT vm.quick batches (in process)
>> - JPRT test jobs
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Gory details about the changes are below...
>>
>> Dan
>>
>> 8130448 summary of changes:
>>
>> src/cpu/x86/vm/macroAssembler_x86.cpp
>> - comment additions for the assembly code
>>
>> src/share/vm/oops/markOop.cpp
>> - has_monitor() has to be checked before is_locked() since
>> the has_monitor() bits are a superset of the is_locked() bits
>> - code style fixes
>>
>> src/share/vm/runtime/globals.hpp
>> - add VerboseStackTrace diagnostic option
>> - add GuaranteeOnMonitorMismatch diagnostic option
>> - add JavaThreadExitReleasesMonitors product option;
>> this is the Java equivalent of JNIDetachReleasesMonitors
>>
>> src/share/vm/runtime/objectMonitor.cpp
>> - delete unused ObjectMonitor::try_enter()
>> - fix assert wording
>>
>> src/share/vm/runtime/objectMonitor.hpp
>> - delete unused ObjectMonitor::try_enter()
>>
>> src/share/vm/runtime/synchronizer.cpp
>> - add GuaranteeOnMonitorMismatch support with some
>> diagnostic output
>>
>> src/share/vm/runtime/thread.cpp
>> - add JavaThreadExitReleasesMonitors support
>>
>> src/share/vm/runtime/vframe.cpp
>> - clarify existing comments
>> - add comments to clarify what "waiting on" means
>> - add line to show when we are "waiting on", but
>> there are no locals available (previously we were
>> "waiting on" silently)
>> - add support for "waiting to relock" which can happen
>> for any of the monitors and not just the top monitor
>> - switch mark->print_on() verbose output to new
>> VerboseStackTrace switch; thread dumps are not enabled
>> with a specific switch so the '-XX:+Verbose' model of
>> being a modifier for another option does not fit
>>
>>
>
From david.holmes at oracle.com Thu Jul 9 06:40:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2015 16:40:00 +1000
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <559D9FBB.6020503@oracle.com>
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
<59B99866-C9BB-46F8-87C3-7E6FA8122227@oracle.com>
<559D66A7.6040902@oracle.com> <559D9FBB.6020503@oracle.com>
Message-ID: <559E1740.6040007@oracle.com>
On 9/07/2015 8:10 AM, Daniel D. Daugherty wrote:
>
> On 7/8/15 12:06 PM, Daniel D. Daugherty wrote:
>> On 7/8/15 11:53 AM, Karen Kinnear wrote:
>>> Dan,
>>>
>>> Looks good.
>>>
>>> Only comment is -
>>>
>>> In ObjectMonitor::INotify - lines 1668-1671
>>> the default value of policy is "2"
>>> -- which basically is "b" not "a" unless the EntryList is empty.
>>
>> Nice catch! For folks on the alias that don't have this code
>> tattooed on the inside of their eyelids. This is the relevant code:
>>
>> src/share/vm/runtime/objectMonitor.cpp:
>>
>> 136 static int Knob_MoveNotifyee = 2; // notify() -
>> disposition of notifyee
>>
>>
>>
>> 1659 void ObjectMonitor::INotify(Thread * Self) {
>> 1660 const int policy = Knob_MoveNotifyee;
>>
>>
>>
>> 1668 // Disposition - what might we do with iterator ?
>> 1669 // a. add it directly to the EntryList - either tail or head.
>> 1670 // b. push it onto the front of the _cxq.
>> 1671 // For now we use (a).
>>
>>
>>
>> 1710 } else if (policy == 2) { // prepend to cxq
>>
>> I will update the comment.
>
> Don't think this update is worth a new webrev so here
> are the diffs instead:
>
> $ diff src/share/vm/runtime/objectMonitor.cpp{.cr1,}
> 1669,1671c1669,1672
> < // a. add it directly to the EntryList - either tail or head.
> < // b. push it onto the front of the _cxq.
> < // For now we use (a).
> ---
> > // a. add it directly to the EntryList - either tail (policy == 1)
> > // or head (policy == 0).
> > // b. push it onto the front of the _cxq (policy == 2).
> > // For now we use (b).
>
> Thanks again for the catch!
Yep good catch!
David
> Dan
>
>
>>
>> Dan
>>
>>
>>>
>>> thanks,
>>> Karen
>>>
>>> On Jul 3, 2015, at 8:11 PM, Daniel D. Daugherty wrote:
>>>
>>>> Greetings,
>>>>
>>>> I've updated the patch for Contended Locking fast notify bucket
>>>> based on David H's and Karen's comments.
>>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8075171 Contended Locking fast notify bucket
>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>>>>
>>>> Here is the JEP link:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>
>>>> Testing:
>>>>
>>>> - RBT vm.quick batches (in process)
>>>> - JPRT test jobs
>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>> - CallTimerGrid stress testing (in process)
>>>>
>>>>
>>>> The changes in this round are in only four of the files:
>>>>
>>>> src/share/vm/opto/runtime.cpp
>>>>
>>>> - deleted comment about hashCode() that belongs in a different bucket
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>
>>>> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
>>>> - cleanup recheck interval code
>>>> - ObjectMonitor::INotify() return type is now "void"
>>>> - delete duplicate comments, clarify/rewrite some comments
>>>>
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>
>>>> - ObjectMonitor::INotify() return type is now "void"
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>>
>>>> - clarify/rewrite comments, add additional comments
>>>> - cleanup variables in ObjectSynchronizer::quick_notify
>>>> - refactor loop to be more clear
>>>> - delete unused enum MaximumRecheckInterval
>>>>
>>>> The easiest way to review the delta is to download the two patch
>>>> files and compare them in something like jfilemerge:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> I have the Contended Locking fast notify bucket ready for review.
>>>>>
>>>>> The code changes in this bucket are the final piece in the triad
>>>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>>>> macro assembler changes in this bucket (yeah!), but there are
>>>>> code review cleanups motivated by comments on other buckets, e.g.,
>>>>> changing variables like 'Tally' -> 'tally'.
>>>>>
>>>>> This work is being tracked by the following bug ID:
>>>>>
>>>>> JDK-8075171 Contended Locking fast notify bucket
>>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>>
>>>>> Here is the webrev URL:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>>>
>>>>> Here is the JEP link:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>>
>>>>> Testing:
>>>>>
>>>>> - Aurora Adhoc RT/SVC baseline batch
>>>>> - JPRT test jobs
>>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>>> - CallTimerGrid stress testing (in process)
>>>>> - Aurora performance testing:
>>>>> - out of the box for the "promotion" and 32-bit server configs
>>>>> - heavy weight monitors for the "promotion" and 32-bit server
>>>>> configs
>>>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>>>> (in process)
>>>>>
>>>>> The hang somehow introduced by the "fast enter" bucket is still
>>>>> unresolved, but progress is being made. That work is being tracked
>>>>> by the following bug:
>>>>>
>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>>>
>>>>> You'll see a change that re-enables the "fast enter" bucket in this
>>>>> webrev, but that change will not be pushed when we're done with the
>>>>> review of this bucket unless JDK-8077392 is resolved.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Gory details about the changes are below...
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> 8075171 summary of changes:
>>>>>
>>>>> src/share/vm/classfile/vmSymbols.hpp
>>>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>>>
>>>>> src/share/vm/opto/library_call.cpp
>>>>> - Add optional inline_notify() that is controlled by new
>>>>> '-XX:[+-]InlineNotify' option
>>>>>
>>>>> src/share/vm/opto/runtime.cpp
>>>>> src/share/vm/opto/runtime.hpp
>>>>> - Add OptoRuntime::monitor_notify_C() and
>>>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>>>> the new "fast notify" code paths
>>>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>>>> the above two new functions
>>>>>
>>>>> src/share/vm/runtime/globals.hpp
>>>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>>>> enabled (true)
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>>>> into wrappers that call the new ObjectMonitor::INotify()
>>>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>>>> between "notify" and "notifyAll" code paths
>>>>>
>>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>> - Temporarily re-enable the "fast enter" optimization in order
>>>>> to do performance testing. JDK-8077392 is still unresolved,
>>>>> but progress is being made.
>>>>>
>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>> src/share/vm/runtime/synchronizer.hpp
>>>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>>>> new "fast notify" code paths
>>>>> - The new code handles a couple of special cases where the
>>>>> "notify" can be done without the heavy weight slow-path
>>>>> (thread state transitions and other baggage)
>>>>>
>>>>>
>>
>>
>>
>
From david.holmes at oracle.com Thu Jul 9 09:27:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2015 19:27:43 +1000
Subject: RFR: 8130728: Disable WorkAroundNPTLTimedWaitHang by default
Message-ID: <559E3E8F.9020300@oracle.com>
https://bugs.openjdk.java.net/browse/JDK-8130728
The workaround triggered by WorkAroundNPTLTimedWaitHang (an experimental
flag set to 1 by default) was to alleviate a hang that could occur on a
pthread_cond_timedwait on Linux, if the timeout value was a time in the
past - see JDK-6314875. This glibc bug was fixed in 2005 in glibc 2.3.5-3
https://lists.debian.org/debian-glibc/2005/08/msg00201.html
but the workaround persists and was (unfortunately) copied into the BSD
and AIX ports.
It is time to remove that workaround but before we can do that we need
to be sure that we are not in fact hitting the workaround code. To that
end I propose to use this bug to switch the flag's value to 0 to verify
correct operation.
If that goes well then we can remove the code either later in JDK 9 or
early in JDK 10.
To be clear the flag impacts both the wait and the signal part of the
condvar usage (park and unpark). On the wait side we have:
status = pthread_cond_timedwait(_cond, _mutex, &abst);
if (status != 0 && WorkAroundNPTLTimedWaitHang) {
pthread_cond_destroy(_cond);
pthread_cond_init(_cond, os::Linux::condAttr());
}
so we will now skip this potential recovery code.
On the signal side we signal while holding the mutex if the workaround
is enabled, and we signal after dropping the mutex otherwise. So this
code will now be using a new path. Here is the code in PlatformEvent::unpark
assert(AnyWaiters == 0 || AnyWaiters == 1, "invariant");
if (AnyWaiters != 0 && WorkAroundNPTLTimedWaitHang) {
AnyWaiters = 0;
pthread_cond_signal(_cond);
}
status = pthread_mutex_unlock(_mutex);
assert_status(status == 0, status, "mutex_unlock");
if (AnyWaiters != 0) {
// Note that we signal() *after* dropping the lock for "immortal"
Events.
// This is safe and avoids a common class of futile wakeups. In rare
// circumstances this can cause a thread to return prematurely from
// cond_{timed}wait() but the spurious wakeup is benign and the victim
// will simply re-test the condition and re-park itself.
// This provides particular benefit if the underlying platform does not
// provide wait morphing.
status = pthread_cond_signal(_cond);
assert_status(status == 0, status, "cond_signal");
}
and similarly in Parker::unpark
if (WorkAroundNPTLTimedWaitHang) {
status = pthread_cond_signal(&_cond[_cur_index]);
assert(status == 0, "invariant");
status = pthread_mutex_unlock(_mutex);
assert(status == 0, "invariant");
} else {
status = pthread_mutex_unlock(_mutex);
assert(status == 0, "invariant");
status = pthread_cond_signal(&_cond[_cur_index]);
assert(status == 0, "invariant");
}
This may cause performance perturbations that will need to be
investigated - but in theory, as per the comment above, signalling
outside the lock should be beneficial in the linux case because there is
no wait-morphing (where a signal simply takes a waiting thread and
places it into the mutex queue thereby avoiding the need to awaken the
thread so it can enqueue itself).
The change itself is of course trivial:
http://cr.openjdk.java.net/~dholmes/8130728/webrev/
I'd appreciate any comments/concerns particularly from the BSD and AIX
folk who acquired this unnecessary workaround.
If deemed necessary we could add a flag that controls whether the signal
happens with or without the lock held.
Thanks,
David
From dmitry.dmitriev at oracle.com Thu Jul 9 10:55:24 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 9 Jul 2015 13:55:24 +0300
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <559E0165.3040902@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5588EA9F.3020001@oracle.com>
<725f7631-425d-4918-8a92-230005d5b5ec@default>
<558A1AE7.6010607@oracle.com>
<224EF327-B898-4DAC-9343-4FE238604276@oracle.com>
<558AD8AD.6020009@oracle.com> <558AF2AB.7040407@oracle.com>
<558B8B45.4060307@oracle.com> <558BA1CC.6040100@oracle.com>
<558BA53E.1010600@oracle.com> <558C312F.4070606@oracle.com>
<558CEB04.5040905@oracle.com> <558D9423.1010903@oracle.com>
<5591EABE.6030301@oracle.com>
<99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
<559D8846.7060803@oracle.com> <559E0165.3040902@oracle.com>
Message-ID: <559E531C.40103@oracle.com>
Hello David,
I think that it look like same limitations which was applied to the
options in environment variables before JDK-8074895
fix. I think Ron can
add more information about that.
Thanks,
Dmitry
On 09.07.2015 8:06, David Holmes wrote:
>
>
> On 9/07/2015 6:29 AM, Dmitry Dmitriev wrote:
>> On 08.07.2015 22:26, Karen Kinnear wrote:
>>> 2) is there a maximum length to the options read in from the file?
>> The current implemented limitations are following: only one VM option
>> file can be specified, maximum size of the file is 1024 bytes, up to 64
>> VM options
>
> That seems extremely limiting. Why should there be a maximum size, why
> can't you just read the file line by line and keep processing until it
> is all read ??
>
> Thanks,
> David
From david.holmes at oracle.com Thu Jul 9 11:14:48 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jul 2015 21:14:48 +1000
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <559E531C.40103@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5588EA9F.3020001@oracle.com>
<725f7631-425d-4918-8a92-230005d5b5ec@default>
<558A1AE7.6010607@oracle.com>
<224EF327-B898-4DAC-9343-4FE238604276@oracle.com>
<558AD8AD.6020009@oracle.com> <558AF2AB.7040407@oracle.com>
<558B8B45.4060307@oracle.com> <558BA1CC.6040100@oracle.com>
<558BA53E.1010600@oracle.com> <558C312F.4070606@oracle.com>
<558CEB04.5040905@oracle.com> <558D9423.1010903@oracle.com>
<5591EABE.6030301@oracle.com>
<99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
<559D8846.7060803@oracle.com> <559E0165.3040902@oracle.com>
<559E531C.40103@oracle.com>
Message-ID: <559E57A8.2060600@oracle.com>
On 9/07/2015 8:55 PM, Dmitry Dmitriev wrote:
> Hello David,
>
> I think that it look like same limitations which was applied to the
> options in environment variables before JDK-8074895
> fix. I think Ron can
> add more information about that.
You can't read an environment variable line-by-line so we have to have
fixed buffer. A file can be read line-by-line.
Cheers,
David
> Thanks,
> Dmitry
>
> On 09.07.2015 8:06, David Holmes wrote:
>>
>>
>> On 9/07/2015 6:29 AM, Dmitry Dmitriev wrote:
>>> On 08.07.2015 22:26, Karen Kinnear wrote:
>>>> 2) is there a maximum length to the options read in from the file?
>>> The current implemented limitations are following: only one VM option
>>> file can be specified, maximum size of the file is 1024 bytes, up to 64
>>> VM options
>>
>> That seems extremely limiting. Why should there be a maximum size, why
>> can't you just read the file line by line and keep processing until it
>> is all read ??
>>
>> Thanks,
>> David
>
From daniel.daugherty at oracle.com Thu Jul 9 12:54:59 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 06:54:59 -0600
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <559E57A8.2060600@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5588EA9F.3020001@oracle.com>
<725f7631-425d-4918-8a92-230005d5b5ec@default>
<558A1AE7.6010607@oracle.com>
<224EF327-B898-4DAC-9343-4FE238604276@oracle.com>
<558AD8AD.6020009@oracle.com> <558AF2AB.7040407@oracle.com>
<558B8B45.4060307@oracle.com> <558BA1CC.6040100@oracle.com>
<558BA53E.1010600@oracle.com> <558C312F.4070606@oracle.com>
<558CEB04.5040905@oracle.com> <558D9423.1010903@oracle.com>
<5591EABE.6030301@oracle.com>
<99352AD6-77D3-42ED-AEE8-1EABD1EEA7B6@oracle.com>
<559D8846.7060803@oracle.com> <559E0165.3040902@oracle.com>
<559E531C.40103@oracle.com> <559E57A8.2060600@oracle.com>
Message-ID: <559E6F23.6080007@oracle.com>
Dimitry is correct that the current limitations on the options file
implementation are based on the previous limitations on the options
environment variables. We did track the fix for JDK-8074895 as it
made its way into the system, but we made the choice to not change
the options file implementation at this time in order to reduce the
risk to this rather large change.
In the "Future Work" section of Ron's soon to be posted document,
there are entries for removing both the 1024 byte limit and the 64
option limit.
Dan
On 7/9/15 5:14 AM, David Holmes wrote:
> On 9/07/2015 8:55 PM, Dmitry Dmitriev wrote:
>> Hello David,
>>
>> I think that it look like same limitations which was applied to the
>> options in environment variables before JDK-8074895
>> fix. I think Ron can
>> add more information about that.
>
> You can't read an environment variable line-by-line so we have to have
> fixed buffer. A file can be read line-by-line.
>
> Cheers,
> David
>
>> Thanks,
>> Dmitry
>>
>> On 09.07.2015 8:06, David Holmes wrote:
>>>
>>>
>>> On 9/07/2015 6:29 AM, Dmitry Dmitriev wrote:
>>>> On 08.07.2015 22:26, Karen Kinnear wrote:
>>>>> 2) is there a maximum length to the options read in from the file?
>>>> The current implemented limitations are following: only one VM option
>>>> file can be specified, maximum size of the file is 1024 bytes, up
>>>> to 64
>>>> VM options
>>>
>>> That seems extremely limiting. Why should there be a maximum size, why
>>> can't you just read the file line by line and keep processing until it
>>> is all read ??
>>>
>>> Thanks,
>>> David
>>
From daniel.daugherty at oracle.com Thu Jul 9 13:00:25 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 07:00:25 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559E030C.8010603@oracle.com>
References: <55972558.6060905@oracle.com> <559A2397.2010409@oracle.com>
<559AE96D.6010508@oracle.com> <559B7BAA.8070705@oracle.com>
<559C0C4D.8090504@oracle.com> <559E030C.8010603@oracle.com>
Message-ID: <559E7069.7030302@oracle.com>
On 7/8/15 11:13 PM, David Holmes wrote:
> On 8/07/2015 3:28 AM, Daniel D. Daugherty wrote:
>> On 7/7/15 1:11 AM, David Holmes wrote:
>>> Hi Dan,
>>>
>>> Top posting as I'm lazy and running late :)
>>
>> No problem with the top posting. It makes your remaining
>> concerns earlier to see and address.
>>
>>
>>> Okay ... I'm still uneasy about adding two additional flags for the
>>> "release monitors on exit" situation. I hear what you are saying about
>>> the cost of the monitor check - I had thought we kept easy access to
>>> the set of monitors owned by a thread but it seems not, so trawling
>>> the global monitor list is indeed an expensive operation. :( So okay
>>> but I don't like it :)
>>
>> Since JavaThreadExitReleasesMonitors and GuaranteeOnMonitorMismatch
>> are targeted at finding/working around bugs in the Java Monitor
>> implementation, I'm going to take a look at moving the flag support
>> down into Java Monitor subsystem's implementation specific options.
>> That will get the options out of the global space and they won't
>> have to be counted against the "cap and trade" limit :-)
>>
>>
>>> I also take your point about viewing the new flag as a superset of the
>>> JNI-detach case. That's fair enough, but of course that aspect needs
>>> to be documented.
>>
>> I'm starting to wonder why we have the 'JNIDetachReleasesMonitors'
>> option at all. Is there a good reason to be able to turn off this
>> piece of code?
>
> My recollection is that hotspot did not implement that part of the
> spec. Simply switching the behaviour with no way to restore the
> original behaviour could break existing apps. Hence a flag, on by
> default.
That's very likely the case. I'll poke around in my historical
archive and see what shakes out.
> Of course by now apps should be spec compliant themselves so this
> seems a flag that should itself be deprecated in 9 and targetted for
> removal in 10. (That will help with the 'conservation of flags'
> problem :) ).
Sounds like a good RFE.
Dan
>
>>
>>
>>> I was left unclear about your position on the VerboseStackTrace. I
>>> agree the new output was likely put under a flag to avoid disturbing
>>> existing output formats. But I don't see that it warrants its own flag
>>> - to me using Verbose okay (though the fact it is a develop flag is
>>> limiting).
>>
>> Thanks for reminding me that '-XX:+Verbose' is a develop flag.
>> That's another reason for not using that flag. Combined with
>> the fact that '-XX:+Verbose' is considered a modifier to other
>> flags and thread dumps aren't enabled/triggered by a flag means
>> (to me anyway) that '-XX:+Verbose' is still not a good match.
>>
>> However, I have a vague memory that the Java Monitor subsystem
>> has its own "verbose" flag. I'll take a look at switching to
>> that...
>
> Okay
>
>> Will be working on the next round...
>
> Thanks,
> David
>
>> Dan
>>
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>> On 7/07/2015 6:47 AM, Daniel D. Daugherty wrote:
>>>> On 7/6/15 12:43 AM, David Holmes wrote:
>>>>> Hi Dan,
>>>>>
>>>>> Metacomment: Could I suggest that in a RFR your subject line has the
>>>>> form : , rather than (bugid) - especially
>>>>> when the synopsis actually starts with a bug id :) Thanks.
>>>>
>>>> Yup that bug synopsis is/was a mess:
>>>>
>>>> Changed the synopsis line to :
>>>>
>>>> thread dump improvements, comment additions, new diagnostics
>>>> inspired by 8077392
>>>>
>>>> Also updated the e-mail thread subject line to your suggested format.
>>>> Will try to remember to switch to that style in the future.
>>>>
>>>>
>>>>> Mostly okay but some major concerns around the can of worms that
>>>>> JavaThreadExitReleasesMonitors opens up.
>>>>
>>>> This is Java monitors so "can of worms" is familiar! :-)
>>>>
>>>>
>>>>>
>>>>> On 4/07/2015 10:14 AM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> The hunt for the following bug:
>>>>>>
>>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to
>>>>>> complete
>>>>>>
>>>>>> and David C's work on the following bug:
>>>>>>
>>>>>> JDK-8069412 Locks need better debug-printing support
>>>>>>
>>>>>> have inspired additional thread dump improvements, comment additions
>>>>>> to some Java monitor code and some new diagnostic options.
>>>>>
>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>>
>>>>> 1821 // update _owner from from BasicLock to thread
>>>>>
>>>>> Typo: from from
>>>>
>>>> Will fix.
>>>>
>>>>
>>>>> 2091 // the placeholder value. If that didn't work, then
>>>>> another
>>>>> 2092 // grabbed the lock so we're done (and exit was a
>>>>> success).
>>>>>
>>>>> another -> another thread ?
>>>>
>>>> Yes, "another thread" is better. Will fix.
>>>>
>>>>
>>>>> 2201 // If that didn't work, then another grabbed the lock
>>>>> 2202 // so we're done (and exit was a success).
>>>>>
>>>>> another -> another thread ?
>>>>
>>>> Yes, "another thread" is better. Will fix.
>>>>
>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/oops/markOop.cpp
>>>>>
>>>>> 40 st->print("NULL"); // this should not happen
>>>>>
>>>>> Shouldn't that be an assert or guarantee in that case? Or at a
>>>>> minimum
>>>>> print something like: "NULL (but you should never see this!)"
>>>>
>>>> This is a relocated line from David C's change:
>>>>
>>>> old 49: st->print("monitor=NULL");
>>>>
>>>> I simply added a comment to it. I don't think I like the idea of the
>>>> thread dump code assert()'ing or guarantee()'ing because there might
>>>> be other useful info that would have been printed after the assert()
>>>> or guarantee() failure.
>>>>
>>>> I do like the idea of changing the message to:
>>>>
>>>> 40: st->print("NULL (this should never be seen!)");
>>>>
>>>>
>>>>> 42 BasicLock * bl = (BasicLock *) mon->owner();
>>>>>
>>>>> What information has told us this is a BasicLock* not a Thread* ? But
>>>>> as all you do is print bl why not just p2i(mon->owner()) ?
>>>>
>>>> Again, this is a relocated line from David C's change:
>>>>
>>>> old 51: BasicLock * bl = (BasicLock *) mon->owner();
>>>>
>>>> I'm going to guess that David C had some other code in there before
>>>> that needed/assumed that the field is a "BasicLock *", but that code
>>>> didn't make it into his final version.
>>>>
>>>> I will drop the 'bl' local and update the p2i() call to use
>>>> mon->owner() directly.
>>>>
>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/globals.hpp
>>>>>
>>>>> JavaThreadExitReleasesMonitors has me perplexed. The JNI DetachThread
>>>>> case seems to be a concession to badly written code that fails to
>>>>> release locks on error paths.
>>>>
>>>> I don't think I would call the JNIDetachReleasesMonitors case a
>>>> concession
>>>> to badly written JNI code. 6282335 is very clear that this code was
>>>> added
>>>> to meet the JNI spec. The JNI spec words might be considered a
>>>> concession...
>>>>
>>>> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#DetachCurrentThread
>>>>
>>>>
>>>>
>>>>
>>>> > DetachCurrentThread
>>>> >
>>>> > jint DetachCurrentThread(JavaVM *vm);
>>>> >
>>>> > Detaches the current thread from a Java VM. All Java monitors
>>>> > held by this thread are released. All Java threads waiting for
>>>> > this thread to die are notified.
>>>> >
>>>> > The main thread can be detached from the VM.
>>>>
>>>>
>>>>
>>>>> The equivalent for a Java thread would again involve lock acquisition
>>>>> via JNI. But I don't recall ever seeing a bug report or RFE
>>>>> related to
>>>>> this. What seems to have motivated this new flag is the potential for
>>>>> a broken VM to actually leave the monitor locked (e.g. because
>>>>> compiled code failed to do the unlock on all paths).
>>>>
>>>> 8077392 and bugs like it are exactly the reason for adding these
>>>> two options.
>>>>
>>>> JavaThreadExitReleasesMonitors is added to provide a work around
>>>> until the underlying bug or bugs are fixed. This option is targeted
>>>> at folks that are chasing their own bugs and don't care about this
>>>> one.
>>>>
>>>> GuaranteeOnMonitorMismatch is added to help hunt 8077392 specifically
>>>> and to sanity check for similar issues generally. I can see using the
>>>> two options in combination with existing test suites as a stress test
>>>> for the Java monitor subsystem.
>>>>
>>>>
>>>>> To address that I'd be inclined to simply have a guarantee in the
>>>>> Java
>>>>> thread exit path, rather than a flag to do the clean up and another
>>>>> flag to control a guarantee.
>>>>
>>>> The check for an unexited Java monitor is not cheap.
>>>>
>>>> The existing check under the JNIDetachReleasesMonitors flag is
>>>> positioned to only affect threads using JNI DetachCurrentThread()
>>>> and that cost is justified as part of meeting the JNI spec.
>>>>
>>>> Adding the unexited Java monitor check to all exiting Java
>>>> threads should not be done lightly due to the cost. If the
>>>> VM is functioning correctly, then why impose this cost on
>>>> all exiting Java threads?
>>>>
>>>>
>>>>> I don't think two new command-line options (has this gone through CCC
>>>>> yet?) are justified.
>>>>
>>>> No, this has not gone through CCC yet. My preference is to get
>>>> code review feedback (like this) before submitting a CCC.
>>>>
>>>> I suppose I could have simply added more sub-options to the
>>>> existing Java monitor subsystem knobs and switches, but it
>>>> seemed to make sense to model JavaThreadExitReleasesMonitors
>>>> on the existing JNIDetachReleasesMonitors.
>>>>
>>>>
>>>>> Also note that allowing for JVM induced missing unlocks is something
>>>>> that can affect JNI attached threads as well as regular Java threads.
>>>>> I'll take this up in discussing thread.cpp below.
>>>>>
>>>>> That aside, the comment, which was modelled on the JNI DetachThread
>>>>> variant, does not really work in this case:
>>>>>
>>>>> 2801 "JavaThread exit() releases monitors owned by thread")
>>>>> \
>>>>>
>>>>> JavaThread is not a programming concept but an internal JVM
>>>>> abstraction. I would suggest something like:
>>>>>
>>>>> "Java thread termination releases monitors unexpectedly still
>>>>> owned by
>>>>> thread"
>>>>
>>>> I'll switch to your description text if we end up keeping the
>>>> new options.
>>>>
>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>
>>>>> No comments
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>
>>>>> If we find the unexpected locked monitor it would be useful to see
>>>>> more Java level information about the Thread (in the non-detaching
>>>>> case) and the object that is locked.
>>>>
>>>> I can probably steal some code from the thread dump side to
>>>> give us more info about the Object associated with the Java
>>>> monitor...
>>>>
>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/thread.cpp
>>>>>
>>>>> As noted previously JNI attached threads can also be affected by JVM
>>>>> induced locking bugs. So the comment block:
>>>>>
>>>>> 1804 // 6282335 JNI DetachCurrentThread spec states that all Java
>>>>> monitors
>>>>> 1805 // held by this thread must be released. A detach operation
>>>>> must only
>>>>> 1806 // get here if there are no Java frames on the stack.
>>>>> Therefore, any
>>>>> 1807 // owned monitors at this point MUST be JNI-acquired monitors
>>>>> which are
>>>>> 1808 // pre-inflated and in the monitor cache.
>>>>>
>>>>> is not strictly correct as it is presuming a correctly operating JVM.
>>>>
>>>> I actually disagree with the last two sentences in that comment block,
>>>> but I didn't have a good rewrite in mind. I'll think about it more.
>>>>
>>>>
>>>>
>>>>> Further the logic now applied:
>>>>>
>>>>> 1816 if ((exit_type == jni_detach && JNIDetachReleasesMonitors) ||
>>>>> 1817 JavaThreadExitReleasesMonitors) {
>>>>>
>>>>> is also not "correct" because if we have
>>>>> JavaThreadExitReleasesMonitors true while
>>>>> JNIDetachReleasesMonitors is
>>>>> false, we will in fact release any JNI acquired monitors because we
>>>>> can't make the distinction.
>>>>
>>>> I don't think JNIDetachReleasesMonitors only has to deal with
>>>> JNI-acquired
>>>> monitors and I don't think that JavaThreadExitReleasesMonitors only
>>>> has to
>>>> deal with Java code acquired monitors. I see these options as
>>>> applying to
>>>> "how you got to the Java thread exit path" and not applying to "what
>>>> needs
>>>> to be cleaned up".
>>>>
>>>> I see JNIDetachReleasesMonitors as a way of cleaning up unexited Java
>>>> monitors when we're executing the JNI DetachCurrentThread() code path.
>>>> I don't really care why the Java monitors are unexited... and I think
>>>> the spec wording is clear that all unexited Java monitors are cleaned
>>>> up... not just JNI-acquired monitors.
>>>>
>>>> I see JavaThreadExitReleasesMonitors as a way of cleaning up unexited
>>>> Java monitors in any code path where we are exiting the Java thread.
>>>> I see
>>>> JavaThreadExitReleasesMonitors as a superset of
>>>> JNIDetachReleasesMonitors.
>>>>
>>>>
>>>>> Given we can't make the distinction I don't see any way for these
>>>>> separate flags to actually work well together.
>>>>
>>>> I think they work well together when JavaThreadExitReleasesMonitors
>>>> is seen as a superset of JNIDetachReleasesMonitors. Of course, that
>>>> hinges on my opinion that JNIDetachReleasesMonitors applies to any
>>>> unexited Java monitor and not just JNI-acquired Java monitors.
>>>>
>>>>
>>>>> As I said above I'm more inclined to just add a guarantee to the
>>>>> non-detach case, than add two new flags. (Even though this means
>>>>> there
>>>>> won't be detection for such bugs when JNI attached threads encounter
>>>>> them - including the main thread :( ).
>>>>
>>>> I really don't want to add this check to all Java thread exit
>>>> paths since it is expensive.
>>>>
>>>>
>>>>> As I said this has me perplexed. :(
>>>>
>>>> Hopefully, I've explained it better now.
>>>>
>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/vframe.cpp
>>>>>
>>>>> 170 // It would be nice to distinguish between "waiting on" and
>>>>> 171 // "waited on". Currently, "waiting on" here with a
>>>>> 172 // java.lang.Thread.State == "WAITING (on object monitor)"
>>>>> 173 // earlier in the output means that the monitor has not yet
>>>>> been
>>>>> 174 // notified and java.lang.Thread.State == "BLOCKED (on
>>>>> object
>>>>> 175 // monitor)" earlier in the output means that the
>>>>> monitor has
>>>>> 176 // been notified and the thread is blocked on reentry.
>>>>>
>>>>> That's a very long sentence that can be quite difficult to parse and
>>>>> could probably be reworded to describe how the output should be
>>>>> interpreted eg:
>>>>>
>>>>> // If earlier in the output we reported java.lang.Thread.State ==
>>>>> // "WAITING (on object monitor)" and now we report "waited on", then
>>>>> // we are still waiting for notification [or timeout?]. Otherwise if
>>>>> // we earlier reported java.lang.Thread.State == "BLOCKED (on object
>>>>> // monitor)", then we are actually waiting to reacquire the monitor
>>>>> // lock. At this level we can't distinguish the two cases to report
>>>>> // "waited on" rather than "waiting on" for the second case.
>>>>
>>>> I'll take a look at rewriting the comment and may just take your
>>>> version entirely.
>>>>
>>>>
>>>>> I wonder if we can prod deeper into VM state to try and make the
>>>>> distinction?
>>>>
>>>> I played around with doing just that, but it seems like the M&M
>>>> code that fetches similar state probes the state stored in the
>>>> java.lang.Thread object. I didn't want to go there.
>>>>
>>>>
>>>>>
>>>>> 184 } else {
>>>>> 185 st->print_cr("\t- %s ", wait_state);
>>>>>
>>>>> The concept of "locals" is confusing here. Isn't the "local" in this
>>>>> case just the object that we have waited upon? In which case we
>>>>> should
>>>>> say "no object reference available".
>>>>
>>>> I got the phrase "locals" from the compiler code that was trying to
>>>> decode the object reference. I can change to "no object reference
>>>> available".
>>>> I definitely want to say _something_ here. The existing code is just
>>>> silent.
>>>>
>>>>
>>>>> Though I would have thought/hoped there must be a way to find the
>>>>> object reference even in a compiled frame?
>>>>
>>>> Yes, if you deopt... I didn't want to go there.
>>>>
>>>>
>>>>> 195 // Print out all monitors that we have locked, are trying to
>>>>> lock
>>>>> 196 // or are trying to relock after a wait().
>>>>>
>>>>> that makes it sound like there are three cases when really a "relock"
>>>>> is just a specific case of lock. I would suggest:
>>>>>
>>>>> // Print out all monitors that we have locked, or are trying to
>>>>> // lock, including re-locking when returning from a wait().
>>>>
>>>> Making it more clear that the "re-locking" is coming from "wait()"
>>>> is an improvement. I'll fix this.
>>>>
>>>>
>>>>> 252 lock_state = "waiting to relock";
>>>>>
>>>>> I prefer "waiting to re-lock in wait()", if that isn't too long.
>>>>> Otherwise "relock" needs to be a concept people are familiar with.
>>>>
>>>> I like "waiting to re-lock in wait()".
>>>>
>>>>
>>>>> 260 if (VerboseStackTrace && mark != NULL) {
>>>>> 261 st->print("\t- lockbits=");
>>>>> 262 mark->print_on(st);
>>>>>
>>>>> This really doesn't seem to warrant a new diagnostic flag, regardless
>>>>> of whether we think applying -XX:+Verbose is a good fit or not.
>>>>
>>>> I suspect that David C didn't want to change the default output format
>>>> and neither do I. We have some tests that try to parse out specific
>>>> things from thread dumps to verify certain bug fixes and we don't want
>>>> to break those. I'm thinking of the "duplicate owner" bug fix that we
>>>> fixed in thread dumps, but I can't pull up the bug ID (yet)...
>>>>
>>>> Thanks for the thorough review. I have to say that I wasn't expecting
>>>> much comment on this review at all. :-)
>>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -------
>>>>>
>>>>>> This work is being tracked by the following bug ID:
>>>>>>
>>>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>>>> additions, new diagnostics
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>>>
>>>>>> Here is the webrev URL:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>>>
>>>>>> Testing:
>>>>>>
>>>>>> - RBT vm.quick batches (in process)
>>>>>> - JPRT test jobs
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Gory details about the changes are below...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> 8130448 summary of changes:
>>>>>>
>>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>>> - comment additions for the assembly code
>>>>>>
>>>>>> src/share/vm/oops/markOop.cpp
>>>>>> - has_monitor() has to be checked before is_locked() since
>>>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>>>> - code style fixes
>>>>>>
>>>>>> src/share/vm/runtime/globals.hpp
>>>>>> - add VerboseStackTrace diagnostic option
>>>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>>>> - add JavaThreadExitReleasesMonitors product option;
>>>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>> - fix assert wording
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>>
>>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>> - add GuaranteeOnMonitorMismatch support with some
>>>>>> diagnostic output
>>>>>>
>>>>>> src/share/vm/runtime/thread.cpp
>>>>>> - add JavaThreadExitReleasesMonitors support
>>>>>>
>>>>>> src/share/vm/runtime/vframe.cpp
>>>>>> - clarify existing comments
>>>>>> - add comments to clarify what "waiting on" means
>>>>>> - add line to show when we are "waiting on", but
>>>>>> there are no locals available (previously we were
>>>>>> "waiting on" silently)
>>>>>> - add support for "waiting to relock" which can happen
>>>>>> for any of the monitors and not just the top monitor
>>>>>> - switch mark->print_on() verbose output to new
>>>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>>>> with a specific switch so the '-XX:+Verbose' model of
>>>>>> being a modifier for another option does not fit
>>>>
>>
From daniel.daugherty at oracle.com Thu Jul 9 13:08:41 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 07:08:41 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559E1611.2070803@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
<559E1611.2070803@oracle.com>
Message-ID: <559E7259.1070605@oracle.com>
David,
Thanks for the quick re-review!
Responses embedded below...
On 7/9/15 12:34 AM, David Holmes wrote:
> Hi Dan,
>
> On 9/07/2015 7:33 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I've updated this patch based on David H's comments along with
>> some additional cleanup.
>
> So to address the high-level changes:
>
> - Use ObjectMonitor::Knob_Verbose as the verbosity flag for printing
> the lockbits in the stack dump. Okay - though I do wonder why the
> SyncVerbose flag also exists?
I'll ping Dice to see if there's a reason for two different verbose
flags in the monitor subsystem. I have to admit that I didn't notice
that one in the large collection of knobs and switches... :-(
> - Use ObjectMonitor::Knob_ExitRelease to control whether Java threads
> are checked for locked monitors when they exit
> - Use ObjectMonitor::Knob_VerifyMatch to control whether finding a
> locked (hence unmatched) monitor causes an abort
>
> That seems like a good way to work within the existing mechanism for
> customizing the sync logic - and no new global options (though SQE
> will still need tests for using these knobs I think).
Glad that this version is more acceptable.
> Some specific comments below ...
>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8130448 8077392 inspired thread dump improvements, comment
>> additions, new diagnostics
>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
>
> src/share/vm/runtime/objectMonitor.cpp
>
> 2393 if (Knob_ReportSettings && v != NULL) {
> 2394 tty->print_cr("INFO: SyncKnob: %s %d(%d)", Key, rslt, Default) ;
> 2395 tty->flush();
> 2396 }
>
> I suspect these were not tty using because this might get called
> before the tty has been initialized - but I can't see how that might
> arise (nor can I be certain it can't).
I couldn't see how tty could not be initialized at these points either.
My current plan is to go with this change to 'tty' and if we run into
an early use case, then we do something else _and_ comment it.
Although with unified logging coming... this may be moot (but the
tty version will be easier to port...)
>
> Ditto for similar changes throughout.
>
> ---
>
> src/share/vm/runtime/synchronizer.cpp
>
> 1648 void do_monitor(ObjectMonitor* mid) {
> 1649 if (mid->owner() == THREAD) {
> 1650 if (ObjectMonitor::Knob_VerifyMatch != 0) {
> 1651 Handle obj((oop) mid->object());
> 1652 tty->print("INFO: unexpected locked object:");
> 1653 javaVFrame::print_locked_object_class_name(tty, obj,
> "locked");
> 1654 }
> 1655 guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
> 1656 err_msg("exiting JavaThread=" INTPTR_FORMAT
> 1657 " unexpectedly owns ObjectMonitor="
> INTPTR_FORMAT,
> 1658 THREAD, mid));
> 1659 (void)mid->complete_exit(CHECK);
> 1660 }
> 1661 }
>
> Took me a while to figure out the expected control flow here. Doesn't
> the above simplify to:
>
> void do_monitor(ObjectMonitor* mid) {
> if (mid->owner() == THREAD) {
> if (ObjectMonitor::Knob_VerifyMatch != 0) {
> Handle obj((oop) mid->object());
> tty->print("INFO: unexpected locked object:");
> javaVFrame::print_locked_object_class_name(tty, obj, "locked");
> fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
> " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
> THREAD, mid));
> }
> (void)mid->complete_exit(CHECK);
> }
> }
>
> ?
Yes, your version is cleaner.
Any particular reason to use "fatal(...)" instead of
"guarantee(false, ...)". I've seen both...
Dan
>
> Thanks,
> David
>
>>
>> The easiest way to review the delta is to download the two patch
>> files and compare them in something like jfilemerge:
>>
>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>>
>>
>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>>
>>
>>
>> Testing:
>>
>> - Aurora Adhoc RT/SVC nightly batches (in process)
>> - JPRT test jobs
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Gory details about the changes are below...
>>
>> Dan
>>
>> Changes between CR0 and CR1 are:
>>
>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>
>> - fix comment typos, clarify comment wording
>>
>> src/share/vm/oops/markOop.cpp
>>
>> - clarify output messages
>> - get rid of confusing local variable
>>
>> src/share/vm/runtime/globals.hpp
>>
>> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
>> and JavaThreadExitReleasesMonitors options
>> - there are no longer changes to this file
>>
>> src/share/vm/runtime/objectMonitor.cpp
>>
>> - add ObjectMonitor::Knob_ExitRelease suboption to replace
>> JavaThreadExitReleasesMonitors
>> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
>> GuaranteeOnMonitorMismatch
>> - cleanup messy logging:
>> - switch from '::printf()' -> 'tty->print_cr()'
>> - switch from '::fflush()' -> 'tty->flush()'
>>
>> src/share/vm/runtime/objectMonitor.hpp
>>
>> - add ObjectMonitor::Knob_ExitRelease suboption
>> - add ObjectMonitor::Knob_VerifyMatch suboption
>> - cleanup messy logging
>>
>> src/share/vm/runtime/synchronizer.cpp
>>
>> - cleanup messy logging
>> - switch from GuaranteeOnMonitorMismatch to
>> ObjectMonitor::Knob_VerifyMatch
>> - add diagnostic information about the locked object
>> when ReleaseJavaMonitorsClosure::do_monitor() finds
>> a problem
>>
>> src/share/vm/runtime/thread.cpp
>>
>> - clarify comments
>> - switch from JavaThreadExitReleasesMonitors to
>> ObjectMonitor::Knob_ExitRelease
>>
>> src/share/vm/runtime/vframe.cpp
>>
>> - print_locked_object_class_name() is now public
>> - clarify comments
>> - clarify output messages
>> - switch from VerboseStackTrace to the already existing
>> ObjectMonitor::Knob_Verbose
>>
>> src/share/vm/runtime/vframe.hpp
>>
>> - print_locked_object_class_name() is now public
>>
>>
>> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> The hunt for the following bug:
>>>
>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>
>>> and David C's work on the following bug:
>>>
>>> JDK-8069412 Locks need better debug-printing support
>>>
>>> have inspired additional thread dump improvements, comment additions
>>> to some Java monitor code and some new diagnostic options.
>>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>> additions, new diagnostics
>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>
>>> Testing:
>>>
>>> - RBT vm.quick batches (in process)
>>> - JPRT test jobs
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>> 8130448 summary of changes:
>>>
>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>> - comment additions for the assembly code
>>>
>>> src/share/vm/oops/markOop.cpp
>>> - has_monitor() has to be checked before is_locked() since
>>> the has_monitor() bits are a superset of the is_locked() bits
>>> - code style fixes
>>>
>>> src/share/vm/runtime/globals.hpp
>>> - add VerboseStackTrace diagnostic option
>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>> - add JavaThreadExitReleasesMonitors product option;
>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>> - delete unused ObjectMonitor::try_enter()
>>> - fix assert wording
>>>
>>> src/share/vm/runtime/objectMonitor.hpp
>>> - delete unused ObjectMonitor::try_enter()
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>> - add GuaranteeOnMonitorMismatch support with some
>>> diagnostic output
>>>
>>> src/share/vm/runtime/thread.cpp
>>> - add JavaThreadExitReleasesMonitors support
>>>
>>> src/share/vm/runtime/vframe.cpp
>>> - clarify existing comments
>>> - add comments to clarify what "waiting on" means
>>> - add line to show when we are "waiting on", but
>>> there are no locals available (previously we were
>>> "waiting on" silently)
>>> - add support for "waiting to relock" which can happen
>>> for any of the monitors and not just the top monitor
>>> - switch mark->print_on() verbose output to new
>>> VerboseStackTrace switch; thread dumps are not enabled
>>> with a specific switch so the '-XX:+Verbose' model of
>>> being a modifier for another option does not fit
>>>
>>>
>>
From karen.kinnear at oracle.com Thu Jul 9 13:20:48 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 9 Jul 2015 09:20:48 -0400
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To: <559E1740.6040007@oracle.com>
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
<59B99866-C9BB-46F8-87C3-7E6FA8122227@oracle.com>
<559D66A7.6040902@oracle.com> <559D9FBB.6020503@oracle.com>
<559E1740.6040007@oracle.com>
Message-ID:
Dan,
ship it!
thanks,
Karen
On Jul 9, 2015, at 2:40 AM, David Holmes wrote:
> On 9/07/2015 8:10 AM, Daniel D. Daugherty wrote:
>>
>> On 7/8/15 12:06 PM, Daniel D. Daugherty wrote:
>>> On 7/8/15 11:53 AM, Karen Kinnear wrote:
>>>> Dan,
>>>>
>>>> Looks good.
>>>>
>>>> Only comment is -
>>>>
>>>> In ObjectMonitor::INotify - lines 1668-1671
>>>> the default value of policy is "2"
>>>> -- which basically is "b" not "a" unless the EntryList is empty.
>>>
>>> Nice catch! For folks on the alias that don't have this code
>>> tattooed on the inside of their eyelids. This is the relevant code:
>>>
>>> src/share/vm/runtime/objectMonitor.cpp:
>>>
>>> 136 static int Knob_MoveNotifyee = 2; // notify() -
>>> disposition of notifyee
>>>
>>>
>>>
>>> 1659 void ObjectMonitor::INotify(Thread * Self) {
>>> 1660 const int policy = Knob_MoveNotifyee;
>>>
>>>
>>>
>>> 1668 // Disposition - what might we do with iterator ?
>>> 1669 // a. add it directly to the EntryList - either tail or head.
>>> 1670 // b. push it onto the front of the _cxq.
>>> 1671 // For now we use (a).
>>>
>>>
>>>
>>> 1710 } else if (policy == 2) { // prepend to cxq
>>>
>>> I will update the comment.
>>
>> Don't think this update is worth a new webrev so here
>> are the diffs instead:
>>
>> $ diff src/share/vm/runtime/objectMonitor.cpp{.cr1,}
>> 1669,1671c1669,1672
>> < // a. add it directly to the EntryList - either tail or head.
>> < // b. push it onto the front of the _cxq.
>> < // For now we use (a).
>> ---
>> > // a. add it directly to the EntryList - either tail (policy == 1)
>> > // or head (policy == 0).
>> > // b. push it onto the front of the _cxq (policy == 2).
>> > // For now we use (b).
>>
>> Thanks again for the catch!
>
> Yep good catch!
>
> David
>
>> Dan
>>
>>
>>>
>>> Dan
>>>
>>>
>>>>
>>>> thanks,
>>>> Karen
>>>>
>>>> On Jul 3, 2015, at 8:11 PM, Daniel D. Daugherty wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> I've updated the patch for Contended Locking fast notify bucket
>>>>> based on David H's and Karen's comments.
>>>>>
>>>>> This work is being tracked by the following bug ID:
>>>>>
>>>>> JDK-8075171 Contended Locking fast notify bucket
>>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>>
>>>>> Here is the webrev URL:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>>>>>
>>>>> Here is the JEP link:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>>
>>>>> Testing:
>>>>>
>>>>> - RBT vm.quick batches (in process)
>>>>> - JPRT test jobs
>>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>>> - CallTimerGrid stress testing (in process)
>>>>>
>>>>>
>>>>> The changes in this round are in only four of the files:
>>>>>
>>>>> src/share/vm/opto/runtime.cpp
>>>>>
>>>>> - deleted comment about hashCode() that belongs in a different bucket
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>
>>>>> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
>>>>> - cleanup recheck interval code
>>>>> - ObjectMonitor::INotify() return type is now "void"
>>>>> - delete duplicate comments, clarify/rewrite some comments
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>
>>>>> - ObjectMonitor::INotify() return type is now "void"
>>>>>
>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>
>>>>> - clarify/rewrite comments, add additional comments
>>>>> - cleanup variables in ObjectSynchronizer::quick_notify
>>>>> - refactor loop to be more clear
>>>>> - delete unused enum MaximumRecheckInterval
>>>>>
>>>>> The easiest way to review the delta is to download the two patch
>>>>> files and compare them in something like jfilemerge:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> I have the Contended Locking fast notify bucket ready for review.
>>>>>>
>>>>>> The code changes in this bucket are the final piece in the triad
>>>>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>>>>> macro assembler changes in this bucket (yeah!), but there are
>>>>>> code review cleanups motivated by comments on other buckets, e.g.,
>>>>>> changing variables like 'Tally' -> 'tally'.
>>>>>>
>>>>>> This work is being tracked by the following bug ID:
>>>>>>
>>>>>> JDK-8075171 Contended Locking fast notify bucket
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>>>
>>>>>> Here is the webrev URL:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>>>>
>>>>>> Here is the JEP link:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>>>
>>>>>> Testing:
>>>>>>
>>>>>> - Aurora Adhoc RT/SVC baseline batch
>>>>>> - JPRT test jobs
>>>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>>>> - CallTimerGrid stress testing (in process)
>>>>>> - Aurora performance testing:
>>>>>> - out of the box for the "promotion" and 32-bit server configs
>>>>>> - heavy weight monitors for the "promotion" and 32-bit server
>>>>>> configs
>>>>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>>>>> (in process)
>>>>>>
>>>>>> The hang somehow introduced by the "fast enter" bucket is still
>>>>>> unresolved, but progress is being made. That work is being tracked
>>>>>> by the following bug:
>>>>>>
>>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>>>>
>>>>>> You'll see a change that re-enables the "fast enter" bucket in this
>>>>>> webrev, but that change will not be pushed when we're done with the
>>>>>> review of this bucket unless JDK-8077392 is resolved.
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Gory details about the changes are below...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> 8075171 summary of changes:
>>>>>>
>>>>>> src/share/vm/classfile/vmSymbols.hpp
>>>>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>>>>
>>>>>> src/share/vm/opto/library_call.cpp
>>>>>> - Add optional inline_notify() that is controlled by new
>>>>>> '-XX:[+-]InlineNotify' option
>>>>>>
>>>>>> src/share/vm/opto/runtime.cpp
>>>>>> src/share/vm/opto/runtime.hpp
>>>>>> - Add OptoRuntime::monitor_notify_C() and
>>>>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>>>>> the new "fast notify" code paths
>>>>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>>>>> the above two new functions
>>>>>>
>>>>>> src/share/vm/runtime/globals.hpp
>>>>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>>>>> enabled (true)
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>>>>> into wrappers that call the new ObjectMonitor::INotify()
>>>>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>>>>> between "notify" and "notifyAll" code paths
>>>>>>
>>>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>>> - Temporarily re-enable the "fast enter" optimization in order
>>>>>> to do performance testing. JDK-8077392 is still unresolved,
>>>>>> but progress is being made.
>>>>>>
>>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>> src/share/vm/runtime/synchronizer.hpp
>>>>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>>>>> new "fast notify" code paths
>>>>>> - The new code handles a couple of special cases where the
>>>>>> "notify" can be done without the heavy weight slow-path
>>>>>> (thread state transitions and other baggage)
>>>>>>
>>>>>>
>>>
>>>
>>>
>>
From daniel.daugherty at oracle.com Thu Jul 9 13:23:18 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 07:23:18 -0600
Subject: RFR(S) Contended Locking fast notify bucket (8075171)
In-Reply-To:
References: <555A4678.7020308@oracle.com> <559724B0.6000507@oracle.com>
<59B99866-C9BB-46F8-87C3-7E6FA8122227@oracle.com>
<559D66A7.6040902@oracle.com> <559D9FBB.6020503@oracle.com>
<559E1740.6040007@oracle.com>
Message-ID: <559E75C6.2030107@oracle.com>
Thanks for closing the loop on this one.
Dan
On 7/9/15 7:20 AM, Karen Kinnear wrote:
> Dan,
>
> ship it!
>
> thanks,
> Karen
>
> On Jul 9, 2015, at 2:40 AM, David Holmes wrote:
>
>> On 9/07/2015 8:10 AM, Daniel D. Daugherty wrote:
>>> On 7/8/15 12:06 PM, Daniel D. Daugherty wrote:
>>>> On 7/8/15 11:53 AM, Karen Kinnear wrote:
>>>>> Dan,
>>>>>
>>>>> Looks good.
>>>>>
>>>>> Only comment is -
>>>>>
>>>>> In ObjectMonitor::INotify - lines 1668-1671
>>>>> the default value of policy is "2"
>>>>> -- which basically is "b" not "a" unless the EntryList is empty.
>>>> Nice catch! For folks on the alias that don't have this code
>>>> tattooed on the inside of their eyelids. This is the relevant code:
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp:
>>>>
>>>> 136 static int Knob_MoveNotifyee = 2; // notify() -
>>>> disposition of notifyee
>>>>
>>>>
>>>>
>>>> 1659 void ObjectMonitor::INotify(Thread * Self) {
>>>> 1660 const int policy = Knob_MoveNotifyee;
>>>>
>>>>
>>>>
>>>> 1668 // Disposition - what might we do with iterator ?
>>>> 1669 // a. add it directly to the EntryList - either tail or head.
>>>> 1670 // b. push it onto the front of the _cxq.
>>>> 1671 // For now we use (a).
>>>>
>>>>
>>>>
>>>> 1710 } else if (policy == 2) { // prepend to cxq
>>>>
>>>> I will update the comment.
>>> Don't think this update is worth a new webrev so here
>>> are the diffs instead:
>>>
>>> $ diff src/share/vm/runtime/objectMonitor.cpp{.cr1,}
>>> 1669,1671c1669,1672
>>> < // a. add it directly to the EntryList - either tail or head.
>>> < // b. push it onto the front of the _cxq.
>>> < // For now we use (a).
>>> ---
>>>> // a. add it directly to the EntryList - either tail (policy == 1)
>>>> // or head (policy == 0).
>>>> // b. push it onto the front of the _cxq (policy == 2).
>>>> // For now we use (b).
>>> Thanks again for the catch!
>> Yep good catch!
>>
>> David
>>
>>> Dan
>>>
>>>
>>>> Dan
>>>>
>>>>
>>>>> thanks,
>>>>> Karen
>>>>>
>>>>> On Jul 3, 2015, at 8:11 PM, Daniel D. Daugherty wrote:
>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> I've updated the patch for Contended Locking fast notify bucket
>>>>>> based on David H's and Karen's comments.
>>>>>>
>>>>>> This work is being tracked by the following bug ID:
>>>>>>
>>>>>> JDK-8075171 Contended Locking fast notify bucket
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>>>
>>>>>> Here is the webrev URL:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/
>>>>>>
>>>>>> Here is the JEP link:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>>>
>>>>>> Testing:
>>>>>>
>>>>>> - RBT vm.quick batches (in process)
>>>>>> - JPRT test jobs
>>>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>>>> - CallTimerGrid stress testing (in process)
>>>>>>
>>>>>>
>>>>>> The changes in this round are in only four of the files:
>>>>>>
>>>>>> src/share/vm/opto/runtime.cpp
>>>>>>
>>>>>> - deleted comment about hashCode() that belongs in a different bucket
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>>
>>>>>> - add MAX_RECHECK_INTERVAL define for use in ObjectMonitor::EnterI()
>>>>>> - cleanup recheck interval code
>>>>>> - ObjectMonitor::INotify() return type is now "void"
>>>>>> - delete duplicate comments, clarify/rewrite some comments
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>>
>>>>>> - ObjectMonitor::INotify() return type is now "void"
>>>>>>
>>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>>
>>>>>> - clarify/rewrite comments, add additional comments
>>>>>> - cleanup variables in ObjectSynchronizer::quick_notify
>>>>>> - refactor loop to be more clear
>>>>>> - delete unused enum MaximumRecheckInterval
>>>>>>
>>>>>> The easiest way to review the delta is to download the two patch
>>>>>> files and compare them in something like jfilemerge:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/hotspot.patch
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/1-jdk9-hs-rt/hotspot.patch
>>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 5/18/15 2:07 PM, Daniel D. Daugherty wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> I have the Contended Locking fast notify bucket ready for review.
>>>>>>>
>>>>>>> The code changes in this bucket are the final piece in the triad
>>>>>>> of {fast-enter, fast-exit, fast-notify} changes. There are no
>>>>>>> macro assembler changes in this bucket (yeah!), but there are
>>>>>>> code review cleanups motivated by comments on other buckets, e.g.,
>>>>>>> changing variables like 'Tally' -> 'tally'.
>>>>>>>
>>>>>>> This work is being tracked by the following bug ID:
>>>>>>>
>>>>>>> JDK-8075171 Contended Locking fast notify bucket
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075171
>>>>>>>
>>>>>>> Here is the webrev URL:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8075171-webrev/0-jdk9-hs-rt/
>>>>>>>
>>>>>>> Here is the JEP link:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046133
>>>>>>>
>>>>>>> Testing:
>>>>>>>
>>>>>>> - Aurora Adhoc RT/SVC baseline batch
>>>>>>> - JPRT test jobs
>>>>>>> - MonitorWaitNotifyStresser micro-benchmark (in process)
>>>>>>> - CallTimerGrid stress testing (in process)
>>>>>>> - Aurora performance testing:
>>>>>>> - out of the box for the "promotion" and 32-bit server configs
>>>>>>> - heavy weight monitors for the "promotion" and 32-bit server
>>>>>>> configs
>>>>>>> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
>>>>>>> (in process)
>>>>>>>
>>>>>>> The hang somehow introduced by the "fast enter" bucket is still
>>>>>>> unresolved, but progress is being made. That work is being tracked
>>>>>>> by the following bug:
>>>>>>>
>>>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8077392
>>>>>>>
>>>>>>> You'll see a change that re-enables the "fast enter" bucket in this
>>>>>>> webrev, but that change will not be pushed when we're done with the
>>>>>>> review of this bucket unless JDK-8077392 is resolved.
>>>>>>>
>>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>>
>>>>>>> Gory details about the changes are below...
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> 8075171 summary of changes:
>>>>>>>
>>>>>>> src/share/vm/classfile/vmSymbols.hpp
>>>>>>> - Add do_intrinsic() entries for _notify and _notifyAll
>>>>>>>
>>>>>>> src/share/vm/opto/library_call.cpp
>>>>>>> - Add optional inline_notify() that is controlled by new
>>>>>>> '-XX:[+-]InlineNotify' option
>>>>>>>
>>>>>>> src/share/vm/opto/runtime.cpp
>>>>>>> src/share/vm/opto/runtime.hpp
>>>>>>> - Add OptoRuntime::monitor_notify_C() and
>>>>>>> OptoRuntime::monitor_notifyAll_C() functions to support
>>>>>>> the new "fast notify" code paths
>>>>>>> - Add new OptoRuntime::monitor_notify_Type() to support
>>>>>>> the above two new functions
>>>>>>>
>>>>>>> src/share/vm/runtime/globals.hpp
>>>>>>> - Add '-XX:[+-]InlineNotify' option; default option value is
>>>>>>> enabled (true)
>>>>>>>
>>>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>>> - Refactor ObjectMonitor::notify() and ObjectMonitor::notifyAll()
>>>>>>> into wrappers that call the new ObjectMonitor::INotify()
>>>>>>> - Add new ObjectMonitor::INotify() to reduce code duplication
>>>>>>> between "notify" and "notifyAll" code paths
>>>>>>>
>>>>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>>>> - Temporarily re-enable the "fast enter" optimization in order
>>>>>>> to do performance testing. JDK-8077392 is still unresolved,
>>>>>>> but progress is being made.
>>>>>>>
>>>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>>> src/share/vm/runtime/synchronizer.hpp
>>>>>>> - Add ObjectSynchronizer::quick_notify() that implements the
>>>>>>> new "fast notify" code paths
>>>>>>> - The new code handles a couple of special cases where the
>>>>>>> "notify" can be done without the heavy weight slow-path
>>>>>>> (thread state transitions and other baggage)
>>>>>>>
>>>>>>>
>>>>
>>>>
>
>
From daniel.daugherty at oracle.com Thu Jul 9 13:32:33 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 07:32:33 -0600
Subject: RFR: 8130728: Disable WorkAroundNPTLTimedWaitHang by default
In-Reply-To: <559E3E8F.9020300@oracle.com>
References: <559E3E8F.9020300@oracle.com>
Message-ID: <559E77F1.4090408@oracle.com>
> http://cr.openjdk.java.net/~dholmes/8130728/webrev/
src/share/vm/runtime/globals.hpp
No comments.
Thumbs up.
Time to see what shakes out with this option turned off.
The BSD/MacOS X blame belongs to me. Our thinking at the time was
to keep the "bsd" files matching the "linux" version unless we
had a specific reason for changing the code. Of course, we thought
we would come back later and clean things up... which just didn't
happen... I don't know the AIX history.
Dan
On 7/9/15 3:27 AM, David Holmes wrote:
> https://bugs.openjdk.java.net/browse/JDK-8130728
>
> The workaround triggered by WorkAroundNPTLTimedWaitHang (an
> experimental flag set to 1 by default) was to alleviate a hang that
> could occur on a pthread_cond_timedwait on Linux, if the timeout value
> was a time in the past - see JDK-6314875. This glibc bug was fixed in
> 2005 in glibc 2.3.5-3
>
> https://lists.debian.org/debian-glibc/2005/08/msg00201.html
>
> but the workaround persists and was (unfortunately) copied into the
> BSD and AIX ports.
>
> It is time to remove that workaround but before we can do that we need
> to be sure that we are not in fact hitting the workaround code. To
> that end I propose to use this bug to switch the flag's value to 0 to
> verify correct operation.
>
> If that goes well then we can remove the code either later in JDK 9 or
> early in JDK 10.
>
> To be clear the flag impacts both the wait and the signal part of the
> condvar usage (park and unpark). On the wait side we have:
>
> status = pthread_cond_timedwait(_cond, _mutex, &abst);
> if (status != 0 && WorkAroundNPTLTimedWaitHang) {
> pthread_cond_destroy(_cond);
> pthread_cond_init(_cond, os::Linux::condAttr());
> }
>
> so we will now skip this potential recovery code.
>
> On the signal side we signal while holding the mutex if the workaround
> is enabled, and we signal after dropping the mutex otherwise. So this
> code will now be using a new path. Here is the code in
> PlatformEvent::unpark
>
> assert(AnyWaiters == 0 || AnyWaiters == 1, "invariant");
> if (AnyWaiters != 0 && WorkAroundNPTLTimedWaitHang) {
> AnyWaiters = 0;
> pthread_cond_signal(_cond);
> }
> status = pthread_mutex_unlock(_mutex);
> assert_status(status == 0, status, "mutex_unlock");
> if (AnyWaiters != 0) {
> // Note that we signal() *after* dropping the lock for "immortal"
> Events.
> // This is safe and avoids a common class of futile wakeups. In rare
> // circumstances this can cause a thread to return prematurely from
> // cond_{timed}wait() but the spurious wakeup is benign and the
> victim
> // will simply re-test the condition and re-park itself.
> // This provides particular benefit if the underlying platform
> does not
> // provide wait morphing.
> status = pthread_cond_signal(_cond);
> assert_status(status == 0, status, "cond_signal");
> }
>
> and similarly in Parker::unpark
>
> if (WorkAroundNPTLTimedWaitHang) {
> status = pthread_cond_signal(&_cond[_cur_index]);
> assert(status == 0, "invariant");
> status = pthread_mutex_unlock(_mutex);
> assert(status == 0, "invariant");
> } else {
> status = pthread_mutex_unlock(_mutex);
> assert(status == 0, "invariant");
> status = pthread_cond_signal(&_cond[_cur_index]);
> assert(status == 0, "invariant");
> }
>
> This may cause performance perturbations that will need to be
> investigated - but in theory, as per the comment above, signalling
> outside the lock should be beneficial in the linux case because there
> is no wait-morphing (where a signal simply takes a waiting thread and
> places it into the mutex queue thereby avoiding the need to awaken the
> thread so it can enqueue itself).
>
> The change itself is of course trivial:
>
> http://cr.openjdk.java.net/~dholmes/8130728/webrev/
>
> I'd appreciate any comments/concerns particularly from the BSD and AIX
> folk who acquired this unnecessary workaround.
>
> If deemed necessary we could add a flag that controls whether the
> signal happens with or without the lock held.
>
> Thanks,
> David
From karen.kinnear at oracle.com Thu Jul 9 13:42:30 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 9 Jul 2015 09:42:30 -0400
Subject: RFR(XS) 8130669: VM prohibits methods with return values
In-Reply-To: <559D8F1A.1000803@oracle.com>
References: <559D2666.5010209@oracle.com> <559D7E0C.6030102@oracle.com>
<559D8345.5060709@oracle.com> <559D8F1A.1000803@oracle.com>
Message-ID: <1E6AA085-9F7D-4A6A-87CA-A29D990F885A@oracle.com>
Looks good. Actually that is easier to read.
thanks,
Karen
On Jul 8, 2015, at 4:59 PM, Ioi Lam wrote:
> Looks good to me. Thanks
> - Ioi
>
> On 7/8/15 1:08 PM, harold seigel wrote:
>> Hi Ioi,
>>
>> Here's an updated webrev with ignoredClinit as a .jasm file. Please let me know if it looks okay.
>>
>> http://cr.openjdk.java.net/~hseigel/bug_8130669.1/
>>
>> Thanks, Harold
>>
>> On 7/8/2015 3:46 PM, Ioi Lam wrote:
>>> Hi Harold,
>>>
>>> Is there any reason why the ignoredClinit needs to be written in a jcod file and not a jasm file? jasm files would be a lot easier to read and maintain than jcod.
>>>
>>> Thanks
>>> - Ioi
>>>
>>> On 7/8/15 6:32 AM, harold seigel wrote:
>>>> Hi,
>>>>
>>>> Please review this small change to fix bug JDK-8130669. The JVM incorrectly throws ClassFormatError exceptions for non-void methods named . But, the JVM Spec 8 says that such methods should be ignored. See http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.9 for details.
>>>>
>>>> The fix changes the JVM to, in this case, only throw ClassFormatError exceptions for non-void methods.
>>>>
>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8130669/
>>>>
>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8130669
>>>>
>>>> The fix was tested with JCK Lang and VM tests, the UTE quick and split_verifier tests, and the hotspot, java/io, java/lang, and java/util JTreg tests.
>>>>
>>>> Thanks, Harold
>>>
>>
>
From daniel.daugherty at oracle.com Thu Jul 9 13:55:38 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 07:55:38 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559E7259.1070605@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
<559E1611.2070803@oracle.com> <559E7259.1070605@oracle.com>
Message-ID: <559E7D5A.2040900@oracle.com>
> Any particular reason to use "fatal(...)" instead of
> "guarantee(false, ...)". I've seen both...
Answering my own question... :-)
fatal() and guarantee() both reach the same place (report_vm_error())
with the same bells-and-whistles on the way...
So "guarantee(false, ...)" is the same as "fatal(...)"
so I'll switch to the more direct "fatal(...)".
I don't think that change requires a re-review, please let me know
if you disagree...
Dan
On 7/9/15 7:08 AM, Daniel D. Daugherty wrote:
> David,
>
> Thanks for the quick re-review!
>
> Responses embedded below...
>
> On 7/9/15 12:34 AM, David Holmes wrote:
>> Hi Dan,
>>
>> On 9/07/2015 7:33 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I've updated this patch based on David H's comments along with
>>> some additional cleanup.
>>
>> So to address the high-level changes:
>>
>> - Use ObjectMonitor::Knob_Verbose as the verbosity flag for printing
>> the lockbits in the stack dump. Okay - though I do wonder why the
>> SyncVerbose flag also exists?
>
> I'll ping Dice to see if there's a reason for two different verbose
> flags in the monitor subsystem. I have to admit that I didn't notice
> that one in the large collection of knobs and switches... :-(
>
>
>> - Use ObjectMonitor::Knob_ExitRelease to control whether Java threads
>> are checked for locked monitors when they exit
>> - Use ObjectMonitor::Knob_VerifyMatch to control whether finding a
>> locked (hence unmatched) monitor causes an abort
>>
>> That seems like a good way to work within the existing mechanism for
>> customizing the sync logic - and no new global options (though SQE
>> will still need tests for using these knobs I think).
>
> Glad that this version is more acceptable.
>
>
>> Some specific comments below ...
>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>> additions, new diagnostics
>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
>>
>> src/share/vm/runtime/objectMonitor.cpp
>>
>> 2393 if (Knob_ReportSettings && v != NULL) {
>> 2394 tty->print_cr("INFO: SyncKnob: %s %d(%d)", Key, rslt,
>> Default) ;
>> 2395 tty->flush();
>> 2396 }
>>
>> I suspect these were not tty using because this might get called
>> before the tty has been initialized - but I can't see how that might
>> arise (nor can I be certain it can't).
>
> I couldn't see how tty could not be initialized at these points either.
> My current plan is to go with this change to 'tty' and if we run into
> an early use case, then we do something else _and_ comment it.
>
> Although with unified logging coming... this may be moot (but the
> tty version will be easier to port...)
>
>
>>
>> Ditto for similar changes throughout.
>>
>> ---
>>
>> src/share/vm/runtime/synchronizer.cpp
>>
>> 1648 void do_monitor(ObjectMonitor* mid) {
>> 1649 if (mid->owner() == THREAD) {
>> 1650 if (ObjectMonitor::Knob_VerifyMatch != 0) {
>> 1651 Handle obj((oop) mid->object());
>> 1652 tty->print("INFO: unexpected locked object:");
>> 1653 javaVFrame::print_locked_object_class_name(tty, obj,
>> "locked");
>> 1654 }
>> 1655 guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
>> 1656 err_msg("exiting JavaThread=" INTPTR_FORMAT
>> 1657 " unexpectedly owns ObjectMonitor="
>> INTPTR_FORMAT,
>> 1658 THREAD, mid));
>> 1659 (void)mid->complete_exit(CHECK);
>> 1660 }
>> 1661 }
>>
>> Took me a while to figure out the expected control flow here. Doesn't
>> the above simplify to:
>>
>> void do_monitor(ObjectMonitor* mid) {
>> if (mid->owner() == THREAD) {
>> if (ObjectMonitor::Knob_VerifyMatch != 0) {
>> Handle obj((oop) mid->object());
>> tty->print("INFO: unexpected locked object:");
>> javaVFrame::print_locked_object_class_name(tty, obj, "locked");
>> fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
>> " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
>> THREAD, mid));
>> }
>> (void)mid->complete_exit(CHECK);
>> }
>> }
>>
>> ?
>
> Yes, your version is cleaner.
>
> Any particular reason to use "fatal(...)" instead of
> "guarantee(false, ...)". I've seen both...
>
> Dan
>
>
>>
>> Thanks,
>> David
>>
>>>
>>> The easiest way to review the delta is to download the two patch
>>> files and compare them in something like jfilemerge:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>>>
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>>>
>>>
>>>
>>> Testing:
>>>
>>> - Aurora Adhoc RT/SVC nightly batches (in process)
>>> - JPRT test jobs
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>> Changes between CR0 and CR1 are:
>>>
>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>
>>> - fix comment typos, clarify comment wording
>>>
>>> src/share/vm/oops/markOop.cpp
>>>
>>> - clarify output messages
>>> - get rid of confusing local variable
>>>
>>> src/share/vm/runtime/globals.hpp
>>>
>>> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
>>> and JavaThreadExitReleasesMonitors options
>>> - there are no longer changes to this file
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>>
>>> - add ObjectMonitor::Knob_ExitRelease suboption to replace
>>> JavaThreadExitReleasesMonitors
>>> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
>>> GuaranteeOnMonitorMismatch
>>> - cleanup messy logging:
>>> - switch from '::printf()' -> 'tty->print_cr()'
>>> - switch from '::fflush()' -> 'tty->flush()'
>>>
>>> src/share/vm/runtime/objectMonitor.hpp
>>>
>>> - add ObjectMonitor::Knob_ExitRelease suboption
>>> - add ObjectMonitor::Knob_VerifyMatch suboption
>>> - cleanup messy logging
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>>
>>> - cleanup messy logging
>>> - switch from GuaranteeOnMonitorMismatch to
>>> ObjectMonitor::Knob_VerifyMatch
>>> - add diagnostic information about the locked object
>>> when ReleaseJavaMonitorsClosure::do_monitor() finds
>>> a problem
>>>
>>> src/share/vm/runtime/thread.cpp
>>>
>>> - clarify comments
>>> - switch from JavaThreadExitReleasesMonitors to
>>> ObjectMonitor::Knob_ExitRelease
>>>
>>> src/share/vm/runtime/vframe.cpp
>>>
>>> - print_locked_object_class_name() is now public
>>> - clarify comments
>>> - clarify output messages
>>> - switch from VerboseStackTrace to the already existing
>>> ObjectMonitor::Knob_Verbose
>>>
>>> src/share/vm/runtime/vframe.hpp
>>>
>>> - print_locked_object_class_name() is now public
>>>
>>>
>>> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> The hunt for the following bug:
>>>>
>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>
>>>> and David C's work on the following bug:
>>>>
>>>> JDK-8069412 Locks need better debug-printing support
>>>>
>>>> have inspired additional thread dump improvements, comment additions
>>>> to some Java monitor code and some new diagnostic options.
>>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>> additions, new diagnostics
>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>
>>>> Testing:
>>>>
>>>> - RBT vm.quick batches (in process)
>>>> - JPRT test jobs
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Gory details about the changes are below...
>>>>
>>>> Dan
>>>>
>>>> 8130448 summary of changes:
>>>>
>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>> - comment additions for the assembly code
>>>>
>>>> src/share/vm/oops/markOop.cpp
>>>> - has_monitor() has to be checked before is_locked() since
>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>> - code style fixes
>>>>
>>>> src/share/vm/runtime/globals.hpp
>>>> - add VerboseStackTrace diagnostic option
>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>> - add JavaThreadExitReleasesMonitors product option;
>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>> - delete unused ObjectMonitor::try_enter()
>>>> - fix assert wording
>>>>
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>> - delete unused ObjectMonitor::try_enter()
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>> - add GuaranteeOnMonitorMismatch support with some
>>>> diagnostic output
>>>>
>>>> src/share/vm/runtime/thread.cpp
>>>> - add JavaThreadExitReleasesMonitors support
>>>>
>>>> src/share/vm/runtime/vframe.cpp
>>>> - clarify existing comments
>>>> - add comments to clarify what "waiting on" means
>>>> - add line to show when we are "waiting on", but
>>>> there are no locals available (previously we were
>>>> "waiting on" silently)
>>>> - add support for "waiting to relock" which can happen
>>>> for any of the monitors and not just the top monitor
>>>> - switch mark->print_on() verbose output to new
>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>> with a specific switch so the '-XX:+Verbose' model of
>>>> being a modifier for another option does not fit
>>>>
>>>>
>>>
>
>
From daniel.daugherty at oracle.com Thu Jul 9 14:11:28 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 08:11:28 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559E7D5A.2040900@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
<559E1611.2070803@oracle.com> <559E7259.1070605@oracle.com>
<559E7D5A.2040900@oracle.com>
Message-ID: <559E8110.40706@oracle.com>
On 7/9/15 7:55 AM, Daniel D. Daugherty wrote:
> > Any particular reason to use "fatal(...)" instead of
> > "guarantee(false, ...)". I've seen both...
>
> Answering my own question... :-)
>
> fatal() and guarantee() both reach the same place (report_vm_error())
> with the same bells-and-whistles on the way...
>
> So "guarantee(false, ...)" is the same as "fatal(...)"
> so I'll switch to the more direct "fatal(...)".
>
> I don't think that change requires a re-review, please let me know
> if you disagree...
Sigh... I meant "webrev"... Here's the diffs:
$ diff -c src/share/vm/runtime/synchronizer.cpp{.cr1,}
*** src/share/vm/runtime/synchronizer.cpp.cr1 Wed Jul 8 07:15:07 2015
--- src/share/vm/runtime/synchronizer.cpp Thu Jul 9 07:07:28 2015
***************
*** 1651,1661 ****
Handle obj((oop) mid->object());
tty->print("INFO: unexpected locked object:");
javaVFrame::print_locked_object_class_name(tty, obj, "locked");
}
- guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
- err_msg("exiting JavaThread=" INTPTR_FORMAT
- " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
- THREAD, mid));
(void)mid->complete_exit(CHECK);
}
}
--- 1651,1660 ----
Handle obj((oop) mid->object());
tty->print("INFO: unexpected locked object:");
javaVFrame::print_locked_object_class_name(tty, obj, "locked");
+ fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
+ " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
+ THREAD, mid));
}
(void)mid->complete_exit(CHECK);
}
}
Dan
>
> Dan
>
>
> On 7/9/15 7:08 AM, Daniel D. Daugherty wrote:
>> David,
>>
>> Thanks for the quick re-review!
>>
>> Responses embedded below...
>>
>> On 7/9/15 12:34 AM, David Holmes wrote:
>>> Hi Dan,
>>>
>>> On 9/07/2015 7:33 AM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I've updated this patch based on David H's comments along with
>>>> some additional cleanup.
>>>
>>> So to address the high-level changes:
>>>
>>> - Use ObjectMonitor::Knob_Verbose as the verbosity flag for printing
>>> the lockbits in the stack dump. Okay - though I do wonder why the
>>> SyncVerbose flag also exists?
>>
>> I'll ping Dice to see if there's a reason for two different verbose
>> flags in the monitor subsystem. I have to admit that I didn't notice
>> that one in the large collection of knobs and switches... :-(
>>
>>
>>> - Use ObjectMonitor::Knob_ExitRelease to control whether Java
>>> threads are checked for locked monitors when they exit
>>> - Use ObjectMonitor::Knob_VerifyMatch to control whether finding a
>>> locked (hence unmatched) monitor causes an abort
>>>
>>> That seems like a good way to work within the existing mechanism for
>>> customizing the sync logic - and no new global options (though SQE
>>> will still need tests for using these knobs I think).
>>
>> Glad that this version is more acceptable.
>>
>>
>>> Some specific comments below ...
>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>> additions, new diagnostics
>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>>
>>> 2393 if (Knob_ReportSettings && v != NULL) {
>>> 2394 tty->print_cr("INFO: SyncKnob: %s %d(%d)", Key, rslt,
>>> Default) ;
>>> 2395 tty->flush();
>>> 2396 }
>>>
>>> I suspect these were not tty using because this might get called
>>> before the tty has been initialized - but I can't see how that might
>>> arise (nor can I be certain it can't).
>>
>> I couldn't see how tty could not be initialized at these points either.
>> My current plan is to go with this change to 'tty' and if we run into
>> an early use case, then we do something else _and_ comment it.
>>
>> Although with unified logging coming... this may be moot (but the
>> tty version will be easier to port...)
>>
>>
>>>
>>> Ditto for similar changes throughout.
>>>
>>> ---
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>>
>>> 1648 void do_monitor(ObjectMonitor* mid) {
>>> 1649 if (mid->owner() == THREAD) {
>>> 1650 if (ObjectMonitor::Knob_VerifyMatch != 0) {
>>> 1651 Handle obj((oop) mid->object());
>>> 1652 tty->print("INFO: unexpected locked object:");
>>> 1653 javaVFrame::print_locked_object_class_name(tty, obj,
>>> "locked");
>>> 1654 }
>>> 1655 guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
>>> 1656 err_msg("exiting JavaThread=" INTPTR_FORMAT
>>> 1657 " unexpectedly owns ObjectMonitor="
>>> INTPTR_FORMAT,
>>> 1658 THREAD, mid));
>>> 1659 (void)mid->complete_exit(CHECK);
>>> 1660 }
>>> 1661 }
>>>
>>> Took me a while to figure out the expected control flow here.
>>> Doesn't the above simplify to:
>>>
>>> void do_monitor(ObjectMonitor* mid) {
>>> if (mid->owner() == THREAD) {
>>> if (ObjectMonitor::Knob_VerifyMatch != 0) {
>>> Handle obj((oop) mid->object());
>>> tty->print("INFO: unexpected locked object:");
>>> javaVFrame::print_locked_object_class_name(tty, obj,
>>> "locked");
>>> fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
>>> " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
>>> THREAD, mid));
>>> }
>>> (void)mid->complete_exit(CHECK);
>>> }
>>> }
>>>
>>> ?
>>
>> Yes, your version is cleaner.
>>
>> Any particular reason to use "fatal(...)" instead of
>> "guarantee(false, ...)". I've seen both...
>>
>> Dan
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> The easiest way to review the delta is to download the two patch
>>>> files and compare them in something like jfilemerge:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>>>>
>>>>
>>>>
>>>> Testing:
>>>>
>>>> - Aurora Adhoc RT/SVC nightly batches (in process)
>>>> - JPRT test jobs
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Gory details about the changes are below...
>>>>
>>>> Dan
>>>>
>>>> Changes between CR0 and CR1 are:
>>>>
>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>
>>>> - fix comment typos, clarify comment wording
>>>>
>>>> src/share/vm/oops/markOop.cpp
>>>>
>>>> - clarify output messages
>>>> - get rid of confusing local variable
>>>>
>>>> src/share/vm/runtime/globals.hpp
>>>>
>>>> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
>>>> and JavaThreadExitReleasesMonitors options
>>>> - there are no longer changes to this file
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>
>>>> - add ObjectMonitor::Knob_ExitRelease suboption to replace
>>>> JavaThreadExitReleasesMonitors
>>>> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
>>>> GuaranteeOnMonitorMismatch
>>>> - cleanup messy logging:
>>>> - switch from '::printf()' -> 'tty->print_cr()'
>>>> - switch from '::fflush()' -> 'tty->flush()'
>>>>
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>
>>>> - add ObjectMonitor::Knob_ExitRelease suboption
>>>> - add ObjectMonitor::Knob_VerifyMatch suboption
>>>> - cleanup messy logging
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>>
>>>> - cleanup messy logging
>>>> - switch from GuaranteeOnMonitorMismatch to
>>>> ObjectMonitor::Knob_VerifyMatch
>>>> - add diagnostic information about the locked object
>>>> when ReleaseJavaMonitorsClosure::do_monitor() finds
>>>> a problem
>>>>
>>>> src/share/vm/runtime/thread.cpp
>>>>
>>>> - clarify comments
>>>> - switch from JavaThreadExitReleasesMonitors to
>>>> ObjectMonitor::Knob_ExitRelease
>>>>
>>>> src/share/vm/runtime/vframe.cpp
>>>>
>>>> - print_locked_object_class_name() is now public
>>>> - clarify comments
>>>> - clarify output messages
>>>> - switch from VerboseStackTrace to the already existing
>>>> ObjectMonitor::Knob_Verbose
>>>>
>>>> src/share/vm/runtime/vframe.hpp
>>>>
>>>> - print_locked_object_class_name() is now public
>>>>
>>>>
>>>> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> The hunt for the following bug:
>>>>>
>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>>
>>>>> and David C's work on the following bug:
>>>>>
>>>>> JDK-8069412 Locks need better debug-printing support
>>>>>
>>>>> have inspired additional thread dump improvements, comment additions
>>>>> to some Java monitor code and some new diagnostic options.
>>>>>
>>>>> This work is being tracked by the following bug ID:
>>>>>
>>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>>> additions, new diagnostics
>>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>>
>>>>> Here is the webrev URL:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>>
>>>>> Testing:
>>>>>
>>>>> - RBT vm.quick batches (in process)
>>>>> - JPRT test jobs
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Gory details about the changes are below...
>>>>>
>>>>> Dan
>>>>>
>>>>> 8130448 summary of changes:
>>>>>
>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>> - comment additions for the assembly code
>>>>>
>>>>> src/share/vm/oops/markOop.cpp
>>>>> - has_monitor() has to be checked before is_locked() since
>>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>>> - code style fixes
>>>>>
>>>>> src/share/vm/runtime/globals.hpp
>>>>> - add VerboseStackTrace diagnostic option
>>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>>> - add JavaThreadExitReleasesMonitors product option;
>>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>> - delete unused ObjectMonitor::try_enter()
>>>>> - fix assert wording
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>
>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>> - add GuaranteeOnMonitorMismatch support with some
>>>>> diagnostic output
>>>>>
>>>>> src/share/vm/runtime/thread.cpp
>>>>> - add JavaThreadExitReleasesMonitors support
>>>>>
>>>>> src/share/vm/runtime/vframe.cpp
>>>>> - clarify existing comments
>>>>> - add comments to clarify what "waiting on" means
>>>>> - add line to show when we are "waiting on", but
>>>>> there are no locals available (previously we were
>>>>> "waiting on" silently)
>>>>> - add support for "waiting to relock" which can happen
>>>>> for any of the monitors and not just the top monitor
>>>>> - switch mark->print_on() verbose output to new
>>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>>> with a specific switch so the '-XX:+Verbose' model of
>>>>> being a modifier for another option does not fit
>>>>>
>>>>>
>>>>
>>
>>
>
From daniel.daugherty at oracle.com Thu Jul 9 15:17:48 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 09:17:48 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559D970E.7000905@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
Message-ID: <559E909C.8050309@oracle.com>
Here are a couple of examples of the new options at work in
the hunt for 8077392:
In this example, ObjectMonitor::Knob_ExitRelease == 1 and
ObjectMonitor::Knob_VerifyMatch == 1 so we catch a JavaThread
exiting while a Java monitor is locked:
config java.util.stream.LoggingTestCase.before(): success
INFO: unexpected locked object: - locked <0xfffffd7be05e9478> (a
java.util.stream.Nodes$CollectorTask$OfInt)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (synchronizer.cpp:1658), pid=10768, tid=0x0000000000000049
# guarantee(ObjectMonitor::Knob_VerifyMatch == 0) failed: exiting
JavaThread=0x0000000001069800 unexpectedly owns
ObjectMonitor=0x000000000116de00
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build
1.9.0-internal-20150708151346.ddaugher.8130448_for_jdk9-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM
(1.9.0-internal-20150708151346.ddaugher.8130448_for_jdk9-b00 mixed mode
solaris-amd64 compressed oops)
The "INFO" line shows details about the Object and the
guarantee() line shows info about the offending thread
and the ObjectMonitor itself. With the latest change, the
guarantee() will change to a fatal()...
In this example, ObjectMonitor::Knob_ExitRelease == 0,
ObjectMonitor::Knob_VerifyMatch == 0 and
ObjectMonitor::Knob_Verbose == 1 so when we hit the hang
in the hunt for 8077392, we'll see a more detailed thread
dump:
Full thread dump Java HotSpot(TM) 64-Bit Server VM
(1.9.0-internal-2015070815134
6.ddaugher.8130448_for_jdk9-b00 mixed mode):
"MainThread" #11 prio=5 os_prio=64 tid=0x0000000000a1e800 nid=0x43 in
Object.wai
t() [0xfffffd7bba9fc000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on
at
java.util.concurrent.ForkJoinTask.externalAwaitDone(ForkJoinTask.java
:334)
- waiting to re-lock in wait() <0xfffffd7be69350c8> (a
java.util.stream.
Nodes$CollectorTask$OfInt)
- lockbits=
monitor(0x0000000001975502)={count=0x0000000000000000,waiter
s=0x0000000000000001,recursions=0x0000000000000000,owner=0x0000000001311000}
at
java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:405)
at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:734)
With the changes for this bug (8130448):
- This line is new:
- waiting on
and it tells us that this compiled code instead of interpreted code.
Prior to 8130448, the "waiting on ..." line would not be present.
- This line is new:
- waiting to re-lock in wait() <0xfffffd7be69350c8> (a java.util.stream.
Nodes$CollectorTask$OfInt)
and it tells us that the Java monitor has been notified and the thread
is waiting to re-lock the Java monitor. Prior to 8130448, the "waiting
to re-lock ..." line would not be present.
- This line was new with David C's changes:
- lockbits= monitor(0x0000000001975502)={count=0x0000000000000000,waiter
s=0x0000000000000001,recursions=0x0000000000000000,owner=0x0000000001311000}
and it tells us which JavaThread owns the Java monitor:
0x0000000001311000. A search of the rest of the thread dump
would show no such thread exists. Adding instrumentation to
the thread-start and thread-exit code paths shows that such
a thread did exist and exited just before this hang happened.
I think that's it for a demo of the new options...
Dan
On 7/8/15 3:33 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I've updated this patch based on David H's comments along with
> some additional cleanup.
>
> This work is being tracked by the following bug ID:
>
> JDK-8130448 8077392 inspired thread dump improvements, comment
> additions, new diagnostics
> https://bugs.openjdk.java.net/browse/JDK-8130448
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
>
> The easiest way to review the delta is to download the two patch
> files and compare them in something like jfilemerge:
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>
> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>
>
> Testing:
>
> - Aurora Adhoc RT/SVC nightly batches (in process)
> - JPRT test jobs
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Gory details about the changes are below...
>
> Dan
>
> Changes between CR0 and CR1 are:
>
> src/cpu/x86/vm/macroAssembler_x86.cpp
>
> - fix comment typos, clarify comment wording
>
> src/share/vm/oops/markOop.cpp
>
> - clarify output messages
> - get rid of confusing local variable
>
> src/share/vm/runtime/globals.hpp
>
> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
> and JavaThreadExitReleasesMonitors options
> - there are no longer changes to this file
>
> src/share/vm/runtime/objectMonitor.cpp
>
> - add ObjectMonitor::Knob_ExitRelease suboption to replace
> JavaThreadExitReleasesMonitors
> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
> GuaranteeOnMonitorMismatch
> - cleanup messy logging:
> - switch from '::printf()' -> 'tty->print_cr()'
> - switch from '::fflush()' -> 'tty->flush()'
>
> src/share/vm/runtime/objectMonitor.hpp
>
> - add ObjectMonitor::Knob_ExitRelease suboption
> - add ObjectMonitor::Knob_VerifyMatch suboption
> - cleanup messy logging
>
> src/share/vm/runtime/synchronizer.cpp
>
> - cleanup messy logging
> - switch from GuaranteeOnMonitorMismatch to
> ObjectMonitor::Knob_VerifyMatch
> - add diagnostic information about the locked object
> when ReleaseJavaMonitorsClosure::do_monitor() finds
> a problem
>
> src/share/vm/runtime/thread.cpp
>
> - clarify comments
> - switch from JavaThreadExitReleasesMonitors to
> ObjectMonitor::Knob_ExitRelease
>
> src/share/vm/runtime/vframe.cpp
>
> - print_locked_object_class_name() is now public
> - clarify comments
> - clarify output messages
> - switch from VerboseStackTrace to the already existing
> ObjectMonitor::Knob_Verbose
>
> src/share/vm/runtime/vframe.hpp
>
> - print_locked_object_class_name() is now public
>
>
> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> The hunt for the following bug:
>>
>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>
>> and David C's work on the following bug:
>>
>> JDK-8069412 Locks need better debug-printing support
>>
>> have inspired additional thread dump improvements, comment additions
>> to some Java monitor code and some new diagnostic options.
>>
>> This work is being tracked by the following bug ID:
>>
>> JDK-8130448 8077392 inspired thread dump improvements, comment
>> additions, new diagnostics
>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>
>> Testing:
>>
>> - RBT vm.quick batches (in process)
>> - JPRT test jobs
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Gory details about the changes are below...
>>
>> Dan
>>
>> 8130448 summary of changes:
>>
>> src/cpu/x86/vm/macroAssembler_x86.cpp
>> - comment additions for the assembly code
>>
>> src/share/vm/oops/markOop.cpp
>> - has_monitor() has to be checked before is_locked() since
>> the has_monitor() bits are a superset of the is_locked() bits
>> - code style fixes
>>
>> src/share/vm/runtime/globals.hpp
>> - add VerboseStackTrace diagnostic option
>> - add GuaranteeOnMonitorMismatch diagnostic option
>> - add JavaThreadExitReleasesMonitors product option;
>> this is the Java equivalent of JNIDetachReleasesMonitors
>>
>> src/share/vm/runtime/objectMonitor.cpp
>> - delete unused ObjectMonitor::try_enter()
>> - fix assert wording
>>
>> src/share/vm/runtime/objectMonitor.hpp
>> - delete unused ObjectMonitor::try_enter()
>>
>> src/share/vm/runtime/synchronizer.cpp
>> - add GuaranteeOnMonitorMismatch support with some
>> diagnostic output
>>
>> src/share/vm/runtime/thread.cpp
>> - add JavaThreadExitReleasesMonitors support
>>
>> src/share/vm/runtime/vframe.cpp
>> - clarify existing comments
>> - add comments to clarify what "waiting on" means
>> - add line to show when we are "waiting on", but
>> there are no locals available (previously we were
>> "waiting on" silently)
>> - add support for "waiting to relock" which can happen
>> for any of the monitors and not just the top monitor
>> - switch mark->print_on() verbose output to new
>> VerboseStackTrace switch; thread dumps are not enabled
>> with a specific switch so the '-XX:+Verbose' model of
>> being a modifier for another option does not fit
>>
>>
>
>
>
From jeremymanson at google.com Thu Jul 9 18:20:40 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 9 Jul 2015 11:20:40 -0700
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To: <559D237C.2060702@oracle.com>
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
Message-ID:
Thanks for looking at this, Coleen.
I merged this with the latest version of hs-rt, but Ron is or I am going to
have to do some merging for 8061999. The changes are relatively
orthogonal, but they touch a couple of the same places. How far away is
Ron's checkin?
Updated webrev:
http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
Updated test:
http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
(Mild complaining on my part: the conflicts wouldn't have been an issue if
someone had looked at this two months ago, when I first asked. I suspect
Ron hadn't even started his change at that point. And if external
developers were able to submit changes to Hotspot, we wouldn't have had to
bother Oracle engineers at all. Neither of these is your fault or your
problem, of course - I'm grateful you were able to take a look.)
Jeremy
On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:
> I'll sponsor it but can you repost the RFR?
>
> There has been a fair bit of work to command line processing lately so I'd
> like to have the others look at it too. Have you merged this up with the
> latest version of hs-rt repository and were there conflicts? Also, have
> you looked at the RFR:
>
> "Open code review for 8061999 Enhance VM option parsing to allow options
> to be specified"
>
> and are there conflicts with this?
>
> The hotspot change looks good to me.
>
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>
> "UseCerealGC" LOL
> Can you use a different option than PrintOopAddress in this test? I don't
> know why this command line option exists or would be useful for, and seems
> to be a good candidate for removal. If you need a valid argument, that is
> unlikely to go away, TraceExceptions would be good.
>
> Thanks,
> Coleen
>
>
> On 7/7/15 8:00 PM, Jeremy Manson wrote:
>
>> No love? Is there a code owner here I should pester more directly?
>>
>> Jeremy
>>
>> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
>> wrote:
>>
>> As usual with Google patches, they are in use locally. This one has been
>>> stable for a while without complaints. Please sponsor.
>>>
>>> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson
>>> wrote:
>>>
>>> All this talk about IgnoreUnrecognizedVMOptions reminded me that this
>>>> review is still outstanding. Any takers?
>>>>
>>>> Jeremy
>>>>
>>>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson >>> >
>>>> wrote:
>>>>
>>>> Hi David,
>>>>>
>>>>> Thanks for taking a look.
>>>>>
>>>>> On Mon, May 4, 2015 at 8:32 PM, David Holmes
>>>>> wrote:
>>>>>
>>>>> Hi Jeremy,
>>>>>>
>>>>>> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>>>>>>
>>>>>> Not sure who might be willing to sponsor this. David? You did the
>>>>>>> last
>>>>>>> one. :)
>>>>>>>
>>>>>>> Might be a while before I can get to it. I did have a quick look
>>>>>> (and
>>>>>> will need a longer one).
>>>>>>
>>>>>
>>>>> I understand. I'm just happy it's possible to upstream this stuff at
>>>>> all[1].
>>>>>
>>>>> [1] With the eternal caveat that I'd be happier if we didn't *have* to
>>>>> go through you folks, but we've learned to live with it.
>>>>>
>>>>>
>>>>>
>>>>> Context: A number of command line options are not settable via
>>>>>>
>>>>>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>>>>>
>>>>>>> - PrintVMOptions
>>>>>>>
>>>>>>> So you have changed the semantics of this to print out the options
>>>>>> from
>>>>>> the command-line and each of the two env vars. Seems reasonable but
>>>>>> may be
>>>>>> better to know which option came from where as we can now see the same
>>>>>> option (or conflicting variants thereof) multiple times.
>>>>>>
>>>>>> I'd be happy to do this. Any preferred syntax? Does someone
>>>>> actually
>>>>> own this feature?
>>>>>
>>>>> I'm unclear what the current processing order is for the different
>>>>>
>>>>>> sources of options, and whether the changes affect that order?
>>>>>>
>>>>>> Nope. I go through sad contortions to keep the processing order the
>>>>> same. It's JAVA_TOOL_OPTIONS, then command line, then _JAVA_OPTIONS.
>>>>> See
>>>>> lines 2549-2567.
>>>>>
>>>>>
>>>>> - IgnoreUnrecognizedVMOptions
>>>>>>
>>>>>>> - PrintFlagsInitial
>>>>>>>
>>>>>>> Unclear what "initial" actually means - is it the default?
>>>>>>
>>>>>
>>>>> More or less. If you stick, for example, IgnoreUnrecognizedVMOptions
>>>>> in
>>>>> there first, it will get printed out as "true". I haven't really
>>>>> changed
>>>>> the semantics here either - I've just added processing of the envvars.
>>>>>
>>>>> - NativeMemoryTracking
>>>>>
>>>>>> - PrintFlagsWithComments
>>>>>>>
>>>>>>> This is because these flags have to be processed before processing
>>>>>>> other
>>>>>>> flags, and no one ever bothered to do that for the flags coming from
>>>>>>> environment variables. This patch fixes that problem.
>>>>>>>
>>>>>>> I have a test, but it is a modification to a JDK test instead of a HS
>>>>>>> test,
>>>>>>> so it can go in separately (I guess).
>>>>>>>
>>>>>>> They can be pushed together to different repos in the same forest.
>>>>>>
>>>>>> Okay. Here's the test change:
>>>>>
>>>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>>>>
>>>>>
>>>>> As I said I'll have to get back to this. And hopefully someone else in
>>>>>> runtime will take a good look as well ;-)
>>>>>>
>>>>>> I'd be happy to toss it over to whomever owns this, if anyone.
>>>>> Thanks!
>>>>>
>>>>> Jeremy
>>>>>
>>>>>
>>>>>
>>>>> Bug:
>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>>
>>>>>>>
>
From dmitry.dmitriev at oracle.com Thu Jul 9 21:52:23 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 10 Jul 2015 00:52:23 +0300
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To:
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
Message-ID: <559EED17.4060109@oracle.com>
Hello Jeremy,
Correct me if I am wrong, but I see small memory leak in your
implementation.
In Arguments::parse_options_environment_variable function memory for
'buffer' allocated by strdup function on line 3415, but now it not freed
in this function because data from this buffer is used later. On the
other hand when we are done with env variables, we free only options
array(lines 3703-3705) and not free previously allocated memory for
'buffer' because we lost track for it.
Thanks,
Dmitry
On 09.07.2015 21:20, Jeremy Manson wrote:
> Thanks for looking at this, Coleen.
>
> I merged this with the latest version of hs-rt, but Ron is or I am going to
> have to do some merging for 8061999. The changes are relatively
> orthogonal, but they touch a couple of the same places. How far away is
> Ron's checkin?
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
>
> Updated test:
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
>
> (Mild complaining on my part: the conflicts wouldn't have been an issue if
> someone had looked at this two months ago, when I first asked. I suspect
> Ron hadn't even started his change at that point. And if external
> developers were able to submit changes to Hotspot, we wouldn't have had to
> bother Oracle engineers at all. Neither of these is your fault or your
> problem, of course - I'm grateful you were able to take a look.)
>
> Jeremy
>
> On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
> coleen.phillimore at oracle.com> wrote:
>
>> I'll sponsor it but can you repost the RFR?
>>
>> There has been a fair bit of work to command line processing lately so I'd
>> like to have the others look at it too. Have you merged this up with the
>> latest version of hs-rt repository and were there conflicts? Also, have
>> you looked at the RFR:
>>
>> "Open code review for 8061999 Enhance VM option parsing to allow options
>> to be specified"
>>
>> and are there conflicts with this?
>>
>> The hotspot change looks good to me.
>>
>>
>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>>
>> "UseCerealGC" LOL
>> Can you use a different option than PrintOopAddress in this test? I don't
>> know why this command line option exists or would be useful for, and seems
>> to be a good candidate for removal. If you need a valid argument, that is
>> unlikely to go away, TraceExceptions would be good.
>>
>> Thanks,
>> Coleen
>>
>>
>> On 7/7/15 8:00 PM, Jeremy Manson wrote:
>>
>>> No love? Is there a code owner here I should pester more directly?
>>>
>>> Jeremy
>>>
>>> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
>>> wrote:
>>>
>>> As usual with Google patches, they are in use locally. This one has been
>>>> stable for a while without complaints. Please sponsor.
>>>>
>>>> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson
>>>> wrote:
>>>>
>>>> All this talk about IgnoreUnrecognizedVMOptions reminded me that this
>>>>> review is still outstanding. Any takers?
>>>>>
>>>>> Jeremy
>>>>>
>>>>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson >>>> wrote:
>>>>>
>>>>> Hi David,
>>>>>> Thanks for taking a look.
>>>>>>
>>>>>> On Mon, May 4, 2015 at 8:32 PM, David Holmes
>>>>>> wrote:
>>>>>>
>>>>>> Hi Jeremy,
>>>>>>> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>>>>>>>
>>>>>>> Not sure who might be willing to sponsor this. David? You did the
>>>>>>>> last
>>>>>>>> one. :)
>>>>>>>>
>>>>>>>> Might be a while before I can get to it. I did have a quick look
>>>>>>> (and
>>>>>>> will need a longer one).
>>>>>>>
>>>>>> I understand. I'm just happy it's possible to upstream this stuff at
>>>>>> all[1].
>>>>>>
>>>>>> [1] With the eternal caveat that I'd be happier if we didn't *have* to
>>>>>> go through you folks, but we've learned to live with it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Context: A number of command line options are not settable via
>>>>>>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>>>>>>
>>>>>>>> - PrintVMOptions
>>>>>>>>
>>>>>>>> So you have changed the semantics of this to print out the options
>>>>>>> from
>>>>>>> the command-line and each of the two env vars. Seems reasonable but
>>>>>>> may be
>>>>>>> better to know which option came from where as we can now see the same
>>>>>>> option (or conflicting variants thereof) multiple times.
>>>>>>>
>>>>>>> I'd be happy to do this. Any preferred syntax? Does someone
>>>>>> actually
>>>>>> own this feature?
>>>>>>
>>>>>> I'm unclear what the current processing order is for the different
>>>>>>
>>>>>>> sources of options, and whether the changes affect that order?
>>>>>>>
>>>>>>> Nope. I go through sad contortions to keep the processing order the
>>>>>> same. It's JAVA_TOOL_OPTIONS, then command line, then _JAVA_OPTIONS.
>>>>>> See
>>>>>> lines 2549-2567.
>>>>>>
>>>>>>
>>>>>> - IgnoreUnrecognizedVMOptions
>>>>>>>> - PrintFlagsInitial
>>>>>>>>
>>>>>>>> Unclear what "initial" actually means - is it the default?
>>>>>> More or less. If you stick, for example, IgnoreUnrecognizedVMOptions
>>>>>> in
>>>>>> there first, it will get printed out as "true". I haven't really
>>>>>> changed
>>>>>> the semantics here either - I've just added processing of the envvars.
>>>>>>
>>>>>> - NativeMemoryTracking
>>>>>>
>>>>>>> - PrintFlagsWithComments
>>>>>>>> This is because these flags have to be processed before processing
>>>>>>>> other
>>>>>>>> flags, and no one ever bothered to do that for the flags coming from
>>>>>>>> environment variables. This patch fixes that problem.
>>>>>>>>
>>>>>>>> I have a test, but it is a modification to a JDK test instead of a HS
>>>>>>>> test,
>>>>>>>> so it can go in separately (I guess).
>>>>>>>>
>>>>>>>> They can be pushed together to different repos in the same forest.
>>>>>>> Okay. Here's the test change:
>>>>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>>>>>
>>>>>>
>>>>>> As I said I'll have to get back to this. And hopefully someone else in
>>>>>>> runtime will take a good look as well ;-)
>>>>>>>
>>>>>>> I'd be happy to toss it over to whomever owns this, if anyone.
>>>>>> Thanks!
>>>>>>
>>>>>> Jeremy
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>>>>>>
>>>>>>>> Jeremy
>>>>>>>>
>>>>>>>>
>>>>>>>>
From claes.redestad at oracle.com Thu Jul 9 22:05:57 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 10 Jul 2015 00:05:57 +0200
Subject: RFR [8u60]: 8081590: The CDS classlist needs to be updated for
8u60
In-Reply-To: <5579965B.7000709@oracle.com>
References: <5579965B.7000709@oracle.com>
Message-ID: <559EF045.10307@oracle.com>
Hi,
new refresh up:
http://cr.openjdk.java.net/~redestad/8081590/webrev.02/
The refresh was put on hold earlier due to an incoming startup
optimization, which affected the classlist (mostly
order).
I've rerun relevant tests, verified -Xshare:dump doesn't log any
warnings and checked that footprint and startup improve.
Thanks!
/Claes
On 2015-06-11 16:08, Claes Redestad wrote:
> Hi,
>
> classlists have been slowly deteriorating since the last refresh
> (https://bugs.openjdk.java.net/browse/JDK-8023041),
> contributing to a small but significant degradation in startup and
> footprint characteristics.
>
> While there are also classlist files for Solaris, Mac and AIX, we
> cannot run the same set of applications we run on
> 32-bit platforms on non-32-bit platforms (due to an application with a
> bundled 32-bit dependency).
>
> Rather than generating new classlists using a different set of
> applications without ability to verify that it helps, I'd
> rather limit this 8u60 refresh to Linux and Windows where we can
> verify the benefit and do a more thorough
> investigation into modernizing the representative set of applications
> for JDK9 and onwards.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8081590/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8081590
>
> I'll need a sponsor to push this to 8u60.
>
> /Claes
From david.holmes at oracle.com Fri Jul 10 00:08:56 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 10 Jul 2015 10:08:56 +1000
Subject: RFR(S) 8130448: thread dump improvements, comment, additions, new
diagnostics inspired by 8077392
In-Reply-To: <559E7259.1070605@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
<559E1611.2070803@oracle.com> <559E7259.1070605@oracle.com>
Message-ID: <559F0D18.3090406@oracle.com>
On 9/07/2015 11:08 PM, Daniel D. Daugherty wrote:
> David,
>
> Thanks for the quick re-review!
>
> Responses embedded below...
>
> On 7/9/15 12:34 AM, David Holmes wrote:
>> Hi Dan,
>>
>> On 9/07/2015 7:33 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I've updated this patch based on David H's comments along with
>>> some additional cleanup.
>>
>> So to address the high-level changes:
>>
>> - Use ObjectMonitor::Knob_Verbose as the verbosity flag for printing
>> the lockbits in the stack dump. Okay - though I do wonder why the
>> SyncVerbose flag also exists?
>
> I'll ping Dice to see if there's a reason for two different verbose
> flags in the monitor subsystem. I have to admit that I didn't notice
> that one in the large collection of knobs and switches... :-(
>
>
>> - Use ObjectMonitor::Knob_ExitRelease to control whether Java threads
>> are checked for locked monitors when they exit
>> - Use ObjectMonitor::Knob_VerifyMatch to control whether finding a
>> locked (hence unmatched) monitor causes an abort
>>
>> That seems like a good way to work within the existing mechanism for
>> customizing the sync logic - and no new global options (though SQE
>> will still need tests for using these knobs I think).
>
> Glad that this version is more acceptable.
>
>
>> Some specific comments below ...
>>
>>> This work is being tracked by the following bug ID:
>>>
>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>> additions, new diagnostics
>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
>>
>> src/share/vm/runtime/objectMonitor.cpp
>>
>> 2393 if (Knob_ReportSettings && v != NULL) {
>> 2394 tty->print_cr("INFO: SyncKnob: %s %d(%d)", Key, rslt, Default) ;
>> 2395 tty->flush();
>> 2396 }
>>
>> I suspect these were not tty using because this might get called
>> before the tty has been initialized - but I can't see how that might
>> arise (nor can I be certain it can't).
>
> I couldn't see how tty could not be initialized at these points either.
> My current plan is to go with this change to 'tty' and if we run into
> an early use case, then we do something else _and_ comment it.
>
> Although with unified logging coming... this may be moot (but the
> tty version will be easier to port...)
>
>
>>
>> Ditto for similar changes throughout.
>>
>> ---
>>
>> src/share/vm/runtime/synchronizer.cpp
>>
>> 1648 void do_monitor(ObjectMonitor* mid) {
>> 1649 if (mid->owner() == THREAD) {
>> 1650 if (ObjectMonitor::Knob_VerifyMatch != 0) {
>> 1651 Handle obj((oop) mid->object());
>> 1652 tty->print("INFO: unexpected locked object:");
>> 1653 javaVFrame::print_locked_object_class_name(tty, obj,
>> "locked");
>> 1654 }
>> 1655 guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
>> 1656 err_msg("exiting JavaThread=" INTPTR_FORMAT
>> 1657 " unexpectedly owns ObjectMonitor="
>> INTPTR_FORMAT,
>> 1658 THREAD, mid));
>> 1659 (void)mid->complete_exit(CHECK);
>> 1660 }
>> 1661 }
>>
>> Took me a while to figure out the expected control flow here. Doesn't
>> the above simplify to:
>>
>> void do_monitor(ObjectMonitor* mid) {
>> if (mid->owner() == THREAD) {
>> if (ObjectMonitor::Knob_VerifyMatch != 0) {
>> Handle obj((oop) mid->object());
>> tty->print("INFO: unexpected locked object:");
>> javaVFrame::print_locked_object_class_name(tty, obj, "locked");
>> fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
>> " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
>> THREAD, mid));
>> }
>> (void)mid->complete_exit(CHECK);
>> }
>> }
>>
>> ?
>
> Yes, your version is cleaner.
>
> Any particular reason to use "fatal(...)" instead of
> "guarantee(false, ...)". I've seen both...
A guarantee that always fires seems like a fatal to me. But as you say
both get used.
David
-----
> Dan
>
>
>>
>> Thanks,
>> David
>>
>>>
>>> The easiest way to review the delta is to download the two patch
>>> files and compare them in something like jfilemerge:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>>>
>>>
>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>>>
>>>
>>>
>>> Testing:
>>>
>>> - Aurora Adhoc RT/SVC nightly batches (in process)
>>> - JPRT test jobs
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Gory details about the changes are below...
>>>
>>> Dan
>>>
>>> Changes between CR0 and CR1 are:
>>>
>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>
>>> - fix comment typos, clarify comment wording
>>>
>>> src/share/vm/oops/markOop.cpp
>>>
>>> - clarify output messages
>>> - get rid of confusing local variable
>>>
>>> src/share/vm/runtime/globals.hpp
>>>
>>> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
>>> and JavaThreadExitReleasesMonitors options
>>> - there are no longer changes to this file
>>>
>>> src/share/vm/runtime/objectMonitor.cpp
>>>
>>> - add ObjectMonitor::Knob_ExitRelease suboption to replace
>>> JavaThreadExitReleasesMonitors
>>> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
>>> GuaranteeOnMonitorMismatch
>>> - cleanup messy logging:
>>> - switch from '::printf()' -> 'tty->print_cr()'
>>> - switch from '::fflush()' -> 'tty->flush()'
>>>
>>> src/share/vm/runtime/objectMonitor.hpp
>>>
>>> - add ObjectMonitor::Knob_ExitRelease suboption
>>> - add ObjectMonitor::Knob_VerifyMatch suboption
>>> - cleanup messy logging
>>>
>>> src/share/vm/runtime/synchronizer.cpp
>>>
>>> - cleanup messy logging
>>> - switch from GuaranteeOnMonitorMismatch to
>>> ObjectMonitor::Knob_VerifyMatch
>>> - add diagnostic information about the locked object
>>> when ReleaseJavaMonitorsClosure::do_monitor() finds
>>> a problem
>>>
>>> src/share/vm/runtime/thread.cpp
>>>
>>> - clarify comments
>>> - switch from JavaThreadExitReleasesMonitors to
>>> ObjectMonitor::Knob_ExitRelease
>>>
>>> src/share/vm/runtime/vframe.cpp
>>>
>>> - print_locked_object_class_name() is now public
>>> - clarify comments
>>> - clarify output messages
>>> - switch from VerboseStackTrace to the already existing
>>> ObjectMonitor::Knob_Verbose
>>>
>>> src/share/vm/runtime/vframe.hpp
>>>
>>> - print_locked_object_class_name() is now public
>>>
>>>
>>> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> The hunt for the following bug:
>>>>
>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>
>>>> and David C's work on the following bug:
>>>>
>>>> JDK-8069412 Locks need better debug-printing support
>>>>
>>>> have inspired additional thread dump improvements, comment additions
>>>> to some Java monitor code and some new diagnostic options.
>>>>
>>>> This work is being tracked by the following bug ID:
>>>>
>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>> additions, new diagnostics
>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>
>>>> Here is the webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>
>>>> Testing:
>>>>
>>>> - RBT vm.quick batches (in process)
>>>> - JPRT test jobs
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Gory details about the changes are below...
>>>>
>>>> Dan
>>>>
>>>> 8130448 summary of changes:
>>>>
>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>> - comment additions for the assembly code
>>>>
>>>> src/share/vm/oops/markOop.cpp
>>>> - has_monitor() has to be checked before is_locked() since
>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>> - code style fixes
>>>>
>>>> src/share/vm/runtime/globals.hpp
>>>> - add VerboseStackTrace diagnostic option
>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>> - add JavaThreadExitReleasesMonitors product option;
>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>> - delete unused ObjectMonitor::try_enter()
>>>> - fix assert wording
>>>>
>>>> src/share/vm/runtime/objectMonitor.hpp
>>>> - delete unused ObjectMonitor::try_enter()
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>> - add GuaranteeOnMonitorMismatch support with some
>>>> diagnostic output
>>>>
>>>> src/share/vm/runtime/thread.cpp
>>>> - add JavaThreadExitReleasesMonitors support
>>>>
>>>> src/share/vm/runtime/vframe.cpp
>>>> - clarify existing comments
>>>> - add comments to clarify what "waiting on" means
>>>> - add line to show when we are "waiting on", but
>>>> there are no locals available (previously we were
>>>> "waiting on" silently)
>>>> - add support for "waiting to relock" which can happen
>>>> for any of the monitors and not just the top monitor
>>>> - switch mark->print_on() verbose output to new
>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>> with a specific switch so the '-XX:+Verbose' model of
>>>> being a modifier for another option does not fit
>>>>
>>>>
>>>
>
From david.holmes at oracle.com Fri Jul 10 00:17:17 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 10 Jul 2015 10:17:17 +1000
Subject: RFR(S) 8130448: thread dump improvements, comment, additions, new
diagnostics inspired by 8077392
In-Reply-To: <559E8110.40706@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
<559E1611.2070803@oracle.com> <559E7259.1070605@oracle.com>
<559E7D5A.2040900@oracle.com> <559E8110.40706@oracle.com>
Message-ID: <559F0F0D.6080108@oracle.com>
Sorry I missed this update before previous reply.
Thumbs up!
David
On 10/07/2015 12:11 AM, Daniel D. Daugherty wrote:
> On 7/9/15 7:55 AM, Daniel D. Daugherty wrote:
>> > Any particular reason to use "fatal(...)" instead of
>> > "guarantee(false, ...)". I've seen both...
>>
>> Answering my own question... :-)
>>
>> fatal() and guarantee() both reach the same place (report_vm_error())
>> with the same bells-and-whistles on the way...
>>
>> So "guarantee(false, ...)" is the same as "fatal(...)"
>> so I'll switch to the more direct "fatal(...)".
>>
>> I don't think that change requires a re-review, please let me know
>> if you disagree...
>
> Sigh... I meant "webrev"... Here's the diffs:
>
> $ diff -c src/share/vm/runtime/synchronizer.cpp{.cr1,}
> *** src/share/vm/runtime/synchronizer.cpp.cr1 Wed Jul 8 07:15:07 2015
> --- src/share/vm/runtime/synchronizer.cpp Thu Jul 9 07:07:28 2015
> ***************
> *** 1651,1661 ****
> Handle obj((oop) mid->object());
> tty->print("INFO: unexpected locked object:");
> javaVFrame::print_locked_object_class_name(tty, obj, "locked");
> }
> - guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
> - err_msg("exiting JavaThread=" INTPTR_FORMAT
> - " unexpectedly owns ObjectMonitor="
> INTPTR_FORMAT,
> - THREAD, mid));
> (void)mid->complete_exit(CHECK);
> }
> }
> --- 1651,1660 ----
> Handle obj((oop) mid->object());
> tty->print("INFO: unexpected locked object:");
> javaVFrame::print_locked_object_class_name(tty, obj, "locked");
> + fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
> + " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
> + THREAD, mid));
> }
> (void)mid->complete_exit(CHECK);
> }
> }
>
> Dan
>
>
>>
>> Dan
>>
>>
>> On 7/9/15 7:08 AM, Daniel D. Daugherty wrote:
>>> David,
>>>
>>> Thanks for the quick re-review!
>>>
>>> Responses embedded below...
>>>
>>> On 7/9/15 12:34 AM, David Holmes wrote:
>>>> Hi Dan,
>>>>
>>>> On 9/07/2015 7:33 AM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> I've updated this patch based on David H's comments along with
>>>>> some additional cleanup.
>>>>
>>>> So to address the high-level changes:
>>>>
>>>> - Use ObjectMonitor::Knob_Verbose as the verbosity flag for printing
>>>> the lockbits in the stack dump. Okay - though I do wonder why the
>>>> SyncVerbose flag also exists?
>>>
>>> I'll ping Dice to see if there's a reason for two different verbose
>>> flags in the monitor subsystem. I have to admit that I didn't notice
>>> that one in the large collection of knobs and switches... :-(
>>>
>>>
>>>> - Use ObjectMonitor::Knob_ExitRelease to control whether Java
>>>> threads are checked for locked monitors when they exit
>>>> - Use ObjectMonitor::Knob_VerifyMatch to control whether finding a
>>>> locked (hence unmatched) monitor causes an abort
>>>>
>>>> That seems like a good way to work within the existing mechanism for
>>>> customizing the sync logic - and no new global options (though SQE
>>>> will still need tests for using these knobs I think).
>>>
>>> Glad that this version is more acceptable.
>>>
>>>
>>>> Some specific comments below ...
>>>>
>>>>> This work is being tracked by the following bug ID:
>>>>>
>>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>>> additions, new diagnostics
>>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>>
>>>>> Here is the webrev URL:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
>>>>
>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>
>>>> 2393 if (Knob_ReportSettings && v != NULL) {
>>>> 2394 tty->print_cr("INFO: SyncKnob: %s %d(%d)", Key, rslt,
>>>> Default) ;
>>>> 2395 tty->flush();
>>>> 2396 }
>>>>
>>>> I suspect these were not tty using because this might get called
>>>> before the tty has been initialized - but I can't see how that might
>>>> arise (nor can I be certain it can't).
>>>
>>> I couldn't see how tty could not be initialized at these points either.
>>> My current plan is to go with this change to 'tty' and if we run into
>>> an early use case, then we do something else _and_ comment it.
>>>
>>> Although with unified logging coming... this may be moot (but the
>>> tty version will be easier to port...)
>>>
>>>
>>>>
>>>> Ditto for similar changes throughout.
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/synchronizer.cpp
>>>>
>>>> 1648 void do_monitor(ObjectMonitor* mid) {
>>>> 1649 if (mid->owner() == THREAD) {
>>>> 1650 if (ObjectMonitor::Knob_VerifyMatch != 0) {
>>>> 1651 Handle obj((oop) mid->object());
>>>> 1652 tty->print("INFO: unexpected locked object:");
>>>> 1653 javaVFrame::print_locked_object_class_name(tty, obj,
>>>> "locked");
>>>> 1654 }
>>>> 1655 guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
>>>> 1656 err_msg("exiting JavaThread=" INTPTR_FORMAT
>>>> 1657 " unexpectedly owns ObjectMonitor="
>>>> INTPTR_FORMAT,
>>>> 1658 THREAD, mid));
>>>> 1659 (void)mid->complete_exit(CHECK);
>>>> 1660 }
>>>> 1661 }
>>>>
>>>> Took me a while to figure out the expected control flow here.
>>>> Doesn't the above simplify to:
>>>>
>>>> void do_monitor(ObjectMonitor* mid) {
>>>> if (mid->owner() == THREAD) {
>>>> if (ObjectMonitor::Knob_VerifyMatch != 0) {
>>>> Handle obj((oop) mid->object());
>>>> tty->print("INFO: unexpected locked object:");
>>>> javaVFrame::print_locked_object_class_name(tty, obj,
>>>> "locked");
>>>> fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
>>>> " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
>>>> THREAD, mid));
>>>> }
>>>> (void)mid->complete_exit(CHECK);
>>>> }
>>>> }
>>>>
>>>> ?
>>>
>>> Yes, your version is cleaner.
>>>
>>> Any particular reason to use "fatal(...)" instead of
>>> "guarantee(false, ...)". I've seen both...
>>>
>>> Dan
>>>
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>>
>>>>> The easiest way to review the delta is to download the two patch
>>>>> files and compare them in something like jfilemerge:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>>>>>
>>>>>
>>>>>
>>>>> Testing:
>>>>>
>>>>> - Aurora Adhoc RT/SVC nightly batches (in process)
>>>>> - JPRT test jobs
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Gory details about the changes are below...
>>>>>
>>>>> Dan
>>>>>
>>>>> Changes between CR0 and CR1 are:
>>>>>
>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>>
>>>>> - fix comment typos, clarify comment wording
>>>>>
>>>>> src/share/vm/oops/markOop.cpp
>>>>>
>>>>> - clarify output messages
>>>>> - get rid of confusing local variable
>>>>>
>>>>> src/share/vm/runtime/globals.hpp
>>>>>
>>>>> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
>>>>> and JavaThreadExitReleasesMonitors options
>>>>> - there are no longer changes to this file
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>
>>>>> - add ObjectMonitor::Knob_ExitRelease suboption to replace
>>>>> JavaThreadExitReleasesMonitors
>>>>> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
>>>>> GuaranteeOnMonitorMismatch
>>>>> - cleanup messy logging:
>>>>> - switch from '::printf()' -> 'tty->print_cr()'
>>>>> - switch from '::fflush()' -> 'tty->flush()'
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>
>>>>> - add ObjectMonitor::Knob_ExitRelease suboption
>>>>> - add ObjectMonitor::Knob_VerifyMatch suboption
>>>>> - cleanup messy logging
>>>>>
>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>
>>>>> - cleanup messy logging
>>>>> - switch from GuaranteeOnMonitorMismatch to
>>>>> ObjectMonitor::Knob_VerifyMatch
>>>>> - add diagnostic information about the locked object
>>>>> when ReleaseJavaMonitorsClosure::do_monitor() finds
>>>>> a problem
>>>>>
>>>>> src/share/vm/runtime/thread.cpp
>>>>>
>>>>> - clarify comments
>>>>> - switch from JavaThreadExitReleasesMonitors to
>>>>> ObjectMonitor::Knob_ExitRelease
>>>>>
>>>>> src/share/vm/runtime/vframe.cpp
>>>>>
>>>>> - print_locked_object_class_name() is now public
>>>>> - clarify comments
>>>>> - clarify output messages
>>>>> - switch from VerboseStackTrace to the already existing
>>>>> ObjectMonitor::Knob_Verbose
>>>>>
>>>>> src/share/vm/runtime/vframe.hpp
>>>>>
>>>>> - print_locked_object_class_name() is now public
>>>>>
>>>>>
>>>>> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> The hunt for the following bug:
>>>>>>
>>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>>>>
>>>>>> and David C's work on the following bug:
>>>>>>
>>>>>> JDK-8069412 Locks need better debug-printing support
>>>>>>
>>>>>> have inspired additional thread dump improvements, comment additions
>>>>>> to some Java monitor code and some new diagnostic options.
>>>>>>
>>>>>> This work is being tracked by the following bug ID:
>>>>>>
>>>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>>>> additions, new diagnostics
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>>>
>>>>>> Here is the webrev URL:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>>>
>>>>>> Testing:
>>>>>>
>>>>>> - RBT vm.quick batches (in process)
>>>>>> - JPRT test jobs
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Gory details about the changes are below...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> 8130448 summary of changes:
>>>>>>
>>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>>> - comment additions for the assembly code
>>>>>>
>>>>>> src/share/vm/oops/markOop.cpp
>>>>>> - has_monitor() has to be checked before is_locked() since
>>>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>>>> - code style fixes
>>>>>>
>>>>>> src/share/vm/runtime/globals.hpp
>>>>>> - add VerboseStackTrace diagnostic option
>>>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>>>> - add JavaThreadExitReleasesMonitors product option;
>>>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>> - fix assert wording
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>>
>>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>> - add GuaranteeOnMonitorMismatch support with some
>>>>>> diagnostic output
>>>>>>
>>>>>> src/share/vm/runtime/thread.cpp
>>>>>> - add JavaThreadExitReleasesMonitors support
>>>>>>
>>>>>> src/share/vm/runtime/vframe.cpp
>>>>>> - clarify existing comments
>>>>>> - add comments to clarify what "waiting on" means
>>>>>> - add line to show when we are "waiting on", but
>>>>>> there are no locals available (previously we were
>>>>>> "waiting on" silently)
>>>>>> - add support for "waiting to relock" which can happen
>>>>>> for any of the monitors and not just the top monitor
>>>>>> - switch mark->print_on() verbose output to new
>>>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>>>> with a specific switch so the '-XX:+Verbose' model of
>>>>>> being a modifier for another option does not fit
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>
From daniel.daugherty at oracle.com Fri Jul 10 00:22:52 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 09 Jul 2015 18:22:52 -0600
Subject: RFR(S) 8130448: thread dump improvements, comment, additions,
new diagnostics inspired by 8077392
In-Reply-To: <559F0F0D.6080108@oracle.com>
References: <55972558.6060905@oracle.com> <559D970E.7000905@oracle.com>
<559E1611.2070803@oracle.com> <559E7259.1070605@oracle.com>
<559E7D5A.2040900@oracle.com> <559E8110.40706@oracle.com>
<559F0F0D.6080108@oracle.com>
Message-ID: <559F105C.5020606@oracle.com>
Thanks!
Dan
On 7/9/15 6:17 PM, David Holmes wrote:
> Sorry I missed this update before previous reply.
>
> Thumbs up!
>
> David
>
> On 10/07/2015 12:11 AM, Daniel D. Daugherty wrote:
>> On 7/9/15 7:55 AM, Daniel D. Daugherty wrote:
>>> > Any particular reason to use "fatal(...)" instead of
>>> > "guarantee(false, ...)". I've seen both...
>>>
>>> Answering my own question... :-)
>>>
>>> fatal() and guarantee() both reach the same place (report_vm_error())
>>> with the same bells-and-whistles on the way...
>>>
>>> So "guarantee(false, ...)" is the same as "fatal(...)"
>>> so I'll switch to the more direct "fatal(...)".
>>>
>>> I don't think that change requires a re-review, please let me know
>>> if you disagree...
>>
>> Sigh... I meant "webrev"... Here's the diffs:
>>
>> $ diff -c src/share/vm/runtime/synchronizer.cpp{.cr1,}
>> *** src/share/vm/runtime/synchronizer.cpp.cr1 Wed Jul 8 07:15:07 2015
>> --- src/share/vm/runtime/synchronizer.cpp Thu Jul 9 07:07:28 2015
>> ***************
>> *** 1651,1661 ****
>> Handle obj((oop) mid->object());
>> tty->print("INFO: unexpected locked object:");
>> javaVFrame::print_locked_object_class_name(tty, obj,
>> "locked");
>> }
>> - guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
>> - err_msg("exiting JavaThread=" INTPTR_FORMAT
>> - " unexpectedly owns ObjectMonitor="
>> INTPTR_FORMAT,
>> - THREAD, mid));
>> (void)mid->complete_exit(CHECK);
>> }
>> }
>> --- 1651,1660 ----
>> Handle obj((oop) mid->object());
>> tty->print("INFO: unexpected locked object:");
>> javaVFrame::print_locked_object_class_name(tty, obj,
>> "locked");
>> + fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
>> + " unexpectedly owns ObjectMonitor="
>> INTPTR_FORMAT,
>> + THREAD, mid));
>> }
>> (void)mid->complete_exit(CHECK);
>> }
>> }
>>
>> Dan
>>
>>
>>>
>>> Dan
>>>
>>>
>>> On 7/9/15 7:08 AM, Daniel D. Daugherty wrote:
>>>> David,
>>>>
>>>> Thanks for the quick re-review!
>>>>
>>>> Responses embedded below...
>>>>
>>>> On 7/9/15 12:34 AM, David Holmes wrote:
>>>>> Hi Dan,
>>>>>
>>>>> On 9/07/2015 7:33 AM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> I've updated this patch based on David H's comments along with
>>>>>> some additional cleanup.
>>>>>
>>>>> So to address the high-level changes:
>>>>>
>>>>> - Use ObjectMonitor::Knob_Verbose as the verbosity flag for printing
>>>>> the lockbits in the stack dump. Okay - though I do wonder why the
>>>>> SyncVerbose flag also exists?
>>>>
>>>> I'll ping Dice to see if there's a reason for two different verbose
>>>> flags in the monitor subsystem. I have to admit that I didn't notice
>>>> that one in the large collection of knobs and switches... :-(
>>>>
>>>>
>>>>> - Use ObjectMonitor::Knob_ExitRelease to control whether Java
>>>>> threads are checked for locked monitors when they exit
>>>>> - Use ObjectMonitor::Knob_VerifyMatch to control whether finding a
>>>>> locked (hence unmatched) monitor causes an abort
>>>>>
>>>>> That seems like a good way to work within the existing mechanism for
>>>>> customizing the sync logic - and no new global options (though SQE
>>>>> will still need tests for using these knobs I think).
>>>>
>>>> Glad that this version is more acceptable.
>>>>
>>>>
>>>>> Some specific comments below ...
>>>>>
>>>>>> This work is being tracked by the following bug ID:
>>>>>>
>>>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>>>> additions, new diagnostics
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>>>
>>>>>> Here is the webrev URL:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/
>>>>>
>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>
>>>>> 2393 if (Knob_ReportSettings && v != NULL) {
>>>>> 2394 tty->print_cr("INFO: SyncKnob: %s %d(%d)", Key, rslt,
>>>>> Default) ;
>>>>> 2395 tty->flush();
>>>>> 2396 }
>>>>>
>>>>> I suspect these were not tty using because this might get called
>>>>> before the tty has been initialized - but I can't see how that might
>>>>> arise (nor can I be certain it can't).
>>>>
>>>> I couldn't see how tty could not be initialized at these points
>>>> either.
>>>> My current plan is to go with this change to 'tty' and if we run into
>>>> an early use case, then we do something else _and_ comment it.
>>>>
>>>> Although with unified logging coming... this may be moot (but the
>>>> tty version will be easier to port...)
>>>>
>>>>
>>>>>
>>>>> Ditto for similar changes throughout.
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>
>>>>> 1648 void do_monitor(ObjectMonitor* mid) {
>>>>> 1649 if (mid->owner() == THREAD) {
>>>>> 1650 if (ObjectMonitor::Knob_VerifyMatch != 0) {
>>>>> 1651 Handle obj((oop) mid->object());
>>>>> 1652 tty->print("INFO: unexpected locked object:");
>>>>> 1653 javaVFrame::print_locked_object_class_name(tty, obj,
>>>>> "locked");
>>>>> 1654 }
>>>>> 1655 guarantee(ObjectMonitor::Knob_VerifyMatch == 0,
>>>>> 1656 err_msg("exiting JavaThread=" INTPTR_FORMAT
>>>>> 1657 " unexpectedly owns ObjectMonitor="
>>>>> INTPTR_FORMAT,
>>>>> 1658 THREAD, mid));
>>>>> 1659 (void)mid->complete_exit(CHECK);
>>>>> 1660 }
>>>>> 1661 }
>>>>>
>>>>> Took me a while to figure out the expected control flow here.
>>>>> Doesn't the above simplify to:
>>>>>
>>>>> void do_monitor(ObjectMonitor* mid) {
>>>>> if (mid->owner() == THREAD) {
>>>>> if (ObjectMonitor::Knob_VerifyMatch != 0) {
>>>>> Handle obj((oop) mid->object());
>>>>> tty->print("INFO: unexpected locked object:");
>>>>> javaVFrame::print_locked_object_class_name(tty, obj,
>>>>> "locked");
>>>>> fatal(err_msg("exiting JavaThread=" INTPTR_FORMAT
>>>>> " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT,
>>>>> THREAD, mid));
>>>>> }
>>>>> (void)mid->complete_exit(CHECK);
>>>>> }
>>>>> }
>>>>>
>>>>> ?
>>>>
>>>> Yes, your version is cleaner.
>>>>
>>>> Any particular reason to use "fatal(...)" instead of
>>>> "guarantee(false, ...)". I've seen both...
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>
>>>>>> The easiest way to review the delta is to download the two patch
>>>>>> files and compare them in something like jfilemerge:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/hotspot.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/1-jdk9-hs-rt/hotspot.patch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Testing:
>>>>>>
>>>>>> - Aurora Adhoc RT/SVC nightly batches (in process)
>>>>>> - JPRT test jobs
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Gory details about the changes are below...
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> Changes between CR0 and CR1 are:
>>>>>>
>>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>>>
>>>>>> - fix comment typos, clarify comment wording
>>>>>>
>>>>>> src/share/vm/oops/markOop.cpp
>>>>>>
>>>>>> - clarify output messages
>>>>>> - get rid of confusing local variable
>>>>>>
>>>>>> src/share/vm/runtime/globals.hpp
>>>>>>
>>>>>> - drop VerboseStackTrace, GuaranteeOnMonitorMismatch
>>>>>> and JavaThreadExitReleasesMonitors options
>>>>>> - there are no longer changes to this file
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>>
>>>>>> - add ObjectMonitor::Knob_ExitRelease suboption to replace
>>>>>> JavaThreadExitReleasesMonitors
>>>>>> - add ObjectMonitor::Knob_VerifyMatch suboption to replace
>>>>>> GuaranteeOnMonitorMismatch
>>>>>> - cleanup messy logging:
>>>>>> - switch from '::printf()' -> 'tty->print_cr()'
>>>>>> - switch from '::fflush()' -> 'tty->flush()'
>>>>>>
>>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>>
>>>>>> - add ObjectMonitor::Knob_ExitRelease suboption
>>>>>> - add ObjectMonitor::Knob_VerifyMatch suboption
>>>>>> - cleanup messy logging
>>>>>>
>>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>>
>>>>>> - cleanup messy logging
>>>>>> - switch from GuaranteeOnMonitorMismatch to
>>>>>> ObjectMonitor::Knob_VerifyMatch
>>>>>> - add diagnostic information about the locked object
>>>>>> when ReleaseJavaMonitorsClosure::do_monitor() finds
>>>>>> a problem
>>>>>>
>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>
>>>>>> - clarify comments
>>>>>> - switch from JavaThreadExitReleasesMonitors to
>>>>>> ObjectMonitor::Knob_ExitRelease
>>>>>>
>>>>>> src/share/vm/runtime/vframe.cpp
>>>>>>
>>>>>> - print_locked_object_class_name() is now public
>>>>>> - clarify comments
>>>>>> - clarify output messages
>>>>>> - switch from VerboseStackTrace to the already existing
>>>>>> ObjectMonitor::Knob_Verbose
>>>>>>
>>>>>> src/share/vm/runtime/vframe.hpp
>>>>>>
>>>>>> - print_locked_object_class_name() is now public
>>>>>>
>>>>>>
>>>>>> On 7/3/15 6:14 PM, Daniel D. Daugherty wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> The hunt for the following bug:
>>>>>>>
>>>>>>> JDK-8077392 Stream fork/join tasks occasionally fail to
>>>>>>> complete
>>>>>>>
>>>>>>> and David C's work on the following bug:
>>>>>>>
>>>>>>> JDK-8069412 Locks need better debug-printing support
>>>>>>>
>>>>>>> have inspired additional thread dump improvements, comment
>>>>>>> additions
>>>>>>> to some Java monitor code and some new diagnostic options.
>>>>>>>
>>>>>>> This work is being tracked by the following bug ID:
>>>>>>>
>>>>>>> JDK-8130448 8077392 inspired thread dump improvements, comment
>>>>>>> additions, new diagnostics
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8130448
>>>>>>>
>>>>>>> Here is the webrev URL:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8130448-webrev/0-jdk9-hs-rt/
>>>>>>>
>>>>>>> Testing:
>>>>>>>
>>>>>>> - RBT vm.quick batches (in process)
>>>>>>> - JPRT test jobs
>>>>>>>
>>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>>
>>>>>>> Gory details about the changes are below...
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>> 8130448 summary of changes:
>>>>>>>
>>>>>>> src/cpu/x86/vm/macroAssembler_x86.cpp
>>>>>>> - comment additions for the assembly code
>>>>>>>
>>>>>>> src/share/vm/oops/markOop.cpp
>>>>>>> - has_monitor() has to be checked before is_locked() since
>>>>>>> the has_monitor() bits are a superset of the is_locked() bits
>>>>>>> - code style fixes
>>>>>>>
>>>>>>> src/share/vm/runtime/globals.hpp
>>>>>>> - add VerboseStackTrace diagnostic option
>>>>>>> - add GuaranteeOnMonitorMismatch diagnostic option
>>>>>>> - add JavaThreadExitReleasesMonitors product option;
>>>>>>> this is the Java equivalent of JNIDetachReleasesMonitors
>>>>>>>
>>>>>>> src/share/vm/runtime/objectMonitor.cpp
>>>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>>> - fix assert wording
>>>>>>>
>>>>>>> src/share/vm/runtime/objectMonitor.hpp
>>>>>>> - delete unused ObjectMonitor::try_enter()
>>>>>>>
>>>>>>> src/share/vm/runtime/synchronizer.cpp
>>>>>>> - add GuaranteeOnMonitorMismatch support with some
>>>>>>> diagnostic output
>>>>>>>
>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>> - add JavaThreadExitReleasesMonitors support
>>>>>>>
>>>>>>> src/share/vm/runtime/vframe.cpp
>>>>>>> - clarify existing comments
>>>>>>> - add comments to clarify what "waiting on" means
>>>>>>> - add line to show when we are "waiting on", but
>>>>>>> there are no locals available (previously we were
>>>>>>> "waiting on" silently)
>>>>>>> - add support for "waiting to relock" which can happen
>>>>>>> for any of the monitors and not just the top monitor
>>>>>>> - switch mark->print_on() verbose output to new
>>>>>>> VerboseStackTrace switch; thread dumps are not enabled
>>>>>>> with a specific switch so the '-XX:+Verbose' model of
>>>>>>> being a modifier for another option does not fit
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
From jeremymanson at google.com Fri Jul 10 00:23:52 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Thu, 9 Jul 2015 17:23:52 -0700
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To: <559EED17.4060109@oracle.com>
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
<559EED17.4060109@oracle.com>
Message-ID:
Hey Dmitry,
Thanks for looking at it. The leak was deliberate (under the theory that
the command line flags were leaked, too), but it was silly that I didn't
fix it.
Anyway, fixed. See:
http://cr.openjdk.java.net/~jmanson/8079301/webrev.03
Jeremy
On Thu, Jul 9, 2015 at 2:52 PM, Dmitry Dmitriev
wrote:
> Hello Jeremy,
>
> Correct me if I am wrong, but I see small memory leak in your
> implementation.
> In Arguments::parse_options_environment_variable function memory for
> 'buffer' allocated by strdup function on line 3415, but now it not freed in
> this function because data from this buffer is used later. On the other
> hand when we are done with env variables, we free only options array(lines
> 3703-3705) and not free previously allocated memory for 'buffer' because we
> lost track for it.
>
> Thanks,
> Dmitry
>
>
> On 09.07.2015 21:20, Jeremy Manson wrote:
>
>> Thanks for looking at this, Coleen.
>>
>> I merged this with the latest version of hs-rt, but Ron is or I am going
>> to
>> have to do some merging for 8061999. The changes are relatively
>> orthogonal, but they touch a couple of the same places. How far away is
>> Ron's checkin?
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
>>
>> Updated test:
>>
>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
>>
>> (Mild complaining on my part: the conflicts wouldn't have been an issue if
>> someone had looked at this two months ago, when I first asked. I suspect
>> Ron hadn't even started his change at that point. And if external
>> developers were able to submit changes to Hotspot, we wouldn't have had to
>> bother Oracle engineers at all. Neither of these is your fault or your
>> problem, of course - I'm grateful you were able to take a look.)
>>
>> Jeremy
>>
>> On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
>> coleen.phillimore at oracle.com> wrote:
>>
>> I'll sponsor it but can you repost the RFR?
>>>
>>> There has been a fair bit of work to command line processing lately so
>>> I'd
>>> like to have the others look at it too. Have you merged this up with the
>>> latest version of hs-rt repository and were there conflicts? Also, have
>>> you looked at the RFR:
>>>
>>> "Open code review for 8061999 Enhance VM option parsing to allow options
>>> to be specified"
>>>
>>> and are there conflicts with this?
>>>
>>> The hotspot change looks good to me.
>>>
>>>
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>>>
>>> "UseCerealGC" LOL
>>> Can you use a different option than PrintOopAddress in this test? I
>>> don't
>>> know why this command line option exists or would be useful for, and
>>> seems
>>> to be a good candidate for removal. If you need a valid argument, that
>>> is
>>> unlikely to go away, TraceExceptions would be good.
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>> On 7/7/15 8:00 PM, Jeremy Manson wrote:
>>>
>>> No love? Is there a code owner here I should pester more directly?
>>>>
>>>> Jeremy
>>>>
>>>> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
>>>> wrote:
>>>>
>>>> As usual with Google patches, they are in use locally. This one has
>>>> been
>>>>
>>>>> stable for a while without complaints. Please sponsor.
>>>>>
>>>>> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson <
>>>>> jeremymanson at google.com>
>>>>> wrote:
>>>>>
>>>>> All this talk about IgnoreUnrecognizedVMOptions reminded me that this
>>>>>
>>>>>> review is still outstanding. Any takers?
>>>>>>
>>>>>> Jeremy
>>>>>>
>>>>>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson <
>>>>>> jeremymanson at google.com
>>>>>> wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>>> Thanks for taking a look.
>>>>>>>
>>>>>>> On Mon, May 4, 2015 at 8:32 PM, David Holmes <
>>>>>>> david.holmes at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Jeremy,
>>>>>>>
>>>>>>>> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>>>>>>>>
>>>>>>>> Not sure who might be willing to sponsor this. David? You did
>>>>>>>> the
>>>>>>>>
>>>>>>>>> last
>>>>>>>>> one. :)
>>>>>>>>>
>>>>>>>>> Might be a while before I can get to it. I did have a quick look
>>>>>>>>>
>>>>>>>> (and
>>>>>>>> will need a longer one).
>>>>>>>>
>>>>>>>> I understand. I'm just happy it's possible to upstream this stuff
>>>>>>> at
>>>>>>> all[1].
>>>>>>>
>>>>>>> [1] With the eternal caveat that I'd be happier if we didn't *have*
>>>>>>> to
>>>>>>> go through you folks, but we've learned to live with it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Context: A number of command line options are not settable via
>>>>>>>
>>>>>>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>>>>>>>
>>>>>>>>> - PrintVMOptions
>>>>>>>>>
>>>>>>>>> So you have changed the semantics of this to print out the
>>>>>>>>> options
>>>>>>>>>
>>>>>>>> from
>>>>>>>> the command-line and each of the two env vars. Seems reasonable but
>>>>>>>> may be
>>>>>>>> better to know which option came from where as we can now see the
>>>>>>>> same
>>>>>>>> option (or conflicting variants thereof) multiple times.
>>>>>>>>
>>>>>>>> I'd be happy to do this. Any preferred syntax? Does someone
>>>>>>>>
>>>>>>> actually
>>>>>>> own this feature?
>>>>>>>
>>>>>>> I'm unclear what the current processing order is for the different
>>>>>>>
>>>>>>> sources of options, and whether the changes affect that order?
>>>>>>>>
>>>>>>>> Nope. I go through sad contortions to keep the processing order
>>>>>>>> the
>>>>>>>>
>>>>>>> same. It's JAVA_TOOL_OPTIONS, then command line, then _JAVA_OPTIONS.
>>>>>>> See
>>>>>>> lines 2549-2567.
>>>>>>>
>>>>>>>
>>>>>>> - IgnoreUnrecognizedVMOptions
>>>>>>>
>>>>>>>> - PrintFlagsInitial
>>>>>>>>>
>>>>>>>>> Unclear what "initial" actually means - is it the default?
>>>>>>>>>
>>>>>>>> More or less. If you stick, for example,
>>>>>>> IgnoreUnrecognizedVMOptions
>>>>>>> in
>>>>>>> there first, it will get printed out as "true". I haven't really
>>>>>>> changed
>>>>>>> the semantics here either - I've just added processing of the
>>>>>>> envvars.
>>>>>>>
>>>>>>> - NativeMemoryTracking
>>>>>>>
>>>>>>> - PrintFlagsWithComments
>>>>>>>>
>>>>>>>>> This is because these flags have to be processed before processing
>>>>>>>>> other
>>>>>>>>> flags, and no one ever bothered to do that for the flags coming
>>>>>>>>> from
>>>>>>>>> environment variables. This patch fixes that problem.
>>>>>>>>>
>>>>>>>>> I have a test, but it is a modification to a JDK test instead of a
>>>>>>>>> HS
>>>>>>>>> test,
>>>>>>>>> so it can go in separately (I guess).
>>>>>>>>>
>>>>>>>>> They can be pushed together to different repos in the same
>>>>>>>>> forest.
>>>>>>>>>
>>>>>>>> Okay. Here's the test change:
>>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>>>>>>
>>>>>>>
>>>>>>> As I said I'll have to get back to this. And hopefully someone
>>>>>>> else in
>>>>>>>
>>>>>>>> runtime will take a good look as well ;-)
>>>>>>>>
>>>>>>>> I'd be happy to toss it over to whomever owns this, if anyone.
>>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bug:
>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>>>>>>>
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
From yumin.qi at oracle.com Fri Jul 10 04:34:35 2015
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 09 Jul 2015 21:34:35 -0700
Subject: RFR: 8025692: Add trace to find out what methods are used at
runtime.
In-Reply-To:
References: <5514C1CB.7020009@oracle.com> <55711388.4090402@oracle.com>
Message-ID: <559F4B5B.60203@oracle.com>
Hi, Karen
Just informed you that RBT testing for quick testing seems will not
get back a completed result(I have tried several times those days).
After 11 hours, there still 4 jobs running:
26 of 34 succeeded, 4 failed, 4 still running.
Those running jobs already run at least 6+ hours.
The 4 failed jobs are dtrace on linux-x64 which are OK, since dtrace
is disabled on it.
Also, I added -Xint to test case, and tested with jtreg on
test/runtime showed no new failures found.
I am going to push the changes if you are OK with current result.
Seems the testing with RBT will never come back. Updated webrev:
http://cr.openjdk.java.net/~minqi/8025692/webrev02/
Thanks
Yumin
On 6/18/2015 1:01 PM, Karen Kinnear wrote:
> Yumin,
>
> Thank you very much for the updates.And the PERM_REFCOUNT rather than -1 :-)
> Looks good.
>
> Thank you for testing this -Xint. If there is an easy way to add an -Xint line
> to the test that would be useful - but not critical.
>
> So I presume that the "aurora default test suites" includes:
> jcks, jtreg hotspot and Christian's new "quick" tests.
>
> thanks,
> Karen
>
> On Jun 4, 2015, at 11:12 PM, Yumin Qi wrote:
>
>> HI, All
>>
>> After several round of codereviews and discussion, now the second version is at:
>> http://cr.openjdk.java.net/~minqi/8025692/webrev02/
>>
>> The flag names changed:
>>
>> TraceMethodUsge => LogTouchedMethods
>> PrintMethodUsageAtExit => PrintTouchedMethodsAtExit
>>
>> The two flags now are diagnostic flags.
>>
>> Also similar, there changed in related variable names.
>> Also fixed a flaw which is not found during last round of review: append new TouchedMethodRecord to end of hash bucket list.
>>
>> Make change to interpreter method entry generation(for both native and normal) to enable build_method_counter called. This is necessary since if run -Xint, the call will be skipped so our code will be skipped so no logging for touched methods.
>>
>> Added test case for jcmd: jcmd VM.print_touched_methods.
>>
>> Tests: JPRT, aurora default test suites (in progress).
>>
>> Thanks
>> Yumin
>>
>>
>> On 3/26/2015 7:34 PM, Yumin Qi wrote:
>>> Please review:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025692
>>> webrev: http://cr.openjdk.java.net/~minqi/8025692/webrev01/
>>>
>>> Summary: Add two flags to help list all java methods called in runtime, this is also in product and can help CDS to rearrange methods in shared archive to avoid loading infrequent methods into memory.
>>>
>>> Tests: vm.runtime.quick.testlist, JPRT
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>>
From david.holmes at oracle.com Fri Jul 10 05:56:48 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 10 Jul 2015 15:56:48 +1000
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <5589B912.2050003@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5589B912.2050003@oracle.com>
Message-ID: <559F5EA0.2080500@oracle.com>
Is there an updated webrev addressing Gerard's comments?
Thanks,
David
On 24/06/2015 5:52 AM, Gerard Ziemski wrote:
> hi Ron,
>
> I'm sending you partial feedback, since I am starting to get a bit
> tired. I will spend more time reviewing your webrev tomorrow, but here
> is what I have so far:
>
> ---
> src/share/vm/utilities/globalDefinitions.hpp
>
> 1. Should we name the method "is_white()", not "iswhite()" since it's
> part of our code base? But then since it's a macro, shouldn't it
> actually be "IS_WHITE()"?
>
> ---
> src/share/vm/runtime/arguments.hpp
>
> 1.
>
> All the arguments in alloc_JVM_options_list(),
> copy_JVM_options_from_buf() and parse_JVM_options_file() use underscores
> in the arguments names except for merge_JVM_options_file(). I think the
> merge_JVM_options_file() should be:
>
> + static jint merge_JVM_options_file(const struct JavaVMInitArgs *args_in,
> + struct JavaVMInitArgs **args_out);
>
>
> ---
> src/share/vm/runtime/arguments.cpp
>
> 1. Why do FreeVMOptions, DumpVMOptions, DumpVMOption and DumpOption
> start with capital letters? Shouldn?t their names start with a lower
> case letter?
>
> 2. Line 4306. The pattern in Arguments::parse() seems to be to print out
> error message and return the error value if something goes wrong, but we
> do vm_exit(1) instead?
>
> 3. Line 4309. I was told that when it comes to NULL pointer check we
> should do (NULL == args), not the other way around.
>
> 4. Line 4375. Don't we need FreeVMOptions() here? Line 4382 as well?
>
> 5. Question. Why do we need N_MAX_OPTIONS?
>
> 6. Question. Why do we need OPTION_BUFFER_SIZE? Can?t we use ?int
> bytes_needed = fseek(stream, 0, SEEK_END); rewind(stream)? and have the
> code dynamically allocate memory without hard coded limits?
>
> 7. Line 3965. Can that comparison ever succeed? ?read()? will not read
> more bytes (only less) than as specified by ?bytes_alloc? and if it did,
> we would overwrite memory since our buf is only ?bytes_alloc? big.
>
>
>
> cheers
>
>
> On 6/22/2015 7:52 AM, Ron Durbin wrote:
>> Webrev URL:
>> http://cr.openjdk.java.net/~rdurbin/8061999_OCR0_JDK9_webrev
>>
>>
>> RFE request:
>> https://bugs.openjdk.java.net/browse/JDK-8061999
>>
>> This RFE allows a file to be specified that holds VM Options that
>> would otherwise be specified on the command line or in an environment
>> variable.
>> Only one options file may be specified on the command line and no
>> options file
>> may be specified in either of the following environment variables
>> "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS".
>>
>> The options file feature supports all VM options currently supported on
>> the command line, except the options file option. The option to
>> specify an
>> options file is "-XX:VMOptionsFile=".
>> The options file feature supports an options file up to 1024 bytes in
>> size
>> and up to 64 options.
>>
>> This feature has been tested on:
>> OS:
>> Solaris, MAC, Windows, Linux
>> Tests:
>> Manual unit tests
>> JPRT with -testset hotspot (including the SQE proposed test
>> coverage for this feature.)
>>
>>
>
From david.holmes at oracle.com Fri Jul 10 06:03:10 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 10 Jul 2015 16:03:10 +1000
Subject: RFR [8u60]: 8081590: The CDS classlist needs to be updated for
8u60
In-Reply-To: <559EF045.10307@oracle.com>
References: <5579965B.7000709@oracle.com> <559EF045.10307@oracle.com>
Message-ID: <559F601E.3000907@oracle.com>
On 10/07/2015 8:05 AM, Claes Redestad wrote:
> Hi,
>
> new refresh up:
>
> http://cr.openjdk.java.net/~redestad/8081590/webrev.02/
>
> The refresh was put on hold earlier due to an incoming startup
> optimization, which affected the classlist (mostly
> order).
>
> I've rerun relevant tests, verified -Xshare:dump doesn't log any
> warnings and checked that footprint and startup improve.
Seems okay. This can go to jdk8u/hs-dev for 8u66 and 8u60.
Thanks,
David
> Thanks!
>
> /Claes
>
> On 2015-06-11 16:08, Claes Redestad wrote:
>> Hi,
>>
>> classlists have been slowly deteriorating since the last refresh
>> (https://bugs.openjdk.java.net/browse/JDK-8023041),
>> contributing to a small but significant degradation in startup and
>> footprint characteristics.
>>
>> While there are also classlist files for Solaris, Mac and AIX, we
>> cannot run the same set of applications we run on
>> 32-bit platforms on non-32-bit platforms (due to an application with a
>> bundled 32-bit dependency).
>>
>> Rather than generating new classlists using a different set of
>> applications without ability to verify that it helps, I'd
>> rather limit this 8u60 refresh to Linux and Windows where we can
>> verify the benefit and do a more thorough
>> investigation into modernizing the representative set of applications
>> for JDK9 and onwards.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8081590/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081590
>>
>> I'll need a sponsor to push this to 8u60.
>>
>> /Claes
>
From david.holmes at oracle.com Fri Jul 10 06:53:23 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 10 Jul 2015 16:53:23 +1000
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To:
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
<559EED17.4060109@oracle.com>
Message-ID: <559F6BE3.9080002@oracle.com>
Hi Jeremy,
On 10/07/2015 10:23 AM, Jeremy Manson wrote:
> Hey Dmitry,
>
> Thanks for looking at it. The leak was deliberate (under the theory that
> the command line flags were leaked, too), but it was silly that I didn't
> fix it.
>
> Anyway, fixed. See:
>
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.03
I'm not sure you've changed anything in this regard but it seems to me
to me that if -XX:Flags=flags-file is specified on the command-line, and
the environment variable(s) then the last setting wins - which would be
the _JAVA_OPTIONS setting.
Or maybe that is the way this whole thing works ie last setting wins?
David
> Jeremy
>
> On Thu, Jul 9, 2015 at 2:52 PM, Dmitry Dmitriev
> wrote:
>
>> Hello Jeremy,
>>
>> Correct me if I am wrong, but I see small memory leak in your
>> implementation.
>> In Arguments::parse_options_environment_variable function memory for
>> 'buffer' allocated by strdup function on line 3415, but now it not freed in
>> this function because data from this buffer is used later. On the other
>> hand when we are done with env variables, we free only options array(lines
>> 3703-3705) and not free previously allocated memory for 'buffer' because we
>> lost track for it.
>>
>> Thanks,
>> Dmitry
>>
>>
>> On 09.07.2015 21:20, Jeremy Manson wrote:
>>
>>> Thanks for looking at this, Coleen.
>>>
>>> I merged this with the latest version of hs-rt, but Ron is or I am going
>>> to
>>> have to do some merging for 8061999. The changes are relatively
>>> orthogonal, but they touch a couple of the same places. How far away is
>>> Ron's checkin?
>>>
>>> Updated webrev:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
>>>
>>> Updated test:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
>>>
>>> (Mild complaining on my part: the conflicts wouldn't have been an issue if
>>> someone had looked at this two months ago, when I first asked. I suspect
>>> Ron hadn't even started his change at that point. And if external
>>> developers were able to submit changes to Hotspot, we wouldn't have had to
>>> bother Oracle engineers at all. Neither of these is your fault or your
>>> problem, of course - I'm grateful you were able to take a look.)
>>>
>>> Jeremy
>>>
>>> On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
>>> coleen.phillimore at oracle.com> wrote:
>>>
>>> I'll sponsor it but can you repost the RFR?
>>>>
>>>> There has been a fair bit of work to command line processing lately so
>>>> I'd
>>>> like to have the others look at it too. Have you merged this up with the
>>>> latest version of hs-rt repository and were there conflicts? Also, have
>>>> you looked at the RFR:
>>>>
>>>> "Open code review for 8061999 Enhance VM option parsing to allow options
>>>> to be specified"
>>>>
>>>> and are there conflicts with this?
>>>>
>>>> The hotspot change looks good to me.
>>>>
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>>>>
>>>> "UseCerealGC" LOL
>>>> Can you use a different option than PrintOopAddress in this test? I
>>>> don't
>>>> know why this command line option exists or would be useful for, and
>>>> seems
>>>> to be a good candidate for removal. If you need a valid argument, that
>>>> is
>>>> unlikely to go away, TraceExceptions would be good.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>> On 7/7/15 8:00 PM, Jeremy Manson wrote:
>>>>
>>>> No love? Is there a code owner here I should pester more directly?
>>>>>
>>>>> Jeremy
>>>>>
>>>>> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
>>>>> wrote:
>>>>>
>>>>> As usual with Google patches, they are in use locally. This one has
>>>>> been
>>>>>
>>>>>> stable for a while without complaints. Please sponsor.
>>>>>>
>>>>>> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson <
>>>>>> jeremymanson at google.com>
>>>>>> wrote:
>>>>>>
>>>>>> All this talk about IgnoreUnrecognizedVMOptions reminded me that this
>>>>>>
>>>>>>> review is still outstanding. Any takers?
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson <
>>>>>>> jeremymanson at google.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>>> Thanks for taking a look.
>>>>>>>>
>>>>>>>> On Mon, May 4, 2015 at 8:32 PM, David Holmes <
>>>>>>>> david.holmes at oracle.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Jeremy,
>>>>>>>>
>>>>>>>>> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>>>>>>>>>
>>>>>>>>> Not sure who might be willing to sponsor this. David? You did
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>> last
>>>>>>>>>> one. :)
>>>>>>>>>>
>>>>>>>>>> Might be a while before I can get to it. I did have a quick look
>>>>>>>>>>
>>>>>>>>> (and
>>>>>>>>> will need a longer one).
>>>>>>>>>
>>>>>>>>> I understand. I'm just happy it's possible to upstream this stuff
>>>>>>>> at
>>>>>>>> all[1].
>>>>>>>>
>>>>>>>> [1] With the eternal caveat that I'd be happier if we didn't *have*
>>>>>>>> to
>>>>>>>> go through you folks, but we've learned to live with it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Context: A number of command line options are not settable via
>>>>>>>>
>>>>>>>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>>>>>>>>
>>>>>>>>>> - PrintVMOptions
>>>>>>>>>>
>>>>>>>>>> So you have changed the semantics of this to print out the
>>>>>>>>>> options
>>>>>>>>>>
>>>>>>>>> from
>>>>>>>>> the command-line and each of the two env vars. Seems reasonable but
>>>>>>>>> may be
>>>>>>>>> better to know which option came from where as we can now see the
>>>>>>>>> same
>>>>>>>>> option (or conflicting variants thereof) multiple times.
>>>>>>>>>
>>>>>>>>> I'd be happy to do this. Any preferred syntax? Does someone
>>>>>>>>>
>>>>>>>> actually
>>>>>>>> own this feature?
>>>>>>>>
>>>>>>>> I'm unclear what the current processing order is for the different
>>>>>>>>
>>>>>>>> sources of options, and whether the changes affect that order?
>>>>>>>>>
>>>>>>>>> Nope. I go through sad contortions to keep the processing order
>>>>>>>>> the
>>>>>>>>>
>>>>>>>> same. It's JAVA_TOOL_OPTIONS, then command line, then _JAVA_OPTIONS.
>>>>>>>> See
>>>>>>>> lines 2549-2567.
>>>>>>>>
>>>>>>>>
>>>>>>>> - IgnoreUnrecognizedVMOptions
>>>>>>>>
>>>>>>>>> - PrintFlagsInitial
>>>>>>>>>>
>>>>>>>>>> Unclear what "initial" actually means - is it the default?
>>>>>>>>>>
>>>>>>>>> More or less. If you stick, for example,
>>>>>>>> IgnoreUnrecognizedVMOptions
>>>>>>>> in
>>>>>>>> there first, it will get printed out as "true". I haven't really
>>>>>>>> changed
>>>>>>>> the semantics here either - I've just added processing of the
>>>>>>>> envvars.
>>>>>>>>
>>>>>>>> - NativeMemoryTracking
>>>>>>>>
>>>>>>>> - PrintFlagsWithComments
>>>>>>>>>
>>>>>>>>>> This is because these flags have to be processed before processing
>>>>>>>>>> other
>>>>>>>>>> flags, and no one ever bothered to do that for the flags coming
>>>>>>>>>> from
>>>>>>>>>> environment variables. This patch fixes that problem.
>>>>>>>>>>
>>>>>>>>>> I have a test, but it is a modification to a JDK test instead of a
>>>>>>>>>> HS
>>>>>>>>>> test,
>>>>>>>>>> so it can go in separately (I guess).
>>>>>>>>>>
>>>>>>>>>> They can be pushed together to different repos in the same
>>>>>>>>>> forest.
>>>>>>>>>>
>>>>>>>>> Okay. Here's the test change:
>>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>>>>>>>
>>>>>>>>
>>>>>>>> As I said I'll have to get back to this. And hopefully someone
>>>>>>>> else in
>>>>>>>>
>>>>>>>>> runtime will take a good look as well ;-)
>>>>>>>>>
>>>>>>>>> I'd be happy to toss it over to whomever owns this, if anyone.
>>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Jeremy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>>>>>>>>
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
From andreas.eriksson at oracle.com Fri Jul 10 11:20:58 2015
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Fri, 10 Jul 2015 13:20:58 +0200
Subject: Jdk8 backports of 6904403 and 8044364
Message-ID: <559FAA9A.6030608@oracle.com>
Hi,
Just a heads up that I'm backporting these fixes to jdk8:
https://bugs.openjdk.java.net/browse/JDK-6904403: assert(f ==
k->has_finalizer(),"inconsistent has_finalizer") with debug VM
https://bugs.openjdk.java.net/browse/JDK-8044364: [TESTBUG]
runtime/RedefineFinalizer test fails on windows
Both of them applies cleanly from the jdk9 changesets (so no review
required).
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c597dc3eb862
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/29d15865d20f
Unless someone objects I'll get them pushed later today.
- Andreas
From dmitry.dmitriev at oracle.com Fri Jul 10 11:36:43 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 10 Jul 2015 14:36:43 +0300
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To:
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
<559EED17.4060109@oracle.com>
Message-ID: <559FAE4B.5060505@oracle.com>
Hello Jeremy,
Thank you for fixing that! But in this case we still have minor issue
when quotes processing failed(lines 3438-3444). Here is my suggestion:
leave 'while' cycle(lines 3423-3462) as I was in your previous
webrev(without 'start' and etc.) and call strdup when copy 'options' to
'options_arr' on lines 3472-3474, i.e. make lines 3472-3474 like this:
3472 for (int i = 0; i < options->length(); i++) {
3473 options_arr[i] = options->at(i);
3474 options_arr[i].optionString = os::strdup(options_arr[i].optionString);
3475 }
What you think about that?
Regards,
Dmitry
On 10.07.2015 3:23, Jeremy Manson wrote:
> Hey Dmitry,
>
> Thanks for looking at it. The leak was deliberate (under the theory
> that the command line flags were leaked, too), but it was silly that I
> didn't fix it.
>
> Anyway, fixed. See:
>
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.03
>
>
> Jeremy
>
> On Thu, Jul 9, 2015 at 2:52 PM, Dmitry Dmitriev
> > wrote:
>
> Hello Jeremy,
>
> Correct me if I am wrong, but I see small memory leak in your
> implementation.
> In Arguments::parse_options_environment_variable function memory
> for 'buffer' allocated by strdup function on line 3415, but now it
> not freed in this function because data from this buffer is used
> later. On the other hand when we are done with env variables, we
> free only options array(lines 3703-3705) and not free previously
> allocated memory for 'buffer' because we lost track for it.
>
> Thanks,
> Dmitry
>
>
> On 09.07.2015 21:20, Jeremy Manson wrote:
>
> Thanks for looking at this, Coleen.
>
> I merged this with the latest version of hs-rt, but Ron is or
> I am going to
> have to do some merging for 8061999. The changes are relatively
> orthogonal, but they touch a couple of the same places. How
> far away is
> Ron's checkin?
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
>
>
> Updated test:
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
>
>
> (Mild complaining on my part: the conflicts wouldn't have been
> an issue if
> someone had looked at this two months ago, when I first
> asked. I suspect
> Ron hadn't even started his change at that point. And if external
> developers were able to submit changes to Hotspot, we wouldn't
> have had to
> bother Oracle engineers at all. Neither of these is your
> fault or your
> problem, of course - I'm grateful you were able to take a look.)
>
> Jeremy
>
> On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
> coleen.phillimore at oracle.com
> > wrote:
>
> I'll sponsor it but can you repost the RFR?
>
> There has been a fair bit of work to command line
> processing lately so I'd
> like to have the others look at it too. Have you merged
> this up with the
> latest version of hs-rt repository and were there
> conflicts? Also, have
> you looked at the RFR:
>
> "Open code review for 8061999 Enhance VM option parsing to
> allow options
> to be specified"
>
> and are there conflicts with this?
>
> The hotspot change looks good to me.
>
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>
>
> "UseCerealGC" LOL
> Can you use a different option than PrintOopAddress in
> this test? I don't
> know why this command line option exists or would be
> useful for, and seems
> to be a good candidate for removal. If you need a valid
> argument, that is
> unlikely to go away, TraceExceptions would be good.
>
> Thanks,
> Coleen
>
>
> On 7/7/15 8:00 PM, Jeremy Manson wrote:
>
> No love? Is there a code owner here I should pester
> more directly?
>
> Jeremy
>
> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
> >
> wrote:
>
> As usual with Google patches, they are in use
> locally. This one has been
>
> stable for a while without complaints. Please
> sponsor.
>
> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson
> >
> wrote:
>
> All this talk about IgnoreUnrecognizedVMOptions
> reminded me that this
>
> review is still outstanding. Any takers?
>
> Jeremy
>
> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson
>
> wrote:
>
> Hi David,
>
> Thanks for taking a look.
>
> On Mon, May 4, 2015 at 8:32 PM, David
> Holmes >
> wrote:
>
> Hi Jeremy,
>
> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>
> Not sure who might be willing to
> sponsor this. David? You did the
>
> last
> one. :)
>
> Might be a while before I can
> get to it. I did have a quick look
>
> (and
> will need a longer one).
>
> I understand. I'm just happy it's
> possible to upstream this stuff at
> all[1].
>
> [1] With the eternal caveat that I'd be
> happier if we didn't *have* to
> go through you folks, but we've learned to
> live with it.
>
>
>
> Context: A number of command line
> options are not settable via
>
> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>
> - PrintVMOptions
>
> So you have changed the
> semantics of this to print out the
> options
>
> from
> the command-line and each of the two
> env vars. Seems reasonable but
> may be
> better to know which option came from
> where as we can now see the same
> option (or conflicting variants
> thereof) multiple times.
>
> I'd be happy to do this. Any
> preferred syntax? Does someone
>
> actually
> own this feature?
>
> I'm unclear what the current processing
> order is for the different
>
> sources of options, and whether the
> changes affect that order?
>
> Nope. I go through sad contortions
> to keep the processing order the
>
> same. It's JAVA_TOOL_OPTIONS, then
> command line, then _JAVA_OPTIONS.
> See
> lines 2549-2567.
>
>
> - IgnoreUnrecognizedVMOptions
>
> - PrintFlagsInitial
>
> Unclear what "initial" actually
> means - is it the default?
>
> More or less. If you stick, for example,
> IgnoreUnrecognizedVMOptions
> in
> there first, it will get printed out as
> "true". I haven't really
> changed
> the semantics here either - I've just
> added processing of the envvars.
>
> - NativeMemoryTracking
>
> - PrintFlagsWithComments
>
> This is because these flags have
> to be processed before processing
> other
> flags, and no one ever bothered to
> do that for the flags coming from
> environment variables. This patch
> fixes that problem.
>
> I have a test, but it is a
> modification to a JDK test instead
> of a HS
> test,
> so it can go in separately (I guess).
>
> They can be pushed together to
> different repos in the same forest.
>
> Okay. Here's the test change:
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>
>
>
> As I said I'll have to get back to this.
> And hopefully someone else in
>
> runtime will take a good look as well ;-)
>
> I'd be happy to toss it over to
> whomever owns this, if anyone.
>
> Thanks!
>
> Jeremy
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8079301
>
> Webrev:
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>
>
> Jeremy
>
>
>
>
>
From ron.durbin at oracle.com Fri Jul 10 12:33:17 2015
From: ron.durbin at oracle.com (Ron Durbin)
Date: Fri, 10 Jul 2015 05:33:17 -0700 (PDT)
Subject: Open code review for 8061999 Enhance VM option parsing to allow
options to be specified
In-Reply-To: <559F5EA0.2080500@oracle.com>
References: <3d1df3cb-fe69-4c3b-b8e1-db8801d5a68f@default>
<5589B912.2050003@oracle.com> <559F5EA0.2080500@oracle.com>
Message-ID: <6f8e0dae-fc8a-4b72-ae83-af20aec7bf46@default>
Not yet
>-----Original Message-----
>From: David Holmes
>Sent: Thursday, July 09, 2015 11:57 PM
>To: hotspot-runtime-dev at openjdk.java.net
>Subject: Re: Open code review for 8061999 Enhance VM option parsing to allow options to be specified
>
>Is there an updated webrev addressing Gerard's comments?
>
>Thanks,
>David
>
>On 24/06/2015 5:52 AM, Gerard Ziemski wrote:
>> hi Ron,
>>
>> I'm sending you partial feedback, since I am starting to get a bit
>> tired. I will spend more time reviewing your webrev tomorrow, but here
>> is what I have so far:
>>
>> ---
>> src/share/vm/utilities/globalDefinitions.hpp
>>
>> 1. Should we name the method "is_white()", not "iswhite()" since it's
>> part of our code base? But then since it's a macro, shouldn't it
>> actually be "IS_WHITE()"?
>>
>> ---
>> src/share/vm/runtime/arguments.hpp
>>
>> 1.
>>
>> All the arguments in alloc_JVM_options_list(),
>> copy_JVM_options_from_buf() and parse_JVM_options_file() use underscores
>> in the arguments names except for merge_JVM_options_file(). I think the
>> merge_JVM_options_file() should be:
>>
>> + static jint merge_JVM_options_file(const struct JavaVMInitArgs *args_in,
>> + struct JavaVMInitArgs **args_out);
>>
>>
>> ---
>> src/share/vm/runtime/arguments.cpp
>>
>> 1. Why do FreeVMOptions, DumpVMOptions, DumpVMOption and DumpOption
>> start with capital letters? Shouldn't their names start with a lower
>> case letter?
>>
>> 2. Line 4306. The pattern in Arguments::parse() seems to be to print out
>> error message and return the error value if something goes wrong, but we
>> do vm_exit(1) instead?
>>
>> 3. Line 4309. I was told that when it comes to NULL pointer check we
>> should do (NULL == args), not the other way around.
>>
>> 4. Line 4375. Don't we need FreeVMOptions() here? Line 4382 as well?
>>
>> 5. Question. Why do we need N_MAX_OPTIONS?
>>
>> 6. Question. Why do we need OPTION_BUFFER_SIZE? Can't we use "int
>> bytes_needed = fseek(stream, 0, SEEK_END); rewind(stream)" and have the
>> code dynamically allocate memory without hard coded limits?
>>
>> 7. Line 3965. Can that comparison ever succeed? "read()" will not read
>> more bytes (only less) than as specified by "bytes_alloc" and if it did,
>> we would overwrite memory since our buf is only "bytes_alloc" big.
>>
>>
>>
>> cheers
>>
>>
>> On 6/22/2015 7:52 AM, Ron Durbin wrote:
>>> Webrev URL:
>>> http://cr.openjdk.java.net/~rdurbin/8061999_OCR0_JDK9_webrev
>>>
>>>
>>> RFE request:
>>> https://bugs.openjdk.java.net/browse/JDK-8061999
>>>
>>> This RFE allows a file to be specified that holds VM Options that
>>> would otherwise be specified on the command line or in an environment
>>> variable.
>>> Only one options file may be specified on the command line and no
>>> options file
>>> may be specified in either of the following environment variables
>>> "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS".
>>>
>>> The options file feature supports all VM options currently supported on
>>> the command line, except the options file option. The option to
>>> specify an
>>> options file is "-XX:VMOptionsFile=".
>>> The options file feature supports an options file up to 1024 bytes in
>>> size
>>> and up to 64 options.
>>>
>>> This feature has been tested on:
>>> OS:
>>> Solaris, MAC, Windows, Linux
>>> Tests:
>>> Manual unit tests
>>> JPRT with -testset hotspot (including the SQE proposed test
>>> coverage for this feature.)
>>>
>>>
>>
From dmitry.dmitriev at oracle.com Fri Jul 10 12:52:11 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 10 Jul 2015 15:52:11 +0300
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To: <559FAE4B.5060505@oracle.com>
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
<559EED17.4060109@oracle.com>
<559FAE4B.5060505@oracle.com>
Message-ID: <559FBFFB.3060206@oracle.com>
Jeremy,
Two additional comments which I didn't catch earlier...
1) Order of processing command line options is
following(Arguments::parse_vm_init_args function): options from
JAVA_TOOL_OPTIONS environment variable, then options from command line
and then options from _JAVA_OPTIONS environment variable. And last
argument wins!
You not change this order in Arguments::parse_vm_init_args function, but
it seems that order in several other places is changed.
Lines 3665-3667:
3665 match_special_option_and_act(args, &flags_file);
3666 match_special_option_and_act(&java_tool_options_args, &flags_file);
3667 match_special_option_and_act(&java_options_args, &flags_file);
Here we see that order is following: options from command line, then
options from JAVA_TOOL_OPTIONS environment variable and then options
from _JAVA_OPTIONS environment variable. Thus, in this case
"-XX:+IgnoreUnrecognizedVMOptions" option in JAVA_TOOL_OPTIONS
environment variable will have bigger priority than in command line(last
argument wins), but this is differ from processing options in
Arguments::parse_vm_init_args function. Thus, I think that you need to
swap 3665 and 3666 lines:
3665 match_special_option_and_act(&java_tool_options_args, &flags_file);
3666 match_special_option_and_act(args, &flags_file);
3667 match_special_option_and_act(&java_options_args, &flags_file);
Similar situation on lines 3696-3700:
3696 if (PrintVMOptions) {
3697 print_options(args);
3698 print_options(&java_tool_options_args);
3699 print_options(&java_options_args);
3700 }
Command line options are printed before options from JAVA_TOOL_OPTIONS
environment variable. Thus, I think that you need to swap 3697 and 3698
lines:
3696 if (PrintVMOptions) {
3697 print_options(&java_tool_options_args);
3698 print_options(args);
3699 print_options(&java_options_args);
3700 }
2) One more thing about error processing :)
I think it will be great to free allocated memory for environment
variables when error occured on lines 3661-3663, 3679-3681 and 3685-3687.
My suggestion is to add some static function which free memory for env
variables, something like that:
static void free_memory_for_environment_variables( JavaVMInitArgs
*options_args ) {
for (int i = 0; i < options_args->nOptions; i++) {
os::free(options_args->options[i].optionString);
}
FREE_C_HEAP_ARRAY(JavaVMOption, options_args->options);
}
And change lines 3661-3663 to following:
3661 if (code != JNI_OK) {
3662 free_memory_for_environment_variables(&java_tool_options_args);
3663 return code;
3664 }
Lines 3679-3681 to following:
3679 if (!process_settings_file(flags_file, true, args->ignoreUnrecognized)) {
3680 free_memory_for_environment_variables(&java_tool_options_args);
3681 free_memory_for_environment_variables(&java_options_args);
3682 return JNI_EINVAL;
3683 }
Lines 3685-3687 to following:
3685 if (!process_settings_file(".hotspotrc", false, args->ignoreUnrecognized)) {
3680 free_memory_for_environment_variables(&java_tool_options_args);
3681 free_memory_for_environment_variables(&java_options_args);
3686 return JNI_EINVAL;
3687 }
And lines 3706-3715 to following:
3706 // Done with the envvars
3707 free_memory_for_environment_variables(&java_tool_options_args);
3708 free_memory_for_environment_variables(&java_options_args);
Thank you,
Dmitry
On 10.07.2015 14:36, Dmitry Dmitriev wrote:
> Hello Jeremy,
>
> Thank you for fixing that! But in this case we still have minor issue
> when quotes processing failed(lines 3438-3444). Here is my suggestion:
> leave 'while' cycle(lines 3423-3462) as I was in your previous
> webrev(without 'start' and etc.) and call strdup when copy 'options'
> to 'options_arr' on lines 3472-3474, i.e. make lines 3472-3474 like this:
>
> 3472 for (int i = 0; i < options->length(); i++) {
> 3473 options_arr[i] = options->at(i);
> 3474 options_arr[i].optionString =
> os::strdup(options_arr[i].optionString);
> 3475 }
>
> What you think about that?
>
> Regards,
> Dmitry
>
> On 10.07.2015 3:23, Jeremy Manson wrote:
>> Hey Dmitry,
>>
>> Thanks for looking at it. The leak was deliberate (under the theory
>> that the command line flags were leaked, too), but it was silly that
>> I didn't fix it.
>>
>> Anyway, fixed. See:
>>
>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.03
>>
>>
>> Jeremy
>>
>> On Thu, Jul 9, 2015 at 2:52 PM, Dmitry Dmitriev
>> > wrote:
>>
>> Hello Jeremy,
>>
>> Correct me if I am wrong, but I see small memory leak in your
>> implementation.
>> In Arguments::parse_options_environment_variable function memory
>> for 'buffer' allocated by strdup function on line 3415, but now it
>> not freed in this function because data from this buffer is used
>> later. On the other hand when we are done with env variables, we
>> free only options array(lines 3703-3705) and not free previously
>> allocated memory for 'buffer' because we lost track for it.
>>
>> Thanks,
>> Dmitry
>>
>>
>> On 09.07.2015 21:20, Jeremy Manson wrote:
>>
>> Thanks for looking at this, Coleen.
>>
>> I merged this with the latest version of hs-rt, but Ron is or
>> I am going to
>> have to do some merging for 8061999. The changes are relatively
>> orthogonal, but they touch a couple of the same places. How
>> far away is
>> Ron's checkin?
>>
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
>>
>>
>> Updated test:
>>
>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
>>
>>
>> (Mild complaining on my part: the conflicts wouldn't have been
>> an issue if
>> someone had looked at this two months ago, when I first
>> asked. I suspect
>> Ron hadn't even started his change at that point. And if
>> external
>> developers were able to submit changes to Hotspot, we wouldn't
>> have had to
>> bother Oracle engineers at all. Neither of these is your
>> fault or your
>> problem, of course - I'm grateful you were able to take a look.)
>>
>> Jeremy
>>
>> On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
>> coleen.phillimore at oracle.com
>> > wrote:
>>
>> I'll sponsor it but can you repost the RFR?
>>
>> There has been a fair bit of work to command line
>> processing lately so I'd
>> like to have the others look at it too. Have you merged
>> this up with the
>> latest version of hs-rt repository and were there
>> conflicts? Also, have
>> you looked at the RFR:
>>
>> "Open code review for 8061999 Enhance VM option parsing to
>> allow options
>> to be specified"
>>
>> and are there conflicts with this?
>>
>> The hotspot change looks good to me.
>>
>>
>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>>
>>
>> "UseCerealGC" LOL
>> Can you use a different option than PrintOopAddress in
>> this test? I don't
>> know why this command line option exists or would be
>> useful for, and seems
>> to be a good candidate for removal. If you need a valid
>> argument, that is
>> unlikely to go away, TraceExceptions would be good.
>>
>> Thanks,
>> Coleen
>>
>>
>> On 7/7/15 8:00 PM, Jeremy Manson wrote:
>>
>> No love? Is there a code owner here I should pester
>> more directly?
>>
>> Jeremy
>>
>> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
>> >
>> wrote:
>>
>> As usual with Google patches, they are in use
>> locally. This one has been
>>
>> stable for a while without complaints. Please
>> sponsor.
>>
>> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson
>> > >
>> wrote:
>>
>> All this talk about IgnoreUnrecognizedVMOptions
>> reminded me that this
>>
>> review is still outstanding. Any takers?
>>
>> Jeremy
>>
>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson
>> >
>> wrote:
>>
>> Hi David,
>>
>> Thanks for taking a look.
>>
>> On Mon, May 4, 2015 at 8:32 PM, David
>> Holmes > >
>> wrote:
>>
>> Hi Jeremy,
>>
>> On 5/05/2015 6:51 AM, Jeremy Manson
>> wrote:
>>
>> Not sure who might be willing to
>> sponsor this. David? You did the
>>
>> last
>> one. :)
>>
>> Might be a while before I can
>> get to it. I did have a quick look
>>
>> (and
>> will need a longer one).
>>
>> I understand. I'm just happy it's
>> possible to upstream this stuff at
>> all[1].
>>
>> [1] With the eternal caveat that I'd be
>> happier if we didn't *have* to
>> go through you folks, but we've learned to
>> live with it.
>>
>>
>>
>> Context: A number of command line
>> options are not settable via
>>
>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>
>> - PrintVMOptions
>>
>> So you have changed the
>> semantics of this to print out the
>> options
>>
>> from
>> the command-line and each of the two
>> env vars. Seems reasonable but
>> may be
>> better to know which option came from
>> where as we can now see the same
>> option (or conflicting variants
>> thereof) multiple times.
>>
>> I'd be happy to do this. Any
>> preferred syntax? Does someone
>>
>> actually
>> own this feature?
>>
>> I'm unclear what the current processing
>> order is for the different
>>
>> sources of options, and whether the
>> changes affect that order?
>>
>> Nope. I go through sad contortions
>> to keep the processing order the
>>
>> same. It's JAVA_TOOL_OPTIONS, then
>> command line, then _JAVA_OPTIONS.
>> See
>> lines 2549-2567.
>>
>>
>> - IgnoreUnrecognizedVMOptions
>>
>> - PrintFlagsInitial
>>
>> Unclear what "initial" actually
>> means - is it the default?
>>
>> More or less. If you stick, for example,
>> IgnoreUnrecognizedVMOptions
>> in
>> there first, it will get printed out as
>> "true". I haven't really
>> changed
>> the semantics here either - I've just
>> added processing of the envvars.
>>
>> - NativeMemoryTracking
>>
>> - PrintFlagsWithComments
>>
>> This is because these flags have
>> to be processed before processing
>> other
>> flags, and no one ever bothered to
>> do that for the flags coming from
>> environment variables. This patch
>> fixes that problem.
>>
>> I have a test, but it is a
>> modification to a JDK test instead
>> of a HS
>> test,
>> so it can go in separately (I
>> guess).
>>
>> They can be pushed together to
>> different repos in the same forest.
>>
>> Okay. Here's the test change:
>>
>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>
>>
>>
>> As I said I'll have to get back to this.
>> And hopefully someone else in
>>
>> runtime will take a good look as well
>> ;-)
>>
>> I'd be happy to toss it over to
>> whomever owns this, if anyone.
>>
>> Thanks!
>>
>> Jeremy
>>
>>
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>
>>
>> Jeremy
>>
>>
>>
>>
>>
>
From mikhailo.seledtsov at oracle.com Fri Jul 10 16:33:58 2015
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Fri, 10 Jul 2015 09:33:58 -0700
Subject: RFR: 8025692: Add trace to find out what methods are used at
runtime.
In-Reply-To: <559F4B5B.60203@oracle.com>
References: <5514C1CB.7020009@oracle.com>
<55711388.4090402@oracle.com>
<559F4B5B.60203@oracle.com>
Message-ID: <559FF3F6.7060400@oracle.com>
It is a known issue with Aurora; the RBT jobs get stuck on Win-x64.
The fix's ETA is on 13-July during next Aurora patch deployemnt.
You could still check status of testing on jobs that complete:
- go to your main RBT status for your job (e.g.
http://sla03.se.oracle.com:3000/rbt/rbt-mikhailo.seledtsov-hs-rt-20150709-1543-2147)
For overall status, just see the summary under "Test Failures" tab
For details on particular failures, do:
- Under "Test Progress"-> x of Y jobs succeeded, click the "wheel"
symbol -> Main
- this will lead you to your Aurora main jobs page
- there, you could click "Go to batch results", see a table of new
failures, and look into them in detail
Hope this helps,
Misha
On 7/9/2015 9:34 PM, Yumin Qi wrote:
> Hi, Karen
>
> Just informed you that RBT testing for quick testing seems will not
> get back a completed result(I have tried several times those days).
> After 11 hours, there still 4 jobs running:
>
> 26 of 34 succeeded, 4 failed, 4 still running.
>
> Those running jobs already run at least 6+ hours.
> The 4 failed jobs are dtrace on linux-x64 which are OK, since
> dtrace is disabled on it.
>
> Also, I added -Xint to test case, and tested with jtreg on
> test/runtime showed no new failures found.
> I am going to push the changes if you are OK with current result.
> Seems the testing with RBT will never come back. Updated webrev:
>
> http://cr.openjdk.java.net/~minqi/8025692/webrev02/
>
> Thanks
> Yumin
>
> On 6/18/2015 1:01 PM, Karen Kinnear wrote:
>> Yumin,
>>
>> Thank you very much for the updates.And the PERM_REFCOUNT rather than
>> -1 :-)
>> Looks good.
>>
>> Thank you for testing this -Xint. If there is an easy way to add an
>> -Xint line
>> to the test that would be useful - but not critical.
>>
>> So I presume that the "aurora default test suites" includes:
>> jcks, jtreg hotspot and Christian's new "quick" tests.
>>
>> thanks,
>> Karen
>>
>> On Jun 4, 2015, at 11:12 PM, Yumin Qi wrote:
>>
>>> HI, All
>>>
>>> After several round of codereviews and discussion, now the second
>>> version is at:
>>> http://cr.openjdk.java.net/~minqi/8025692/webrev02/
>>>
>>> The flag names changed:
>>>
>>> TraceMethodUsge => LogTouchedMethods
>>> PrintMethodUsageAtExit => PrintTouchedMethodsAtExit
>>>
>>> The two flags now are diagnostic flags.
>>>
>>> Also similar, there changed in related variable names.
>>> Also fixed a flaw which is not found during last round of review:
>>> append new TouchedMethodRecord to end of hash bucket list.
>>>
>>> Make change to interpreter method entry generation(for both
>>> native and normal) to enable build_method_counter called. This is
>>> necessary since if run -Xint, the call will be skipped so our code
>>> will be skipped so no logging for touched methods.
>>>
>>> Added test case for jcmd: jcmd VM.print_touched_methods.
>>>
>>> Tests: JPRT, aurora default test suites (in progress).
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 3/26/2015 7:34 PM, Yumin Qi wrote:
>>>> Please review:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025692
>>>> webrev: http://cr.openjdk.java.net/~minqi/8025692/webrev01/
>>>>
>>>> Summary: Add two flags to help list all java methods called in
>>>> runtime, this is also in product and can help CDS to rearrange
>>>> methods in shared archive to avoid loading infrequent methods into
>>>> memory.
>>>>
>>>> Tests: vm.runtime.quick.testlist, JPRT
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>
From jeremymanson at google.com Fri Jul 10 17:15:19 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 10 Jul 2015 10:15:19 -0700
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To: <559FBFFB.3060206@oracle.com>
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
<559EED17.4060109@oracle.com>
<559FAE4B.5060505@oracle.com> <559FBFFB.3060206@oracle.com>
Message-ID:
Thanks for the detailed look, Dmitry. I have taken your advice, with a
couple of exceptions:
1) I named the method free_memory_for_vm_init_args instead
of free_memory_for_environment_variables.
2) I did not free the memory in 3661-3663 or in 3679-3681, because those
are error paths where the memory may not have been allocated in the first
place. So freeing it might lead to a crash.
New Rev:
http://cr.openjdk.java.net/~jmanson/8079301/webrev.04/
Jeremy
On Fri, Jul 10, 2015 at 5:52 AM, Dmitry Dmitriev wrote:
> Jeremy,
>
> Two additional comments which I didn't catch earlier...
>
> 1) Order of processing command line options is
> following(Arguments::parse_vm_init_args function): options from
> JAVA_TOOL_OPTIONS environment variable, then options from command line and
> then options from _JAVA_OPTIONS environment variable. And last argument
> wins!
>
> You not change this order in Arguments::parse_vm_init_args function, but
> it seems that order in several other places is changed.
>
> Lines 3665-3667:
>
> 3665 match_special_option_and_act(args, &flags_file);
> 3666 match_special_option_and_act(&java_tool_options_args, &flags_file);
> 3667 match_special_option_and_act(&java_options_args, &flags_file);
>
> Here we see that order is following: options from command line, then
> options from JAVA_TOOL_OPTIONS environment variable and then options from
> _JAVA_OPTIONS environment variable. Thus, in this case
> "-XX:+IgnoreUnrecognizedVMOptions" option in JAVA_TOOL_OPTIONS environment
> variable will have bigger priority than in command line(last argument
> wins), but this is differ from processing options in
> Arguments::parse_vm_init_args function. Thus, I think that you need to swap
> 3665 and 3666 lines:
>
> 3665 match_special_option_and_act(&java_tool_options_args, &flags_file);
> 3666 match_special_option_and_act(args, &flags_file);
> 3667 match_special_option_and_act(&java_options_args, &flags_file);
>
> Similar situation on lines 3696-3700:
>
> 3696 if (PrintVMOptions) {
> 3697 print_options(args);
> 3698 print_options(&java_tool_options_args);
> 3699 print_options(&java_options_args);
> 3700 }
>
> Command line options are printed before options from JAVA_TOOL_OPTIONS
> environment variable. Thus, I think that you need to swap 3697 and 3698
> lines:
>
> 3696 if (PrintVMOptions) {
> 3697 print_options(&java_tool_options_args);
> 3698 print_options(args);
> 3699 print_options(&java_options_args);
> 3700 }
>
>
> 2) One more thing about error processing :)
> I think it will be great to free allocated memory for environment
> variables when error occured on lines 3661-3663, 3679-3681 and 3685-3687.
> My suggestion is to add some static function which free memory for env
> variables, something like that:
> static void free_memory_for_environment_variables( JavaVMInitArgs
> *options_args ) {
> for (int i = 0; i < options_args->nOptions; i++) {
> os::free(options_args->options[i].optionString);
> }
> FREE_C_HEAP_ARRAY(JavaVMOption, options_args->options);
> }
>
> And change lines 3661-3663 to following:
>
> 3661 if (code != JNI_OK) {
> 3662 free_memory_for_environment_variables(&java_tool_options_args);
> 3663 return code;
> 3664 }
>
> Lines 3679-3681 to following:
>
> 3679 if (!process_settings_file(flags_file, true,
> args->ignoreUnrecognized)) {
> 3680 free_memory_for_environment_variables(&java_tool_options_args);
> 3681 free_memory_for_environment_variables(&java_options_args);
> 3682 return JNI_EINVAL;
> 3683 }
>
> Lines 3685-3687 to following:
>
> 3685 if (!process_settings_file(".hotspotrc", false,
> args->ignoreUnrecognized)) {
> 3680 free_memory_for_environment_variables(&java_tool_options_args);
> 3681 free_memory_for_environment_variables(&java_options_args);
> 3686 return JNI_EINVAL;
> 3687 }
>
> And lines 3706-3715 to following:
>
> 3706 // Done with the envvars
> 3707 free_memory_for_environment_variables(&java_tool_options_args);
> 3708 free_memory_for_environment_variables(&java_options_args);
>
>
> Thank you,
> Dmitry
>
>
> On 10.07.2015 14:36, Dmitry Dmitriev wrote:
>
>> Hello Jeremy,
>>
>> Thank you for fixing that! But in this case we still have minor issue
>> when quotes processing failed(lines 3438-3444). Here is my suggestion:
>> leave 'while' cycle(lines 3423-3462) as I was in your previous
>> webrev(without 'start' and etc.) and call strdup when copy 'options' to
>> 'options_arr' on lines 3472-3474, i.e. make lines 3472-3474 like this:
>>
>> 3472 for (int i = 0; i < options->length(); i++) {
>> 3473 options_arr[i] = options->at(i);
>> 3474 options_arr[i].optionString =
>> os::strdup(options_arr[i].optionString);
>> 3475 }
>>
>> What you think about that?
>>
>> Regards,
>> Dmitry
>>
>> On 10.07.2015 3:23, Jeremy Manson wrote:
>>
>>> Hey Dmitry,
>>>
>>> Thanks for looking at it. The leak was deliberate (under the theory
>>> that the command line flags were leaked, too), but it was silly that I
>>> didn't fix it.
>>>
>>> Anyway, fixed. See:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.03 <
>>> http://cr.openjdk.java.net/%7Ejmanson/8079301/webrev.03>
>>>
>>> Jeremy
>>>
>>> On Thu, Jul 9, 2015 at 2:52 PM, Dmitry Dmitriev <
>>> dmitry.dmitriev at oracle.com > wrote:
>>>
>>> Hello Jeremy,
>>>
>>> Correct me if I am wrong, but I see small memory leak in your
>>> implementation.
>>> In Arguments::parse_options_environment_variable function memory
>>> for 'buffer' allocated by strdup function on line 3415, but now it
>>> not freed in this function because data from this buffer is used
>>> later. On the other hand when we are done with env variables, we
>>> free only options array(lines 3703-3705) and not free previously
>>> allocated memory for 'buffer' because we lost track for it.
>>>
>>> Thanks,
>>> Dmitry
>>>
>>>
>>> On 09.07.2015 21:20, Jeremy Manson wrote:
>>>
>>> Thanks for looking at this, Coleen.
>>>
>>> I merged this with the latest version of hs-rt, but Ron is or
>>> I am going to
>>> have to do some merging for 8061999. The changes are relatively
>>> orthogonal, but they touch a couple of the same places. How
>>> far away is
>>> Ron's checkin?
>>>
>>> Updated webrev:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
>>>
>>>
>>> Updated test:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
>>>
>>>
>>> (Mild complaining on my part: the conflicts wouldn't have been
>>> an issue if
>>> someone had looked at this two months ago, when I first
>>> asked. I suspect
>>> Ron hadn't even started his change at that point. And if
>>> external
>>> developers were able to submit changes to Hotspot, we wouldn't
>>> have had to
>>> bother Oracle engineers at all. Neither of these is your
>>> fault or your
>>> problem, of course - I'm grateful you were able to take a look.)
>>>
>>> Jeremy
>>>
>>> On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
>>> coleen.phillimore at oracle.com
>>> > wrote:
>>>
>>> I'll sponsor it but can you repost the RFR?
>>>
>>> There has been a fair bit of work to command line
>>> processing lately so I'd
>>> like to have the others look at it too. Have you merged
>>> this up with the
>>> latest version of hs-rt repository and were there
>>> conflicts? Also, have
>>> you looked at the RFR:
>>>
>>> "Open code review for 8061999 Enhance VM option parsing to
>>> allow options
>>> to be specified"
>>>
>>> and are there conflicts with this?
>>>
>>> The hotspot change looks good to me.
>>>
>>>
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>>> <
>>> http://cr.openjdk.java.net/%7Ejmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>>> >
>>>
>>> "UseCerealGC" LOL
>>> Can you use a different option than PrintOopAddress in
>>> this test? I don't
>>> know why this command line option exists or would be
>>> useful for, and seems
>>> to be a good candidate for removal. If you need a valid
>>> argument, that is
>>> unlikely to go away, TraceExceptions would be good.
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>> On 7/7/15 8:00 PM, Jeremy Manson wrote:
>>>
>>> No love? Is there a code owner here I should pester
>>> more directly?
>>>
>>> Jeremy
>>>
>>> On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz
>>> >
>>> wrote:
>>>
>>> As usual with Google patches, they are in use
>>> locally. This one has been
>>>
>>> stable for a while without complaints. Please
>>> sponsor.
>>>
>>> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson
>>> >> >
>>> wrote:
>>>
>>> All this talk about IgnoreUnrecognizedVMOptions
>>> reminded me that this
>>>
>>> review is still outstanding. Any takers?
>>>
>>> Jeremy
>>>
>>> On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson
>>> >>
>>> wrote:
>>>
>>> Hi David,
>>>
>>> Thanks for taking a look.
>>>
>>> On Mon, May 4, 2015 at 8:32 PM, David
>>> Holmes >> >
>>>
>>> wrote:
>>>
>>> Hi Jeremy,
>>>
>>> On 5/05/2015 6:51 AM, Jeremy Manson
>>> wrote:
>>>
>>> Not sure who might be willing to
>>> sponsor this. David? You did the
>>>
>>> last
>>> one. :)
>>>
>>> Might be a while before I can
>>> get to it. I did have a quick look
>>>
>>> (and
>>> will need a longer one).
>>>
>>> I understand. I'm just happy it's
>>> possible to upstream this stuff at
>>> all[1].
>>>
>>> [1] With the eternal caveat that I'd be
>>> happier if we didn't *have* to
>>> go through you folks, but we've learned to
>>> live with it.
>>>
>>>
>>>
>>> Context: A number of command line
>>> options are not settable via
>>>
>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>
>>> - PrintVMOptions
>>>
>>> So you have changed the
>>> semantics of this to print out the
>>> options
>>>
>>> from
>>> the command-line and each of the two
>>> env vars. Seems reasonable but
>>> may be
>>> better to know which option came from
>>> where as we can now see the same
>>> option (or conflicting variants
>>> thereof) multiple times.
>>>
>>> I'd be happy to do this. Any
>>> preferred syntax? Does someone
>>>
>>> actually
>>> own this feature?
>>>
>>> I'm unclear what the current processing
>>> order is for the different
>>>
>>> sources of options, and whether the
>>> changes affect that order?
>>>
>>> Nope. I go through sad contortions
>>> to keep the processing order the
>>>
>>> same. It's JAVA_TOOL_OPTIONS, then
>>> command line, then _JAVA_OPTIONS.
>>> See
>>> lines 2549-2567.
>>>
>>>
>>> - IgnoreUnrecognizedVMOptions
>>>
>>> - PrintFlagsInitial
>>>
>>> Unclear what "initial" actually
>>> means - is it the default?
>>>
>>> More or less. If you stick, for example,
>>> IgnoreUnrecognizedVMOptions
>>> in
>>> there first, it will get printed out as
>>> "true". I haven't really
>>> changed
>>> the semantics here either - I've just
>>> added processing of the envvars.
>>>
>>> - NativeMemoryTracking
>>>
>>> - PrintFlagsWithComments
>>>
>>> This is because these flags have
>>> to be processed before processing
>>> other
>>> flags, and no one ever bothered to
>>> do that for the flags coming from
>>> environment variables. This patch
>>> fixes that problem.
>>>
>>> I have a test, but it is a
>>> modification to a JDK test instead
>>> of a HS
>>> test,
>>> so it can go in separately (I guess).
>>>
>>> They can be pushed together to
>>> different repos in the same forest.
>>>
>>> Okay. Here's the test change:
>>>
>>> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>>>
>>>
>>>
>>> As I said I'll have to get back to this.
>>> And hopefully someone else in
>>>
>>> runtime will take a good look as well ;-)
>>>
>>> I'd be happy to toss it over to
>>> whomever owns this, if anyone.
>>>
>>> Thanks!
>>>
>>> Jeremy
>>>
>>>
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>
>>>
>>> Jeremy
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
From jeremymanson at google.com Fri Jul 10 17:16:14 2015
From: jeremymanson at google.com (Jeremy Manson)
Date: Fri, 10 Jul 2015 10:16:14 -0700
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To: <559F6BE3.9080002@oracle.com>
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
<559EED17.4060109@oracle.com>
<559F6BE3.9080002@oracle.com>
Message-ID:
On Thu, Jul 9, 2015 at 11:53 PM, David Holmes
wrote:
> Hi Jeremy,
>
> On 10/07/2015 10:23 AM, Jeremy Manson wrote:
>
>> Hey Dmitry,
>>
>> Thanks for looking at it. The leak was deliberate (under the theory that
>> the command line flags were leaked, too), but it was silly that I didn't
>> fix it.
>>
>> Anyway, fixed. See:
>>
>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.03
>>
>
> I'm not sure you've changed anything in this regard but it seems to me to
> me that if -XX:Flags=flags-file is specified on the command-line, and the
> environment variable(s) then the last setting wins - which would be the
> _JAVA_OPTIONS setting.
>
> Or maybe that is the way this whole thing works ie last setting wins?
Yep - last setting is supposed to win. I tried to keep the behavior
consistent with what was there for the other flags.
Jeremy
From derek.white at oracle.com Fri Jul 10 15:40:30 2015
From: derek.white at oracle.com (Derek White)
Date: Fri, 10 Jul 2015 11:40:30 -0400
Subject: Runtime command-line deprecation (Was Re: RFR: 8066821(S) Enhance
command line processing to manage deprecating and obsoleting -XX
command line arguments
In-Reply-To: <559AEC80.3010907@oracle.com>
References: <54B44661.8070007@oracle.com> <54B84E91.1050708@oracle.com>
<54D15A0B.6030501@oracle.com>
<87B07B03-3423-4738-9617-0C7B72A74A6E@oracle.com>
<559AEC80.3010907@oracle.com>
Message-ID: <559FE76E.2060009@oracle.com>
Hi Karen, Coleen,
FYI - I'm getting back to this (was waiting for Gerard's big change).
Once I have this merged and tested I'll send it out for review sometime
next week. To the right alias this time :-)
- Derek
On 7/6/15 5:00 PM, Coleen Phillimore wrote:
>
> Hi,
>
> I'm happy for more clarity in the process of removing command line
> arguments. I have some questions and comments below.
>
> On 6/26/15 4:09 PM, Karen Kinnear wrote:
>> Derek,
>>
>> ...
> So this is my question which is around the code review in question.
> Note, Derek, can you resend the RFR to hotspot-dev at openjdk.java.net so
> it gets to all of us (even the compiler team may want to share in the
> mechanism).
From dmitry.dmitriev at oracle.com Fri Jul 10 18:40:04 2015
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 10 Jul 2015 21:40:04 +0300
Subject: RFR: 8079301: Some command line options not settable via
JAVA_TOOL_OPTIONS
In-Reply-To:
References:
<554839B4.3020800@oracle.com>
<559D237C.2060702@oracle.com>
<559EED17.4060109@oracle.com>
<559FAE4B.5060505@oracle.com> <559FBFFB.3060206@oracle.com>
Message-ID: <55A01184.7080102@oracle.com>
Jeremy, thank you for fixing that! Please, see my comments inline for 2
item and one more comment.
On 10.07.2015 20:15, Jeremy Manson wrote:
> Thanks for the detailed look, Dmitry. I have taken your advice, with
> a couple of exceptions:
>
> 1) I named the method free_memory_for_vm_init_args instead
> of free_memory_for_environment_variables.
> 2) I did not free the memory in 3661-3663 or in 3679-3681, because
> those are error paths where the memory may not have been allocated in
> the first place. So freeing it might lead to a crash.
Yes, you are right. But I think we can guard from this by adding check
for args->options in new free_memory_for_vm_init_args function and free
memory in all execution paths. If args->options is not NULL, then memory
is allocated and must be freed:
3485 static void free_memory_for_vm_init_args(JavaVMInitArgs* args) {
3486 if( args->options != NULL ) {
3487 for (int i = 0; i < args->nOptions; i++) {
3488 os::free(args->options[i].optionString);
3489 }
3490 FREE_C_HEAP_ARRAY(JavaVMOption, args->options);
3491 }
3492 }
As I see you add free memory for error paths at lines(webrev.04)
3668-3671 and 3687-3691. Thus, with that guard you can add two calls to
free_memory_for_vm_init_args function before "return JNI_EINVAL;" on
line 3696:
3693 #ifdef ASSERT
3694 // Parse default .hotspotrc settings file
3695 if (!process_settings_file(".hotspotrc", false, args->ignoreUnrecognized)) {
3696 return JNI_EINVAL;
3697 }
3698 #else
And one more comment. Unfortunately I oversight this before... You not
check return value from 'match_special_option_and_act' new function on
lines 3673-3675, but in one case it can return error(JNI_ERR) when
"-XX:NativeMemoryTracking" is specified and INCLUDE_NMT is not defined.
Thus, I think that check for return value should be added(with freeing
memory for env variables in case of error).
Thank you,
Dmitry
>
> New Rev:
>
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.04/
>
>
> Jeremy
>
> On Fri, Jul 10, 2015 at 5:52 AM, Dmitry Dmitriev
> > wrote:
>
> Jeremy,
>
> Two additional comments which I didn't catch earlier...
>
> 1) Order of processing command line options is
> following(Arguments::parse_vm_init_args function): options from
> JAVA_TOOL_OPTIONS environment variable, then options from command
> line and then options from _JAVA_OPTIONS environment variable. And
> last argument wins!
>
> You not change this order in Arguments::parse_vm_init_args
> function, but it seems that order in several other places is changed.
>
> Lines 3665-3667:
>
> 3665 match_special_option_and_act(args, &flags_file);
> 3666 match_special_option_and_act(&java_tool_options_args,
> &flags_file);
> 3667 match_special_option_and_act(&java_options_args, &flags_file);
>
> Here we see that order is following: options from command line,
> then options from JAVA_TOOL_OPTIONS environment variable and then
> options from _JAVA_OPTIONS environment variable. Thus, in this
> case "-XX:+IgnoreUnrecognizedVMOptions" option in
> JAVA_TOOL_OPTIONS environment variable will have bigger priority
> than in command line(last argument wins), but this is differ from
> processing options in Arguments::parse_vm_init_args function.
> Thus, I think that you need to swap 3665 and 3666 lines:
>
> 3665 match_special_option_and_act(&java_tool_options_args,
> &flags_file);
> 3666 match_special_option_and_act(args, &flags_file);
> 3667 match_special_option_and_act(&java_options_args, &flags_file);
>
> Similar situation on lines 3696-3700:
>
> 3696 if (PrintVMOptions) {
> 3697 print_options(args);
> 3698 print_options(&java_tool_options_args);
> 3699 print_options(&java_options_args);
> 3700 }
>
> Command line options are printed before options from
> JAVA_TOOL_OPTIONS environment variable. Thus, I think that you
> need to swap 3697 and 3698 lines:
>
> 3696 if (PrintVMOptions) {
> 3697 print_options(&java_tool_options_args);
> 3698 print_options(args);
> 3699 print_options(&java_options_args);
> 3700 }
>
>
> 2) One more thing about error processing :)
> I think it will be great to free allocated memory for environment
> variables when error occured on lines 3661-3663, 3679-3681 and
> 3685-3687.
> My suggestion is to add some static function which free memory for
> env variables, something like that:
> static void free_memory_for_environment_variables( JavaVMInitArgs
> *options_args ) {
> for (int i = 0; i < options_args->nOptions; i++) {
> os::free(options_args->options[i].optionString);
> }
> FREE_C_HEAP_ARRAY(JavaVMOption, options_args->options);
> }
>
> And change lines 3661-3663 to following:
>
> 3661 if (code != JNI_OK) {
> 3662 free_memory_for_environment_variables(&java_tool_options_args);
> 3663 return code;
> 3664 }
>
> Lines 3679-3681 to following:
>
> 3679 if (!process_settings_file(flags_file, true,
> args->ignoreUnrecognized)) {
> 3680 free_memory_for_environment_variables(&java_tool_options_args);
> 3681 free_memory_for_environment_variables(&java_options_args);
> 3682 return JNI_EINVAL;
> 3683 }
>
> Lines 3685-3687 to following:
>
> 3685 if (!process_settings_file(".hotspotrc", false,
> args->ignoreUnrecognized)) {
> 3680 free_memory_for_environment_variables(&java_tool_options_args);
> 3681 free_memory_for_environment_variables(&java_options_args);
> 3686 return JNI_EINVAL;
> 3687 }
>
> And lines 3706-3715 to following:
>
> 3706 // Done with the envvars
> 3707 free_memory_for_environment_variables(&java_tool_options_args);
> 3708 free_memory_for_environment_variables(&java_options_args);
>
>
> Thank you,
> Dmitry
>
>
> On 10.07.2015 14:36, Dmitry Dmitriev wrote:
>
> Hello Jeremy,
>
> Thank you for fixing that! But in this case we still have
> minor issue when quotes processing failed(lines 3438-3444).
> Here is my suggestion: leave 'while' cycle(lines 3423-3462) as
> I was in your previous webrev(without 'start' and etc.) and
> call strdup when copy 'options' to 'options_arr' on lines
> 3472-3474, i.e. make lines 3472-3474 like this:
>
> 3472 for (int i = 0; i < options->length(); i++) {
> 3473 options_arr[i] = options->at(i);
> 3474 options_arr[i].optionString =
> os::strdup(options_arr[i].optionString);
> 3475 }
>
> What you think about that?
>
> Regards,
> Dmitry
>
> On 10.07.2015 3:23, Jeremy Manson wrote:
>
> Hey Dmitry,
>
> Thanks for looking at it. The leak was deliberate (under
> the theory that the command line flags were leaked, too),
> but it was silly that I didn't fix it.
>
> Anyway, fixed. See:
>
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.03
>
>
>
> Jeremy
>
> On Thu, Jul 9, 2015 at 2:52 PM, Dmitry Dmitriev
>
> >> wrote:
>
> Hello Jeremy,
>
> Correct me if I am wrong, but I see small memory leak
> in your
> implementation.
> In Arguments::parse_options_environment_variable
> function memory
> for 'buffer' allocated by strdup function on line
> 3415, but now it
> not freed in this function because data from this
> buffer is used
> later. On the other hand when we are done with env
> variables, we
> free only options array(lines 3703-3705) and not free
> previously
> allocated memory for 'buffer' because we lost track
> for it.
>
> Thanks,
> Dmitry
>
>
> On 09.07.2015 21:20, Jeremy Manson wrote:
>
> Thanks for looking at this, Coleen.
>
> I merged this with the latest version of hs-rt,
> but Ron is or
> I am going to
> have to do some merging for 8061999. The changes
> are relatively
> orthogonal, but they touch a couple of the same
> places. How
> far away is
> Ron's checkin?
>
> Updated webrev:
>
> http://cr.openjdk.java.net/~jmanson/8079301/webrev.01/
>
>
>
> Updated test:
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.01/
>
>
>
> (Mild complaining on my part: the conflicts
> wouldn't have been
> an issue if
> someone had looked at this two months ago, when I
> first
> asked. I suspect
> Ron hadn't even started his change at that point.
> And if external
> developers were able to submit changes to Hotspot,
> we wouldn't
> have had to
> bother Oracle engineers at all. Neither of these
> is your
> fault or your
> problem, of course - I'm grateful you were able to
> take a look.)
>
> Jeremy
>
> On Wed, Jul 8, 2015 at 6:19 AM, Coleen Phillimore <
> coleen.phillimore at oracle.com
>
> >> wrote:
>
> I'll sponsor it but can you repost the RFR?
>
> There has been a fair bit of work to command line
> processing lately so I'd
> like to have the others look at it too. Have
> you merged
> this up with the
> latest version of hs-rt repository and were there
> conflicts? Also, have
> you looked at the RFR:
>
> "Open code review for 8061999 Enhance VM
> option parsing to
> allow options
> to be specified"
>
> and are there conflicts with this?
>
> The hotspot change looks good to me.
>
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/test/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java.udiff.html
>
>