From david.holmes at oracle.com Tue Apr 1 05:46:19 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 01 Apr 2014 15:46:19 +1000
Subject: RFR (M): JDK-8038587: [TESTBUG] Create CDS tests to exercise
region sizes and classlist
In-Reply-To: <53347D4C.4070406@oracle.com>
References: <53347D4C.4070406@oracle.com>
Message-ID: <533A52AB.9010401@oracle.com>
Hi Misha,
On 28/03/2014 5:34 AM, Mikhailo Seledtsov wrote:
> Please review these 3 new CDS tests, an ongoing effort in implementation
> of the CDS test specification.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8038587
> Webrev: http://cr.openjdk.java.net/~mseledtsov/8038587/webrev.00/
> Testing:
> Local testing on multiple platforms
> JPRT to exercise the added tests:
> 2014-03-27-184953.mseledtsov.cds (PASS)
> These tests found 2 bugs, and one potential issue
I don't quite get the point of the ClassListExerciser test. The
classlist may well contain classes that do not exist, or that can not be
instantiated in the test context, even if they have a no-arg
constructor. Simply creating an archive "exercises" the classlist, so
I'm really not sure what this test is intending to test.
Also this test won't work with SE Embedded as we have a customized
default classlist for the Embedded stack.
Thanks,
David
> Thank you,
> Misha
From david.holmes at oracle.com Tue Apr 1 06:27:32 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 01 Apr 2014 16:27:32 +1000
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <53395EB7.1000108@oracle.com>
References: <53395EB7.1000108@oracle.com>
Message-ID: <533A5C54.9010403@oracle.com>
Hi Fred,
This looks okay to me. Great to see so much red :) Probably worth
mentioning to other readers that you're going to re-examine the use of
yield_all() in the future.
Minor nit in os_solaris.cpp:
void os::yield_all() {
// Yields to all threads, including threads with lower priorities
os::sleep(Thread::current(), 1, false);
}
the indent for sleep needs to be 4 spaces less now.
Thanks,
David
On 31/03/2014 10:25 PM, frederic parain wrote:
> Greetings,
>
> Back in Solaris 8 days, the JVM used a thread library
> called T1. In Solaris 9, a new thread library, called T2,
> was added to Solaris. The JVM code was extended to be able
> to use either the T1 libthread or the T2 libthread.
> Since Solaris 10, T2 is the default thread library and the
> T1 libthread is not part of Solaris anymore, all its APIs
> are wrappers around T2 APIs. This changeset removes the
> support for the T1 libthread and the workarounds put in
> VM code to deal with some T1 issues.
>
> Note: the minimal requirement for JDK9 is Solaris 10u9.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038473
>
> Webrev:
> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>
> Thank you,
>
> Fred
>
From frederic.parain at oracle.com Tue Apr 1 09:00:34 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 01 Apr 2014 11:00:34 +0200
Subject: RFR (XXS) 8037295: Add size_t versions of Atomic::add, dec, and
inc
In-Reply-To: <53329507.3080003@oracle.com>
References: <53329507.3080003@oracle.com>
Message-ID: <533A8032.1050304@oracle.com>
Looks good to me.
Fred
On 03/26/2014 09:51 AM, David Simms wrote:
> Gidday,
>
> Some folks have requested size_t type variants of Atomic add, dec and
> inc; to save on messy looking casts or using an inappropriate type.
>
> Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-8037295
>
> Webrev: http://cr.openjdk.java.net/~dsimms/8037295/
>
>
> Have searched for existing cases, most looked like a potential change in
> type size or requiring const (still needs cast), except for
> heapRegionRemSet.hpp where size_t was clearly the intended type.
>
> Testing: hotspot jtreg tests and "quick test list".
>
> Cheers
> /David Simms
>
>
>
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From frederic.parain at oracle.com Tue Apr 1 09:04:50 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 01 Apr 2014 11:04:50 +0200
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <533A5C54.9010403@oracle.com>
References: <53395EB7.1000108@oracle.com> <533A5C54.9010403@oracle.com>
Message-ID: <533A8132.8010908@oracle.com>
Hi David,
Thank you for the review, the indentation is now fixed:
http://cr.openjdk.java.net/~fparain/8038473/webrev.01/
Regards,
Fred
On 04/01/2014 08:27 AM, David Holmes wrote:
> Hi Fred,
>
> This looks okay to me. Great to see so much red :) Probably worth
> mentioning to other readers that you're going to re-examine the use of
> yield_all() in the future.
>
> Minor nit in os_solaris.cpp:
>
> void os::yield_all() {
> // Yields to all threads, including threads with lower priorities
> os::sleep(Thread::current(), 1, false);
> }
>
> the indent for sleep needs to be 4 spaces less now.
>
> Thanks,
> David
>
> On 31/03/2014 10:25 PM, frederic parain wrote:
>> Greetings,
>>
>> Back in Solaris 8 days, the JVM used a thread library
>> called T1. In Solaris 9, a new thread library, called T2,
>> was added to Solaris. The JVM code was extended to be able
>> to use either the T1 libthread or the T2 libthread.
>> Since Solaris 10, T2 is the default thread library and the
>> T1 libthread is not part of Solaris anymore, all its APIs
>> are wrappers around T2 APIs. This changeset removes the
>> support for the T1 libthread and the workarounds put in
>> VM code to deal with some T1 issues.
>>
>> Note: the minimal requirement for JDK9 is Solaris 10u9.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8038473
>>
>> Webrev:
>> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>>
>> Thank you,
>>
>> Fred
>>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From coleen.phillimore at oracle.com Tue Apr 1 18:03:24 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 01 Apr 2014 14:03:24 -0400
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <53395EB7.1000108@oracle.com>
References: <53395EB7.1000108@oracle.com>
Message-ID: <533AFF6C.8020603@oracle.com>
Frederic,
This looks really nice.
Thanks!
Coleen
On 03/31/2014 08:25 AM, frederic parain wrote:
> Greetings,
>
> Back in Solaris 8 days, the JVM used a thread library
> called T1. In Solaris 9, a new thread library, called T2,
> was added to Solaris. The JVM code was extended to be able
> to use either the T1 libthread or the T2 libthread.
> Since Solaris 10, T2 is the default thread library and the
> T1 libthread is not part of Solaris anymore, all its APIs
> are wrappers around T2 APIs. This changeset removes the
> support for the T1 libthread and the workarounds put in
> VM code to deal with some T1 issues.
>
> Note: the minimal requirement for JDK9 is Solaris 10u9.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038473
>
> Webrev:
> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>
> Thank you,
>
> Fred
>
From karen.kinnear at oracle.com Tue Apr 1 19:02:05 2014
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Tue, 1 Apr 2014 15:02:05 -0400
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <53395EB7.1000108@oracle.com>
References: <53395EB7.1000108@oracle.com>
Message-ID: <314C243A-805C-4926-99BF-E5C1CC13227F@oracle.com>
Looks good.
Thank you Frederic, for all the careful work.
thanks,
Karen
On Mar 31, 2014, at 8:25 AM, frederic parain wrote:
> Greetings,
>
> Back in Solaris 8 days, the JVM used a thread library
> called T1. In Solaris 9, a new thread library, called T2,
> was added to Solaris. The JVM code was extended to be able
> to use either the T1 libthread or the T2 libthread.
> Since Solaris 10, T2 is the default thread library and the
> T1 libthread is not part of Solaris anymore, all its APIs
> are wrappers around T2 APIs. This changeset removes the
> support for the T1 libthread and the workarounds put in
> VM code to deal with some T1 issues.
>
> Note: the minimal requirement for JDK9 is Solaris 10u9.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8038473
>
> Webrev:
> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>
> Thank you,
>
> Fred
>
> --
> Frederic Parain - Oracle
> Grenoble Engineering Center - France
> Phone: +33 4 76 18 81 17
> Email: Frederic.Parain at oracle.com
From christian.tornqvist at oracle.com Tue Apr 1 20:25:02 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 1 Apr 2014 16:25:02 -0400
Subject: RFR(XXS): [TESTBUG] vmerrors.sh should suppress windows .mdmp files
Message-ID: <047201cf4de8$765c36e0$6314a4a0$@oracle.com>
Hi everyone,
Very small fix that disables dumps from being generated on Windows when
running vmerror.sh. Tested locally on Windows and test execution time went
from 25 to 5 seconds (plus we're using less temporary disk space!).
Webrev can be found at:
http://cr.openjdk.java.net/~ctornqvi/webrev/7049895/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-7049895
Thanks,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From peter.allwin at oracle.com Tue Apr 1 20:32:57 2014
From: peter.allwin at oracle.com (Peter Allwin)
Date: Tue, 1 Apr 2014 22:32:57 +0200
Subject: RFR(XXS): [TESTBUG] vmerrors.sh should suppress windows .mdmp
files
In-Reply-To: <047201cf4de8$765c36e0$6314a4a0$@oracle.com>
References: <047201cf4de8$765c36e0$6314a4a0$@oracle.com>
Message-ID:
Looks good!
/peter
> On 1 apr 2014, at 22:25, Christian Tornqvist wrote:
>
> Hi everyone,
>
> Very small fix that disables dumps from being generated on Windows when running vmerror.sh. Tested locally on Windows and test execution time went from 25 to 5 seconds (plus we?re using less temporary disk space!).
>
> Webrev can be found at:
> http://cr.openjdk.java.net/~ctornqvi/webrev/7049895/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-7049895
>
> Thanks,
> Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Tue Apr 1 20:30:48 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 01 Apr 2014 16:30:48 -0400
Subject: RFR(XXS): [TESTBUG] vmerrors.sh should suppress windows .mdmp
files
In-Reply-To: <047201cf4de8$765c36e0$6314a4a0$@oracle.com>
References: <047201cf4de8$765c36e0$6314a4a0$@oracle.com>
Message-ID: <533B21F8.6090108@oracle.com>
Excellent.
Coleen
On 04/01/2014 04:25 PM, Christian Tornqvist wrote:
>
> Hi everyone,
>
> Very small fix that disables dumps from being generated on Windows
> when running vmerror.sh. Tested locally on Windows and test execution
> time went from 25 to 5 seconds (plus we're using less temporary disk
> space!).
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/7049895/webrev.00/
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-7049895
>
> Thanks,
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From zhengyu.gu at oracle.com Tue Apr 1 20:35:37 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 01 Apr 2014 16:35:37 -0400
Subject: RFR(XXS): [TESTBUG] vmerrors.sh should suppress windows .mdmp
files
In-Reply-To: <047201cf4de8$765c36e0$6314a4a0$@oracle.com>
References: <047201cf4de8$765c36e0$6314a4a0$@oracle.com>
Message-ID: <533B2319.4040302@oracle.com>
Look good.
-Zhenguy
On 4/1/2014 4:25 PM, Christian Tornqvist wrote:
>
> Hi everyone,
>
> Very small fix that disables dumps from being generated on Windows
> when running vmerror.sh. Tested locally on Windows and test execution
> time went from 25 to 5 seconds (plus we're using less temporary disk
> space!).
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/7049895/webrev.00/
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-7049895
>
> Thanks,
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From daniel.daugherty at oracle.com Tue Apr 1 20:46:19 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 01 Apr 2014 14:46:19 -0600
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <533A8132.8010908@oracle.com>
References: <53395EB7.1000108@oracle.com> <533A5C54.9010403@oracle.com>
<533A8132.8010908@oracle.com>
Message-ID: <533B259B.5080702@oracle.com>
On 4/1/14 3:04 AM, Frederic Parain wrote:
> Hi David,
>
> Thank you for the review, the indentation is now fixed:
>
> http://cr.openjdk.java.net/~fparain/8038473/webrev.01/
Thumbs up!
src/os/aix/vm/os_aix.cpp
No comments.
src/os/bsd/vm/os_bsd.cpp
No comments.
src/os/linux/vm/os_linux.cpp
No comments.
src/os/solaris/vm/osThread_solaris.cpp
No comments.
src/os/solaris/vm/osThread_solaris.hpp
No comments.
src/os/solaris/vm/os_solaris.cpp
No comments.
src/os/solaris/vm/os_solaris.hpp
No comments.
src/os/windows/vm/os_windows.cpp
No comments.
src/os/windows/vm/os_windows.inline.hpp
No comments.
src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
No comments.
src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
No comments.
src/share/vm/runtime/arguments.cpp
No comments.
src/share/vm/runtime/os.hpp
No comments.
src/share/vm/runtime/safepoint.cpp
No comments.
src/share/vm/runtime/sharedRuntime.cpp
No comments.
src/share/vm/runtime/sharedRuntime.hpp
No comments.
Dan
>
> Regards,
>
> Fred
>
> On 04/01/2014 08:27 AM, David Holmes wrote:
>> Hi Fred,
>>
>> This looks okay to me. Great to see so much red :) Probably worth
>> mentioning to other readers that you're going to re-examine the use of
>> yield_all() in the future.
>>
>> Minor nit in os_solaris.cpp:
>>
>> void os::yield_all() {
>> // Yields to all threads, including threads with lower priorities
>> os::sleep(Thread::current(), 1, false);
>> }
>>
>> the indent for sleep needs to be 4 spaces less now.
>>
>> Thanks,
>> David
>>
>> On 31/03/2014 10:25 PM, frederic parain wrote:
>>> Greetings,
>>>
>>> Back in Solaris 8 days, the JVM used a thread library
>>> called T1. In Solaris 9, a new thread library, called T2,
>>> was added to Solaris. The JVM code was extended to be able
>>> to use either the T1 libthread or the T2 libthread.
>>> Since Solaris 10, T2 is the default thread library and the
>>> T1 libthread is not part of Solaris anymore, all its APIs
>>> are wrappers around T2 APIs. This changeset removes the
>>> support for the T1 libthread and the workarounds put in
>>> VM code to deal with some T1 issues.
>>>
>>> Note: the minimal requirement for JDK9 is Solaris 10u9.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8038473
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>>>
>>> Thank you,
>>>
>>> Fred
>>>
>
From kevin.walls at oracle.com Tue Apr 1 20:53:48 2014
From: kevin.walls at oracle.com (Kevin Walls)
Date: Tue, 01 Apr 2014 21:53:48 +0100
Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a
humanly readable format
In-Reply-To: <53336666.2060909@oracle.com>
References: <53335DEE.3080805@oracle.com> <53336666.2060909@oracle.com>
Message-ID: <533B275C.5070008@oracle.com>
Thanks Coleen -
Here's an update, the constants are good, here's an attempt to use
constants and keep it not too verbose:
http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
Thanks
Kevin & Masato
On 26/03/14 23:44, Coleen Phillimore wrote:
>
> Can you make these expressions into a variable for the calculations? IE.
> 86400 = seconds_in_a_day
> 3600 = seconds_in_an_hour
> 60 = seconds_in_a_minute
>
> and then have
> eldays * 86400 be something like day_seconds
>
> Thanks - it would be nice if these numbers only appear once each.
> Coleen
> On 3/26/14 7:08 PM, Kevin Walls wrote:
>>
>> Hi,
>>
>> I'd like to get a review of this change:
>>
>> It's adding a human-readable breakdown of the elapsed time, which is
>> currently printed in raw seconds in the hs_err file (it's the last
>> item printed).
>>
>> This is on behalf of Masato Yoshido who has worked on it. Further
>> details below, including a method that was used for manual testing.
>>
>> bug:
>> https://bugs.openjdk.java.net/browse/JDK-8026334
>>
>> webrev:
>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/
>>
>> Many thanks,
>> Kevin
>> Masato
>>
>>
>> [Change details]
>>
>> - Time format will change as follows:
>>
>> (from)
>> elapsed time: %d seconds
>>
>> (to)
>> elapsed time: %d seconds (%dd %dh %dm %ds)
>>
>> - The reason why I leave the original elapsed time format is:
>> -- We don?t need to remove the original format. If we remove it, ones
>> who want time information in seconds need to calculate from day-,
>> hour-, minute- and second-parts.
>>
>> - There is no code doing exactly the same thing. Another code to which
>> we might be able to apply calculation similar to this conversion is
>> the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time
>> in GC log is a floating point number, while the time in hs_err log
>> is an integer since there is a problem when %f is used in printf
>> on Linux platform (See comments in os::print_date_and_time function).
>> Therefore, the same code as this cannot simply be share with GC log.
>>
>>
>> [Test]
>>
>> (1) Tested only part of code of elapsed time calculation and printing.
>>
>> --- test_print_time.cpp ---
>> #include
>> #include
>> #include
>>
>> void print_date_and_time(double t) {
>> int eltime = (int)t; // elapsed time in seconds
>> int eldays, elhours, elminutes, elseconds; // for printing elapsed
>> time in a humanly readable format
>> eldays = eltime / 86400;
>> elhours = (eltime - eldays * 86400) / 3600;
>> elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60;
>> elseconds = (eltime - eldays * 86400 - elhours * 3600 - elminutes *
>> 60);
>> printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime,
>> eldays, elhours, elminutes, elseconds);
>> printf("\n");
>> }
>>
>> int main(int argc, char *argv[]) {
>> print_date_and_time((double)86399);
>> print_date_and_time((double)86400);
>> print_date_and_time((double)86401);
>> printf("\n");
>>
>> print_date_and_time((double)86399.999);
>> print_date_and_time((double)86400.999);
>> print_date_and_time((double)86401.999);
>> printf("\n");
>>
>> print_date_and_time((double)(-86399));
>> print_date_and_time((double)(-86400));
>> print_date_and_time((double)(-86401));
>> printf("\n");
>>
>> print_date_and_time((double)INT_MAX);
>> print_date_and_time((double)(INT_MAX+1));
>> print_date_and_time((double)UINT_MAX);
>> }
>> ---
>>
>> --- Run the test program
>> $ ./test_print_time
>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>
>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>
>> elapsed time: -86399 seconds (0d -23h -59m -59s)
>> elapsed time: -86400 seconds (-1d 0h 0m 0s)
>> elapsed time: -86401 seconds (-1d 0h 0m -1s)
>>
>> elapsed time: 2147483647 seconds (24855d 3h 14m 7s)
>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>> ---
>>
>>
>> (2) Tested using a JNI program causing Segmentation Violation.
>> Tested on the following platforms:
>> solaris sparcv9
>> solaris x64
>> linux x86
>> linux x64
>> windows x86
>> windows x64
>> macosx x64
>> hs_err_pid.log file was successfully generated with expected
>> ?elapsed time? line on each platform.
>>
>>
>> --- TestCrash.java ---
>> public class TestCrash {
>> static {
>> System.loadLibrary("testcrash");
>> }
>>
>> public static native void crash();
>>
>> public static void main(String[] args) {
>> try {
>> Thread.sleep(61000);
>> } catch (InterruptedException e) {
>> e.printStackTrace();
>> }
>> crash();
>> }
>> }
>> ---
>>
>> --- TestCrash.c ---
>> #include
>>
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> /*
>> * Class: TestCrash
>> * Method: crash
>> * Signature: ()V
>> */
>> JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass cls) {
>> const char *p = "Hello, world!";
>> *(char *)p = 'a';
>> }
>>
>> #ifdef __cplusplus
>> }
>> #endif
>> ---
>>
>>
>> Thanks and best regards,
>> Masato
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mikhailo.seledtsov at oracle.com Tue Apr 1 21:06:46 2014
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Tue, 01 Apr 2014 17:06:46 -0400
Subject: RFR (M): JDK-8038587: [TESTBUG] Create CDS tests to exercise
region sizes and classlist
In-Reply-To: <533A52AB.9010401@oracle.com>
References: <53347D4C.4070406@oracle.com> <533A52AB.9010401@oracle.com>
Message-ID: <533B2A66.3030403@oracle.com>
Hi David,
Thank you for review and your feedback.
The intent of this test is sanity check of basic functionality, making
sure the shared classes are loaded w/o crashes or errors. Even though
creating a shared archive with -Xshare:dump does exercise loading of the
classes from the classlist, I believe SQE should verify it, by
explicitly performing this operation. In my experience I have found that
basic tests often find interesting bugs.
I did drop the attempt to instantiate classes, because the amount of
classes in the class list that have default constructors and instantiate
successfully is quite small, and not worth the trouble. Many classes
fail instantiation due to the absence of UI, or other valid reasons.
What I have found, however, as part of this exercise, is that the
default SE classlist is optimized for the client, not the server.
As for classes that are part of the classlist, but are really missing
from rt.jar: will you consider this to be a bug?
Thank you,
Misha
On 4/1/2014 1:46 AM, David Holmes wrote:
> Hi Misha,
>
> On 28/03/2014 5:34 AM, Mikhailo Seledtsov wrote:
>> Please review these 3 new CDS tests, an ongoing effort in implementation
>> of the CDS test specification.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038587
>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8038587/webrev.00/
>> Testing:
>> Local testing on multiple platforms
>> JPRT to exercise the added tests:
>> 2014-03-27-184953.mseledtsov.cds (PASS)
>> These tests found 2 bugs, and one potential issue
>
> I don't quite get the point of the ClassListExerciser test. The
> classlist may well contain classes that do not exist, or that can not
> be instantiated in the test context, even if they have a no-arg
> constructor. Simply creating an archive "exercises" the classlist, so
> I'm really not sure what this test is intending to test.
>
> Also this test won't work with SE Embedded as we have a customized
> default classlist for the Embedded stack.
>
> Thanks,
> David
>
>> Thank you,
>> Misha
From david.holmes at oracle.com Wed Apr 2 01:52:15 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 02 Apr 2014 11:52:15 +1000
Subject: RFR (M): JDK-8038587: [TESTBUG] Create CDS tests to exercise
region sizes and classlist
In-Reply-To: <533B2A66.3030403@oracle.com>
References: <53347D4C.4070406@oracle.com> <533A52AB.9010401@oracle.com>
<533B2A66.3030403@oracle.com>
Message-ID: <533B6D4F.3010509@oracle.com>
On 2/04/2014 7:06 AM, Mikhailo Seledtsov wrote:
> Hi David,
>
> Thank you for review and your feedback.
>
> The intent of this test is sanity check of basic functionality, making
> sure the shared classes are loaded w/o crashes or errors. Even though
> creating a shared archive with -Xshare:dump does exercise loading of the
> classes from the classlist, I believe SQE should verify it, by
> explicitly performing this operation. In my experience I have found that
> basic tests often find interesting bugs.
>
> I did drop the attempt to instantiate classes, because the amount of
> classes in the class list that have default constructors and instantiate
> successfully is quite small, and not worth the trouble. Many classes
> fail instantiation due to the absence of UI, or other valid reasons.
Okay. Dropping that seems to alleviate most of my concerns.
> What I have found, however, as part of this exercise, is that the
> default SE classlist is optimized for the client, not the server.
>
> As for classes that are part of the classlist, but are really missing
> from rt.jar: will you consider this to be a bug?
No. The default classlist, as you note is defined for a particular
scenario - at the moment "client" apps. But many of those classes are
not present in Compact Profiles. So unless/until we have customized
default classlists for Compact Profiles, missing classes can be
expected. I don't see this as an issue that warrants such customized
classlists.
Thanks,
David
>
> Thank you,
> Misha
>
>
> On 4/1/2014 1:46 AM, David Holmes wrote:
>> Hi Misha,
>>
>> On 28/03/2014 5:34 AM, Mikhailo Seledtsov wrote:
>>> Please review these 3 new CDS tests, an ongoing effort in implementation
>>> of the CDS test specification.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038587
>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8038587/webrev.00/
>>> Testing:
>>> Local testing on multiple platforms
>>> JPRT to exercise the added tests:
>>> 2014-03-27-184953.mseledtsov.cds (PASS)
>>> These tests found 2 bugs, and one potential issue
>>
>> I don't quite get the point of the ClassListExerciser test. The
>> classlist may well contain classes that do not exist, or that can not
>> be instantiated in the test context, even if they have a no-arg
>> constructor. Simply creating an archive "exercises" the classlist, so
>> I'm really not sure what this test is intending to test.
>>
>> Also this test won't work with SE Embedded as we have a customized
>> default classlist for the Embedded stack.
>>
>> Thanks,
>> David
>>
>>> Thank you,
>>> Misha
>
From dmitry.samersoff at oracle.com Wed Apr 2 07:46:11 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 02 Apr 2014 11:46:11 +0400
Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a
humanly readable format
In-Reply-To: <533B275C.5070008@oracle.com>
References: <53335DEE.3080805@oracle.com> <53336666.2060909@oracle.com>
<533B275C.5070008@oracle.com>
Message-ID: <533BC043.4050701@oracle.com>
Kevin,
1. It's better to use double for arithmetics and convert it to int on
printing.
2. we probably can get rid of intermittent variables
day_secs, hour_secs, minute_secs
3. I would prefer to have constants as all-caps #defines outside of
function definition or (if you or Coleen disagree with it) at least
moved to ll.935 with empty line before and after it.
-Dmitry
On 2014-04-02 00:53, Kevin Walls wrote:
> Thanks Coleen -
>
> Here's an update, the constants are good, here's an attempt to use
> constants and keep it not too verbose:
>
> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>
> Thanks
> Kevin & Masato
>
>
> On 26/03/14 23:44, Coleen Phillimore wrote:
>>
>> Can you make these expressions into a variable for the calculations? IE.
>> 86400 = seconds_in_a_day
>> 3600 = seconds_in_an_hour
>> 60 = seconds_in_a_minute
>>
>> and then have
>> eldays * 86400 be something like day_seconds
>>
>> Thanks - it would be nice if these numbers only appear once each.
>> Coleen
>> On 3/26/14 7:08 PM, Kevin Walls wrote:
>>>
>>> Hi,
>>>
>>> I'd like to get a review of this change:
>>>
>>> It's adding a human-readable breakdown of the elapsed time, which is
>>> currently printed in raw seconds in the hs_err file (it's the last
>>> item printed).
>>>
>>> This is on behalf of Masato Yoshido who has worked on it. Further
>>> details below, including a method that was used for manual testing.
>>>
>>> bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8026334
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/
>>>
>>> Many thanks,
>>> Kevin
>>> Masato
>>>
>>>
>>> [Change details]
>>>
>>> - Time format will change as follows:
>>>
>>> (from)
>>> elapsed time: %d seconds
>>>
>>> (to)
>>> elapsed time: %d seconds (%dd %dh %dm %ds)
>>>
>>> - The reason why I leave the original elapsed time format is:
>>> -- We don?t need to remove the original format. If we remove it, ones
>>> who want time information in seconds need to calculate from day-,
>>> hour-, minute- and second-parts.
>>>
>>> - There is no code doing exactly the same thing. Another code to which
>>> we might be able to apply calculation similar to this conversion is
>>> the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time
>>> in GC log is a floating point number, while the time in hs_err log
>>> is an integer since there is a problem when %f is used in printf
>>> on Linux platform (See comments in os::print_date_and_time function).
>>> Therefore, the same code as this cannot simply be share with GC log.
>>>
>>>
>>> [Test]
>>>
>>> (1) Tested only part of code of elapsed time calculation and printing.
>>>
>>> --- test_print_time.cpp ---
>>> #include
>>> #include
>>> #include
>>>
>>> void print_date_and_time(double t) {
>>> int eltime = (int)t; // elapsed time in seconds
>>> int eldays, elhours, elminutes, elseconds; // for printing elapsed
>>> time in a humanly readable format
>>> eldays = eltime / 86400;
>>> elhours = (eltime - eldays * 86400) / 3600;
>>> elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60;
>>> elseconds = (eltime - eldays * 86400 - elhours * 3600 - elminutes *
>>> 60);
>>> printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime,
>>> eldays, elhours, elminutes, elseconds);
>>> printf("\n");
>>> }
>>>
>>> int main(int argc, char *argv[]) {
>>> print_date_and_time((double)86399);
>>> print_date_and_time((double)86400);
>>> print_date_and_time((double)86401);
>>> printf("\n");
>>>
>>> print_date_and_time((double)86399.999);
>>> print_date_and_time((double)86400.999);
>>> print_date_and_time((double)86401.999);
>>> printf("\n");
>>>
>>> print_date_and_time((double)(-86399));
>>> print_date_and_time((double)(-86400));
>>> print_date_and_time((double)(-86401));
>>> printf("\n");
>>>
>>> print_date_and_time((double)INT_MAX);
>>> print_date_and_time((double)(INT_MAX+1));
>>> print_date_and_time((double)UINT_MAX);
>>> }
>>> ---
>>>
>>> --- Run the test program
>>> $ ./test_print_time
>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>
>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>
>>> elapsed time: -86399 seconds (0d -23h -59m -59s)
>>> elapsed time: -86400 seconds (-1d 0h 0m 0s)
>>> elapsed time: -86401 seconds (-1d 0h 0m -1s)
>>>
>>> elapsed time: 2147483647 seconds (24855d 3h 14m 7s)
>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>> ---
>>>
>>>
>>> (2) Tested using a JNI program causing Segmentation Violation.
>>> Tested on the following platforms:
>>> solaris sparcv9
>>> solaris x64
>>> linux x86
>>> linux x64
>>> windows x86
>>> windows x64
>>> macosx x64
>>> hs_err_pid.log file was successfully generated with expected
>>> ?elapsed time? line on each platform.
>>>
>>>
>>> --- TestCrash.java ---
>>> public class TestCrash {
>>> static {
>>> System.loadLibrary("testcrash");
>>> }
>>>
>>> public static native void crash();
>>>
>>> public static void main(String[] args) {
>>> try {
>>> Thread.sleep(61000);
>>> } catch (InterruptedException e) {
>>> e.printStackTrace();
>>> }
>>> crash();
>>> }
>>> }
>>> ---
>>>
>>> --- TestCrash.c ---
>>> #include
>>>
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>> /*
>>> * Class: TestCrash
>>> * Method: crash
>>> * Signature: ()V
>>> */
>>> JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass cls) {
>>> const char *p = "Hello, world!";
>>> *(char *)p = 'a';
>>> }
>>>
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>> ---
>>>
>>>
>>> Thanks and best regards,
>>> Masato
>>>
>>>
>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From christian.tornqvist at oracle.com Wed Apr 2 11:46:20 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Wed, 2 Apr 2014 07:46:20 -0400
Subject: RFR(XXS) 8028733: [TESTBUG] Remove test exclusion for
runtime/6626217/Test6626217.sh
Message-ID: <05e901cf4e69$2acaa550$805feff0$@oracle.com>
Hi everyone,
Again a very small fix, simply removed the @ignore tag in Test6626217.sh.
JDK-7015395 seems to have solved the problem mentioned in this bug but did
not remove the @ignore from the test.
Webrev can be found at:
http://cr.openjdk.java.net/~ctornqvi/webrev/8028733/webrev.00/
Bug is unfortunately not visible externally:
https://bugs.openjdk.java.net/browse/JDK-8028733
Thanks,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Wed Apr 2 11:55:41 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 2 Apr 2014 13:55:41 +0200
Subject: RFR(XXS) 8028733: [TESTBUG] Remove test exclusion for
runtime/6626217/Test6626217.sh
In-Reply-To: <05e901cf4e69$2acaa550$805feff0$@oracle.com>
References: <05e901cf4e69$2acaa550$805feff0$@oracle.com>
Message-ID: <56170CB6-B31A-453C-8015-67063EC7B0C9@oracle.com>
Looks good!
Thanks,
/Staffan
On 2 apr 2014, at 13:46, Christian Tornqvist wrote:
> Hi everyone,
>
> Again a very small fix, simply removed the @ignore tag in Test6626217.sh. JDK-7015395 seems to have solved the problem mentioned in this bug but did not remove the @ignore from the test.
>
> Webrev can be found at:
> http://cr.openjdk.java.net/~ctornqvi/webrev/8028733/webrev.00/
>
> Bug is unfortunately not visible externally:
> https://bugs.openjdk.java.net/browse/JDK-8028733
>
> Thanks,
> Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lois.foltan at oracle.com Wed Apr 2 11:56:55 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 02 Apr 2014 07:56:55 -0400
Subject: RFR(XXS) 8028733: [TESTBUG] Remove test exclusion for
runtime/6626217/Test6626217.sh
In-Reply-To: <05e901cf4e69$2acaa550$805feff0$@oracle.com>
References: <05e901cf4e69$2acaa550$805feff0$@oracle.com>
Message-ID: <533BFB07.2090702@oracle.com>
Looks good.
Lois
On 4/2/2014 7:46 AM, Christian Tornqvist wrote:
>
> Hi everyone,
>
> Again a very small fix, simply removed the @ignore tag in
> Test6626217.sh. JDK-7015395 seems to have solved the problem mentioned
> in this bug but did not remove the @ignore from the test.
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8028733/webrev.00/
>
>
> Bug is unfortunately not visible externally:
>
> https://bugs.openjdk.java.net/browse/JDK-8028733
>
> Thanks,
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From george.triantafillou at oracle.com Wed Apr 2 12:05:42 2014
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Wed, 02 Apr 2014 08:05:42 -0400
Subject: RFR(XXS) 8028733: [TESTBUG] Remove test exclusion for
runtime/6626217/Test6626217.sh
In-Reply-To: <05e901cf4e69$2acaa550$805feff0$@oracle.com>
References: <05e901cf4e69$2acaa550$805feff0$@oracle.com>
Message-ID: <533BFD16.2050900@oracle.com>
Christian,
Looks good.
-George
On 4/2/2014 7:46 AM, Christian Tornqvist wrote:
>
> Hi everyone,
>
> Again a very small fix, simply removed the @ignore tag in
> Test6626217.sh. JDK-7015395 seems to have solved the problem mentioned
> in this bug but did not remove the @ignore from the test.
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8028733/webrev.00/
>
>
> Bug is unfortunately not visible externally:
>
> https://bugs.openjdk.java.net/browse/JDK-8028733
>
> Thanks,
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From markus.gronlund at oracle.com Wed Apr 2 14:29:36 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 2 Apr 2014 07:29:36 -0700 (PDT)
Subject: RFR(S): 8038624:interpretedVFrame::expressions() must respect
InterpreterOopMap for liveness
Message-ID: <74f24048-4476-46db-ade9-8c5085b581c9@default>
Greetings,
?
Kindly asking for reviews for the following change:
?
Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624
https://bugs.openjdk.java.net/browse/JDK-8038344
?
Webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/
?
Problem description:
?
An InterpreterOopMap for a particular bci position does not include expression/operand stack liveness info in the oop_mask/bit_mask if the bci is a call instruction, i.e. for the invoke* instructions (invokevirtual, invokespecial, invokestatic, invokedynamic, invokeinterface).
?
This leads to a discrepancy between what is actually on the expression/operand stack (given via fr().interpreter_frame_expression_stack_size()) and what is given in the liveness oop_mask/bit_mask (given via InterpreterOopMap) at a particular bci.
The code in interpretedVFrame::expressions() is currently based on information given from fr().interpreter_frame_expression_stack_size(), and will index into the retrieved oop_mask/bit_mask based on this information (expression slot nr + _max_locals). These indexes either:
1. Fetches a 0 (since no live info at that position in the mask) if the index is low enough to still be inside the bit_mask word boundary. It will then proceed to treat the expression slot (which might be a real reference) as a T_INT (0 is a value, 1 is a reference)
2. Indexes out of bounds for the oop_map/bit_mask (see https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up information outside that is not related to a liveness bit mask. If that position happens to yield a 1, but the real expression slot is a value ("v"), the system can assert "(obj->is_oop()) failed: not an oop: 0x00000001"
?
Tested by running:
?
nsk/jdi/*
?
?
Other info:
?
I dislike having to create a new StackValueCollection even though I know the length is 0 and it will not be actively used. However, this pattern of always creating and returning empty objects is prevalent in this piece of code and is not easily detangled.
?
?
Thanks in advance
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From kevin.walls at oracle.com Wed Apr 2 14:27:19 2014
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 02 Apr 2014 15:27:19 +0100
Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a
humanly readable format
In-Reply-To: <533BC043.4050701@oracle.com>
References: <53335DEE.3080805@oracle.com> <53336666.2060909@oracle.com>
<533B275C.5070008@oracle.com> <533BC043.4050701@oracle.com>
Message-ID: <533C1E47.6090107@oracle.com>
Hi Dmitry, all,
So we exchanged emails off the list about the accuracy, and are content
to keep the ints for the calculations. They can be re-multiplied to
accurately reconstruct the int value of the "elapsed time" that we
print, which we did as an exercise. Any accuracy concerns after the
initial cast from double to int, which we already do, don't seem
relevant within the expected uptime of most life forms, let alone
processes[1].
It is with formatting changes alone that we refresh the webrev:
http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
Thanks
Kevin
[1] that's a forward-looking statement, should come with a disclaimer.
On 02/04/14 08:46, Dmitry Samersoff wrote:
> Kevin,
>
> 1. It's better to use double for arithmetics and convert it to int on
> printing.
>
>
> 2. we probably can get rid of intermittent variables
> day_secs, hour_secs, minute_secs
>
>
> 3. I would prefer to have constants as all-caps #defines outside of
> function definition or (if you or Coleen disagree with it) at least
> moved to ll.935 with empty line before and after it.
>
> -Dmitry
>
> On 2014-04-02 00:53, Kevin Walls wrote:
>> Thanks Coleen -
>>
>> Here's an update, the constants are good, here's an attempt to use
>> constants and keep it not too verbose:
>>
>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>>
>> Thanks
>> Kevin & Masato
>>
>>
>> On 26/03/14 23:44, Coleen Phillimore wrote:
>>> Can you make these expressions into a variable for the calculations? IE.
>>> 86400 = seconds_in_a_day
>>> 3600 = seconds_in_an_hour
>>> 60 = seconds_in_a_minute
>>>
>>> and then have
>>> eldays * 86400 be something like day_seconds
>>>
>>> Thanks - it would be nice if these numbers only appear once each.
>>> Coleen
>>> On 3/26/14 7:08 PM, Kevin Walls wrote:
>>>> Hi,
>>>>
>>>> I'd like to get a review of this change:
>>>>
>>>> It's adding a human-readable breakdown of the elapsed time, which is
>>>> currently printed in raw seconds in the hs_err file (it's the last
>>>> item printed).
>>>>
>>>> This is on behalf of Masato Yoshido who has worked on it. Further
>>>> details below, including a method that was used for manual testing.
>>>>
>>>> bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8026334
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/
>>>>
>>>> Many thanks,
>>>> Kevin
>>>> Masato
>>>>
>>>>
>>>> [Change details]
>>>>
>>>> - Time format will change as follows:
>>>>
>>>> (from)
>>>> elapsed time: %d seconds
>>>>
>>>> (to)
>>>> elapsed time: %d seconds (%dd %dh %dm %ds)
>>>>
>>>> - The reason why I leave the original elapsed time format is:
>>>> -- We don?t need to remove the original format. If we remove it, ones
>>>> who want time information in seconds need to calculate from day-,
>>>> hour-, minute- and second-parts.
>>>>
>>>> - There is no code doing exactly the same thing. Another code to which
>>>> we might be able to apply calculation similar to this conversion is
>>>> the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time
>>>> in GC log is a floating point number, while the time in hs_err log
>>>> is an integer since there is a problem when %f is used in printf
>>>> on Linux platform (See comments in os::print_date_and_time function).
>>>> Therefore, the same code as this cannot simply be share with GC log.
>>>>
>>>>
>>>> [Test]
>>>>
>>>> (1) Tested only part of code of elapsed time calculation and printing.
>>>>
>>>> --- test_print_time.cpp ---
>>>> #include
>>>> #include
>>>> #include
>>>>
>>>> void print_date_and_time(double t) {
>>>> int eltime = (int)t; // elapsed time in seconds
>>>> int eldays, elhours, elminutes, elseconds; // for printing elapsed
>>>> time in a humanly readable format
>>>> eldays = eltime / 86400;
>>>> elhours = (eltime - eldays * 86400) / 3600;
>>>> elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60;
>>>> elseconds = (eltime - eldays * 86400 - elhours * 3600 - elminutes *
>>>> 60);
>>>> printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime,
>>>> eldays, elhours, elminutes, elseconds);
>>>> printf("\n");
>>>> }
>>>>
>>>> int main(int argc, char *argv[]) {
>>>> print_date_and_time((double)86399);
>>>> print_date_and_time((double)86400);
>>>> print_date_and_time((double)86401);
>>>> printf("\n");
>>>>
>>>> print_date_and_time((double)86399.999);
>>>> print_date_and_time((double)86400.999);
>>>> print_date_and_time((double)86401.999);
>>>> printf("\n");
>>>>
>>>> print_date_and_time((double)(-86399));
>>>> print_date_and_time((double)(-86400));
>>>> print_date_and_time((double)(-86401));
>>>> printf("\n");
>>>>
>>>> print_date_and_time((double)INT_MAX);
>>>> print_date_and_time((double)(INT_MAX+1));
>>>> print_date_and_time((double)UINT_MAX);
>>>> }
>>>> ---
>>>>
>>>> --- Run the test program
>>>> $ ./test_print_time
>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>
>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>
>>>> elapsed time: -86399 seconds (0d -23h -59m -59s)
>>>> elapsed time: -86400 seconds (-1d 0h 0m 0s)
>>>> elapsed time: -86401 seconds (-1d 0h 0m -1s)
>>>>
>>>> elapsed time: 2147483647 seconds (24855d 3h 14m 7s)
>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>> ---
>>>>
>>>>
>>>> (2) Tested using a JNI program causing Segmentation Violation.
>>>> Tested on the following platforms:
>>>> solaris sparcv9
>>>> solaris x64
>>>> linux x86
>>>> linux x64
>>>> windows x86
>>>> windows x64
>>>> macosx x64
>>>> hs_err_pid.log file was successfully generated with expected
>>>> ?elapsed time? line on each platform.
>>>>
>>>>
>>>> --- TestCrash.java ---
>>>> public class TestCrash {
>>>> static {
>>>> System.loadLibrary("testcrash");
>>>> }
>>>>
>>>> public static native void crash();
>>>>
>>>> public static void main(String[] args) {
>>>> try {
>>>> Thread.sleep(61000);
>>>> } catch (InterruptedException e) {
>>>> e.printStackTrace();
>>>> }
>>>> crash();
>>>> }
>>>> }
>>>> ---
>>>>
>>>> --- TestCrash.c ---
>>>> #include
>>>>
>>>> #ifdef __cplusplus
>>>> extern "C" {
>>>> #endif
>>>> /*
>>>> * Class: TestCrash
>>>> * Method: crash
>>>> * Signature: ()V
>>>> */
>>>> JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass cls) {
>>>> const char *p = "Hello, world!";
>>>> *(char *)p = 'a';
>>>> }
>>>>
>>>> #ifdef __cplusplus
>>>> }
>>>> #endif
>>>> ---
>>>>
>>>>
>>>> Thanks and best regards,
>>>> Masato
>>>>
>>>>
>>>>
>
From coleen.phillimore at oracle.com Wed Apr 2 14:31:12 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 02 Apr 2014 10:31:12 -0400
Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a
humanly readable format
In-Reply-To: <533C1E47.6090107@oracle.com>
References: <53335DEE.3080805@oracle.com> <53336666.2060909@oracle.com>
<533B275C.5070008@oracle.com> <533BC043.4050701@oracle.com>
<533C1E47.6090107@oracle.com>
Message-ID: <533C1F30.6060508@oracle.com>
Looks good to me. Thanks for making the code humanly readable also :)
Coleen
On 4/2/14 10:27 AM, Kevin Walls wrote:
>
> Hi Dmitry, all,
>
> So we exchanged emails off the list about the accuracy, and are
> content to keep the ints for the calculations. They can be
> re-multiplied to accurately reconstruct the int value of the "elapsed
> time" that we print, which we did as an exercise. Any accuracy
> concerns after the initial cast from double to int, which we already
> do, don't seem relevant within the expected uptime of most life forms,
> let alone processes[1].
>
> It is with formatting changes alone that we refresh the webrev:
>
> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>
> Thanks
> Kevin
>
> [1] that's a forward-looking statement, should come with a disclaimer.
>
>
>
> On 02/04/14 08:46, Dmitry Samersoff wrote:
>> Kevin,
>>
>> 1. It's better to use double for arithmetics and convert it to int on
>> printing.
>>
>>
>> 2. we probably can get rid of intermittent variables
>> day_secs, hour_secs, minute_secs
>>
>>
>> 3. I would prefer to have constants as all-caps #defines outside of
>> function definition or (if you or Coleen disagree with it) at least
>> moved to ll.935 with empty line before and after it.
>>
>> -Dmitry
>>
>> On 2014-04-02 00:53, Kevin Walls wrote:
>>> Thanks Coleen -
>>>
>>> Here's an update, the constants are good, here's an attempt to use
>>> constants and keep it not too verbose:
>>>
>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>>>
>>> Thanks
>>> Kevin & Masato
>>>
>>>
>>> On 26/03/14 23:44, Coleen Phillimore wrote:
>>>> Can you make these expressions into a variable for the
>>>> calculations? IE.
>>>> 86400 = seconds_in_a_day
>>>> 3600 = seconds_in_an_hour
>>>> 60 = seconds_in_a_minute
>>>>
>>>> and then have
>>>> eldays * 86400 be something like day_seconds
>>>>
>>>> Thanks - it would be nice if these numbers only appear once each.
>>>> Coleen
>>>> On 3/26/14 7:08 PM, Kevin Walls wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to get a review of this change:
>>>>>
>>>>> It's adding a human-readable breakdown of the elapsed time, which is
>>>>> currently printed in raw seconds in the hs_err file (it's the last
>>>>> item printed).
>>>>>
>>>>> This is on behalf of Masato Yoshido who has worked on it. Further
>>>>> details below, including a method that was used for manual testing.
>>>>>
>>>>> bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8026334
>>>>>
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/
>>>>>
>>>>> Many thanks,
>>>>> Kevin
>>>>> Masato
>>>>>
>>>>>
>>>>> [Change details]
>>>>>
>>>>> - Time format will change as follows:
>>>>>
>>>>> (from)
>>>>> elapsed time: %d seconds
>>>>>
>>>>> (to)
>>>>> elapsed time: %d seconds (%dd %dh %dm %ds)
>>>>>
>>>>> - The reason why I leave the original elapsed time format is:
>>>>> -- We don?t need to remove the original format. If we remove
>>>>> it, ones
>>>>> who want time information in seconds need to calculate from
>>>>> day-,
>>>>> hour-, minute- and second-parts.
>>>>>
>>>>> - There is no code doing exactly the same thing. Another code to
>>>>> which
>>>>> we might be able to apply calculation similar to this
>>>>> conversion is
>>>>> the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time
>>>>> in GC log is a floating point number, while the time in hs_err log
>>>>> is an integer since there is a problem when %f is used in printf
>>>>> on Linux platform (See comments in os::print_date_and_time
>>>>> function).
>>>>> Therefore, the same code as this cannot simply be share with GC
>>>>> log.
>>>>>
>>>>>
>>>>> [Test]
>>>>>
>>>>> (1) Tested only part of code of elapsed time calculation and
>>>>> printing.
>>>>>
>>>>> --- test_print_time.cpp ---
>>>>> #include
>>>>> #include
>>>>> #include
>>>>>
>>>>> void print_date_and_time(double t) {
>>>>> int eltime = (int)t; // elapsed time in seconds
>>>>> int eldays, elhours, elminutes, elseconds; // for printing
>>>>> elapsed
>>>>> time in a humanly readable format
>>>>> eldays = eltime / 86400;
>>>>> elhours = (eltime - eldays * 86400) / 3600;
>>>>> elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60;
>>>>> elseconds = (eltime - eldays * 86400 - elhours * 3600 -
>>>>> elminutes *
>>>>> 60);
>>>>> printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime,
>>>>> eldays, elhours, elminutes, elseconds);
>>>>> printf("\n");
>>>>> }
>>>>>
>>>>> int main(int argc, char *argv[]) {
>>>>> print_date_and_time((double)86399);
>>>>> print_date_and_time((double)86400);
>>>>> print_date_and_time((double)86401);
>>>>> printf("\n");
>>>>>
>>>>> print_date_and_time((double)86399.999);
>>>>> print_date_and_time((double)86400.999);
>>>>> print_date_and_time((double)86401.999);
>>>>> printf("\n");
>>>>>
>>>>> print_date_and_time((double)(-86399));
>>>>> print_date_and_time((double)(-86400));
>>>>> print_date_and_time((double)(-86401));
>>>>> printf("\n");
>>>>>
>>>>> print_date_and_time((double)INT_MAX);
>>>>> print_date_and_time((double)(INT_MAX+1));
>>>>> print_date_and_time((double)UINT_MAX);
>>>>> }
>>>>> ---
>>>>>
>>>>> --- Run the test program
>>>>> $ ./test_print_time
>>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>>
>>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>>
>>>>> elapsed time: -86399 seconds (0d -23h -59m -59s)
>>>>> elapsed time: -86400 seconds (-1d 0h 0m 0s)
>>>>> elapsed time: -86401 seconds (-1d 0h 0m -1s)
>>>>>
>>>>> elapsed time: 2147483647 seconds (24855d 3h 14m 7s)
>>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>>> ---
>>>>>
>>>>>
>>>>> (2) Tested using a JNI program causing Segmentation Violation.
>>>>> Tested on the following platforms:
>>>>> solaris sparcv9
>>>>> solaris x64
>>>>> linux x86
>>>>> linux x64
>>>>> windows x86
>>>>> windows x64
>>>>> macosx x64
>>>>> hs_err_pid.log file was successfully generated with
>>>>> expected
>>>>> ?elapsed time? line on each platform.
>>>>>
>>>>>
>>>>> --- TestCrash.java ---
>>>>> public class TestCrash {
>>>>> static {
>>>>> System.loadLibrary("testcrash");
>>>>> }
>>>>>
>>>>> public static native void crash();
>>>>>
>>>>> public static void main(String[] args) {
>>>>> try {
>>>>> Thread.sleep(61000);
>>>>> } catch (InterruptedException e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>> crash();
>>>>> }
>>>>> }
>>>>> ---
>>>>>
>>>>> --- TestCrash.c ---
>>>>> #include
>>>>>
>>>>> #ifdef __cplusplus
>>>>> extern "C" {
>>>>> #endif
>>>>> /*
>>>>> * Class: TestCrash
>>>>> * Method: crash
>>>>> * Signature: ()V
>>>>> */
>>>>> JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass
>>>>> cls) {
>>>>> const char *p = "Hello, world!";
>>>>> *(char *)p = 'a';
>>>>> }
>>>>>
>>>>> #ifdef __cplusplus
>>>>> }
>>>>> #endif
>>>>> ---
>>>>>
>>>>>
>>>>> Thanks and best regards,
>>>>> Masato
>>>>>
>>>>>
>>>>>
>>
>
From dmitry.samersoff at oracle.com Wed Apr 2 14:34:40 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 02 Apr 2014 18:34:40 +0400
Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a
humanly readable format
In-Reply-To: <533C1E47.6090107@oracle.com>
References: <53335DEE.3080805@oracle.com> <53336666.2060909@oracle.com>
<533B275C.5070008@oracle.com> <533BC043.4050701@oracle.com>
<533C1E47.6090107@oracle.com>
Message-ID: <533C2000.4000108@oracle.com>
Kevin,
Looks good for me.
-Dmitry
On 2014-04-02 18:27, Kevin Walls wrote:
>
> Hi Dmitry, all,
>
> So we exchanged emails off the list about the accuracy, and are content
> to keep the ints for the calculations. They can be re-multiplied to
> accurately reconstruct the int value of the "elapsed time" that we
> print, which we did as an exercise. Any accuracy concerns after the
> initial cast from double to int, which we already do, don't seem
> relevant within the expected uptime of most life forms, let alone
> processes[1].
>
> It is with formatting changes alone that we refresh the webrev:
>
> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>
> Thanks
> Kevin
>
> [1] that's a forward-looking statement, should come with a disclaimer.
>
>
>
> On 02/04/14 08:46, Dmitry Samersoff wrote:
>> Kevin,
>>
>> 1. It's better to use double for arithmetics and convert it to int on
>> printing.
>>
>>
>> 2. we probably can get rid of intermittent variables
>> day_secs, hour_secs, minute_secs
>>
>>
>> 3. I would prefer to have constants as all-caps #defines outside of
>> function definition or (if you or Coleen disagree with it) at least
>> moved to ll.935 with empty line before and after it.
>>
>> -Dmitry
>>
>> On 2014-04-02 00:53, Kevin Walls wrote:
>>> Thanks Coleen -
>>>
>>> Here's an update, the constants are good, here's an attempt to use
>>> constants and keep it not too verbose:
>>>
>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>>>
>>> Thanks
>>> Kevin & Masato
>>>
>>>
>>> On 26/03/14 23:44, Coleen Phillimore wrote:
>>>> Can you make these expressions into a variable for the
>>>> calculations? IE.
>>>> 86400 = seconds_in_a_day
>>>> 3600 = seconds_in_an_hour
>>>> 60 = seconds_in_a_minute
>>>>
>>>> and then have
>>>> eldays * 86400 be something like day_seconds
>>>>
>>>> Thanks - it would be nice if these numbers only appear once each.
>>>> Coleen
>>>> On 3/26/14 7:08 PM, Kevin Walls wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to get a review of this change:
>>>>>
>>>>> It's adding a human-readable breakdown of the elapsed time, which is
>>>>> currently printed in raw seconds in the hs_err file (it's the last
>>>>> item printed).
>>>>>
>>>>> This is on behalf of Masato Yoshido who has worked on it. Further
>>>>> details below, including a method that was used for manual testing.
>>>>>
>>>>> bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8026334
>>>>>
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/
>>>>>
>>>>> Many thanks,
>>>>> Kevin
>>>>> Masato
>>>>>
>>>>>
>>>>> [Change details]
>>>>>
>>>>> - Time format will change as follows:
>>>>>
>>>>> (from)
>>>>> elapsed time: %d seconds
>>>>>
>>>>> (to)
>>>>> elapsed time: %d seconds (%dd %dh %dm %ds)
>>>>>
>>>>> - The reason why I leave the original elapsed time format is:
>>>>> -- We don?t need to remove the original format. If we remove it,
>>>>> ones
>>>>> who want time information in seconds need to calculate from
>>>>> day-,
>>>>> hour-, minute- and second-parts.
>>>>>
>>>>> - There is no code doing exactly the same thing. Another code to which
>>>>> we might be able to apply calculation similar to this conversion is
>>>>> the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time
>>>>> in GC log is a floating point number, while the time in hs_err log
>>>>> is an integer since there is a problem when %f is used in printf
>>>>> on Linux platform (See comments in os::print_date_and_time
>>>>> function).
>>>>> Therefore, the same code as this cannot simply be share with GC
>>>>> log.
>>>>>
>>>>>
>>>>> [Test]
>>>>>
>>>>> (1) Tested only part of code of elapsed time calculation and printing.
>>>>>
>>>>> --- test_print_time.cpp ---
>>>>> #include
>>>>> #include
>>>>> #include
>>>>>
>>>>> void print_date_and_time(double t) {
>>>>> int eltime = (int)t; // elapsed time in seconds
>>>>> int eldays, elhours, elminutes, elseconds; // for printing elapsed
>>>>> time in a humanly readable format
>>>>> eldays = eltime / 86400;
>>>>> elhours = (eltime - eldays * 86400) / 3600;
>>>>> elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60;
>>>>> elseconds = (eltime - eldays * 86400 - elhours * 3600 - elminutes *
>>>>> 60);
>>>>> printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime,
>>>>> eldays, elhours, elminutes, elseconds);
>>>>> printf("\n");
>>>>> }
>>>>>
>>>>> int main(int argc, char *argv[]) {
>>>>> print_date_and_time((double)86399);
>>>>> print_date_and_time((double)86400);
>>>>> print_date_and_time((double)86401);
>>>>> printf("\n");
>>>>>
>>>>> print_date_and_time((double)86399.999);
>>>>> print_date_and_time((double)86400.999);
>>>>> print_date_and_time((double)86401.999);
>>>>> printf("\n");
>>>>>
>>>>> print_date_and_time((double)(-86399));
>>>>> print_date_and_time((double)(-86400));
>>>>> print_date_and_time((double)(-86401));
>>>>> printf("\n");
>>>>>
>>>>> print_date_and_time((double)INT_MAX);
>>>>> print_date_and_time((double)(INT_MAX+1));
>>>>> print_date_and_time((double)UINT_MAX);
>>>>> }
>>>>> ---
>>>>>
>>>>> --- Run the test program
>>>>> $ ./test_print_time
>>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>>
>>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>>
>>>>> elapsed time: -86399 seconds (0d -23h -59m -59s)
>>>>> elapsed time: -86400 seconds (-1d 0h 0m 0s)
>>>>> elapsed time: -86401 seconds (-1d 0h 0m -1s)
>>>>>
>>>>> elapsed time: 2147483647 seconds (24855d 3h 14m 7s)
>>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>>> ---
>>>>>
>>>>>
>>>>> (2) Tested using a JNI program causing Segmentation Violation.
>>>>> Tested on the following platforms:
>>>>> solaris sparcv9
>>>>> solaris x64
>>>>> linux x86
>>>>> linux x64
>>>>> windows x86
>>>>> windows x64
>>>>> macosx x64
>>>>> hs_err_pid.log file was successfully generated with expected
>>>>> ?elapsed time? line on each platform.
>>>>>
>>>>>
>>>>> --- TestCrash.java ---
>>>>> public class TestCrash {
>>>>> static {
>>>>> System.loadLibrary("testcrash");
>>>>> }
>>>>>
>>>>> public static native void crash();
>>>>>
>>>>> public static void main(String[] args) {
>>>>> try {
>>>>> Thread.sleep(61000);
>>>>> } catch (InterruptedException e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>> crash();
>>>>> }
>>>>> }
>>>>> ---
>>>>>
>>>>> --- TestCrash.c ---
>>>>> #include
>>>>>
>>>>> #ifdef __cplusplus
>>>>> extern "C" {
>>>>> #endif
>>>>> /*
>>>>> * Class: TestCrash
>>>>> * Method: crash
>>>>> * Signature: ()V
>>>>> */
>>>>> JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass cls) {
>>>>> const char *p = "Hello, world!";
>>>>> *(char *)p = 'a';
>>>>> }
>>>>>
>>>>> #ifdef __cplusplus
>>>>> }
>>>>> #endif
>>>>> ---
>>>>>
>>>>>
>>>>> Thanks and best regards,
>>>>> Masato
>>>>>
>>>>>
>>>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From kevin.walls at oracle.com Wed Apr 2 14:35:37 2014
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 02 Apr 2014 15:35:37 +0100
Subject: RR(S): 8026334: hs_err improvement: Print elapsed time in a
humanly readable format
In-Reply-To: <533C2000.4000108@oracle.com>
References: <53335DEE.3080805@oracle.com> <53336666.2060909@oracle.com>
<533B275C.5070008@oracle.com> <533BC043.4050701@oracle.com>
<533C1E47.6090107@oracle.com> <533C2000.4000108@oracle.com>
Message-ID: <533C2039.1000508@oracle.com>
Great, thanks Coleen, thanks Dmitry!
Regards
Kevin
On 02/04/14 15:34, Dmitry Samersoff wrote:
> Kevin,
>
> Looks good for me.
>
> -Dmitry
>
> On 2014-04-02 18:27, Kevin Walls wrote:
>> Hi Dmitry, all,
>>
>> So we exchanged emails off the list about the accuracy, and are content
>> to keep the ints for the calculations. They can be re-multiplied to
>> accurately reconstruct the int value of the "elapsed time" that we
>> print, which we did as an exercise. Any accuracy concerns after the
>> initial cast from double to int, which we already do, don't seem
>> relevant within the expected uptime of most life forms, let alone
>> processes[1].
>>
>> It is with formatting changes alone that we refresh the webrev:
>>
>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>>
>> Thanks
>> Kevin
>>
>> [1] that's a forward-looking statement, should come with a disclaimer.
>>
>>
>>
>> On 02/04/14 08:46, Dmitry Samersoff wrote:
>>> Kevin,
>>>
>>> 1. It's better to use double for arithmetics and convert it to int on
>>> printing.
>>>
>>>
>>> 2. we probably can get rid of intermittent variables
>>> day_secs, hour_secs, minute_secs
>>>
>>>
>>> 3. I would prefer to have constants as all-caps #defines outside of
>>> function definition or (if you or Coleen disagree with it) at least
>>> moved to ll.935 with empty line before and after it.
>>>
>>> -Dmitry
>>>
>>> On 2014-04-02 00:53, Kevin Walls wrote:
>>>> Thanks Coleen -
>>>>
>>>> Here's an update, the constants are good, here's an attempt to use
>>>> constants and keep it not too verbose:
>>>>
>>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.01/
>>>>
>>>> Thanks
>>>> Kevin & Masato
>>>>
>>>>
>>>> On 26/03/14 23:44, Coleen Phillimore wrote:
>>>>> Can you make these expressions into a variable for the
>>>>> calculations? IE.
>>>>> 86400 = seconds_in_a_day
>>>>> 3600 = seconds_in_an_hour
>>>>> 60 = seconds_in_a_minute
>>>>>
>>>>> and then have
>>>>> eldays * 86400 be something like day_seconds
>>>>>
>>>>> Thanks - it would be nice if these numbers only appear once each.
>>>>> Coleen
>>>>> On 3/26/14 7:08 PM, Kevin Walls wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to get a review of this change:
>>>>>>
>>>>>> It's adding a human-readable breakdown of the elapsed time, which is
>>>>>> currently printed in raw seconds in the hs_err file (it's the last
>>>>>> item printed).
>>>>>>
>>>>>> This is on behalf of Masato Yoshido who has worked on it. Further
>>>>>> details below, including a method that was used for manual testing.
>>>>>>
>>>>>> bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8026334
>>>>>>
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~kevinw/8026334/webrev.00/
>>>>>>
>>>>>> Many thanks,
>>>>>> Kevin
>>>>>> Masato
>>>>>>
>>>>>>
>>>>>> [Change details]
>>>>>>
>>>>>> - Time format will change as follows:
>>>>>>
>>>>>> (from)
>>>>>> elapsed time: %d seconds
>>>>>>
>>>>>> (to)
>>>>>> elapsed time: %d seconds (%dd %dh %dm %ds)
>>>>>>
>>>>>> - The reason why I leave the original elapsed time format is:
>>>>>> -- We don?t need to remove the original format. If we remove it,
>>>>>> ones
>>>>>> who want time information in seconds need to calculate from
>>>>>> day-,
>>>>>> hour-, minute- and second-parts.
>>>>>>
>>>>>> - There is no code doing exactly the same thing. Another code to which
>>>>>> we might be able to apply calculation similar to this conversion is
>>>>>> the GC log with -XX:+PrintGCTimeStamps. However, the elapsed time
>>>>>> in GC log is a floating point number, while the time in hs_err log
>>>>>> is an integer since there is a problem when %f is used in printf
>>>>>> on Linux platform (See comments in os::print_date_and_time
>>>>>> function).
>>>>>> Therefore, the same code as this cannot simply be share with GC
>>>>>> log.
>>>>>>
>>>>>>
>>>>>> [Test]
>>>>>>
>>>>>> (1) Tested only part of code of elapsed time calculation and printing.
>>>>>>
>>>>>> --- test_print_time.cpp ---
>>>>>> #include
>>>>>> #include
>>>>>> #include
>>>>>>
>>>>>> void print_date_and_time(double t) {
>>>>>> int eltime = (int)t; // elapsed time in seconds
>>>>>> int eldays, elhours, elminutes, elseconds; // for printing elapsed
>>>>>> time in a humanly readable format
>>>>>> eldays = eltime / 86400;
>>>>>> elhours = (eltime - eldays * 86400) / 3600;
>>>>>> elminutes = (eltime - eldays * 86400 - elhours * 3600) / 60;
>>>>>> elseconds = (eltime - eldays * 86400 - elhours * 3600 - elminutes *
>>>>>> 60);
>>>>>> printf("elapsed time: %d seconds (%dd %dh %dm %ds)", eltime,
>>>>>> eldays, elhours, elminutes, elseconds);
>>>>>> printf("\n");
>>>>>> }
>>>>>>
>>>>>> int main(int argc, char *argv[]) {
>>>>>> print_date_and_time((double)86399);
>>>>>> print_date_and_time((double)86400);
>>>>>> print_date_and_time((double)86401);
>>>>>> printf("\n");
>>>>>>
>>>>>> print_date_and_time((double)86399.999);
>>>>>> print_date_and_time((double)86400.999);
>>>>>> print_date_and_time((double)86401.999);
>>>>>> printf("\n");
>>>>>>
>>>>>> print_date_and_time((double)(-86399));
>>>>>> print_date_and_time((double)(-86400));
>>>>>> print_date_and_time((double)(-86401));
>>>>>> printf("\n");
>>>>>>
>>>>>> print_date_and_time((double)INT_MAX);
>>>>>> print_date_and_time((double)(INT_MAX+1));
>>>>>> print_date_and_time((double)UINT_MAX);
>>>>>> }
>>>>>> ---
>>>>>>
>>>>>> --- Run the test program
>>>>>> $ ./test_print_time
>>>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>>>
>>>>>> elapsed time: 86399 seconds (0d 23h 59m 59s)
>>>>>> elapsed time: 86400 seconds (1d 0h 0m 0s)
>>>>>> elapsed time: 86401 seconds (1d 0h 0m 1s)
>>>>>>
>>>>>> elapsed time: -86399 seconds (0d -23h -59m -59s)
>>>>>> elapsed time: -86400 seconds (-1d 0h 0m 0s)
>>>>>> elapsed time: -86401 seconds (-1d 0h 0m -1s)
>>>>>>
>>>>>> elapsed time: 2147483647 seconds (24855d 3h 14m 7s)
>>>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>>>> elapsed time: -2147483648 seconds (-24855d -3h -14m -8s)
>>>>>> ---
>>>>>>
>>>>>>
>>>>>> (2) Tested using a JNI program causing Segmentation Violation.
>>>>>> Tested on the following platforms:
>>>>>> solaris sparcv9
>>>>>> solaris x64
>>>>>> linux x86
>>>>>> linux x64
>>>>>> windows x86
>>>>>> windows x64
>>>>>> macosx x64
>>>>>> hs_err_pid.log file was successfully generated with expected
>>>>>> ?elapsed time? line on each platform.
>>>>>>
>>>>>>
>>>>>> --- TestCrash.java ---
>>>>>> public class TestCrash {
>>>>>> static {
>>>>>> System.loadLibrary("testcrash");
>>>>>> }
>>>>>>
>>>>>> public static native void crash();
>>>>>>
>>>>>> public static void main(String[] args) {
>>>>>> try {
>>>>>> Thread.sleep(61000);
>>>>>> } catch (InterruptedException e) {
>>>>>> e.printStackTrace();
>>>>>> }
>>>>>> crash();
>>>>>> }
>>>>>> }
>>>>>> ---
>>>>>>
>>>>>> --- TestCrash.c ---
>>>>>> #include
>>>>>>
>>>>>> #ifdef __cplusplus
>>>>>> extern "C" {
>>>>>> #endif
>>>>>> /*
>>>>>> * Class: TestCrash
>>>>>> * Method: crash
>>>>>> * Signature: ()V
>>>>>> */
>>>>>> JNIEXPORT void JNICALL Java_TestCrash_crash(JNIEnv *env, jclass cls) {
>>>>>> const char *p = "Hello, world!";
>>>>>> *(char *)p = 'a';
>>>>>> }
>>>>>>
>>>>>> #ifdef __cplusplus
>>>>>> }
>>>>>> #endif
>>>>>> ---
>>>>>>
>>>>>>
>>>>>> Thanks and best regards,
>>>>>> Masato
>>>>>>
>>>>>>
>>>>>>
>
From andreas.eriksson at oracle.com Wed Apr 2 15:26:46 2014
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Wed, 02 Apr 2014 17:26:46 +0200
Subject: RFR: JDK-8033696: "assert(thread != NULL) failed: just checking"
due to Thread::current() and JNI pthread interaction
In-Reply-To: <5332A001.3080203@oracle.com>
References: <52F8FC95.5090608@oracle.com>
<530E4B1C.2070201@oracle.com> <530F122F.1090107@oracle.com>
<530F23DE.8010008@oracle.com> <530F30C1.7070601@oracle.com>
<53151A83.1090106@oracle.com> <5331529E.8090209@oracle.com>
<5332A001.3080203@oracle.com>
Message-ID: <533C2C36.1060106@oracle.com>
Thanks David.
Could I get a second review as well?
Thanks,
Andreas
On 2014-03-26 10:38, David Holmes wrote:
> Still seems okay to me.
>
> Thanks,
> David
>
> On 25/03/2014 7:55 PM, Andreas Eriksson wrote:
>> Hi,
>>
>> Could I get some eyes on this new webrev?
>>
>> Thanks,
>> Andreas
>>
>> On 2014-03-04 01:12, Andreas Eriksson wrote:
>>> That output was because the VMThread didn't reset it's TLS before
>>> exiting (presumably since the VM is shutting down anyway).
>>> This meant that the thread pointer destructor was run until the
>>> pthread implementation gave up.
>>> I added code that sets the thread pointer to NULL before exiting the
>>> VMThread, ensuring the thread pointer destructor is never called for
>>> the exiting VMThread.
>>>
>>> A new updated webrev can be found here:
>>> http://cr.openjdk.java.net/~aeriksso/8033696/webrev.01/
>>>
>>> I also removed the bug reference from the comments, since I got the
>>> feeling that it's usually discouraged.
>>>
>>> Thanks,
>>> Andreas
>>>
>>> On 2014-02-27 13:34, Andreas Eriksson wrote:
>>>> Oh, sorry, I misread your mail.
>>>>
>>>> I will look into the pthread output from java -version.
>>>>
>>>> Thread 80103f400 has exited with leftover thread-specific data after 4
>>>> destructor iterations
>>>>
>>>> Thanks,
>>>> Andreas
>>>>
>>>> On 2014-02-27 12:39, Dmitry Samersoff wrote:
>>>>> Andreas,
>>>>>
>>>>> I's not growing - always only two threads.
>>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2014-02-27 14:23, Andreas Eriksson wrote:
>>>>>> Thanks Dmitry.
>>>>>>
>>>>>> There are no crashes, only an assert that is hit if running with a
>>>>>> debug
>>>>>> build.
>>>>>> Otherwise the active threads keep growing, like you are seeing.
>>>>>>
>>>>>> It is worrying that they keep growing with the patch as well.
>>>>>> I will have to look at it and see what can be done.
>>>>>>
>>>>>> Regards,
>>>>>> Andreas
>>>>>>
>>>>>> On 2014-02-26 21:14, Dmitry Samersoff wrote:
>>>>>>> Andreas,
>>>>>>>
>>>>>>> With JDK7 I didn't observe any crash with or without your patch.
>>>>>>> Without the patch the number of active threads constantly grows,
>>>>>>> with patch it remains the same.
>>>>>>>
>>>>>>>
>>>>>>> uname -a
>>>>>>> FreeBSD samersoff.net 9.2-RELEASE FreeBSD 9.2-RELEASE #1: Thu
>>>>>>> Jan 2
>>>>>>> 02:15:13 MSK 2014 dms at minext:/sys/amd64/compile/MIRCAT amd64
>>>>>>>
>>>>>>>
>>>>>>> With patch:
>>>>>>>
>>>>>>> #java -version
>>>>>>>
>>>>>>> openjdk version "1.7.0_45"
>>>>>>> OpenJDK Runtime Environment (build 1.7.0_45-b18)
>>>>>>> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>>>>>>> Thread 80103f400 has exited with leftover thread-specific data
>>>>>>> after 4
>>>>>>> destructor iterations
>>>>>>>
>>>>>>> #$JAVA_HOME/bin/java -Djava.library.path=$NATIVE
>>>>>>> com.test.callback.App
>>>>>>>
>>>>>>> Java callback: native thread: 34376799232, java thread:
>>>>>>> Thread-391, 2
>>>>>>> active threads
>>>>>>> Successfully detached native thread 0x801045400
>>>>>>> Deleting callback
>>>>>>>
>>>>>>>
>>>>>>> Without patch:
>>>>>>>
>>>>>>> #/opt/openjdk7/bin/java -version
>>>>>>>
>>>>>>> openjdk version "1.7.0_25"
>>>>>>> OpenJDK Runtime Environment (build 1.7.0_25-b15)
>>>>>>> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode)
>>>>>>>
>>>>>>> #/opt/openjdk7/bin/java -Djava.library.path=$NATIVE
>>>>>>> com.test.callback.App
>>>>>>>
>>>>>>> Java callback: native thread: 34376788992, java thread:
>>>>>>> Thread-402, 404
>>>>>>> active threads
>>>>>>> Successfully detached native thread 0x801042c00
>>>>>>> Deleting callback
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>>
>>>>>>> On 2014-02-10 20:21, Andreas Eriksson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Could I please get reviews for this change.
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696
>>>>>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/
>>>>>>>> Mail discussion:
>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>> JNI code is using pthread_key_create with a destructor to
>>>>>>>> detach the
>>>>>>>> thread from the JVM when the thread is exiting.
>>>>>>>> For some flavors of Linux and BSD the JVM is also using the
>>>>>>>> pthread_key_create, to store the Thread::current() value in a
>>>>>>>> thread
>>>>>>>> local storage.
>>>>>>>> Since the thread local storage containing the thread pointer is
>>>>>>>> erased
>>>>>>>> (by pthread) before the JNI destructor runs, we run
>>>>>>>> detachCurrentThread
>>>>>>>> on a thread that has NULL as current thread.
>>>>>>>> This fix uses a destructor for the thread pointer that restores
>>>>>>>> the
>>>>>>>> value, so that the JNI destructor can run detachCurrentThread
>>>>>>>> successfully.
>>>>>>>> More info in JBS.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> Native code regtest attached to JBS tested on Linux, but not on
>>>>>>>> Mac
>>>>>>>> since I don't have access to one.
>>>>>>>> JPRT ran without a problem.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Andreas
>>>>>
>>>>
>>>
>>
From dmitry.samersoff at oracle.com Wed Apr 2 15:36:22 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 02 Apr 2014 19:36:22 +0400
Subject: RFR: JDK-8033696: "assert(thread != NULL) failed: just checking"
due to Thread::current() and JNI pthread interaction
In-Reply-To: <533C2C36.1060106@oracle.com>
References: <52F8FC95.5090608@oracle.com> <530E4B1C.2070201@oracle.com> <530F122F.1090107@oracle.com> <530F23DE.8010008@oracle.com> <530F30C1.7070601@oracle.com> <53151A83.1090106@oracle.com>
<5331529E.8090209@oracle.com> <5332A001.3080203@oracle.com>
<533C2C36.1060106@oracle.com>
Message-ID: <533C2E76.5030903@oracle.com>
Andreas,
Looks good for me!
-Dmitry
On 2014-04-02 19:26, Andreas Eriksson wrote:
> Thanks David.
>
> Could I get a second review as well?
>
> Thanks,
> Andreas
>
> On 2014-03-26 10:38, David Holmes wrote:
>> Still seems okay to me.
>>
>> Thanks,
>> David
>>
>> On 25/03/2014 7:55 PM, Andreas Eriksson wrote:
>>> Hi,
>>>
>>> Could I get some eyes on this new webrev?
>>>
>>> Thanks,
>>> Andreas
>>>
>>> On 2014-03-04 01:12, Andreas Eriksson wrote:
>>>> That output was because the VMThread didn't reset it's TLS before
>>>> exiting (presumably since the VM is shutting down anyway).
>>>> This meant that the thread pointer destructor was run until the
>>>> pthread implementation gave up.
>>>> I added code that sets the thread pointer to NULL before exiting the
>>>> VMThread, ensuring the thread pointer destructor is never called for
>>>> the exiting VMThread.
>>>>
>>>> A new updated webrev can be found here:
>>>> http://cr.openjdk.java.net/~aeriksso/8033696/webrev.01/
>>>>
>>>> I also removed the bug reference from the comments, since I got the
>>>> feeling that it's usually discouraged.
>>>>
>>>> Thanks,
>>>> Andreas
>>>>
>>>> On 2014-02-27 13:34, Andreas Eriksson wrote:
>>>>> Oh, sorry, I misread your mail.
>>>>>
>>>>> I will look into the pthread output from java -version.
>>>>>
>>>>> Thread 80103f400 has exited with leftover thread-specific data after 4
>>>>> destructor iterations
>>>>>
>>>>> Thanks,
>>>>> Andreas
>>>>>
>>>>> On 2014-02-27 12:39, Dmitry Samersoff wrote:
>>>>>> Andreas,
>>>>>>
>>>>>> I's not growing - always only two threads.
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>> On 2014-02-27 14:23, Andreas Eriksson wrote:
>>>>>>> Thanks Dmitry.
>>>>>>>
>>>>>>> There are no crashes, only an assert that is hit if running with a
>>>>>>> debug
>>>>>>> build.
>>>>>>> Otherwise the active threads keep growing, like you are seeing.
>>>>>>>
>>>>>>> It is worrying that they keep growing with the patch as well.
>>>>>>> I will have to look at it and see what can be done.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Andreas
>>>>>>>
>>>>>>> On 2014-02-26 21:14, Dmitry Samersoff wrote:
>>>>>>>> Andreas,
>>>>>>>>
>>>>>>>> With JDK7 I didn't observe any crash with or without your patch.
>>>>>>>> Without the patch the number of active threads constantly grows,
>>>>>>>> with patch it remains the same.
>>>>>>>>
>>>>>>>>
>>>>>>>> uname -a
>>>>>>>> FreeBSD samersoff.net 9.2-RELEASE FreeBSD 9.2-RELEASE #1: Thu
>>>>>>>> Jan 2
>>>>>>>> 02:15:13 MSK 2014 dms at minext:/sys/amd64/compile/MIRCAT amd64
>>>>>>>>
>>>>>>>>
>>>>>>>> With patch:
>>>>>>>>
>>>>>>>> #java -version
>>>>>>>>
>>>>>>>> openjdk version "1.7.0_45"
>>>>>>>> OpenJDK Runtime Environment (build 1.7.0_45-b18)
>>>>>>>> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>>>>>>>> Thread 80103f400 has exited with leftover thread-specific data
>>>>>>>> after 4
>>>>>>>> destructor iterations
>>>>>>>>
>>>>>>>> #$JAVA_HOME/bin/java -Djava.library.path=$NATIVE
>>>>>>>> com.test.callback.App
>>>>>>>>
>>>>>>>> Java callback: native thread: 34376799232, java thread:
>>>>>>>> Thread-391, 2
>>>>>>>> active threads
>>>>>>>> Successfully detached native thread 0x801045400
>>>>>>>> Deleting callback
>>>>>>>>
>>>>>>>>
>>>>>>>> Without patch:
>>>>>>>>
>>>>>>>> #/opt/openjdk7/bin/java -version
>>>>>>>>
>>>>>>>> openjdk version "1.7.0_25"
>>>>>>>> OpenJDK Runtime Environment (build 1.7.0_25-b15)
>>>>>>>> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode)
>>>>>>>>
>>>>>>>> #/opt/openjdk7/bin/java -Djava.library.path=$NATIVE
>>>>>>>> com.test.callback.App
>>>>>>>>
>>>>>>>> Java callback: native thread: 34376788992, java thread:
>>>>>>>> Thread-402, 404
>>>>>>>> active threads
>>>>>>>> Successfully detached native thread 0x801042c00
>>>>>>>> Deleting callback
>>>>>>>>
>>>>>>>> -Dmitry
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2014-02-10 20:21, Andreas Eriksson wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Could I please get reviews for this change.
>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/
>>>>>>>>> Mail discussion:
>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Summary:
>>>>>>>>> JNI code is using pthread_key_create with a destructor to
>>>>>>>>> detach the
>>>>>>>>> thread from the JVM when the thread is exiting.
>>>>>>>>> For some flavors of Linux and BSD the JVM is also using the
>>>>>>>>> pthread_key_create, to store the Thread::current() value in a
>>>>>>>>> thread
>>>>>>>>> local storage.
>>>>>>>>> Since the thread local storage containing the thread pointer is
>>>>>>>>> erased
>>>>>>>>> (by pthread) before the JNI destructor runs, we run
>>>>>>>>> detachCurrentThread
>>>>>>>>> on a thread that has NULL as current thread.
>>>>>>>>> This fix uses a destructor for the thread pointer that restores
>>>>>>>>> the
>>>>>>>>> value, so that the JNI destructor can run detachCurrentThread
>>>>>>>>> successfully.
>>>>>>>>> More info in JBS.
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> Native code regtest attached to JBS tested on Linux, but not on
>>>>>>>>> Mac
>>>>>>>>> since I don't have access to one.
>>>>>>>>> JPRT ran without a problem.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Andreas
>>>>>>
>>>>>
>>>>
>>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From andreas.eriksson at oracle.com Wed Apr 2 15:49:48 2014
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Wed, 02 Apr 2014 17:49:48 +0200
Subject: RFR: JDK-8033696: "assert(thread != NULL) failed: just checking"
due to Thread::current() and JNI pthread interaction
In-Reply-To: <533C2E76.5030903@oracle.com>
References: <52F8FC95.5090608@oracle.com> <530E4B1C.2070201@oracle.com> <530F122F.1090107@oracle.com> <530F23DE.8010008@oracle.com> <530F30C1.7070601@oracle.com> <53151A83.1090106@oracle.com>
<5331529E.8090209@oracle.com> <5332A001.3080203@oracle.com>
<533C2C36.1060106@oracle.com> <533C2E76.5030903@oracle.com>
Message-ID: <533C319C.9080105@oracle.com>
Thanks Dmitry.
/Andreas
On 2014-04-02 17:36, Dmitry Samersoff wrote:
> Andreas,
>
> Looks good for me!
>
> -Dmitry
>
> On 2014-04-02 19:26, Andreas Eriksson wrote:
>> Thanks David.
>>
>> Could I get a second review as well?
>>
>> Thanks,
>> Andreas
>>
>> On 2014-03-26 10:38, David Holmes wrote:
>>> Still seems okay to me.
>>>
>>> Thanks,
>>> David
>>>
>>> On 25/03/2014 7:55 PM, Andreas Eriksson wrote:
>>>> Hi,
>>>>
>>>> Could I get some eyes on this new webrev?
>>>>
>>>> Thanks,
>>>> Andreas
>>>>
>>>> On 2014-03-04 01:12, Andreas Eriksson wrote:
>>>>> That output was because the VMThread didn't reset it's TLS before
>>>>> exiting (presumably since the VM is shutting down anyway).
>>>>> This meant that the thread pointer destructor was run until the
>>>>> pthread implementation gave up.
>>>>> I added code that sets the thread pointer to NULL before exiting the
>>>>> VMThread, ensuring the thread pointer destructor is never called for
>>>>> the exiting VMThread.
>>>>>
>>>>> A new updated webrev can be found here:
>>>>> http://cr.openjdk.java.net/~aeriksso/8033696/webrev.01/
>>>>>
>>>>> I also removed the bug reference from the comments, since I got the
>>>>> feeling that it's usually discouraged.
>>>>>
>>>>> Thanks,
>>>>> Andreas
>>>>>
>>>>> On 2014-02-27 13:34, Andreas Eriksson wrote:
>>>>>> Oh, sorry, I misread your mail.
>>>>>>
>>>>>> I will look into the pthread output from java -version.
>>>>>>
>>>>>> Thread 80103f400 has exited with leftover thread-specific data after 4
>>>>>> destructor iterations
>>>>>>
>>>>>> Thanks,
>>>>>> Andreas
>>>>>>
>>>>>> On 2014-02-27 12:39, Dmitry Samersoff wrote:
>>>>>>> Andreas,
>>>>>>>
>>>>>>> I's not growing - always only two threads.
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>> On 2014-02-27 14:23, Andreas Eriksson wrote:
>>>>>>>> Thanks Dmitry.
>>>>>>>>
>>>>>>>> There are no crashes, only an assert that is hit if running with a
>>>>>>>> debug
>>>>>>>> build.
>>>>>>>> Otherwise the active threads keep growing, like you are seeing.
>>>>>>>>
>>>>>>>> It is worrying that they keep growing with the patch as well.
>>>>>>>> I will have to look at it and see what can be done.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> On 2014-02-26 21:14, Dmitry Samersoff wrote:
>>>>>>>>> Andreas,
>>>>>>>>>
>>>>>>>>> With JDK7 I didn't observe any crash with or without your patch.
>>>>>>>>> Without the patch the number of active threads constantly grows,
>>>>>>>>> with patch it remains the same.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> uname -a
>>>>>>>>> FreeBSD samersoff.net 9.2-RELEASE FreeBSD 9.2-RELEASE #1: Thu
>>>>>>>>> Jan 2
>>>>>>>>> 02:15:13 MSK 2014 dms at minext:/sys/amd64/compile/MIRCAT amd64
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With patch:
>>>>>>>>>
>>>>>>>>> #java -version
>>>>>>>>>
>>>>>>>>> openjdk version "1.7.0_45"
>>>>>>>>> OpenJDK Runtime Environment (build 1.7.0_45-b18)
>>>>>>>>> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
>>>>>>>>> Thread 80103f400 has exited with leftover thread-specific data
>>>>>>>>> after 4
>>>>>>>>> destructor iterations
>>>>>>>>>
>>>>>>>>> #$JAVA_HOME/bin/java -Djava.library.path=$NATIVE
>>>>>>>>> com.test.callback.App
>>>>>>>>>
>>>>>>>>> Java callback: native thread: 34376799232, java thread:
>>>>>>>>> Thread-391, 2
>>>>>>>>> active threads
>>>>>>>>> Successfully detached native thread 0x801045400
>>>>>>>>> Deleting callback
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Without patch:
>>>>>>>>>
>>>>>>>>> #/opt/openjdk7/bin/java -version
>>>>>>>>>
>>>>>>>>> openjdk version "1.7.0_25"
>>>>>>>>> OpenJDK Runtime Environment (build 1.7.0_25-b15)
>>>>>>>>> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode)
>>>>>>>>>
>>>>>>>>> #/opt/openjdk7/bin/java -Djava.library.path=$NATIVE
>>>>>>>>> com.test.callback.App
>>>>>>>>>
>>>>>>>>> Java callback: native thread: 34376788992, java thread:
>>>>>>>>> Thread-402, 404
>>>>>>>>> active threads
>>>>>>>>> Successfully detached native thread 0x801042c00
>>>>>>>>> Deleting callback
>>>>>>>>>
>>>>>>>>> -Dmitry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2014-02-10 20:21, Andreas Eriksson wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Could I please get reviews for this change.
>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/
>>>>>>>>>> Mail discussion:
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Summary:
>>>>>>>>>> JNI code is using pthread_key_create with a destructor to
>>>>>>>>>> detach the
>>>>>>>>>> thread from the JVM when the thread is exiting.
>>>>>>>>>> For some flavors of Linux and BSD the JVM is also using the
>>>>>>>>>> pthread_key_create, to store the Thread::current() value in a
>>>>>>>>>> thread
>>>>>>>>>> local storage.
>>>>>>>>>> Since the thread local storage containing the thread pointer is
>>>>>>>>>> erased
>>>>>>>>>> (by pthread) before the JNI destructor runs, we run
>>>>>>>>>> detachCurrentThread
>>>>>>>>>> on a thread that has NULL as current thread.
>>>>>>>>>> This fix uses a destructor for the thread pointer that restores
>>>>>>>>>> the
>>>>>>>>>> value, so that the JNI destructor can run detachCurrentThread
>>>>>>>>>> successfully.
>>>>>>>>>> More info in JBS.
>>>>>>>>>>
>>>>>>>>>> Testing:
>>>>>>>>>> Native code regtest attached to JBS tested on Linux, but not on
>>>>>>>>>> Mac
>>>>>>>>>> since I don't have access to one.
>>>>>>>>>> JPRT ran without a problem.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Andreas
>
From yumin.qi at oracle.com Wed Apr 2 17:33:11 2014
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 02 Apr 2014 10:33:11 -0700
Subject: RFR(S): 8038624:interpretedVFrame::expressions() must respect
InterpreterOopMap for liveness
In-Reply-To: <74f24048-4476-46db-ade9-8c5085b581c9@default>
References: <74f24048-4476-46db-ade9-8c5085b581c9@default>
Message-ID: <533C49D7.8030104@oracle.com>
Markus,
Excellent finding and fix. I have question:
324 StackValueCollection* interpretedVFrame::expressions() const {
325
326 int length = 0;
327 InterpreterOopMap oop_mask; <<<< ------------------ default initialize will set _expression_stack_size
to 0.
328
329 if (!method()->is_native()) {
330 // Get oopmap describing oops and int for current bci
331 if (TraceDeoptimization && Verbose) {
332 methodHandle m_h(method());
333 OopMapCache::compute_one_oop_map(m_h, bci(), &oop_mask);
334 } else {
335 method()->mask_for(bci(), &oop_mask);
336 }
337
338 length = oop_mask.expression_stack_size(); <<<<<-------------------------- 1)
339 }
340
341 StackValueCollection* result = new StackValueCollection(length);
342
343 if (0 == length) {
344 return result;
345 }
346
347 int nof_locals = method()->max_locals();
348
349 // handle expressions
350 for(int i=0; i < length; i++) { <<<<------------------------------------------------------2)
351 // Find stack location
352 intptr_t *addr = fr().interpreter_frame_expression_stack_at(i); <<<<------------------- 2)
353
354 // Depending on oop/int put it in the right package
355 StackValue *sv;
356 if (oop_mask.is_oop(i + nof_locals)) {
357 // oop value
358 Handle h(*(oop *)addr);
359 sv = new StackValue(h);
360 } else {
361 // integer
362 sv = new StackValue(*addr);
363 }
364 assert(sv != NULL, "sanity check");
365 result->add(sv);
366 }
367 return result;
368 }
For 1) and 2), the length may not be consistent, this is from your
analysis from JIRA, what if
interpreter_frame_expression_stack_size() is different from 'length'? Is there a possibility out of bound here?
Thanks
Yumin
On 4/2/2014 7:29 AM, Markus Gr?nlund wrote:
>
> Greetings,
>
> Kindly asking for reviews for the following change:
>
> Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624
>
> https://bugs.openjdk.java.net/browse/JDK-8038344
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/
>
>
> Problem description:
>
> An InterpreterOopMap for a particular bci position does not include
> expression/operand stack liveness info in the oop_mask/bit_mask if the
> bci is a call instruction, i.e. for the invoke* instructions
> (invokevirtual, invokespecial, invokestatic, invokedynamic,
> invokeinterface).
>
> This leads to a discrepancy between what is actually on the
> expression/operand stack (given via
> fr().interpreter_frame_expression_stack_size()) and what is given in
> the liveness oop_mask/bit_mask (given via InterpreterOopMap) at a
> particular bci.
>
> The code in interpretedVFrame::expressions() is currently based on
> information given from fr().interpreter_frame_expression_stack_size(),
> and will index into the retrieved oop_mask/bit_mask based on this
> information (expression slot nr + _max_locals). These indexes either:
>
> 1. Fetches a 0 (since no live info at that position in the mask) if
> the index is low enough to still be inside the bit_mask word boundary.
> It will then proceed to treat the expression slot (which might be a
> real reference) as a T_INT (0 is a value, 1 is a reference)
>
> 2. Indexes out of bounds for the oop_map/bit_mask (see
> https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up
> information outside that is not related to a liveness bit mask. If
> that position happens to yield a 1, but the real expression slot is a
> value ("v"), the system can assert "(obj->is_oop()) failed: not an
> oop: 0x00000001"
>
> Tested by running:
>
> nsk/jdi/*
>
> Other info:
>
> I dislike having to create a new StackValueCollection even though I
> know the length is 0 and it will not be actively used. However, this
> pattern of always creating and returning empty objects is prevalent in
> this piece of code and is not easily detangled.
>
> Thanks in advance
>
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From markus.gronlund at oracle.com Wed Apr 2 18:41:31 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 2 Apr 2014 11:41:31 -0700 (PDT)
Subject: RFR(S): 8038624:interpretedVFrame::expressions() must respect
InterpreterOopMap for liveness
In-Reply-To: <533C49D7.8030104@oracle.com>
References: <74f24048-4476-46db-ade9-8c5085b581c9@default>
<533C49D7.8030104@oracle.com>
Message-ID: <58a70e29-a55b-472f-b66f-6f3bb1ae5625@default>
Hi Yumin,
?
Thanks for taking a look.
?
For 1,
?
Thanks for pointing out the default initialization step. I have updated the code to use it.
?
For 2,
?
>From what I have seen so far, the bci liveness information in the bit_mask for the expression stack is, for all bytecodes (except invoke*), reflecting the current top-of-stack state (tos) *before* the seeked bci is executed. For these, the fr().interpreter_frame_expression_stack_size() should == length.
?
For invoke* instructions, the bci liveness information in the bit_mask reflects the current top-of-stack state *after* the seeked bci is executed. Here, fr().interpreter_frame_expression_stack_size() will most likely ?be > length.
?
This means indexing into via fr().interpreter_frame_expression_stack_at(i) should be safe ( index variable will index subset or equal to real expression stack len -1)
?
I have updated the webrev to check this invariant in an assertion as well.
?
Updated webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev02/
?
Thanks
Markus
?
?
?
From: Yumin Qi
Sent: den 2 april 2014 19:33
To: Markus Gr?nlund; serviceability-dev at openjdk.net; hotspot-runtime-dev
Subject: Re: RFR(S): 8038624:interpretedVFrame::expressions() must respect InterpreterOopMap for liveness
?
Markus,
? Excellent finding and fix. I have question:
324 StackValueCollection* interpretedVFrame::expressions() const {
325
?326?? int length = 0;
327?? InterpreterOopMap oop_mask;??? <<<< ------------------ default initialize will set _expression_stack_size
to 0.
328
?329?? if (!method()->is_native()) {
330???? // Get oopmap describing oops and int for current bci
331???? if (TraceDeoptimization && Verbose) {
332?????? methodHandle m_h(method());
333?????? OopMapCache::compute_one_oop_map(m_h, bci(), &oop_mask);
334???? } else {
335?????? method()->mask_for(bci(), &oop_mask);
336???? }
337
?338???? length = oop_mask.expression_stack_size();??????? <<<<<-------------------------- 1)
?339?? }
340
?341?? StackValueCollection* result = new StackValueCollection(length);
342
?343?? if (0 == length) {
344???? return result;
345?? }
346
?347?? int nof_locals = method()->max_locals();
348
?349?? // handle expressions
350?? for(int i=0; i < length; i++) {? <<<<------------------------------------------------------2)
351???? // Find stack location
352???? intptr_t *addr = fr().interpreter_frame_expression_stack_at(i);? <<<<------------------- 2)
353
?354???? // Depending on oop/int put it in the right package
355???? StackValue *sv;
356???? if (oop_mask.is_oop(i + nof_locals)) {
357?????? // oop value
358?????? Handle h(*(oop *)addr);
359?????? sv = new StackValue(h);
360???? } else {
361?????? // integer
362?????? sv = new StackValue(*addr);
363???? }
364???? assert(sv != NULL, "sanity check");
365???? result->add(sv);
366?? }
367?? return result;
368 }
For 1) and 2), the length may not be consistent, this is from your analysis from JIRA, what if??
interpreter_frame_expression_stack_size() is different from 'length'? Is there a possibility out of bound here?
?
Thanks
Yumin
?
?
?
?
On 4/2/2014 7:29 AM, Markus Gr?nlund wrote:
Greetings,
?
Kindly asking for reviews for the following change:
?
Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624
https://bugs.openjdk.java.net/browse/JDK-8038344
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8038624/webrev01/"http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/
?
Problem description:
?
An InterpreterOopMap for a particular bci position does not include expression/operand stack liveness info in the oop_mask/bit_mask if the bci is a call instruction, i.e. for the invoke* instructions (invokevirtual, invokespecial, invokestatic, invokedynamic, invokeinterface).
?
This leads to a discrepancy between what is actually on the expression/operand stack (given via fr().interpreter_frame_expression_stack_size()) and what is given in the liveness oop_mask/bit_mask (given via InterpreterOopMap) at a particular bci.
The code in interpretedVFrame::expressions() is currently based on information given from fr().interpreter_frame_expression_stack_size(), and will index into the retrieved oop_mask/bit_mask based on this information (expression slot nr + _max_locals). These indexes either:
1. Fetches a 0 (since no live info at that position in the mask) if the index is low enough to still be inside the bit_mask word boundary. It will then proceed to treat the expression slot (which might be a real reference) as a T_INT (0 is a value, 1 is a reference)
2. Indexes out of bounds for the oop_map/bit_mask (see https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up information outside that is not related to a liveness bit mask. If that position happens to yield a 1, but the real expression slot is a value ("v"), the system can assert "(obj->is_oop()) failed: not an oop: 0x00000001"
?
Tested by running:
?
nsk/jdi/*
?
?
Other info:
?
I dislike having to create a new StackValueCollection even though I know the length is 0 and it will not be actively used. However, this pattern of always creating and returning empty objects is prevalent in this piece of code and is not easily detangled.
?
?
Thanks in advance
Markus
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From yumin.qi at oracle.com Wed Apr 2 19:23:53 2014
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 02 Apr 2014 12:23:53 -0700
Subject: RFR(S): 8038624:interpretedVFrame::expressions() must respect
InterpreterOopMap for liveness
In-Reply-To: <58a70e29-a55b-472f-b66f-6f3bb1ae5625@default>
References: <74f24048-4476-46db-ade9-8c5085b581c9@default>
<533C49D7.8030104@oracle.com>
<58a70e29-a55b-472f-b66f-6f3bb1ae5625@default>
Message-ID: <533C63C9.10601@oracle.com>
Looks good to me. (not a reviewer:-) )
Thanks for the explain.
Yumin
On 4/2/2014 11:41 AM, Markus Gr?nlund wrote:
>
> Hi Yumin,
>
> Thanks for taking a look.
>
> For 1,
>
> Thanks for pointing out the default initialization step. I have
> updated the code to use it.
>
> For 2,
>
> From what I have seen so far, the bci liveness information in the
> bit_mask for the expression stack is, for all bytecodes (except
> invoke*), reflecting the current top-of-stack state (tos) **before**
> the seeked bci is executed. For these, the
> fr().interpreter_frame_expression_stack_size() should == length.
>
> For invoke* instructions, the bci liveness information in the bit_mask
> reflects the current top-of-stack state *after* the seeked bci is
> executed. Here, fr().interpreter_frame_expression_stack_size() will
> most likely be > length.
>
> This means indexing into via
> fr().interpreter_frame_expression_stack_at(i) should be safe ( index
> variable will index subset or equal to real expression stack len -1)
>
> I have updated the webrev to check this invariant in an assertion as well.
>
> Updated webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev02/
>
>
> Thanks
>
> Markus
>
> *From:*Yumin Qi
> *Sent:* den 2 april 2014 19:33
> *To:* Markus Gr?nlund; serviceability-dev at openjdk.net; hotspot-runtime-dev
> *Subject:* Re: RFR(S): 8038624:interpretedVFrame::expressions() must
> respect InterpreterOopMap for liveness
>
> Markus,
>
> Excellent finding and fix. I have question:
>
>
> 324 StackValueCollection* interpretedVFrame::expressions() const {
> 325
> 326 int length = 0;
> 327 InterpreterOopMap oop_mask; <<<< ------------------ default initialize will set _expression_stack_size
> to 0.
> 328
> 329 if (!method()->is_native()) {
> 330 // Get oopmap describing oops and int for current bci
> 331 if (TraceDeoptimization && Verbose) {
> 332 methodHandle m_h(method());
> 333 OopMapCache::compute_one_oop_map(m_h, bci(), &oop_mask);
> 334 } else {
> 335 method()->mask_for(bci(), &oop_mask);
> 336 }
> 337
> 338 length = oop_mask.expression_stack_size(); <<<<<-------------------------- 1)
> 339 }
> 340
> 341 StackValueCollection* result = new StackValueCollection(length);
> 342
> 343 if (0 == length) {
> 344 return result;
> 345 }
> 346
> 347 int nof_locals = method()->max_locals();
> 348
> 349 // handle expressions
> 350 for(int i=0; i < length; i++) { <<<<------------------------------------------------------2)
> 351 // Find stack location
> 352 intptr_t *addr = fr().interpreter_frame_expression_stack_at(i); <<<<------------------- 2)
> 353
> 354 // Depending on oop/int put it in the right package
> 355 StackValue *sv;
> 356 if (oop_mask.is_oop(i + nof_locals)) {
> 357 // oop value
> 358 Handle h(*(oop *)addr);
> 359 sv = new StackValue(h);
> 360 } else {
> 361 // integer
> 362 sv = new StackValue(*addr);
> 363 }
> 364 assert(sv != NULL, "sanity check");
> 365 result->add(sv);
> 366 }
> 367 return result;
> 368 }
>
>
> For 1) and 2), the length may not be consistent, this is from your
> analysis from JIRA, what if
>
> interpreter_frame_expression_stack_size() is different from 'length'? Is there a possibility out of bound here?
>
> Thanks
> Yumin
>
>
>
>
> On 4/2/2014 7:29 AM, Markus Gr?nlund wrote:
>
> Greetings,
>
> Kindly asking for reviews for the following change:
>
> Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624
>
> https://bugs.openjdk.java.net/browse/JDK-8038344
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/
>
>
> Problem description:
>
> An InterpreterOopMap for a particular bci position does not
> include expression/operand stack liveness info in the
> oop_mask/bit_mask if the bci is a call instruction, i.e. for the
> invoke* instructions (invokevirtual, invokespecial, invokestatic,
> invokedynamic, invokeinterface).
>
> This leads to a discrepancy between what is actually on the
> expression/operand stack (given via
> fr().interpreter_frame_expression_stack_size()) and what is given
> in the liveness oop_mask/bit_mask (given via InterpreterOopMap) at
> a particular bci.
>
> The code in interpretedVFrame::expressions() is currently based on
> information given from
> fr().interpreter_frame_expression_stack_size(), and will index
> into the retrieved oop_mask/bit_mask based on this information
> (expression slot nr + _max_locals). These indexes either:
>
> 1. Fetches a 0 (since no live info at that position in the mask)
> if the index is low enough to still be inside the bit_mask word
> boundary. It will then proceed to treat the expression slot (which
> might be a real reference) as a T_INT (0 is a value, 1 is a
> reference)
>
> 2. Indexes out of bounds for the oop_map/bit_mask (see
> https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up
> information outside that is not related to a liveness bit mask. If
> that position happens to yield a 1, but the real expression slot
> is a value ("v"), the system can assert "(obj->is_oop()) failed:
> not an oop: 0x00000001"
>
> Tested by running:
>
> nsk/jdi/*
>
> Other info:
>
> I dislike having to create a new StackValueCollection even though
> I know the length is 0 and it will not be actively used. However,
> this pattern of always creating and returning empty objects is
> prevalent in this piece of code and is not easily detangled.
>
> Thanks in advance
>
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Wed Apr 2 20:56:37 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 02 Apr 2014 16:56:37 -0400
Subject: RFR(S): 8038624:interpretedVFrame::expressions() must respect
InterpreterOopMap for liveness
In-Reply-To: <74f24048-4476-46db-ade9-8c5085b581c9@default>
References: <74f24048-4476-46db-ade9-8c5085b581c9@default>
Message-ID: <533C7985.6020606@oracle.com>
Markus,
This is really disturbing because deoptimization uses this code to
layout the interpreter frame (unpack_on_stack). Bugs in deoptimization
can be very subtle but we would see some bugs if this was wrong, I think.
Is this a recent failure and there was a change in some other area that
made this crash?
I don't know why interpreter_frame_stack_size wouldn't be the same as
oopmap.expression_stack_size() unless it doesn't include the pushed
arguments?
There's some odd code I've never understood for deoptimization in
interpreter/interpreter.cpp. I think you should have someone from the
compiler group (added) who understands deoptimization review your change.
Coleen
On 4/2/14 10:29 AM, Markus Gr?nlund wrote:
>
> Greetings,
>
> Kindly asking for reviews for the following change:
>
> Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624
>
> https://bugs.openjdk.java.net/browse/JDK-8038344
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/
>
>
> Problem description:
>
> An InterpreterOopMap for a particular bci position does not include
> expression/operand stack liveness info in the oop_mask/bit_mask if the
> bci is a call instruction, i.e. for the invoke* instructions
> (invokevirtual, invokespecial, invokestatic, invokedynamic,
> invokeinterface).
>
> This leads to a discrepancy between what is actually on the
> expression/operand stack (given via
> fr().interpreter_frame_expression_stack_size()) and what is given in
> the liveness oop_mask/bit_mask (given via InterpreterOopMap) at a
> particular bci.
>
> The code in interpretedVFrame::expressions() is currently based on
> information given from fr().interpreter_frame_expression_stack_size(),
> and will index into the retrieved oop_mask/bit_mask based on this
> information (expression slot nr + _max_locals). These indexes either:
>
> 1. Fetches a 0 (since no live info at that position in the mask) if
> the index is low enough to still be inside the bit_mask word boundary.
> It will then proceed to treat the expression slot (which might be a
> real reference) as a T_INT (0 is a value, 1 is a reference)
>
> 2. Indexes out of bounds for the oop_map/bit_mask (see
> https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up
> information outside that is not related to a liveness bit mask. If
> that position happens to yield a 1, but the real expression slot is a
> value ("v"), the system can assert "(obj->is_oop()) failed: not an
> oop: 0x00000001"
>
> Tested by running:
>
> nsk/jdi/*
>
> Other info:
>
> I dislike having to create a new StackValueCollection even though I
> know the length is 0 and it will not be actively used. However, this
> pattern of always creating and returning empty objects is prevalent in
> this piece of code and is not easily detangled.
>
> Thanks in advance
>
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mikhailo.seledtsov at oracle.com Wed Apr 2 23:55:21 2014
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Wed, 02 Apr 2014 19:55:21 -0400
Subject: RFR (M): JDK-8038587: [TESTBUG] Create CDS tests to exercise
region sizes and classlist
In-Reply-To: <533B6D4F.3010509@oracle.com>
References: <53347D4C.4070406@oracle.com> <533A52AB.9010401@oracle.com>
<533B2A66.3030403@oracle.com> <533B6D4F.3010509@oracle.com>
Message-ID: <533CA369.8080601@oracle.com>
David,
Thank you. I will rework ClassListExerciser test to take your comments
into consideration, and will submit a new webrev.
Misha
On 4/1/2014 9:52 PM, David Holmes wrote:
> On 2/04/2014 7:06 AM, Mikhailo Seledtsov wrote:
>> Hi David,
>>
>> Thank you for review and your feedback.
>>
>> The intent of this test is sanity check of basic functionality, making
>> sure the shared classes are loaded w/o crashes or errors. Even though
>> creating a shared archive with -Xshare:dump does exercise loading of the
>> classes from the classlist, I believe SQE should verify it, by
>> explicitly performing this operation. In my experience I have found that
>> basic tests often find interesting bugs.
>>
>> I did drop the attempt to instantiate classes, because the amount of
>> classes in the class list that have default constructors and instantiate
>> successfully is quite small, and not worth the trouble. Many classes
>> fail instantiation due to the absence of UI, or other valid reasons.
>
> Okay. Dropping that seems to alleviate most of my concerns.
>
>> What I have found, however, as part of this exercise, is that the
>> default SE classlist is optimized for the client, not the server.
>>
>> As for classes that are part of the classlist, but are really missing
>> from rt.jar: will you consider this to be a bug?
>
> No. The default classlist, as you note is defined for a particular
> scenario - at the moment "client" apps. But many of those classes are
> not present in Compact Profiles. So unless/until we have customized
> default classlists for Compact Profiles, missing classes can be
> expected. I don't see this as an issue that warrants such customized
> classlists.
>
> Thanks,
> David
>
>>
>> Thank you,
>> Misha
>>
>>
>> On 4/1/2014 1:46 AM, David Holmes wrote:
>>> Hi Misha,
>>>
>>> On 28/03/2014 5:34 AM, Mikhailo Seledtsov wrote:
>>>> Please review these 3 new CDS tests, an ongoing effort in
>>>> implementation
>>>> of the CDS test specification.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038587
>>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8038587/webrev.00/
>>>> Testing:
>>>> Local testing on multiple platforms
>>>> JPRT to exercise the added tests:
>>>> 2014-03-27-184953.mseledtsov.cds (PASS)
>>>> These tests found 2 bugs, and one potential issue
>>>
>>> I don't quite get the point of the ClassListExerciser test. The
>>> classlist may well contain classes that do not exist, or that can not
>>> be instantiated in the test context, even if they have a no-arg
>>> constructor. Simply creating an archive "exercises" the classlist, so
>>> I'm really not sure what this test is intending to test.
>>>
>>> Also this test won't work with SE Embedded as we have a customized
>>> default classlist for the Embedded stack.
>>>
>>> Thanks,
>>> David
>>>
>>>> Thank you,
>>>> Misha
>>
From staffan.larsen at oracle.com Thu Apr 3 09:31:07 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 3 Apr 2014 11:31:07 +0200
Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException:
Command failed in target VM
In-Reply-To: <533514F4.8050906@oracle.com>
References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com>
<6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com>
<533514F4.8050906@oracle.com>
Message-ID: <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com>
Thanks Serguei,
I don?t think it is necessary to initialize ?end? since strtol will always set it.
I still need an official Reviewer for this change.
Thanks,
/Staffan
On 28 mar 2014, at 07:21, serguei.spitsyn at oracle.com wrote:
> On 3/27/14 12:55 AM, Staffan Larsen wrote:
>> Here is an updated webrev which incorporates Dmitry?s feedback:
>>
>> http://cr.openjdk.java.net/~sla/8038296/webrev.01/
>
>
> It looks good.
> The only suggestion is to initialize the 'end':
> char* end;
>
> Not sure what value is better to use for initialization.
> Probably, end = probe would work Ok.
>
> Thanks,
> Serguei
>>
>> Thanks,
>> /Staffan
>>
>> On 25 mar 2014, at 19:36, Dmitry Samersoff wrote:
>>
>>> Staffan,
>>>
>>>> Yes, that will find problems when trying to convert something like
>>>> ?bla?. It will not capture the case where the input string is a too
>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>> both cases it looks like we need something like:
>>>> errno = 0;
>>>> char* end;
>>>> int probe_typess = (int) strtol(probe, &end, 10);
>>>> if (end == probe || errno) {
>>>> return JNI_ERR;
>>>> }
>>> As probe_typess is positive and you are converting long to int
>>> It's be better to check value boundaries explicitly:
>>>
>>> char* end;
>>> long ptl = strtol(probe, &end, 10);
>>> if (end == probe || ptl < 0 || ptl > MAX_INT) {
>>> return JNI_ERR;
>>> }
>>>
>>> int probe_typess = (int) ptl;
>>>
>>>
>>> -Dmitry
>>>
>>>
>>> On 2014-03-25 17:35, Staffan Larsen wrote:
>>>> On 25 mar 2014, at 13:46, Dmitry Samersoff
>>>> wrote:
>>>>
>>>>> Staffan,
>>>>>
>>>>> strtol() sets errno in two cases -
>>>>>
>>>>> ERANGE if supplied value is less then LONG_MIN or greater than
>>>>> LONG_MAX EINVAL if supplied base is not supported.
>>>>>
>>>>> if you pass probe == 'bla', strtol just return 0 and errno will not
>>>>> be set. So I'm not sure that check for errno has any value here.
>>>>>
>>>>> One of possible way to check that supplied value is convertible to
>>>>> long is
>>>>>
>>>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr ==
>>>>> probe) { // we can't convert supplied value return JNI_ERR; }
>>>> Yes, that will find problems when trying to convert something like
>>>> ?bla?. It will not capture the case where the input string is a too
>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>> both cases it looks like we need something like:
>>>>
>>>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end,
>>>> 10); if (end == probe || errno) { return JNI_ERR; }
>>>>
>>>>
>>>> /Staffan
>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 2014-03-25 11:31, Staffan Larsen wrote:
>>>>>> attachListener_solaris.cpp calls atoi() and then checks errno to
>>>>>> see if any errors occurred. The problem is that atoi() does not
>>>>>> set errno, so some old value of errno is checked which sometimes
>>>>>> causes the function to fail.
>>>>>>
>>>>>> The fix is to replace atoi() with strtol() which does set errno.
>>>>>> But errno is only set if an error occurred and not set to 0 in
>>>>>> case of success. Thus, I set errno to 0 before calling strtol()
>>>>>> and check the value afterwards.
>>>>>>
>>>>>> Verified with a JPRT run.
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038296
>>>>>>
>>>>>> Thanks, /Staffan
>>>>>>
>>>>>
>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg,
>>>>> Russia * I would love to change the world, but they won't give me
>>>>> the sources.
>>>
>>> --
>>> Dmitry Samersoff
>>> Oracle Java development team, Saint Petersburg, Russia
>>> * I would love to change the world, but they won't give me the sources.
>
From frederic.parain at oracle.com Thu Apr 3 09:32:57 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 03 Apr 2014 11:32:57 +0200
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <533B259B.5080702@oracle.com>
References: <53395EB7.1000108@oracle.com> <533A5C54.9010403@oracle.com>
<533A8132.8010908@oracle.com> <533B259B.5080702@oracle.com>
Message-ID: <533D2AC9.9030506@oracle.com>
Hi Dan,
Thanks for the review.
Fred
On 04/01/2014 10:46 PM, Daniel D. Daugherty wrote:
> On 4/1/14 3:04 AM, Frederic Parain wrote:
>> Hi David,
>>
>> Thank you for the review, the indentation is now fixed:
>>
>> http://cr.openjdk.java.net/~fparain/8038473/webrev.01/
>
> Thumbs up!
>
>
> src/os/aix/vm/os_aix.cpp
> No comments.
>
> src/os/bsd/vm/os_bsd.cpp
> No comments.
>
> src/os/linux/vm/os_linux.cpp
> No comments.
>
> src/os/solaris/vm/osThread_solaris.cpp
> No comments.
>
> src/os/solaris/vm/osThread_solaris.hpp
> No comments.
>
> src/os/solaris/vm/os_solaris.cpp
> No comments.
>
> src/os/solaris/vm/os_solaris.hpp
> No comments.
>
> src/os/windows/vm/os_windows.cpp
> No comments.
>
> src/os/windows/vm/os_windows.inline.hpp
> No comments.
>
> src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
> No comments.
>
> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
> No comments.
>
> src/share/vm/runtime/arguments.cpp
> No comments.
>
> src/share/vm/runtime/os.hpp
> No comments.
>
> src/share/vm/runtime/safepoint.cpp
> No comments.
>
> src/share/vm/runtime/sharedRuntime.cpp
> No comments.
>
> src/share/vm/runtime/sharedRuntime.hpp
> No comments.
>
> Dan
>
>
>>
>> Regards,
>>
>> Fred
>>
>> On 04/01/2014 08:27 AM, David Holmes wrote:
>>> Hi Fred,
>>>
>>> This looks okay to me. Great to see so much red :) Probably worth
>>> mentioning to other readers that you're going to re-examine the use of
>>> yield_all() in the future.
>>>
>>> Minor nit in os_solaris.cpp:
>>>
>>> void os::yield_all() {
>>> // Yields to all threads, including threads with lower priorities
>>> os::sleep(Thread::current(), 1, false);
>>> }
>>>
>>> the indent for sleep needs to be 4 spaces less now.
>>>
>>> Thanks,
>>> David
>>>
>>> On 31/03/2014 10:25 PM, frederic parain wrote:
>>>> Greetings,
>>>>
>>>> Back in Solaris 8 days, the JVM used a thread library
>>>> called T1. In Solaris 9, a new thread library, called T2,
>>>> was added to Solaris. The JVM code was extended to be able
>>>> to use either the T1 libthread or the T2 libthread.
>>>> Since Solaris 10, T2 is the default thread library and the
>>>> T1 libthread is not part of Solaris anymore, all its APIs
>>>> are wrappers around T2 APIs. This changeset removes the
>>>> support for the T1 libthread and the workarounds put in
>>>> VM code to deal with some T1 issues.
>>>>
>>>> Note: the minimal requirement for JDK9 is Solaris 10u9.
>>>>
>>>> CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8038473
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>>>>
>>>> Thank you,
>>>>
>>>> Fred
>>>>
>>
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From frederic.parain at oracle.com Thu Apr 3 09:33:23 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 03 Apr 2014 11:33:23 +0200
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <533AFF6C.8020603@oracle.com>
References: <53395EB7.1000108@oracle.com> <533AFF6C.8020603@oracle.com>
Message-ID: <533D2AE3.9090407@oracle.com>
Coleen,
Thanks for the review,
Fred
On 04/01/2014 08:03 PM, Coleen Phillimore wrote:
>
> Frederic,
> This looks really nice.
> Thanks!
> Coleen
>
> On 03/31/2014 08:25 AM, frederic parain wrote:
>> Greetings,
>>
>> Back in Solaris 8 days, the JVM used a thread library
>> called T1. In Solaris 9, a new thread library, called T2,
>> was added to Solaris. The JVM code was extended to be able
>> to use either the T1 libthread or the T2 libthread.
>> Since Solaris 10, T2 is the default thread library and the
>> T1 libthread is not part of Solaris anymore, all its APIs
>> are wrappers around T2 APIs. This changeset removes the
>> support for the T1 libthread and the workarounds put in
>> VM code to deal with some T1 issues.
>>
>> Note: the minimal requirement for JDK9 is Solaris 10u9.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8038473
>>
>> Webrev:
>> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>>
>> Thank you,
>>
>> Fred
>>
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From frederic.parain at oracle.com Thu Apr 3 09:36:24 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 03 Apr 2014 11:36:24 +0200
Subject: RFR: 8038473 Remove support for old T1 libthread
In-Reply-To: <314C243A-805C-4926-99BF-E5C1CC13227F@oracle.com>
References: <53395EB7.1000108@oracle.com>
<314C243A-805C-4926-99BF-E5C1CC13227F@oracle.com>
Message-ID: <533D2B98.1010101@oracle.com>
Karen,
Thanks for the review and your wise advices
when I was preparing this changeset.
Fred
On 04/01/2014 09:02 PM, Karen Kinnear wrote:
> Looks good.
> Thank you Frederic, for all the careful work.
>
> thanks,
> Karen
>
> On Mar 31, 2014, at 8:25 AM, frederic parain wrote:
>
>> Greetings,
>>
>> Back in Solaris 8 days, the JVM used a thread library
>> called T1. In Solaris 9, a new thread library, called T2,
>> was added to Solaris. The JVM code was extended to be able
>> to use either the T1 libthread or the T2 libthread.
>> Since Solaris 10, T2 is the default thread library and the
>> T1 libthread is not part of Solaris anymore, all its APIs
>> are wrappers around T2 APIs. This changeset removes the
>> support for the T1 libthread and the workarounds put in
>> VM code to deal with some T1 issues.
>>
>> Note: the minimal requirement for JDK9 is Solaris 10u9.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8038473
>>
>> Webrev:
>> http://cr.openjdk.java.net/~fparain/8038473/webrev.00/
>>
>> Thank you,
>>
>> Fred
>>
>> --
>> Frederic Parain - Oracle
>> Grenoble Engineering Center - France
>> Phone: +33 4 76 18 81 17
>> Email: Frederic.Parain at oracle.com
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From marcus.larsson at oracle.com Thu Apr 3 13:17:08 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 03 Apr 2014 15:17:08 +0200
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
Message-ID: <533D5F54.4060202@oracle.com>
Hello,
I would like reviews for the following bugfix removing a redundant memcpy.
Built on all platforms and tested with JCK.
Webrev:
http://cr.openjdk.java.net/~dsimms/6664815/
Bug:
https://bugs.openjdk.java.net/browse/JDK-6664815
Regards,
Marcus
From staffan.larsen at oracle.com Thu Apr 3 13:29:53 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 3 Apr 2014 15:29:53 +0200
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
In-Reply-To: <533D5F54.4060202@oracle.com>
References: <533D5F54.4060202@oracle.com>
Message-ID: <7ABBE238-7C19-404F-856F-C16D3DFE02B5@oracle.com>
Looks good to me.
Thanks,
/Staffan
On 3 apr 2014, at 15:17, Marcus Larsson wrote:
> Hello,
>
> I would like reviews for the following bugfix removing a redundant memcpy.
> Built on all platforms and tested with JCK.
>
> Webrev:
> http://cr.openjdk.java.net/~dsimms/6664815/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-6664815
>
> Regards,
> Marcus
From goetz.lindenmaier at sap.com Thu Apr 3 13:33:27 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 3 Apr 2014 13:33:27 +0000
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAD6E3@DEWDFEMB12A.global.corp.sap>
Hi,
please review an test this small fix to the interpreters. I please need
a sponsor.
http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/
JNIHandleBlock::_top is an int field. Various places store into
this field using a pointer store. On 64-bit platforms
this can cause errors.
This change adapts the corresponding operations on sparc
and both x86 variants to use fixed 32-bit operations.
Best regards,
Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dmitry.samersoff at oracle.com Thu Apr 3 13:48:35 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 03 Apr 2014 17:48:35 +0400
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
In-Reply-To: <533D5F54.4060202@oracle.com>
References: <533D5F54.4060202@oracle.com>
Message-ID: <533D66B3.1@oracle.com>
Andrew,
Could you take a look at this changes, especially on jni.cpp:3154 ?
-Dmitry
On 2014-04-03 17:17, Marcus Larsson wrote:
> Hello,
>
> I would like reviews for the following bugfix removing a redundant memcpy.
> Built on all platforms and tested with JCK.
>
> Webrev:
> http://cr.openjdk.java.net/~dsimms/6664815/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-6664815
>
> Regards,
> Marcus
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From andrew.gross at oracle.com Thu Apr 3 21:35:35 2014
From: andrew.gross at oracle.com (Andrew Gross)
Date: Thu, 03 Apr 2014 14:35:35 -0700
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
In-Reply-To: <533D66B3.1@oracle.com>
References: <533D5F54.4060202@oracle.com> <533D66B3.1@oracle.com>
Message-ID: <533DD427.3020701@oracle.com>
Hi,
I understand your concern. However, this looks like a place where the
spec allows callers to cause problems easily rather than one where we
are causing the overflow. While not optimal, it does not introduce a
vulnerability.
Drew
On 4/3/2014 6:48 AM, Dmitry Samersoff wrote:
> Andrew,
>
> Could you take a look at this changes, especially on jni.cpp:3154 ?
>
> -Dmitry
>
> On 2014-04-03 17:17, Marcus Larsson wrote:
>> Hello,
>>
>> I would like reviews for the following bugfix removing a redundant memcpy.
>> Built on all platforms and tested with JCK.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~dsimms/6664815/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-6664815
>>
>> Regards,
>> Marcus
>
From ivan.gerasimov at oracle.com Fri Apr 4 07:30:49 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 04 Apr 2014 11:30:49 +0400
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
In-Reply-To: <533D5F54.4060202@oracle.com>
References: <533D5F54.4060202@oracle.com>
Message-ID: <533E5FA9.2030909@oracle.com>
Hi Marcus!
While it's not critical and not really connected to the issue you're
solving, wouldn't it be better to replace
344 p = utf8_write(p, base[index]);
with
344 p = utf8_write(p,*c*);
in src/share/vm/utilities/utf8.cpp?
Sincerely yours,
Ivan
On 03.04.2014 17:17, Marcus Larsson wrote:
> Hello,
>
> I would like reviews for the following bugfix removing a redundant
> memcpy.
> Built on all platforms and tested with JCK.
>
> Webrev:
> http://cr.openjdk.java.net/~dsimms/6664815/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-6664815
>
> Regards,
> Marcus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From marcus.larsson at oracle.com Fri Apr 4 10:54:53 2014
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 04 Apr 2014 12:54:53 +0200
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
In-Reply-To: <533E5FA9.2030909@oracle.com>
References: <533D5F54.4060202@oracle.com> <533E5FA9.2030909@oracle.com>
Message-ID: <533E8F7D.3010602@oracle.com>
Good point,
Updated: http://cr.openjdk.java.net/~dsimms/6664815/
Still looking for one more review for this.
Thanks,
Marcus
On 04/04/2014 09:30 AM, Ivan Gerasimov wrote:
> Hi Marcus!
>
> While it's not critical and not really connected to the issue you're
> solving, wouldn't it be better to replace
> 344 p = utf8_write(p, base[index]);
> with
> 344 p = utf8_write(p,*c*);
> in src/share/vm/utilities/utf8.cpp?
>
> Sincerely yours,
> Ivan
>
>
> On 03.04.2014 17:17, Marcus Larsson wrote:
>> Hello,
>>
>> I would like reviews for the following bugfix removing a redundant
>> memcpy.
>> Built on all platforms and tested with JCK.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~dsimms/6664815/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-6664815
>>
>> Regards,
>> Marcus
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Fri Apr 4 11:36:13 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 4 Apr 2014 13:36:13 +0200
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
In-Reply-To: <533E8F7D.3010602@oracle.com>
References: <533D5F54.4060202@oracle.com> <533E5FA9.2030909@oracle.com>
<533E8F7D.3010602@oracle.com>
Message-ID: <18B5C5F1-AA4E-4201-9FA0-D155FF41BB96@oracle.com>
Still good!
Thanks,
/Staffan
On 4 apr 2014, at 12:54, Marcus Larsson wrote:
> Good point,
>
> Updated: http://cr.openjdk.java.net/~dsimms/6664815/
>
> Still looking for one more review for this.
>
> Thanks,
> Marcus
>
> On 04/04/2014 09:30 AM, Ivan Gerasimov wrote:
>> Hi Marcus!
>>
>> While it's not critical and not really connected to the issue you're solving, wouldn't it be better to replace
>> 344 p = utf8_write(p, base[index]);
>> with
>> 344 p = utf8_write(p, c);
>> in src/share/vm/utilities/utf8.cpp?
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 03.04.2014 17:17, Marcus Larsson wrote:
>>> Hello,
>>>
>>> I would like reviews for the following bugfix removing a redundant memcpy.
>>> Built on all platforms and tested with JCK.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~dsimms/6664815/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-6664815
>>>
>>> Regards,
>>> Marcus
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.holmes at oracle.com Fri Apr 4 12:26:37 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 04 Apr 2014 22:26:37 +1000
Subject: RFR(XXS) 6664815: Eliminate redundant memcpy operation in
jni_GetStringUTFRegion
In-Reply-To: <533E8F7D.3010602@oracle.com>
References: <533D5F54.4060202@oracle.com> <533E5FA9.2030909@oracle.com>
<533E8F7D.3010602@oracle.com>
Message-ID: <533EA4FD.2090202@oracle.com>
On 4/04/2014 8:54 PM, Marcus Larsson wrote:
> Good point,
>
> Updated: http://cr.openjdk.java.net/~dsimms/6664815/
>
>
> Still looking for one more review for this.
Looks okay to me.
David
-----
> Thanks,
> Marcus
>
> On 04/04/2014 09:30 AM, Ivan Gerasimov wrote:
>> Hi Marcus!
>>
>> While it's not critical and not really connected to the issue you're
>> solving, wouldn't it be better to replace
>> 344 p = utf8_write(p, base[index]);
>> with
>> 344 p = utf8_write(p,*c*);
>> in src/share/vm/utilities/utf8.cpp?
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 03.04.2014 17:17, Marcus Larsson wrote:
>>> Hello,
>>>
>>> I would like reviews for the following bugfix removing a redundant
>>> memcpy.
>>> Built on all platforms and tested with JCK.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~dsimms/6664815/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-6664815
>>>
>>> Regards,
>>> Marcus
>>>
>>>
>>
>
From markus.gronlund at oracle.com Fri Apr 4 15:56:51 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Fri, 4 Apr 2014 08:56:51 -0700 (PDT)
Subject: RFR(S): 8038624:interpretedVFrame::expressions() must respect
InterpreterOopMap for liveness
In-Reply-To: <533C7985.6020606@oracle.com>
References: <74f24048-4476-46db-ade9-8c5085b581c9@default>
<533C7985.6020606@oracle.com>
Message-ID: <12e437d6-45cf-4b05-80fb-dcf4c509f028@default>
Hi Coleen,
?
Deoptimization does not use this code for anything critical - deoptimization is based on compiledVFrame::expressions(), not InterpretedVFrame::expressions().
?
After deopting the compiled frame to an interpreter frame, there is an debug section in vframeArrayElement::unpack_on_stack (#ifndef PRODUCT which will call InterpretedVFrame::expressions() if you have set the TraceDeoptimization && Verbose), which is used for outputting debug information only.
?
Thanks
Markus
?
From: Coleen Phillimore
Sent: den 2 april 2014 22:57
To: hotspot-runtime-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8038624:interpretedVFrame::expressions() must respect InterpreterOopMap for liveness
?
Markus,
This is really disturbing because deoptimization uses this code to layout the interpreter frame (unpack_on_stack).? Bugs in deoptimization can be very subtle but we would see some bugs if this was wrong, I think.
Is this a recent failure and there was a change in some other area that made this crash?
I don't know why interpreter_frame_stack_size wouldn't be the same as oopmap.expression_stack_size() unless it doesn't include the pushed arguments?
There's some odd code I've never understood for deoptimization in interpreter/interpreter.cpp.?? I think you should have someone from the compiler group (added) who understands deoptimization review your change.
Coleen
On 4/2/14 10:29 AM, Markus Gr?nlund wrote:
Greetings,
?
Kindly asking for reviews for the following change:
?
Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624
https://bugs.openjdk.java.net/browse/JDK-8038344
?
Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8038624/webrev01/"http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/
?
Problem description:
?
An InterpreterOopMap for a particular bci position does not include expression/operand stack liveness info in the oop_mask/bit_mask if the bci is a call instruction, i.e. for the invoke* instructions (invokevirtual, invokespecial, invokestatic, invokedynamic, invokeinterface).
?
This leads to a discrepancy between what is actually on the expression/operand stack (given via fr().interpreter_frame_expression_stack_size()) and what is given in the liveness oop_mask/bit_mask (given via InterpreterOopMap) at a particular bci.
The code in interpretedVFrame::expressions() is currently based on information given from fr().interpreter_frame_expression_stack_size(), and will index into the retrieved oop_mask/bit_mask based on this information (expression slot nr + _max_locals). These indexes either:
1. Fetches a 0 (since no live info at that position in the mask) if the index is low enough to still be inside the bit_mask word boundary. It will then proceed to treat the expression slot (which might be a real reference) as a T_INT (0 is a value, 1 is a reference)
2. Indexes out of bounds for the oop_map/bit_mask (see https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up information outside that is not related to a liveness bit mask. If that position happens to yield a 1, but the real expression slot is a value ("v"), the system can assert "(obj->is_oop()) failed: not an oop: 0x00000001"
?
Tested by running:
?
nsk/jdi/*
?
?
Other info:
?
I dislike having to create a new StackValueCollection even though I know the length is 0 and it will not be actively used. However, this pattern of always creating and returning empty objects is prevalent in this piece of code and is not easily detangled.
?
?
Thanks in advance
Markus
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Fri Apr 4 16:02:26 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 04 Apr 2014 12:02:26 -0400
Subject: RFR(S): 8038624:interpretedVFrame::expressions() must respect
InterpreterOopMap for liveness
In-Reply-To: <12e437d6-45cf-4b05-80fb-dcf4c509f028@default>
References: <74f24048-4476-46db-ade9-8c5085b581c9@default>
<533C7985.6020606@oracle.com>
<12e437d6-45cf-4b05-80fb-dcf4c509f028@default>
Message-ID: <533ED792.5030805@oracle.com>
Hi Markus,
I double checked this myself and I agree with you. Your fix to this
code looks really good.
Before you check this in, can you add a short comment before line 338
why this doesn't equal fr().interpreter_frame_expression_stack_size();
in case someone wanders into this complicated code again? The comment
below in your RFR is fine (I don't need to read it again).
Thanks!
Coleen
On 4/4/14 11:56 AM, Markus Gr?nlund wrote:
>
> Hi Coleen,
>
> Deoptimization does not use this code for anything critical --
> deoptimization is based on compiledVFrame::expressions(), not
> InterpretedVFrame::expressions().
>
> After deopting the compiled frame to an interpreter frame, there is an
> debug section in vframeArrayElement::unpack_on_stack (#ifndef PRODUCT
> which will call InterpretedVFrame::expressions() if you have set the
> TraceDeoptimization && Verbose), which is used for outputting debug
> information only.
>
> Thanks
>
> Markus
>
> *From:*Coleen Phillimore
> *Sent:* den 2 april 2014 22:57
> *To:* hotspot-runtime-dev at openjdk.java.net;
> hotspot-compiler-dev at openjdk.java.net
> *Subject:* Re: RFR(S): 8038624:interpretedVFrame::expressions() must
> respect InterpreterOopMap for liveness
>
>
> Markus,
>
> This is really disturbing because deoptimization uses this code to
> layout the interpreter frame (unpack_on_stack). Bugs in
> deoptimization can be very subtle but we would see some bugs if this
> was wrong, I think.
> Is this a recent failure and there was a change in some other area
> that made this crash?
> I don't know why interpreter_frame_stack_size wouldn't be the same as
> oopmap.expression_stack_size() unless it doesn't include the pushed
> arguments?
>
> There's some odd code I've never understood for deoptimization in
> interpreter/interpreter.cpp. I think you should have someone from
> the compiler group (added) who understands deoptimization review your
> change.
>
> Coleen
>
> On 4/2/14 10:29 AM, Markus Gr?nlund wrote:
>
> Greetings,
>
> Kindly asking for reviews for the following change:
>
> Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624
>
> https://bugs.openjdk.java.net/browse/JDK-8038344
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/
>
>
> Problem description:
>
> An InterpreterOopMap for a particular bci position does not
> include expression/operand stack liveness info in the
> oop_mask/bit_mask if the bci is a call instruction, i.e. for the
> invoke* instructions (invokevirtual, invokespecial, invokestatic,
> invokedynamic, invokeinterface).
>
> This leads to a discrepancy between what is actually on the
> expression/operand stack (given via
> fr().interpreter_frame_expression_stack_size()) and what is given
> in the liveness oop_mask/bit_mask (given via InterpreterOopMap) at
> a particular bci.
>
> The code in interpretedVFrame::expressions() is currently based on
> information given from
> fr().interpreter_frame_expression_stack_size(), and will index
> into the retrieved oop_mask/bit_mask based on this information
> (expression slot nr + _max_locals). These indexes either:
>
> 1. Fetches a 0 (since no live info at that position in the mask)
> if the index is low enough to still be inside the bit_mask word
> boundary. It will then proceed to treat the expression slot (which
> might be a real reference) as a T_INT (0 is a value, 1 is a
> reference)
>
> 2. Indexes out of bounds for the oop_map/bit_mask (see
> https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up
> information outside that is not related to a liveness bit mask. If
> that position happens to yield a 1, but the real expression slot
> is a value ("v"), the system can assert "(obj->is_oop()) failed:
> not an oop: 0x00000001"
>
> Tested by running:
>
> nsk/jdi/*
>
> Other info:
>
> I dislike having to create a new StackValueCollection even though
> I know the length is 0 and it will not be actively used. However,
> this pattern of always creating and returning empty objects is
> prevalent in this piece of code and is not easily detangled.
>
> Thanks in advance
>
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From markus.gronlund at oracle.com Sun Apr 6 17:05:53 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Sun, 6 Apr 2014 10:05:53 -0700 (PDT)
Subject: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp can
crash VM
Message-ID: <3939f4d1-150e-408e-b2b5-7ae96b7387d7@default>
Greetings,
?
Kindly asking for reviews for this small fix:
?
Bug: https://bugs.openjdk.java.net/browse/JDK-8039348
Webrev: http://cr.openjdk.java.net/~mgronlun/8039348/webrev01/
?
Found when debugging:
-XX:+TraceDeoptimization -XX:+Verbose -Xcomp
?
Using -Xcomp can cause an uncommon trap in java/lang/String constructors before the [C value field has been assigned.
?
Thanks
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Sun Apr 6 18:24:24 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Sun, 6 Apr 2014 20:24:24 +0200
Subject: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp
can crash VM
In-Reply-To: <3939f4d1-150e-408e-b2b5-7ae96b7387d7@default>
References: <3939f4d1-150e-408e-b2b5-7ae96b7387d7@default>
Message-ID: <3E384F09-F461-411C-A67A-E53B352169F7@oracle.com>
You have changed the output when the ?value? field is not set from NULL to ??. Was this intentional?
/Staffan
On 6 apr 2014, at 19:05, Markus Gr?nlund wrote:
> Greetings,
>
> Kindly asking for reviews for this small fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039348
> Webrev: http://cr.openjdk.java.net/~mgronlun/8039348/webrev01/
>
> Found when debugging:
> -XX:+TraceDeoptimization -XX:+Verbose ?Xcomp
>
> Using ?Xcomp can cause an uncommon trap in java/lang/String constructors before the [C value field has been assigned.
>
> Thanks
> Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From markus.gronlund at oracle.com Sun Apr 6 18:51:16 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Sun, 6 Apr 2014 11:51:16 -0700 (PDT)
Subject: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp
can crash VM
In-Reply-To: <3E384F09-F461-411C-A67A-E53B352169F7@oracle.com>
References: <3939f4d1-150e-408e-b2b5-7ae96b7387d7@default>
<3E384F09-F461-411C-A67A-E53B352169F7@oracle.com>
Message-ID:
Yes. The java/lang/String object is not NULL but it's [C field is.
?
In the local/expression slots output, there is an object there, it's not NULL, it's being created.
?
/Markus
?
From: Staffan Larsen
Sent: den 6 april 2014 20:24
To: Markus Gr?nlund
Cc: serviceability-dev at openjdk.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp can crash VM
?
You have changed the output when the 'value' field is not set from NULL to "". Was this intentional?
?
/Staffan
?
On 6 apr 2014, at 19:05, Markus Gr?nlund wrote:
Greetings,
?
Kindly asking for reviews for this small fix:
?
Bug:?https://bugs.openjdk.java.net/browse/JDK-8039348
Webrev:?http://cr.openjdk.java.net/~mgronlun/8039348/webrev01/
?
Found when debugging:
-XX:+TraceDeoptimization -XX:+Verbose -Xcomp
?
Using -Xcomp can cause an uncommon trap in java/lang/String constructors before the [C value field has been assigned.
?
Thanks
Markus
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From markus.gronlund at oracle.com Sun Apr 6 19:07:55 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Sun, 6 Apr 2014 12:07:55 -0700 (PDT)
Subject: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp
can crash VM
In-Reply-To:
References: <3939f4d1-150e-408e-b2b5-7ae96b7387d7@default>
<3E384F09-F461-411C-A67A-E53B352169F7@oracle.com>
Message-ID:
Actually, now reflecting a bit more on it, since this uncommon trap happens while executing the constructor itself, one could argue that the object instance is not yet created.
?
In addition, the "normal" representation of the java/lang/String ?object in print() is the value of the [C array - so in that case it might very well be that "NULL" is? the value to output, since there is no [C.
?
I can keep "NULL" as is.
?
/Markus
?
?
?
From: Markus Gr?nlund
Sent: den 6 april 2014 20:51
To: Staffan Larsen
Cc: serviceability-dev at openjdk.net; hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp can crash VM
?
Yes. The java/lang/String object is not NULL but it's [C field is.
?
In the local/expression slots output, there is an object there, it's not NULL, it's being created.
?
/Markus
?
From: Staffan Larsen
Sent: den 6 april 2014 20:24
To: Markus Gr?nlund
Cc: HYPERLINK "mailto:serviceability-dev at openjdk.net"serviceability-dev at openjdk.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp can crash VM
?
You have changed the output when the 'value' field is not set from NULL to "". Was this intentional?
?
/Staffan
?
On 6 apr 2014, at 19:05, Markus Gr?nlund wrote:
?
Greetings,
?
Kindly asking for reviews for this small fix:
?
Bug:?https://bugs.openjdk.java.net/browse/JDK-8039348
Webrev:?http://cr.openjdk.java.net/~mgronlun/8039348/webrev01/
?
Found when debugging:
-XX:+TraceDeoptimization -XX:+Verbose -Xcomp
?
Using -Xcomp can cause an uncommon trap in java/lang/String constructors before the [C value field has been assigned.
?
Thanks
Markus
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Mon Apr 7 06:31:08 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 7 Apr 2014 08:31:08 +0200
Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException:
Command failed in target VM
In-Reply-To: <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com>
References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com>
<6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com>
<533514F4.8050906@oracle.com>
<48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com>
Message-ID: <4B0BFA9A-4970-4BDB-A2A0-BF6057EB7298@oracle.com>
Could I have an official Review of this change?
Thanks,
/Staffan
On 3 apr 2014, at 11:31, Staffan Larsen wrote:
> Thanks Serguei,
>
> I don?t think it is necessary to initialize ?end? since strtol will always set it.
>
> I still need an official Reviewer for this change.
>
> Thanks,
> /Staffan
>
> On 28 mar 2014, at 07:21, serguei.spitsyn at oracle.com wrote:
>
>> On 3/27/14 12:55 AM, Staffan Larsen wrote:
>>> Here is an updated webrev which incorporates Dmitry?s feedback:
>>>
>>> http://cr.openjdk.java.net/~sla/8038296/webrev.01/
>>
>>
>> It looks good.
>> The only suggestion is to initialize the 'end':
>> char* end;
>>
>> Not sure what value is better to use for initialization.
>> Probably, end = probe would work Ok.
>>
>> Thanks,
>> Serguei
>>>
>>> Thanks,
>>> /Staffan
>>>
>>> On 25 mar 2014, at 19:36, Dmitry Samersoff wrote:
>>>
>>>> Staffan,
>>>>
>>>>> Yes, that will find problems when trying to convert something like
>>>>> ?bla?. It will not capture the case where the input string is a too
>>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>>> both cases it looks like we need something like:
>>>>> errno = 0;
>>>>> char* end;
>>>>> int probe_typess = (int) strtol(probe, &end, 10);
>>>>> if (end == probe || errno) {
>>>>> return JNI_ERR;
>>>>> }
>>>> As probe_typess is positive and you are converting long to int
>>>> It's be better to check value boundaries explicitly:
>>>>
>>>> char* end;
>>>> long ptl = strtol(probe, &end, 10);
>>>> if (end == probe || ptl < 0 || ptl > MAX_INT) {
>>>> return JNI_ERR;
>>>> }
>>>>
>>>> int probe_typess = (int) ptl;
>>>>
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2014-03-25 17:35, Staffan Larsen wrote:
>>>>> On 25 mar 2014, at 13:46, Dmitry Samersoff
>>>>> wrote:
>>>>>
>>>>>> Staffan,
>>>>>>
>>>>>> strtol() sets errno in two cases -
>>>>>>
>>>>>> ERANGE if supplied value is less then LONG_MIN or greater than
>>>>>> LONG_MAX EINVAL if supplied base is not supported.
>>>>>>
>>>>>> if you pass probe == 'bla', strtol just return 0 and errno will not
>>>>>> be set. So I'm not sure that check for errno has any value here.
>>>>>>
>>>>>> One of possible way to check that supplied value is convertible to
>>>>>> long is
>>>>>>
>>>>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr ==
>>>>>> probe) { // we can't convert supplied value return JNI_ERR; }
>>>>> Yes, that will find problems when trying to convert something like
>>>>> ?bla?. It will not capture the case where the input string is a too
>>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>>> both cases it looks like we need something like:
>>>>>
>>>>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end,
>>>>> 10); if (end == probe || errno) { return JNI_ERR; }
>>>>>
>>>>>
>>>>> /Staffan
>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>>
>>>>>> On 2014-03-25 11:31, Staffan Larsen wrote:
>>>>>>> attachListener_solaris.cpp calls atoi() and then checks errno to
>>>>>>> see if any errors occurred. The problem is that atoi() does not
>>>>>>> set errno, so some old value of errno is checked which sometimes
>>>>>>> causes the function to fail.
>>>>>>>
>>>>>>> The fix is to replace atoi() with strtol() which does set errno.
>>>>>>> But errno is only set if an error occurred and not set to 0 in
>>>>>>> case of success. Thus, I set errno to 0 before calling strtol()
>>>>>>> and check the value afterwards.
>>>>>>>
>>>>>>> Verified with a JPRT run.
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038296
>>>>>>>
>>>>>>> Thanks, /Staffan
>>>>>>>
>>>>>>
>>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg,
>>>>>> Russia * I would love to change the world, but they won't give me
>>>>>> the sources.
>>>>
>>>> --
>>>> Dmitry Samersoff
>>>> Oracle Java development team, Saint Petersburg, Russia
>>>> * I would love to change the world, but they won't give me the sources.
>>
>
From serguei.spitsyn at oracle.com Mon Apr 7 07:05:57 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 07 Apr 2014 00:05:57 -0700
Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException:
Command failed in target VM
In-Reply-To: <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com>
References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com>
<6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com>
<533514F4.8050906@oracle.com>
<48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com>
Message-ID: <53424E55.1020907@oracle.com>
On 4/3/14 2:31 AM, Staffan Larsen wrote:
> Thanks Serguei,
>
> I don?t think it is necessary to initialize ?end? since strtol will always set it.
Ok.
>
> I still need an official Reviewer for this change.
I'm not an official reviewer yet.
Thanks,
Serguei
>
> Thanks,
> /Staffan
>
> On 28 mar 2014, at 07:21, serguei.spitsyn at oracle.com wrote:
>
>> On 3/27/14 12:55 AM, Staffan Larsen wrote:
>>> Here is an updated webrev which incorporates Dmitry?s feedback:
>>>
>>> http://cr.openjdk.java.net/~sla/8038296/webrev.01/
>>
>> It looks good.
>> The only suggestion is to initialize the 'end':
>> char* end;
>>
>> Not sure what value is better to use for initialization.
>> Probably, end = probe would work Ok.
>>
>> Thanks,
>> Serguei
>>> Thanks,
>>> /Staffan
>>>
>>> On 25 mar 2014, at 19:36, Dmitry Samersoff wrote:
>>>
>>>> Staffan,
>>>>
>>>>> Yes, that will find problems when trying to convert something like
>>>>> ?bla?. It will not capture the case where the input string is a too
>>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>>> both cases it looks like we need something like:
>>>>> errno = 0;
>>>>> char* end;
>>>>> int probe_typess = (int) strtol(probe, &end, 10);
>>>>> if (end == probe || errno) {
>>>>> return JNI_ERR;
>>>>> }
>>>> As probe_typess is positive and you are converting long to int
>>>> It's be better to check value boundaries explicitly:
>>>>
>>>> char* end;
>>>> long ptl = strtol(probe, &end, 10);
>>>> if (end == probe || ptl < 0 || ptl > MAX_INT) {
>>>> return JNI_ERR;
>>>> }
>>>>
>>>> int probe_typess = (int) ptl;
>>>>
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2014-03-25 17:35, Staffan Larsen wrote:
>>>>> On 25 mar 2014, at 13:46, Dmitry Samersoff
>>>>> wrote:
>>>>>
>>>>>> Staffan,
>>>>>>
>>>>>> strtol() sets errno in two cases -
>>>>>>
>>>>>> ERANGE if supplied value is less then LONG_MIN or greater than
>>>>>> LONG_MAX EINVAL if supplied base is not supported.
>>>>>>
>>>>>> if you pass probe == 'bla', strtol just return 0 and errno will not
>>>>>> be set. So I'm not sure that check for errno has any value here.
>>>>>>
>>>>>> One of possible way to check that supplied value is convertible to
>>>>>> long is
>>>>>>
>>>>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr ==
>>>>>> probe) { // we can't convert supplied value return JNI_ERR; }
>>>>> Yes, that will find problems when trying to convert something like
>>>>> ?bla?. It will not capture the case where the input string is a too
>>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>>> both cases it looks like we need something like:
>>>>>
>>>>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end,
>>>>> 10); if (end == probe || errno) { return JNI_ERR; }
>>>>>
>>>>>
>>>>> /Staffan
>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>>
>>>>>> On 2014-03-25 11:31, Staffan Larsen wrote:
>>>>>>> attachListener_solaris.cpp calls atoi() and then checks errno to
>>>>>>> see if any errors occurred. The problem is that atoi() does not
>>>>>>> set errno, so some old value of errno is checked which sometimes
>>>>>>> causes the function to fail.
>>>>>>>
>>>>>>> The fix is to replace atoi() with strtol() which does set errno.
>>>>>>> But errno is only set if an error occurred and not set to 0 in
>>>>>>> case of success. Thus, I set errno to 0 before calling strtol()
>>>>>>> and check the value afterwards.
>>>>>>>
>>>>>>> Verified with a JPRT run.
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038296
>>>>>>>
>>>>>>> Thanks, /Staffan
>>>>>>>
>>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg,
>>>>>> Russia * I would love to change the world, but they won't give me
>>>>>> the sources.
>>>> --
>>>> Dmitry Samersoff
>>>> Oracle Java development team, Saint Petersburg, Russia
>>>> * I would love to change the world, but they won't give me the sources.
From goetz.lindenmaier at sap.com Mon Apr 7 10:07:41 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 7 Apr 2014 10:07:41 +0000
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEADE9A@DEWDFEMB12A.global.corp.sap>
Hi,
could I please get a review of this change? It fixes a rather
obvious error, and is really simple.
Is runtime the wrong mainling list for interpreter changes? Should I
post to comp?
Best regards,
Goetz.
From: Lindenmaier, Goetz
Sent: Donnerstag, 3. April 2014 15:33
To: hotspot-runtime-dev at openjdk.java.net
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
Hi,
please review an test this small fix to the interpreters. I please need
a sponsor.
http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/
JNIHandleBlock::_top is an int field. Various places store into
this field using a pointer store. On 64-bit platforms
this can cause errors.
This change adapts the corresponding operations on sparc
and both x86 variants to use fixed 32-bit operations.
Best regards,
Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Mon Apr 7 17:33:02 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 07 Apr 2014 13:33:02 -0400
Subject: RFR: 8038296 sun/tools/jinfo/Basic.sh: java.io.IOException:
Command failed in target VM
In-Reply-To: <53424E55.1020907@oracle.com>
References: <5817E015-E567-4524-B685-8E1AE1E7CF36@oracle.com> <53317A9F.7050400@oracle.com> <5331CCB7.4090206@oracle.com> <6D3336E3-E5A1-45F9-9309-D2C777070342@oracle.com> <533514F4.8050906@oracle.com> <48DC532D-2D99-4106-90CA-5E3289A6256B@oracle.com>
<53424E55.1020907@oracle.com>
Message-ID: <5342E14E.4020801@oracle.com>
Looks good.
Coleen
On 4/7/14, 3:05 AM, serguei.spitsyn at oracle.com wrote:
> On 4/3/14 2:31 AM, Staffan Larsen wrote:
>> Thanks Serguei,
>>
>> I don?t think it is necessary to initialize ?end? since strtol will
>> always set it.
>
> Ok.
>
>>
>> I still need an official Reviewer for this change.
>
> I'm not an official reviewer yet.
>
>
> Thanks,
> Serguei
>
>>
>> Thanks,
>> /Staffan
>>
>> On 28 mar 2014, at 07:21, serguei.spitsyn at oracle.com wrote:
>>
>>> On 3/27/14 12:55 AM, Staffan Larsen wrote:
>>>> Here is an updated webrev which incorporates Dmitry?s feedback:
>>>>
>>>> http://cr.openjdk.java.net/~sla/8038296/webrev.01/
>>>
>>> It looks good.
>>> The only suggestion is to initialize the 'end':
>>> char* end;
>>>
>>> Not sure what value is better to use for initialization.
>>> Probably, end = probe would work Ok.
>>>
>>> Thanks,
>>> Serguei
>>>> Thanks,
>>>> /Staffan
>>>>
>>>> On 25 mar 2014, at 19:36, Dmitry Samersoff
>>>> wrote:
>>>>
>>>>> Staffan,
>>>>>
>>>>>> Yes, that will find problems when trying to convert something like
>>>>>> ?bla?. It will not capture the case where the input string is a too
>>>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>>>> both cases it looks like we need something like:
>>>>>> errno = 0;
>>>>>> char* end;
>>>>>> int probe_typess = (int) strtol(probe, &end, 10);
>>>>>> if (end == probe || errno) {
>>>>>> return JNI_ERR;
>>>>>> }
>>>>> As probe_typess is positive and you are converting long to int
>>>>> It's be better to check value boundaries explicitly:
>>>>>
>>>>> char* end;
>>>>> long ptl = strtol(probe, &end, 10);
>>>>> if (end == probe || ptl < 0 || ptl > MAX_INT) {
>>>>> return JNI_ERR;
>>>>> }
>>>>>
>>>>> int probe_typess = (int) ptl;
>>>>>
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 2014-03-25 17:35, Staffan Larsen wrote:
>>>>>> On 25 mar 2014, at 13:46, Dmitry Samersoff
>>>>>> wrote:
>>>>>>
>>>>>>> Staffan,
>>>>>>>
>>>>>>> strtol() sets errno in two cases -
>>>>>>>
>>>>>>> ERANGE if supplied value is less then LONG_MIN or greater than
>>>>>>> LONG_MAX EINVAL if supplied base is not supported.
>>>>>>>
>>>>>>> if you pass probe == 'bla', strtol just return 0 and errno will not
>>>>>>> be set. So I'm not sure that check for errno has any value here.
>>>>>>>
>>>>>>> One of possible way to check that supplied value is convertible to
>>>>>>> long is
>>>>>>>
>>>>>>> char *eptr = probe; strtol(probe, (char **)&eptr, 10); if (eptr ==
>>>>>>> probe) { // we can't convert supplied value return JNI_ERR; }
>>>>>> Yes, that will find problems when trying to convert something like
>>>>>> ?bla?. It will not capture the case where the input string is a too
>>>>>> large (or small) value (value < LONG_MIN or > LONG_MAX). To capture
>>>>>> both cases it looks like we need something like:
>>>>>>
>>>>>> errno = 0; char* end; int probe_typess = (int) strtol(probe, &end,
>>>>>> 10); if (end == probe || errno) { return JNI_ERR; }
>>>>>>
>>>>>>
>>>>>> /Staffan
>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>>
>>>>>>> On 2014-03-25 11:31, Staffan Larsen wrote:
>>>>>>>> attachListener_solaris.cpp calls atoi() and then checks errno to
>>>>>>>> see if any errors occurred. The problem is that atoi() does not
>>>>>>>> set errno, so some old value of errno is checked which sometimes
>>>>>>>> causes the function to fail.
>>>>>>>>
>>>>>>>> The fix is to replace atoi() with strtol() which does set errno.
>>>>>>>> But errno is only set if an error occurred and not set to 0 in
>>>>>>>> case of success. Thus, I set errno to 0 before calling strtol()
>>>>>>>> and check the value afterwards.
>>>>>>>>
>>>>>>>> Verified with a JPRT run.
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8038296/webrev.00/ bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038296
>>>>>>>>
>>>>>>>> Thanks, /Staffan
>>>>>>>>
>>>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg,
>>>>>>> Russia * I would love to change the world, but they won't give me
>>>>>>> the sources.
>>>>> --
>>>>> Dmitry Samersoff
>>>>> Oracle Java development team, Saint Petersburg, Russia
>>>>> * I would love to change the world, but they won't give me the
>>>>> sources.
>
From coleen.phillimore at oracle.com Mon Apr 7 17:41:05 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 07 Apr 2014 13:41:05 -0400
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEADE9A@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEADE9A@DEWDFEMB12A.global.corp.sap>
Message-ID: <5342E331.7090108@oracle.com>
The change looks fine. I can sponsor it unless someone else would like to.
Thanks,
Coleen
On 4/7/14, 6:07 AM, Lindenmaier, Goetz wrote:
>
> Hi,
>
> could I please get a review of this change? It fixes a rather
>
> obvious error, and is really simple.
>
> Is runtime the wrong mainling list for interpreter changes? Should I
>
> post to comp?
>
> Best regards,
>
> Goetz.
>
> *From:*Lindenmaier, Goetz
> *Sent:* Donnerstag, 3. April 2014 15:33
> *To:* hotspot-runtime-dev at openjdk.java.net
> *Subject:* RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
>
> Hi,
>
> please review an test this small fix to the interpreters. I please need
>
> a sponsor.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/
>
>
> JNIHandleBlock::_top is an int field. Various places store into
>
> this field using a pointer store. On 64-bit platforms
>
> this can cause errors.
>
> This change adapts the corresponding operations on sparc
>
> and both x86 variants to use fixed 32-bit operations.
>
> Best regards,
>
> Goetz.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vladimir.kozlov at oracle.com Mon Apr 7 17:55:57 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 07 Apr 2014 10:55:57 -0700
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
In-Reply-To: <5342E331.7090108@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEADE9A@DEWDFEMB12A.global.corp.sap>
<5342E331.7090108@oracle.com>
Message-ID: <5342E6AD.80402@oracle.com>
Fix is good but it requires closed changes which we need to prepare
before the push.
Thanks,
Vladimir
On 4/7/14 10:41 AM, Coleen Phillimore wrote:
>
> The change looks fine. I can sponsor it unless someone else would like to.
> Thanks,
> Coleen
>
> On 4/7/14, 6:07 AM, Lindenmaier, Goetz wrote:
>>
>> Hi,
>>
>> could I please get a review of this change? It fixes a rather
>>
>> obvious error, and is really simple.
>>
>> Is runtime the wrong mainling list for interpreter changes? Should I
>>
>> post to comp?
>>
>> Best regards,
>>
>> Goetz.
>>
>> *From:*Lindenmaier, Goetz
>> *Sent:* Donnerstag, 3. April 2014 15:33
>> *To:* hotspot-runtime-dev at openjdk.java.net
>> *Subject:* RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
>>
>> Hi,
>>
>> please review an test this small fix to the interpreters. I please need
>>
>> a sponsor.
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/
>>
>>
>> JNIHandleBlock::_top is an int field. Various places store into
>>
>> this field using a pointer store. On 64-bit platforms
>>
>> this can cause errors.
>>
>> This change adapts the corresponding operations on sparc
>>
>> and both x86 variants to use fixed 32-bit operations.
>>
>> Best regards,
>>
>> Goetz.
>>
>
From staffan.larsen at oracle.com Mon Apr 7 18:08:34 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 7 Apr 2014 20:08:34 +0200
Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing
on all platforms
Message-ID: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com>
The problem here is that the code for finding local VMs is not looking for the data in the correct place.
When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place.
(*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths.
The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory.
(Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)).
The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there.
Thanks,
/Staffan
From markus.gronlund at oracle.com Mon Apr 7 18:24:23 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Mon, 7 Apr 2014 11:24:23 -0700 (PDT)
Subject: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp
can crash VM
In-Reply-To:
References: <3939f4d1-150e-408e-b2b5-7ae96b7387d7@default>
<3E384F09-F461-411C-A67A-E53B352169F7@oracle.com>
Message-ID: <0587b71c-04a4-4471-a67a-bd7ebfad0866@default>
Hi again,
?
Updated the webrev to give a bit more descriptive message for debugging purposes:
?
Webrev02: http://cr.openjdk.java.net/~mgronlun/8039348/webrev02/
?
Thanks again
Markus
?
?
From: Markus Gr?nlund
Sent: den 6 april 2014 21:08
To: Staffan Larsen
Cc: serviceability-dev at openjdk.net; hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp can crash VM
?
Actually, now reflecting a bit more on it, since this uncommon trap happens while executing the constructor itself, one could argue that the object instance is not yet created.
?
In addition, the "normal" representation of the java/lang/String ?object in print() is the value of the [C array - so in that case it might very well be that "NULL" is? the value to output, since there is no [C.
?
I can keep "NULL" as is.
?
/Markus
?
?
?
From: Markus Gr?nlund
Sent: den 6 april 2014 20:51
To: Staffan Larsen
Cc: HYPERLINK "mailto:serviceability-dev at openjdk.net"serviceability-dev at openjdk.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net
Subject: RE: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp can crash VM
?
Yes. The java/lang/String object is not NULL but it's [C field is.
?
In the local/expression slots output, there is an object there, it's not NULL, it's being created.
?
/Markus
?
From: Staffan Larsen
Sent: den 6 april 2014 20:24
To: Markus Gr?nlund
Cc: HYPERLINK "mailto:serviceability-dev at openjdk.net"serviceability-dev at openjdk.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp can crash VM
?
You have changed the output when the 'value' field is not set from NULL to "". Was this intentional?
?
/Staffan
?
On 6 apr 2014, at 19:05, Markus Gr?nlund wrote:
?
Greetings,
?
Kindly asking for reviews for this small fix:
?
Bug:?https://bugs.openjdk.java.net/browse/JDK-8039348
Webrev:?http://cr.openjdk.java.net/~mgronlun/8039348/webrev01/
?
Found when debugging:
-XX:+TraceDeoptimization -XX:+Verbose -Xcomp
?
Using -Xcomp can cause an uncommon trap in java/lang/String constructors before the [C value field has been assigned.
?
Thanks
Markus
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Mon Apr 7 19:19:03 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 7 Apr 2014 21:19:03 +0200
Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java
failing on all platforms
In-Reply-To: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com>
References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com>
Message-ID: <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com>
And the links:
bug: https://bugs.openjdk.java.net/browse/JDK-8033104
webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/
Sorry about that,
/Staffan
On 7 apr 2014, at 20:08, Staffan Larsen wrote:
>
> The problem here is that the code for finding local VMs is not looking for the data in the correct place.
>
> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place.
>
> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths.
>
> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory.
>
> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)).
>
> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there.
>
> Thanks,
> /Staffan
From vladimir.kozlov at oracle.com Mon Apr 7 19:32:45 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 07 Apr 2014 12:32:45 -0700
Subject: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose -Xcomp
can crash VM
In-Reply-To: <0587b71c-04a4-4471-a67a-bd7ebfad0866@default>
References: <3939f4d1-150e-408e-b2b5-7ae96b7387d7@default> <3E384F09-F461-411C-A67A-E53B352169F7@oracle.com>
<0587b71c-04a4-4471-a67a-bd7ebfad0866@default>
Message-ID: <5342FD5D.8050106@oracle.com>
Hi, Markus
Thank you for fixing this. Please, keep "NULL" output as it was before.
Otherwise it is good.
Thanks,
Vladimir
On 4/7/14 11:24 AM, Markus Gr?nlund wrote:
> Hi again,
>
> Updated the webrev to give a bit more descriptive message for debugging
> purposes:
>
> Webrev02: http://cr.openjdk.java.net/~mgronlun/8039348/webrev02/
>
> Thanks again
>
> Markus
>
> *From:*Markus Gr?nlund
> *Sent:* den 6 april 2014 21:08
> *To:* Staffan Larsen
> *Cc:* serviceability-dev at openjdk.net; hotspot-runtime-dev at openjdk.java.net
> *Subject:* RE: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose
> -Xcomp can crash VM
>
> Actually, now reflecting a bit more on it, since this uncommon trap
> happens while executing the constructor itself, one could argue that the
> object instance is not yet created.
>
> In addition, the ?normal? representation of the java/lang/String object
> in print() is the value of the [C array ? so in that case it might very
> well be that ?NULL? is the value to output, since there is no [C.
>
> I can keep ?NULL? as is.
>
> /Markus
>
> *From:*Markus Gr?nlund
> *Sent:* den 6 april 2014 20:51
> *To:* Staffan Larsen
> *Cc:* serviceability-dev at openjdk.net
> ;
> hotspot-runtime-dev at openjdk.java.net
>
> *Subject:* RE: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose
> -Xcomp can crash VM
>
> Yes. The java/lang/String object is not NULL but it?s [C field is.
>
> In the local/expression slots output, there is an object there, it?s not
> NULL, it?s being created.
>
> /Markus
>
> *From:*Staffan Larsen
> *Sent:* den 6 april 2014 20:24
> *To:* Markus Gr?nlund
> *Cc:* serviceability-dev at openjdk.net
> ;
> hotspot-runtime-dev at openjdk.java.net
>
> *Subject:* Re: RFR(XXS): 8039348: -XX:+TraceDeoptimization -XX:+Verbose
> -Xcomp can crash VM
>
> You have changed the output when the ?value? field is not set from NULL
> to ??. Was this intentional?
>
> /Staffan
>
> On 6 apr 2014, at 19:05, Markus Gr?nlund > wrote:
>
> Greetings,
>
> Kindly asking for reviews for this small fix:
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8039348
>
> Webrev:http://cr.openjdk.java.net/~mgronlun/8039348/webrev01/
>
> Found when debugging:
>
> -XX:+TraceDeoptimization -XX:+Verbose ?Xcomp
>
> Using ?Xcomp can cause an uncommon trap in java/lang/String constructors
> before the [C value field has been assigned.
>
> Thanks
>
> Markus
>
From goetz.lindenmaier at sap.com Mon Apr 7 21:19:21 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 7 Apr 2014 21:19:21 +0000
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
In-Reply-To: <5342E331.7090108@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEADE9A@DEWDFEMB12A.global.corp.sap>
<5342E331.7090108@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAE052@DEWDFEMB12A.global.corp.sap>
Hi Coleen,
thanks for the review and the sponsoring!
Sorry I can't help with closed changes, I didn't expect any
with this one.
Best regards,
Goetz.
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore
Sent: Monday, April 07, 2014 7:41 PM
To: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
The change looks fine. I can sponsor it unless someone else would like to.
Thanks,
Coleen
On 4/7/14, 6:07 AM, Lindenmaier, Goetz wrote:
Hi,
could I please get a review of this change? It fixes a rather
obvious error, and is really simple.
Is runtime the wrong mainling list for interpreter changes? Should I
post to comp?
Best regards,
Goetz.
From: Lindenmaier, Goetz
Sent: Donnerstag, 3. April 2014 15:33
To: hotspot-runtime-dev at openjdk.java.net
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
Hi,
please review an test this small fix to the interpreters. I please need
a sponsor.
http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/
JNIHandleBlock::_top is an int field. Various places store into
this field using a pointer store. On 64-bit platforms
this can cause errors.
This change adapts the corresponding operations on sparc
and both x86 variants to use fixed 32-bit operations.
Best regards,
Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From goetz.lindenmaier at sap.com Mon Apr 7 21:20:03 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 7 Apr 2014 21:20:03 +0000
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
In-Reply-To: <5342E6AD.80402@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEADE9A@DEWDFEMB12A.global.corp.sap>
<5342E331.7090108@oracle.com> <5342E6AD.80402@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEAE06D@DEWDFEMB12A.global.corp.sap>
Thanks for the review, Vladimir!
Best regards,
Goetz
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Monday, April 07, 2014 7:56 PM
To: hotspot-runtime-dev at openjdk.java.net
Cc: Lindenmaier, Goetz
Subject: Re: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
Fix is good but it requires closed changes which we need to prepare
before the push.
Thanks,
Vladimir
On 4/7/14 10:41 AM, Coleen Phillimore wrote:
>
> The change looks fine. I can sponsor it unless someone else would like to.
> Thanks,
> Coleen
>
> On 4/7/14, 6:07 AM, Lindenmaier, Goetz wrote:
>>
>> Hi,
>>
>> could I please get a review of this change? It fixes a rather
>>
>> obvious error, and is really simple.
>>
>> Is runtime the wrong mainling list for interpreter changes? Should I
>>
>> post to comp?
>>
>> Best regards,
>>
>> Goetz.
>>
>> *From:*Lindenmaier, Goetz
>> *Sent:* Donnerstag, 3. April 2014 15:33
>> *To:* hotspot-runtime-dev at openjdk.java.net
>> *Subject:* RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
>>
>> Hi,
>>
>> please review an test this small fix to the interpreters. I please need
>>
>> a sponsor.
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/
>>
>>
>> JNIHandleBlock::_top is an int field. Various places store into
>>
>> this field using a pointer store. On 64-bit platforms
>>
>> this can cause errors.
>>
>> This change adapts the corresponding operations on sparc
>>
>> and both x86 variants to use fixed 32-bit operations.
>>
>> Best regards,
>>
>> Goetz.
>>
>
From vladimir.kozlov at oracle.com Mon Apr 7 21:45:23 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 07 Apr 2014 14:45:23 -0700
Subject: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEAE06D@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEADE9A@DEWDFEMB12A.global.corp.sap> <5342E331.7090108@oracle.com>
<5342E6AD.80402@oracle.com>
<4295855A5C1DE049A61835A1887419CC2CEAE06D@DEWDFEMB12A.global.corp.sap>
Message-ID: <53431C73.7080901@oracle.com>
Turns out that we don't need closed changes. We can push this as it is.
Thanks,
Vladimir
On 4/7/14 2:20 PM, Lindenmaier, Goetz wrote:
> Thanks for the review, Vladimir!
>
> Best regards,
> Goetz
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Monday, April 07, 2014 7:56 PM
> To: hotspot-runtime-dev at openjdk.java.net
> Cc: Lindenmaier, Goetz
> Subject: Re: RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
>
> Fix is good but it requires closed changes which we need to prepare
> before the push.
>
> Thanks,
> Vladimir
>
> On 4/7/14 10:41 AM, Coleen Phillimore wrote:
>>
>> The change looks fine. I can sponsor it unless someone else would like to.
>> Thanks,
>> Coleen
>>
>> On 4/7/14, 6:07 AM, Lindenmaier, Goetz wrote:
>>>
>>> Hi,
>>>
>>> could I please get a review of this change? It fixes a rather
>>>
>>> obvious error, and is really simple.
>>>
>>> Is runtime the wrong mainling list for interpreter changes? Should I
>>>
>>> post to comp?
>>>
>>> Best regards,
>>>
>>> Goetz.
>>>
>>> *From:*Lindenmaier, Goetz
>>> *Sent:* Donnerstag, 3. April 2014 15:33
>>> *To:* hotspot-runtime-dev at openjdk.java.net
>>> *Subject:* RFR (S): 8039146: Fix 64-bit store to int JNIHandleBlock::_top
>>>
>>> Hi,
>>>
>>> please review an test this small fix to the interpreters. I please need
>>>
>>> a sponsor.
>>>
>>> http://cr.openjdk.java.net/~goetz/webrevs/8039146-intSt/webrev.00/
>>>
>>>
>>> JNIHandleBlock::_top is an int field. Various places store into
>>>
>>> this field using a pointer store. On 64-bit platforms
>>>
>>> this can cause errors.
>>>
>>> This change adapts the corresponding operations on sparc
>>>
>>> and both x86 variants to use fixed 32-bit operations.
>>>
>>> Best regards,
>>>
>>> Goetz.
>>>
>>
From staffan.larsen at oracle.com Tue Apr 8 09:38:43 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 8 Apr 2014 11:38:43 +0200
Subject: RR(S,
TEST) JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit
linux
In-Reply-To: <5322C06E.3070203@oracle.com>
References: <5321B267.1010904@oracle.com> <53222C6B.9070907@oracle.com>
<5322C06E.3070203@oracle.com>
Message-ID: <80174D17-79E5-4417-8270-457A153A13D9@oracle.com>
Looks ok. Eventually these kinds of tests should be compiled when the product is compiled, not when the tests are bang run.
/Staffan
On 14 mar 2014, at 09:40, Dmitry Samersoff wrote:
> Serguei,
>
> Thank you for review.
>
> On 2014-03-14 02:08, serguei.spitsyn at oracle.com wrote:
>
>> The fix looks good and seems to be a nice cleanup.
>>
>> Do you see this test always failing without your fix?
>
> It's always testing COMPILEJAVA not TESTJAVA so if both
> points to the same image - test works as expected, if not - test result
> is not predictable.
>
>> It is not clear if it fixes the original issue.
>> But this step seems to be in the right direction anyway.
>
> Yes, I'm not sure it the root of crash. But it's better to fix it.
>
> -Dmitry
>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 3/13/14 6:28 AM, Dmitry Samersoff wrote:
>>> Hi Everyone,
>>>
>>> Please review test-only fix:
>>>
>>> JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8037279/webrev.01/
>>>
>>> The test has it's own java launcher. This launcher compiles against
>>> $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java.
>>>
>>> Also I'd changed the test to use variables from test_env.sh
>>>
>>> -Dmitry
>>>
>>
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
From dmitry.samersoff at oracle.com Tue Apr 8 09:40:09 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 08 Apr 2014 13:40:09 +0400
Subject: RR(S, TEST) JDK-8037279: runtime/6929067/Test6929067.sh crashes
on 32bit linux
In-Reply-To: <80174D17-79E5-4417-8270-457A153A13D9@oracle.com>
References: <5321B267.1010904@oracle.com> <53222C6B.9070907@oracle.com>
<5322C06E.3070203@oracle.com>
<80174D17-79E5-4417-8270-457A153A13D9@oracle.com>
Message-ID: <5343C3F9.40603@oracle.com>
Staffan,
On 2014-04-08 13:38, Staffan Larsen wrote:
> Looks ok. Eventually these kinds of tests should be compiled when the product is compiled, not when the tests are bang run.
Thanks. Yes, I agree.
-Dmitry
>
> /Staffan
>
> On 14 mar 2014, at 09:40, Dmitry Samersoff wrote:
>
>> Serguei,
>>
>> Thank you for review.
>>
>> On 2014-03-14 02:08, serguei.spitsyn at oracle.com wrote:
>>
>>> The fix looks good and seems to be a nice cleanup.
>>>
>>> Do you see this test always failing without your fix?
>>
>> It's always testing COMPILEJAVA not TESTJAVA so if both
>> points to the same image - test works as expected, if not - test result
>> is not predictable.
>>
>>> It is not clear if it fixes the original issue.
>>> But this step seems to be in the right direction anyway.
>>
>> Yes, I'm not sure it the root of crash. But it's better to fix it.
>>
>> -Dmitry
>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 3/13/14 6:28 AM, Dmitry Samersoff wrote:
>>>> Hi Everyone,
>>>>
>>>> Please review test-only fix:
>>>>
>>>> JDK-8037279: runtime/6929067/Test6929067.sh crashes on 32bit linux
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8037279/webrev.01/
>>>>
>>>> The test has it's own java launcher. This launcher compiles against
>>>> $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java.
>>>>
>>>> Also I'd changed the test to use variables from test_env.sh
>>>>
>>>> -Dmitry
>>>>
>>>
>>
>>
>> --
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the sources.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
From staffan.larsen at oracle.com Tue Apr 8 09:40:33 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 8 Apr 2014 11:40:33 +0200
Subject: RR(S,
TEST) JDK-8029139: [TESTBUG] runtime/InitialThreadOverflow/testme.sh
fails with exit code 127
In-Reply-To: <5321B30A.6010205@oracle.com>
References: <5321B30A.6010205@oracle.com>
Message-ID: <837EA54F-6F9C-4294-B4D0-C167AEC7088C@oracle.com>
Looks good.
Thanks,
/Staffan
On 13 mar 2014, at 14:30, Dmitry Samersoff wrote:
> Hi Everyone,
>
> Please review test-only fix:
>
> JDK-8029139: [TESTBUG] runtime/InitialThreadOverflow/testme.sh fails
> with exit code 127
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8029139/webrev.01/
>
> The test has it's own java launcher. This launcher compiles against
> $TESTJAVA but LD_LIBRARY_PATH set to $COMPILE java.
>
> Also I'd changed the test to be C not C++ as C compilation seems to be
> more reliable on test hosts.
>
> -Dmitry
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
From markus.gronlund at oracle.com Tue Apr 8 11:52:09 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Tue, 8 Apr 2014 04:52:09 -0700 (PDT)
Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java
failing on all platforms
In-Reply-To: <3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com>
References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com>
<3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com>
Message-ID: <5b42d4a9-4606-4fc0-9104-a2659eee7e2a@default>
Hi Staffan,
I think it looks good.
Some minor things:
src/share/native/sun/misc/VMSupport.c:
line 60: There is some weirdness with the indentation.
src/share/javavm/export/jvm.h (both Hotspot and JDK):
You might want to consider co-locating
114 JNIEXPORT jstring JNICALL
115 JVM_GetTemporaryDirectory(JNIEnv *env);
with
1334 JNIEXPORT jobject JNICALL
1335 JVM_InitAgentProperties(JNIEnv *env, jobject agent_props);
Other than that I thinks good - thanks for fixing this.
/Markus
-----Original Message-----
From: Staffan Larsen
Sent: den 7 april 2014 21:19
To: Staffan Larsen
Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev
Subject: Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
And the links:
bug: https://bugs.openjdk.java.net/browse/JDK-8033104
webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/
Sorry about that,
/Staffan
On 7 apr 2014, at 20:08, Staffan Larsen wrote:
>
> The problem here is that the code for finding local VMs is not looking for the data in the correct place.
>
> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place.
>
> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths.
>
> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory.
>
> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)).
>
> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there.
>
> Thanks,
> /Staffan
From staffan.larsen at oracle.com Tue Apr 8 14:21:47 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 8 Apr 2014 16:21:47 +0200
Subject: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java
failing on all platforms
In-Reply-To: <5b42d4a9-4606-4fc0-9104-a2659eee7e2a@default>
References: <52A644A0-6EF1-44F2-BAAF-11F035EF585A@oracle.com>
<3D74F5CF-1294-45E7-AAB2-761D0E485625@oracle.com>
<5b42d4a9-4606-4fc0-9104-a2659eee7e2a@default>
Message-ID: <1D53CA94-1A49-457E-A6F9-8B94A17B2B66@oracle.com>
Thanks Marcus,
I will fix those two issues before pushing.
/Staffan
On 8 apr 2014, at 13:52, Markus Gr?nlund wrote:
> Hi Staffan,
>
> I think it looks good.
>
> Some minor things:
>
> src/share/native/sun/misc/VMSupport.c:
>
> line 60: There is some weirdness with the indentation.
>
> src/share/javavm/export/jvm.h (both Hotspot and JDK):
>
> You might want to consider co-locating
>
> 114 JNIEXPORT jstring JNICALL
> 115 JVM_GetTemporaryDirectory(JNIEnv *env);
>
> with
>
> 1334 JNIEXPORT jobject JNICALL
> 1335 JVM_InitAgentProperties(JNIEnv *env, jobject agent_props);
>
>
> Other than that I thinks good - thanks for fixing this.
>
> /Markus
>
>
> -----Original Message-----
> From: Staffan Larsen
> Sent: den 7 april 2014 21:19
> To: Staffan Larsen
> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev
> Subject: Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
>
> And the links:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8033104
> webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/
>
> Sorry about that,
> /Staffan
>
> On 7 apr 2014, at 20:08, Staffan Larsen wrote:
>
>>
>> The problem here is that the code for finding local VMs is not looking for the data in the correct place.
>>
>> When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place.
>>
>> (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths.
>>
>> The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory.
>>
>> (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)).
>>
>> The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there.
>>
>> Thanks,
>> /Staffan
>
From markus.gronlund at oracle.com Wed Apr 9 12:04:03 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 9 Apr 2014 05:04:03 -0700 (PDT)
Subject: RFR(S): 8039458: Ensure consistency of Monitor/Mutex lock
acquisitions in relation to safepoint protocol
Message-ID:
Greetings,
?
Kindly asking for reviews for the following bug fix/enhancement
?
Webrev: http://cr.openjdk.java.net/~mgronlun/8039458/webrev01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8039458
?
Problem:
?
VM code acquire Monitor/Mutex locks by respecting the correct lock order, which is enforced in debug builds (asserts). This is great.
?
However, you could be taking locks in the correct order and everything might work just fine during development and testing (even product) but depending on runtime circumstances (load/concurrency), the way the lock(s) was acquired, i.e. the lock acquisition mode, can lead to very hard to debug problems (hangs/deadlocks). This is primarily related to the lock acquisition mode option "Mutex::_no_safepoint_check_flag" by which you inform your intent to respect or not-respect the safepoint protocol during lock acquisition/ownership.
If a lock has already been acquired by a thread by passing the Mutex::_no_safepoint_check_flag to circumvent the safepoint protocol, the thread must *not* be allowed to attempt taking yet another lock on which it *might* block ( a lock which was not acquired by passing Mutex::_no_safepoint_check_flag in its acquisition operation), as such a lock would be participating in the safepoint protocol.
?
Today, doing this mistake will work just fine _if the lock is currently uncontended_ which it normally is in development/testing situations. However, once the lock then becomes contended (highly volatile pressured/concurrent product deployment) you might get the worst kind of issues to debug (hangs/deadlocks).
?
Naturally and as always, you have to very careful when you are taking locks using the Mutex::_no_safepoint_check_flag -however it can be very hard to determine what other code you can safely call once you are the owner of a Mutex::_no_safepoint_check_flag:ed lock ?- and ?today there is nothing but the developers attention to details that will find/help stay clear of this. I think we can do better here in enforcing some invariants in code for preempting potential deadlock prone situations.
?
Description:
?
Add debug assertions that enforce correct usages of the Mutex::_no_safepoint_check_flag when taking multiple locks.
This suggestion leverages much of the existing code targeting enforcement of lock ordering- this is a simple additive change to also add invariant checking on "lock acquisition mode".
?
Do note this primarily targets Java Threads running in the VM.
?
Also included code comment:
?
/*
?* Ensure consistency of Monitor/Mutex lock acquisitions
?* for Java Threads running inside the VM.
?*
?* If a thread has already acquired lock(s) using
?* "Mutex::_no_safepoint_check_flag" (effectively going outside the
?* safepoint protocol), the thread should be disallowed to acquire any
?* additional lock which _is_ participating in the safepoint protocol.
?*
?* If a "safepoint protocol aware" lock is contended, and the thread entering
?* is unable to "fast acquire" the lock using cas/try_spin,
?* it will need to block/park. Blocking on a contended lock involves a
?* state transition and a potential SafepointSynchronize::block() call.
?* Transitioning to a blocked state still holding "Mutex::_no_safepoint_check_flag"
?* acquired locks is allowed, but is *very* deadlock prone.
?*
?* The effect of allowing this state to happen without checking is subtle
?* and hard to debug since a problem might only appear under heavy load and
?* only in situations with increased concurrency levels (product builds).
?*
?*/
?
Testing:
Artificial code changes to MutexLocker and Mutex::_no_safepoint_check_flag on certain locks for detecting potential deadlock situations.
Speccjbb2005
Kitchensink
?
Thank you
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From yasuenag at gmail.com Wed Apr 9 13:22:23 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 09 Apr 2014 22:22:23 +0900
Subject: -XX:MetaspaceSize is correct?
Message-ID: <5345498F.20904@gmail.com>
Hi all,
I checked initial metaspace size through jcmd PerfCounter.print .
However, it seems to be incorrect:
- Java command:
java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
- Output from -XX:+PrintFlagsFinal:
uintx MetaspaceSize = 21807104 {pd product}
- Result of "PerfCounter.print"
sun.gc.metaspace.capacity=4194304
sun.gc.metaspace.maxCapacity=8388608
sun.gc.metaspace.minCapacity=0
I checked metaspace.cpp, initial size of metaspace is detected by
InitialBootClassLoaderMetaspaceSize.
However, description of MetaspaceSize in globals.hpp is
"Initial size of Metaspaces (in bytes)" .
Is description of MetaspaceSize is correct?
And this behavior is correct?
I have two plan for this mismatch:
A) Change description of MetaspaceSize
MetaspaceSize is used to HWM in metaspace.cpp .
So we should change description for this behavior.
------------
diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
+++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
@@ -3160,7 +3156,7 @@
"non-daemon thread (in bytes)") \
\
product_pd(uintx, MetaspaceSize, \
- "Initial size of Metaspaces (in bytes)") \
+ "Initial HWM of Metaspaces (in bytes)") \
\
product(uintx, MaxMetaspaceSize, max_uintx, \
"Maximum size of Metaspaces (in bytes)") \
------------
B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
metaspace.
InitialBootClassLoaderMetaspaceSize is only to use for it.
Thus we should remove this option and use MetaspaceSize to initialize
metaspace.
------------
diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
--- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
+++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
@@ -3172,7 +3172,7 @@
#endif
// Initialize these before initializing the VirtualSpaceList
- _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize / BytesPerWord;
+ _first_chunk_word_size = MetaspaceSize / BytesPerWord;
_first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
// Make the first class chunk bigger than a medium chunk so it's not put
// on the medium chunk list. The next chunk will be small and progress
diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
+++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
@@ -2333,10 +2333,6 @@
develop(bool, TraceClassLoaderData, false, \
"Trace class loader loader_data lifetime") \
\
- product(uintx, InitialBootClassLoaderMetaspaceSize, \
- NOT_LP64(2200*K) LP64_ONLY(4*M), \
- "Initial size of the boot class loader data metaspace") \
- \
product(bool, TraceGen0Time, false, \
"Trace accumulated time for Gen 0 collection") \
\
------------
I prefer "B" .
Because, I guess many users think MetaspaceSize decides initial
metaspace size.
If my idea is correct, I will file this to JBS and upload patch to webrev.
Thanks,
Yasumasa
From jon.masamitsu at oracle.com Wed Apr 9 21:51:44 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 09 Apr 2014 14:51:44 -0700
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <5345498F.20904@gmail.com>
References: <5345498F.20904@gmail.com>
Message-ID: <5345C0F0.7020606@oracle.com>
On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
> Hi all,
>
> I checked initial metaspace size through jcmd PerfCounter.print .
> However, it seems to be incorrect:
>
> - Java command:
> java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>
> - Output from -XX:+PrintFlagsFinal:
> uintx MetaspaceSize =
> 21807104 {pd product}
>
> - Result of "PerfCounter.print"
> sun.gc.metaspace.capacity=4194304
> sun.gc.metaspace.maxCapacity=8388608
> sun.gc.metaspace.minCapacity=0
>
>
> I checked metaspace.cpp, initial size of metaspace is detected by
> InitialBootClassLoaderMetaspaceSize.
> However, description of MetaspaceSize in globals.hpp is
> "Initial size of Metaspaces (in bytes)" .
>
> Is description of MetaspaceSize is correct?
Description is not correct.
> And this behavior is correct?
Behavior is correct.
>
> I have two plan for this mismatch:
>
> A) Change description of MetaspaceSize
> MetaspaceSize is used to HWM in metaspace.cpp .
> So we should change description for this behavior.
> ------------
> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
> @@ -3160,7 +3156,7 @@
> "non-daemon thread (in
> bytes)") \
> \
> product_pd(uintx,
> MetaspaceSize, \
> - "Initial size of Metaspaces (in
> bytes)") \
> + "Initial HWM of Metaspaces (in
> bytes)") \
Explain what HWM is if you're going to use it.
> \
> product(uintx, MaxMetaspaceSize,
> max_uintx, \
> "Maximum size of Metaspaces (in
> bytes)") \
> ------------
>
> B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
> In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
> metaspace.
> InitialBootClassLoaderMetaspaceSize is only to use for it.
> Thus we should remove this option and use MetaspaceSize to initialize
> metaspace.
InitialBootClassLoaderMetaspaceSize is an optimization. It allows
approximately
enough space for the system classes without repeated allocations of
Metaspaces.
Not everyone agrees with this optimization but I would like it kept.
> ------------
> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
> @@ -3172,7 +3172,7 @@
> #endif
>
> // Initialize these before initializing the VirtualSpaceList
> - _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
> BytesPerWord;
> + _first_chunk_word_size = MetaspaceSize / BytesPerWord;
> _first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
> // Make the first class chunk bigger than a medium chunk so it's
> not put
> // on the medium chunk list. The next chunk will be small and
> progress
> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
> @@ -2333,10 +2333,6 @@
> develop(bool, TraceClassLoaderData,
> false, \
> "Trace class loader loader_data
> lifetime") \
> \
> - product(uintx,
> InitialBootClassLoaderMetaspaceSize, \
> - NOT_LP64(2200*K)
> LP64_ONLY(4*M), \
> - "Initial size of the boot class loader data
> metaspace") \
> - \
> product(bool, TraceGen0Time,
> false, \
> "Trace accumulated time for Gen 0
> collection") \
> \
> ------------
>
> I prefer "B" .
> Because, I guess many users think MetaspaceSize decides initial
> metaspace size.
>
> If my idea is correct, I will file this to JBS and upload patch to
> webrev.
Please only correct the description of MetaspaceSize.
Jon
>
>
> Thanks,
>
> Yasumasa
>
From yasuenag at gmail.com Thu Apr 10 03:37:16 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 10 Apr 2014 12:37:16 +0900
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <5345C0F0.7020606@oracle.com>
References: <5345498F.20904@gmail.com>
<5345C0F0.7020606@oracle.com>
Message-ID:
Hi Jon,
Thank you for replying.
I filed this issue as JDK-8039867: Incorrect description: -XX:MetaspaceSize .
I attached a patch to this entry.
I will upload webrev later.
Thanks,
Yasumasa
2014-04-10 6:51 GMT+09:00, Jon Masamitsu :
>
> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> I checked initial metaspace size through jcmd PerfCounter.print .
>> However, it seems to be incorrect:
>>
>> - Java command:
>> java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>
>> - Output from -XX:+PrintFlagsFinal:
>> uintx MetaspaceSize =
>> 21807104 {pd product}
>>
>> - Result of "PerfCounter.print"
>> sun.gc.metaspace.capacity=4194304
>> sun.gc.metaspace.maxCapacity=8388608
>> sun.gc.metaspace.minCapacity=0
>>
>>
>> I checked metaspace.cpp, initial size of metaspace is detected by
>> InitialBootClassLoaderMetaspaceSize.
>> However, description of MetaspaceSize in globals.hpp is
>> "Initial size of Metaspaces (in bytes)" .
>>
>> Is description of MetaspaceSize is correct?
>
> Description is not correct.
>
>> And this behavior is correct?
>
> Behavior is correct.
>
>>
>> I have two plan for this mismatch:
>>
>> A) Change description of MetaspaceSize
>> MetaspaceSize is used to HWM in metaspace.cpp .
>> So we should change description for this behavior.
>> ------------
>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>> @@ -3160,7 +3156,7 @@
>> "non-daemon thread (in
>> bytes)") \
>> \
>> product_pd(uintx,
>> MetaspaceSize, \
>> - "Initial size of Metaspaces (in
>> bytes)") \
>> + "Initial HWM of Metaspaces (in
>> bytes)") \
>
> Explain what HWM is if you're going to use it.
>
>> \
>> product(uintx, MaxMetaspaceSize,
>> max_uintx, \
>> "Maximum size of Metaspaces (in
>> bytes)") \
>> ------------
>>
>> B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>> In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
>> metaspace.
>> InitialBootClassLoaderMetaspaceSize is only to use for it.
>> Thus we should remove this option and use MetaspaceSize to initialize
>> metaspace.
>
> InitialBootClassLoaderMetaspaceSize is an optimization. It allows
> approximately
> enough space for the system classes without repeated allocations of
> Metaspaces.
> Not everyone agrees with this optimization but I would like it kept.
>
>> ------------
>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>> @@ -3172,7 +3172,7 @@
>> #endif
>>
>> // Initialize these before initializing the VirtualSpaceList
>> - _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>> BytesPerWord;
>> + _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>> _first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
>> // Make the first class chunk bigger than a medium chunk so it's
>> not put
>> // on the medium chunk list. The next chunk will be small and
>> progress
>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>> @@ -2333,10 +2333,6 @@
>> develop(bool, TraceClassLoaderData,
>> false, \
>> "Trace class loader loader_data
>> lifetime") \
>> \
>> - product(uintx,
>> InitialBootClassLoaderMetaspaceSize, \
>> - NOT_LP64(2200*K)
>> LP64_ONLY(4*M), \
>> - "Initial size of the boot class loader data
>> metaspace") \
>> - \
>> product(bool, TraceGen0Time,
>> false, \
>> "Trace accumulated time for Gen 0
>> collection") \
>> \
>> ------------
>>
>> I prefer "B" .
>> Because, I guess many users think MetaspaceSize decides initial
>> metaspace size.
>>
>> If my idea is correct, I will file this to JBS and upload patch to
>> webrev.
>
> Please only correct the description of MetaspaceSize.
>
> Jon
>
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>
>
From rednaxelafx at gmail.com Thu Apr 10 09:29:30 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Thu, 10 Apr 2014 02:29:30 -0700
Subject: Unable to start VM with JDK8 on Linux/x64
Message-ID:
Hi HotSpot runtime team,
I'd like to report a bug on behave of someone from a discussion thread [1]
from the HLLVM forum that I run.
This is the symptom he reported:
$ uname -a
Linux IS-CDSM-166 2.6.32.61-cds-64 #1 SMP PREEMPT Tue Feb 25 20:23:18 PST
2014 x86_64 x86_64 x86_64 GNU/Linux
$ java -version
Error occurred during initialization of VM
Could not allocate metaspace: 1073741824 bytes
$ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version
Error occurred during initialization of VM
Could not allocate metaspace: 1073741824 bytes
Apparently the error message says it's trying to allocate a 1GB metaspace,
but failed. This seems to be related to JDK-8003424: Enable Class Data
Sharing for CompressedOops [2].
He further tested working around with -XX:-UseCompressedClassPointers, and
it worked:
# java -XX:ClassMetaspaceSize=512m -version
Unrecognized VM option 'ClassMetaspaceSize=512m'
Did you mean 'MetaspaceSize='?
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
$ java -XX:-UseCompressedClassPointers -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
The tests above were run in a virtual machine with 3GB of memory.
When he bumped up the memory for his virtual machine to 8GB, the VM is able
to start without the workaround.
Has this behavior been seen before?
Best regards,
Kris
[1]: http://hllvm.group.iteye.com/group/topic/39890
[2]: https://bugs.openjdk.java.net/browse/JDK-8003424
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.holmes at oracle.com Thu Apr 10 09:39:38 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Apr 2014 19:39:38 +1000
Subject: Trivial RFR: 8039891: Remove ppcsflt builds from JPRT
Message-ID: <534666DA.9060507@oracle.com>
Subject says it all, these builds (only used by SE Embedded) are no
longer needed.
http://cr.openjdk.java.net/~dholmes/8039891/webrev/
I'll be pushing this via jdk9/hs-rt and backporting to 8u and 7u.
Thanks,
David
From david.holmes at oracle.com Thu Apr 10 10:00:10 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Apr 2014 20:00:10 +1000
Subject: RFR(S): 8039458: Ensure consistency of Monitor/Mutex lock
acquisitions in relation to safepoint protocol
In-Reply-To:
References:
Message-ID: <53466BAA.4060809@oracle.com>
Hi Markus,
Not sure about the need to set _acquired_with_no_safepoint_check = false
in unlock, but otherwise this looks okay to me. You only need to check
the most recently acquired lock, because when you acquired it you would
have checked the previously acquired lock and so forth.
The double negation, !_acquired_with_no_safepoint_check, does make this
a little hard to think about. :)
I think you may need some additional test coverage to see if this is
going to expose existing potentially broken behaviour.
Thanks,
David
On 9/04/2014 10:04 PM, Markus Gr?nlund wrote:
> Greetings,
>
> Kindly asking for reviews for the following bug fix/enhancement
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8039458/webrev01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039458
>
> Problem:
>
> VM code acquire Monitor/Mutex locks by respecting the correct lock
> order, which is enforced in debug builds (asserts). This is great.
>
> However, you could be taking locks in the correct order and everything
> might work just fine during development and testing (even product) but
> depending on runtime circumstances (load/concurrency), the way the
> lock(s) was acquired, i.e. the lock acquisition /mode/, can lead to very
> hard to debug problems (hangs/deadlocks). This is primarily related to
> the lock acquisition mode option ?Mutex::_no_safepoint_check_flag? by
> which you inform your intent to respect or not-respect the safepoint
> protocol during lock acquisition/ownership.
>
>
> If a lock has already been acquired by a thread by passing the
> Mutex::_no_safepoint_check_flag to circumvent the safepoint protocol,
> the thread must *not* be allowed to attempt taking yet another lock on
> which it *might* block ( a lock which was not acquired by passing
> Mutex::_no_safepoint_check_flag in its acquisition operation), as such a
> lock would be participating in the safepoint protocol.
>
> Today, doing this mistake will work just fine _/if the lock is currently
> uncontended_ /which it normally is in development/testing situations*.*
> However, once the lock then becomes contended (highly volatile
> pressured/concurrent product deployment) you might get the worst kind of
> issues to debug (hangs/deadlocks).
>
> Naturally and as always, you have to very careful when you are taking
> locks using the Mutex::_no_safepoint_check_flag ?however it can be very
> hard to determine what other code you can safely call once you are the
> owner of a Mutex::_no_safepoint_check_flag:ed lock - and today there
> is nothing but the developers attention to details that will find/help
> stay clear of this. I think we can do better here in enforcing some
> invariants in code for preempting potential deadlock prone situations.
>
> Description:
>
> Add debug assertions that enforce correct usages of the
> Mutex::_no_safepoint_check_flag when taking multiple locks.
>
>
> This suggestion leverages much of the existing code targeting
> enforcement of lock ordering- this is a simple additive change to also
> add invariant checking on "lock acquisition mode".
>
> Do note this primarily targets Java Threads running in the VM.
>
> Also included code comment:
>
> /*
> * Ensure consistency of Monitor/Mutex lock acquisitions
> * for Java Threads running inside the VM.
> *
> * If a thread has already acquired lock(s) using
> * "Mutex::_no_safepoint_check_flag" (effectively going outside the
> * safepoint protocol), the thread should be disallowed to acquire any
> * additional lock which _is_ participating in the safepoint protocol.
> *
> * If a "safepoint protocol aware" lock is contended, and the thread
> entering
> * is unable to "fast acquire" the lock using cas/try_spin,
> * it will need to block/park. Blocking on a contended lock involves a
> * state transition and a potential SafepointSynchronize::block() call.
> * Transitioning to a blocked state still holding
> "Mutex::_no_safepoint_check_flag"
> * acquired locks is allowed, but is *very* deadlock prone.
> *
> * The effect of allowing this state to happen without checking is subtle
> * and hard to debug since a problem might only appear under heavy load
> and
> * only in situations with increased concurrency levels (product builds).
> *
> */
>
> Testing:
>
> Artificial code changes to MutexLocker and
> Mutex::_no_safepoint_check_flag on certain locks for detecting potential
> deadlock situations.
>
> Speccjbb2005
>
> Kitchensink
>
> Thank you
>
> Markus
>
From staffan.larsen at oracle.com Thu Apr 10 11:23:37 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 10 Apr 2014 13:23:37 +0200
Subject: Trivial RFR: 8039891: Remove ppcsflt builds from JPRT
In-Reply-To: <534666DA.9060507@oracle.com>
References: <534666DA.9060507@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
On 10 apr 2014, at 11:39, David Holmes wrote:
> Subject says it all, these builds (only used by SE Embedded) are no longer needed.
>
> http://cr.openjdk.java.net/~dholmes/8039891/webrev/
>
> I'll be pushing this via jdk9/hs-rt and backporting to 8u and 7u.
>
> Thanks,
> David
From stefan.karlsson at oracle.com Thu Apr 10 11:25:51 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 10 Apr 2014 13:25:51 +0200
Subject: Unable to start VM with JDK8 on Linux/x64
In-Reply-To:
References:
Message-ID: <53467FBF.4040501@oracle.com>
On 2014-04-10 11:29, Krystal Mok wrote:
> Hi HotSpot runtime team,
>
> I'd like to report a bug on behave of someone from a discussion thread
> [1] from the HLLVM forum that I run.
>
> This is the symptom he reported:
>
> $ uname -a
> Linux IS-CDSM-166 2.6.32.61-cds-64 #1 SMP PREEMPT Tue Feb 25 20:23:18
> PST 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> $ java -version
> Error occurred during initialization of VM
> Could not allocate metaspace: 1073741824 bytes
>
> $ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version
> Error occurred during initialization of VM
> Could not allocate metaspace: 1073741824 bytes
>
> Apparently the error message says it's trying to allocate a 1GB
> metaspace, but failed. This seems to be related to JDK-8003424: Enable
> Class Data Sharing for CompressedOops [2].
>
> He further tested working around with -XX:-UseCompressedClassPointers,
> and it worked:
>
> # java -XX:ClassMetaspaceSize=512m -version
> Unrecognized VM option 'ClassMetaspaceSize=512m'
> Did you mean 'MetaspaceSize='?
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
The correct flag to use is: -XX:CompressedClassSpaceSize=512m
>
> $ java -XX:-UseCompressedClassPointers -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
>
> The tests above were run in a virtual machine with 3GB of memory.
> When he bumped up the memory for his virtual machine to 8GB, the VM is
> able to start without the workaround.
>
> Has this behavior been seen before?
I think you'll see this behavior if overcommit_memory is set to 2.
$ man 5 proc
---
/proc/sys/vm/overcommit_memory
This file contains the kernel virtual memory accounting
mode. Values are:
0: heuristic overcommit (this is the default)
1: always overcommit, never check
2: always check, never overcommit
In mode 0, calls of mmap(2) with MAP_NORESERVE are not
checked, and the default check is very weak, leading to the risk of
getting a process "OOM-killed". Under Linux 2.4 any nonzero value
implies mode 1. In mode 2
(available since Linux 2.6), the total virtual address
space on the system is limited to (SS + RAM*(r/100)), where SS is the
size of the swap space, and RAM is the size of the physical memory, and
r is the contents of
the file /proc/sys/vm/overcommit_ratio.
---
Could this be the reason why we fail to reserve the 1 GB large
compressed class space?
StefanK
>
> Best regards,
> Kris
>
> [1]: http://hllvm.group.iteye.com/group/topic/39890
> [2]: https://bugs.openjdk.java.net/browse/JDK-8003424
From yasuenag at gmail.com Thu Apr 10 12:20:38 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 10 Apr 2014 21:20:38 +0900
Subject: -XX:MetaspaceSize is correct?
In-Reply-To:
References: <5345498F.20904@gmail.com> <5345C0F0.7020606@oracle.com>
Message-ID: <53468C96.6080107@gmail.com>
I uploaded webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.00/
Please review and sponsoring!
Yasumasa
On 04/10/2014 12:37 PM, Yasumasa Suenaga wrote:
> Hi Jon,
> Thank you for replying.
>
> I filed this issue as JDK-8039867: Incorrect description: -XX:MetaspaceSize .
>
> I attached a patch to this entry.
> I will upload webrev later.
>
>
> Thanks,
>
> Yasumasa
>
>
>
> 2014-04-10 6:51 GMT+09:00, Jon Masamitsu :
>> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> I checked initial metaspace size through jcmd PerfCounter.print .
>>> However, it seems to be incorrect:
>>>
>>> - Java command:
>>> java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>>
>>> - Output from -XX:+PrintFlagsFinal:
>>> uintx MetaspaceSize =
>>> 21807104 {pd product}
>>>
>>> - Result of "PerfCounter.print"
>>> sun.gc.metaspace.capacity=4194304
>>> sun.gc.metaspace.maxCapacity=8388608
>>> sun.gc.metaspace.minCapacity=0
>>>
>>>
>>> I checked metaspace.cpp, initial size of metaspace is detected by
>>> InitialBootClassLoaderMetaspaceSize.
>>> However, description of MetaspaceSize in globals.hpp is
>>> "Initial size of Metaspaces (in bytes)" .
>>>
>>> Is description of MetaspaceSize is correct?
>> Description is not correct.
>>
>>> And this behavior is correct?
>> Behavior is correct.
>>
>>> I have two plan for this mismatch:
>>>
>>> A) Change description of MetaspaceSize
>>> MetaspaceSize is used to HWM in metaspace.cpp .
>>> So we should change description for this behavior.
>>> ------------
>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>>> @@ -3160,7 +3156,7 @@
>>> "non-daemon thread (in
>>> bytes)") \
>>> \
>>> product_pd(uintx,
>>> MetaspaceSize, \
>>> - "Initial size of Metaspaces (in
>>> bytes)") \
>>> + "Initial HWM of Metaspaces (in
>>> bytes)") \
>> Explain what HWM is if you're going to use it.
>>
>>> \
>>> product(uintx, MaxMetaspaceSize,
>>> max_uintx, \
>>> "Maximum size of Metaspaces (in
>>> bytes)") \
>>> ------------
>>>
>>> B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>> In currently, InitialBootClassLoaderMetaspaceSize is used to initialize
>>> metaspace.
>>> InitialBootClassLoaderMetaspaceSize is only to use for it.
>>> Thus we should remove this option and use MetaspaceSize to initialize
>>> metaspace.
>> InitialBootClassLoaderMetaspaceSize is an optimization. It allows
>> approximately
>> enough space for the system classes without repeated allocations of
>> Metaspaces.
>> Not everyone agrees with this optimization but I would like it kept.
>>
>>> ------------
>>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>>> @@ -3172,7 +3172,7 @@
>>> #endif
>>>
>>> // Initialize these before initializing the VirtualSpaceList
>>> - _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>>> BytesPerWord;
>>> + _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>> _first_chunk_word_size = align_word_size_up(_first_chunk_word_size);
>>> // Make the first class chunk bigger than a medium chunk so it's
>>> not put
>>> // on the medium chunk list. The next chunk will be small and
>>> progress
>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>>> @@ -2333,10 +2333,6 @@
>>> develop(bool, TraceClassLoaderData,
>>> false, \
>>> "Trace class loader loader_data
>>> lifetime") \
>>> \
>>> - product(uintx,
>>> InitialBootClassLoaderMetaspaceSize, \
>>> - NOT_LP64(2200*K)
>>> LP64_ONLY(4*M), \
>>> - "Initial size of the boot class loader data
>>> metaspace") \
>>> - \
>>> product(bool, TraceGen0Time,
>>> false, \
>>> "Trace accumulated time for Gen 0
>>> collection") \
>>> \
>>> ------------
>>>
>>> I prefer "B" .
>>> Because, I guess many users think MetaspaceSize decides initial
>>> metaspace size.
>>>
>>> If my idea is correct, I will file this to JBS and upload patch to
>>> webrev.
>> Please only correct the description of MetaspaceSize.
>>
>> Jon
>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>
From harold.seigel at oracle.com Thu Apr 10 12:26:11 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 10 Apr 2014 08:26:11 -0400
Subject: Trivial RFR: 8039891: Remove ppcsflt builds from JPRT
In-Reply-To: <534666DA.9060507@oracle.com>
References: <534666DA.9060507@oracle.com>
Message-ID: <53468DE3.7060102@oracle.com>
Hi David,
It looks good.
Harold
On 4/10/2014 5:39 AM, David Holmes wrote:
> Subject says it all, these builds (only used by SE Embedded) are no
> longer needed.
>
> http://cr.openjdk.java.net/~dholmes/8039891/webrev/
>
> I'll be pushing this via jdk9/hs-rt and backporting to 8u and 7u.
>
> Thanks,
> David
From coleen.phillimore at oracle.com Thu Apr 10 12:30:19 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 10 Apr 2014 08:30:19 -0400
Subject: Trivial RFR: 8039891: Remove ppcsflt builds from JPRT
In-Reply-To:
References: <534666DA.9060507@oracle.com>
Message-ID: <53468EDB.9020507@oracle.com>
+1
Coleen
On 4/10/14, 7:23 AM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 10 apr 2014, at 11:39, David Holmes wrote:
>
>> Subject says it all, these builds (only used by SE Embedded) are no longer needed.
>>
>> http://cr.openjdk.java.net/~dholmes/8039891/webrev/
>>
>> I'll be pushing this via jdk9/hs-rt and backporting to 8u and 7u.
>>
>> Thanks,
>> David
From rednaxelafx at gmail.com Thu Apr 10 19:54:31 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Thu, 10 Apr 2014 12:54:31 -0700
Subject: Unable to start VM with JDK8 on Linux/x64
In-Reply-To: <53467FBF.4040501@oracle.com>
References:
<53467FBF.4040501@oracle.com>
Message-ID:
Hi Stefan,
Thank you for your explanation. The overcommit_memory=2 theory looks
reasonable.
Let me pass it back to the original discussion thread and see if that's the
case.
Anyway, it'd still be nice if Java could start in a more graceful way.
Thanks,
Kris
On Thu, Apr 10, 2014 at 4:25 AM, Stefan Karlsson wrote:
>
> On 2014-04-10 11:29, Krystal Mok wrote:
>
>> Hi HotSpot runtime team,
>>
>> I'd like to report a bug on behave of someone from a discussion thread
>> [1] from the HLLVM forum that I run.
>>
>> This is the symptom he reported:
>>
>> $ uname -a
>> Linux IS-CDSM-166 2.6.32.61-cds-64 #1 SMP PREEMPT Tue Feb 25 20:23:18 PST
>> 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> $ java -version
>> Error occurred during initialization of VM
>> Could not allocate metaspace: 1073741824 bytes
>>
>> $ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version
>> Error occurred during initialization of VM
>> Could not allocate metaspace: 1073741824 bytes
>>
>> Apparently the error message says it's trying to allocate a 1GB
>> metaspace, but failed. This seems to be related to JDK-8003424: Enable
>> Class Data Sharing for CompressedOops [2].
>>
>> He further tested working around with -XX:-UseCompressedClassPointers,
>> and it worked:
>>
>> # java -XX:ClassMetaspaceSize=512m -version
>> Unrecognized VM option 'ClassMetaspaceSize=512m'
>> Did you mean 'MetaspaceSize='?
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>>
>
> The correct flag to use is: -XX:CompressedClassSpaceSize=512m
>
>
>
>> $ java -XX:-UseCompressedClassPointers -version
>> java version "1.8.0"
>> Java(TM) SE Runtime Environment (build 1.8.0-b132)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
>>
>> The tests above were run in a virtual machine with 3GB of memory.
>> When he bumped up the memory for his virtual machine to 8GB, the VM is
>> able to start without the workaround.
>>
>> Has this behavior been seen before?
>>
>
> I think you'll see this behavior if overcommit_memory is set to 2.
>
> $ man 5 proc
> ---
> /proc/sys/vm/overcommit_memory
> This file contains the kernel virtual memory accounting
> mode. Values are:
>
> 0: heuristic overcommit (this is the default)
> 1: always overcommit, never check
> 2: always check, never overcommit
>
> In mode 0, calls of mmap(2) with MAP_NORESERVE are not
> checked, and the default check is very weak, leading to the risk of getting
> a process "OOM-killed". Under Linux 2.4 any nonzero value implies mode 1.
> In mode 2
> (available since Linux 2.6), the total virtual address
> space on the system is limited to (SS + RAM*(r/100)), where SS is the size
> of the swap space, and RAM is the size of the physical memory, and r is the
> contents of
> the file /proc/sys/vm/overcommit_ratio.
> ---
>
> Could this be the reason why we fail to reserve the 1 GB large compressed
> class space?
>
> StefanK
>
>
>
>> Best regards,
>> Kris
>>
>> [1]: http://hllvm.group.iteye.com/group/topic/39890
>> [2]: https://bugs.openjdk.java.net/browse/JDK-8003424
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.simms at oracle.com Fri Apr 11 10:44:17 2014
From: david.simms at oracle.com (David Simms)
Date: Fri, 11 Apr 2014 12:44:17 +0200
Subject: RFR (XS) 8039947: Dtrace return probe name for
jni_SetStaticBooleanField named incorrectly
Message-ID: <5347C781.5030508@oracle.com>
Gidday,
I have an embarrassingly small one line fix...
https://bugs.openjdk.java.net/browse/JDK-8039947
http://cr.openjdk.java.net/~dsimms/8039947/
From david.holmes at oracle.com Fri Apr 11 11:16:21 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Apr 2014 21:16:21 +1000
Subject: RFR (XS) 8039947: Dtrace return probe name for
jni_SetStaticBooleanField named incorrectly
In-Reply-To: <5347C781.5030508@oracle.com>
References: <5347C781.5030508@oracle.com>
Message-ID: <5347CF05.5030005@oracle.com>
On 11/04/2014 8:44 PM, David Simms wrote:
> Gidday,
>
> I have an embarrassingly small one line fix...
Ship it! :)
David
>
> https://bugs.openjdk.java.net/browse/JDK-8039947
>
> http://cr.openjdk.java.net/~dsimms/8039947/
>
>
>
>
From david.simms at oracle.com Fri Apr 11 11:18:34 2014
From: david.simms at oracle.com (David Simms)
Date: Fri, 11 Apr 2014 13:18:34 +0200
Subject: RFR (XS) 8039947: Dtrace return probe name for
jni_SetStaticBooleanField named incorrectly
In-Reply-To: <5347CF05.5030005@oracle.com>
References: <5347C781.5030508@oracle.com> <5347CF05.5030005@oracle.com>
Message-ID: <5347CF8A.1040902@oracle.com>
Thanks David !
On 04/11/2014 01:16 PM, David Holmes wrote:
> On 11/04/2014 8:44 PM, David Simms wrote:
>> Gidday,
>>
>> I have an embarrassingly small one line fix...
>
> Ship it! :)
>
> David
>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8039947
>>
>> http://cr.openjdk.java.net/~dsimms/8039947/
>>
>>
>>
>>
From staffan.larsen at oracle.com Fri Apr 11 11:21:50 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 11 Apr 2014 13:21:50 +0200
Subject: RFR (XS) 8039947: Dtrace return probe name for
jni_SetStaticBooleanField named incorrectly
In-Reply-To: <5347C781.5030508@oracle.com>
References: <5347C781.5030508@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
On 11 apr 2014, at 12:44, David Simms wrote:
> Gidday,
>
> I have an embarrassingly small one line fix...
>
>
> https://bugs.openjdk.java.net/browse/JDK-8039947
>
> http://cr.openjdk.java.net/~dsimms/8039947/
>
>
>
From george.triantafillou at oracle.com Fri Apr 11 11:36:31 2014
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Fri, 11 Apr 2014 07:36:31 -0400
Subject: RFR (XS) 8039947: Dtrace return probe name for
jni_SetStaticBooleanField named incorrectly
In-Reply-To: <5347C781.5030508@oracle.com>
References: <5347C781.5030508@oracle.com>
Message-ID: <5347D3BF.8070606@oracle.com>
David,
Looks good.
-George
On 4/11/2014 6:44 AM, David Simms wrote:
> Gidday,
>
> I have an embarrassingly small one line fix...
>
>
> https://bugs.openjdk.java.net/browse/JDK-8039947
>
> http://cr.openjdk.java.net/~dsimms/8039947/
>
>
>
>
From lois.foltan at oracle.com Fri Apr 11 13:04:13 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 09:04:13 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic: IncompatibleClassChangeError
trying to invoke static method from a parent in presence of
conflicting defaults
In-Reply-To: <5339C72A.8040405@oracle.com>
References: <5339A511.7000202@oracle.com>
<5339C72A.8040405@oracle.com>
Message-ID: <5347E84D.60304@oracle.com>
Please review the updated fix, webrev at:
http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
This includes Keith's suggestion below. All testing has been rerun
successfully.
Thank you,
Lois
On 3/31/2014 3:51 PM, Lois Foltan wrote:
>
> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>> Hi Lois,
>>
>> I think that looks good. I like it much better than doing the static
>> method check in the default method processing.
>> My only suggestion is that it would be nice to encode new parameter
>> to uncached_lookup_method to be some sort of enum instead of a
>> boolean, so that it is obvious from the call-site what the behavior
>> should be (having just "false" in the parameter list requires you to
>> reference back to the declaration to figure out what that "false" means).
>>
>> So instead of:
>> uncached_lookup_method(field_name, field_sig, false);
>> It'd be:
>> uncached_lookup_method(field_name, field_sig, NORMAL); or
>> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>>
>> (or something like that -- I'm no good at names).
>
> Thank you Keith. Good suggestion. I will implement and repost an
> updated webrev for review.
> Lois
>
>>
>> --
>> - Keith
>>
>>
>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan > > wrote:
>>
>> Hi,
>>
>> Please review the following fix:
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>
>>
>> Bug: invokestatic: IncompatibleClassChangeError trying to invoke
>> static method from a parent in presence of conflicting defaults
>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>
>> Summary of fix:
>> During default method processing, determine_target(), is
>> responsible for making decisions on whether
>> to create and add an overpass method to the current class for
>> issues that have been encountered during the walk
>> of the default methods. The routine
>> defaultMethods.cpp/has_matching_static() helped determine this
>> decision by looking within the current class for a static method
>> that should be preferred during method
>> resolution over an overpass method being created. However,
>> has_matching_static() did not continue to
>> look for a static method in current class' superclasses which
>> JDK-8033150 exposed.
>>
>> After looking at the code more closely, the has
>> _matching_static() concept is being moved out out of default
>> method processing and into method resolution processing. The
>> primary reason for this is to allow
>> default method processing to match method selection where statics
>> are and should be ignored. According
>> to JVMS, static methods should only be preferred over an overpass
>> method at method and interface
>> method resolution time. To enable method resolution to
>> potentially find a static method over an overpass
>> method, a new parameter "ignore_overpass" was added to
>> InstanceKlass::uncached_lookup_method().
>> It has the affect of indicating to find_method_index() to ignore
>> overpass methods and continue the search
>> in case a static method of the same name and signature is present
>> in the current class or its superclasses.
>>
>> Tests:
>> - jtreg hotspot/test/*, JDK java.lang & java.util,
>> vm.quick.testlist, JCK lang & vm, defmeth tests
>> - Test will be added to the defmeth test system
>>
>> Thank you,
>> Lois
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lois.foltan at oracle.com Fri Apr 11 13:19:12 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 09:19:12 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction is
not checked since class version 50
Message-ID: <5347EBD0.4080906@oracle.com>
Hello,
Please review the following fix:
Webrev:
http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
Bug: constraint on multianewarray instruction is not checked since class
version 50
https://bugs.openjdk.java.net/browse/JDK-8038076
Summary of fix:
The incorrect placement of a post increment operator was causing the
calculated dimensions of a multianewarray bytecode to be 1 greater than
reality. The end result of this bug was that a VerifyError would not be
correctly generated if the multianewarray bytecode contained an array
type descriptor that was 1 dimension smaller than the number of
dimensions specified. Thank you to Christian Tornqvist for writing the
test case included.
Tests:
- jtreg hotspot/test/*, JDK java.lang & java.util,
vm.quick.testlist, JCK lang tests
- JCK vm in progress
Thank you,
Lois
From harold.seigel at oracle.com Fri Apr 11 13:32:23 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 11 Apr 2014 09:32:23 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction
is not checked since class version 50
In-Reply-To: <5347EBD0.4080906@oracle.com>
References: <5347EBD0.4080906@oracle.com>
Message-ID: <5347EEE7.4090309@oracle.com>
Hi Lois,
This looks good.
Harold
On 4/11/2014 9:19 AM, Lois Foltan wrote:
> Hello,
>
> Please review the following fix:
>
> Webrev:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
>
> Bug: constraint on multianewarray instruction is not checked since
> class version 50
> https://bugs.openjdk.java.net/browse/JDK-8038076
>
> Summary of fix:
> The incorrect placement of a post increment operator was causing the
> calculated dimensions of a multianewarray bytecode to be 1 greater
> than reality. The end result of this bug was that a VerifyError would
> not be correctly generated if the multianewarray bytecode contained an
> array type descriptor that was 1 dimension smaller than the number of
> dimensions specified. Thank you to Christian Tornqvist for writing
> the test case included.
>
> Tests:
> - jtreg hotspot/test/*, JDK java.lang & java.util,
> vm.quick.testlist, JCK lang tests
> - JCK vm in progress
>
> Thank you,
> Lois
From christian.tornqvist at oracle.com Fri Apr 11 13:35:38 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Fri, 11 Apr 2014 09:35:38 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction
is not checked since class version 50
In-Reply-To: <5347EBD0.4080906@oracle.com>
References: <5347EBD0.4080906@oracle.com>
Message-ID: <051a01cf558a$ed3e61d0$c7bb2570$@oracle.com>
Looks good, thanks for fixing this.
Thanks,
Christian
-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Lois Foltan
Sent: Friday, April 11, 2014 9:19 AM
To: hotspot-runtime-dev
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction is not checked since class version 50
Hello,
Please review the following fix:
Webrev:
http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
Bug: constraint on multianewarray instruction is not checked since class version 50
https://bugs.openjdk.java.net/browse/JDK-8038076
Summary of fix:
The incorrect placement of a post increment operator was causing the calculated dimensions of a multianewarray bytecode to be 1 greater than reality. The end result of this bug was that a VerifyError would not be correctly generated if the multianewarray bytecode contained an array type descriptor that was 1 dimension smaller than the number of dimensions specified. Thank you to Christian Tornqvist for writing the test case included.
Tests:
- jtreg hotspot/test/*, JDK java.lang & java.util, vm.quick.testlist, JCK lang tests
- JCK vm in progress
Thank you,
Lois
From lois.foltan at oracle.com Fri Apr 11 13:41:22 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 09:41:22 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction
is not checked since class version 50
In-Reply-To: <051a01cf558a$ed3e61d0$c7bb2570$@oracle.com>
References: <5347EBD0.4080906@oracle.com>
<051a01cf558a$ed3e61d0$c7bb2570$@oracle.com>
Message-ID: <5347F102.1030904@oracle.com>
Thank you Harold and Christian for the review!
Lois
On 4/11/2014 9:35 AM, Christian Tornqvist wrote:
> Looks good, thanks for fixing this.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Lois Foltan
> Sent: Friday, April 11, 2014 9:19 AM
> To: hotspot-runtime-dev
> Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction is not checked since class version 50
>
> Hello,
>
> Please review the following fix:
>
> Webrev:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
>
> Bug: constraint on multianewarray instruction is not checked since class version 50
> https://bugs.openjdk.java.net/browse/JDK-8038076
>
> Summary of fix:
> The incorrect placement of a post increment operator was causing the calculated dimensions of a multianewarray bytecode to be 1 greater than reality. The end result of this bug was that a VerifyError would not be correctly generated if the multianewarray bytecode contained an array type descriptor that was 1 dimension smaller than the number of dimensions specified. Thank you to Christian Tornqvist for writing the test case included.
>
> Tests:
> - jtreg hotspot/test/*, JDK java.lang & java.util, vm.quick.testlist, JCK lang tests
> - JCK vm in progress
>
> Thank you,
> Lois
>
From kmcguigan at twitter.com Fri Apr 11 13:51:01 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Fri, 11 Apr 2014 09:51:01 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic:
IncompatibleClassChangeError
trying to invoke static method from a parent in presence of conflicting
defaults
In-Reply-To: <5347E84D.60304@oracle.com>
References: <5339A511.7000202@oracle.com>
<5339C72A.8040405@oracle.com> <5347E84D.60304@oracle.com>
Message-ID:
Hi Lois,
Looks good, thanks for making that change!
--
- Keith
On Fri, Apr 11, 2014 at 9:04 AM, Lois Foltan wrote:
>
> Please review the updated fix, webrev at:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
>
> This includes Keith's suggestion below. All testing has been rerun
> successfully.
>
> Thank you,
> Lois
>
>
> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>
>
> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>
> Hi Lois,
>
> I think that looks good. I like it much better than doing the static
> method check in the default method processing.
> My only suggestion is that it would be nice to encode new parameter to
> uncached_lookup_method to be some sort of enum instead of a boolean, so
> that it is obvious from the call-site what the behavior should be (having
> just "false" in the parameter list requires you to reference back to the
> declaration to figure out what that "false" means).
>
> So instead of:
> uncached_lookup_method(field_name, field_sig, false);
> It'd be:
> uncached_lookup_method(field_name, field_sig, NORMAL); or
> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>
> (or something like that -- I'm no good at names).
>
>
> Thank you Keith. Good suggestion. I will implement and repost an updated
> webrev for review.
> Lois
>
>
> --
> - Keith
>
>
> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan wrote:
>
>> Hi,
>>
>> Please review the following fix:
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>
>> Bug: invokestatic: IncompatibleClassChangeError trying to invoke static
>> method from a parent in presence of conflicting defaults
>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>
>> Summary of fix:
>> During default method processing, determine_target(), is responsible for
>> making decisions on whether
>> to create and add an overpass method to the current class for issues that
>> have been encountered during the walk
>> of the default methods. The routine
>> defaultMethods.cpp/has_matching_static() helped determine this
>> decision by looking within the current class for a static method that
>> should be preferred during method
>> resolution over an overpass method being created. However,
>> has_matching_static() did not continue to
>> look for a static method in current class' superclasses which JDK-8033150
>> exposed.
>>
>> After looking at the code more closely, the has _matching_static()
>> concept is being moved out out of default
>> method processing and into method resolution processing. The primary
>> reason for this is to allow
>> default method processing to match method selection where statics are and
>> should be ignored. According
>> to JVMS, static methods should only be preferred over an overpass method
>> at method and interface
>> method resolution time. To enable method resolution to potentially find
>> a static method over an overpass
>> method, a new parameter "ignore_overpass" was added to
>> InstanceKlass::uncached_lookup_method().
>> It has the affect of indicating to find_method_index() to ignore overpass
>> methods and continue the search
>> in case a static method of the same name and signature is present in the
>> current class or its superclasses.
>>
>> Tests:
>> - jtreg hotspot/test/*, JDK java.lang & java.util, vm.quick.testlist,
>> JCK lang & vm, defmeth tests
>> - Test will be added to the defmeth test system
>>
>> Thank you,
>> Lois
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From kmcguigan at twitter.com Fri Apr 11 13:54:46 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Fri, 11 Apr 2014 09:54:46 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction is
not checked since class version 50
In-Reply-To: <5347EBD0.4080906@oracle.com>
References: <5347EBD0.4080906@oracle.com>
Message-ID:
D'oh! That'd be my bad. Darn off-by-one errors. Fix looks good, thanks
for doing it!
--
- Keith
On Fri, Apr 11, 2014 at 9:19 AM, Lois Foltan wrote:
> Hello,
>
> Please review the following fix:
>
> Webrev:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
>
> Bug: constraint on multianewarray instruction is not checked since class
> version 50
> https://bugs.openjdk.java.net/browse/JDK-8038076
>
> Summary of fix:
> The incorrect placement of a post increment operator was causing the
> calculated dimensions of a multianewarray bytecode to be 1 greater than
> reality. The end result of this bug was that a VerifyError would not be
> correctly generated if the multianewarray bytecode contained an array type
> descriptor that was 1 dimension smaller than the number of dimensions
> specified. Thank you to Christian Tornqvist for writing the test case
> included.
>
> Tests:
> - jtreg hotspot/test/*, JDK java.lang & java.util,
> vm.quick.testlist, JCK lang tests
> - JCK vm in progress
>
> Thank you,
> Lois
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Fri Apr 11 13:58:03 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 11 Apr 2014 09:58:03 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction
is not checked since class version 50
In-Reply-To: <5347EBD0.4080906@oracle.com>
References: <5347EBD0.4080906@oracle.com>
Message-ID: <5347F4EB.3050502@oracle.com>
Looks good.
Coleen
On 4/11/14, 9:19 AM, Lois Foltan wrote:
> Hello,
>
> Please review the following fix:
>
> Webrev:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
>
> Bug: constraint on multianewarray instruction is not checked since
> class version 50
> https://bugs.openjdk.java.net/browse/JDK-8038076
>
> Summary of fix:
> The incorrect placement of a post increment operator was causing the
> calculated dimensions of a multianewarray bytecode to be 1 greater
> than reality. The end result of this bug was that a VerifyError would
> not be correctly generated if the multianewarray bytecode contained an
> array type descriptor that was 1 dimension smaller than the number of
> dimensions specified. Thank you to Christian Tornqvist for writing
> the test case included.
>
> Tests:
> - jtreg hotspot/test/*, JDK java.lang & java.util,
> vm.quick.testlist, JCK lang tests
> - JCK vm in progress
>
> Thank you,
> Lois
From coleen.phillimore at oracle.com Fri Apr 11 14:02:35 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 11 Apr 2014 10:02:35 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic:
IncompatibleClassChangeError
trying to invoke static method from a parent in presence of conflicting
defaults
In-Reply-To: <5347E84D.60304@oracle.com>
References: <5339A511.7000202@oracle.com> <5339C72A.8040405@oracle.com>
<5347E84D.60304@oracle.com>
Message-ID: <5347F5FB.20309@oracle.com>
This code looks good. The MethodLookupMode enum is a nice improvement.
It's a good warning of the complexity of this code.
Did something part of the build complain about MethodLookupMode not
being in vmStructs?
I'd prefer the serviceability agent not be tempted to duplicate the
method lookup code in the JVM, so not have this change.
Thanks,
Coleen
On 4/11/14, 9:04 AM, Lois Foltan wrote:
>
> Please review the updated fix, webrev at:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
>
> This includes Keith's suggestion below. All testing has been rerun
> successfully.
>
> Thank you,
> Lois
>
>
> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>>
>> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>>> Hi Lois,
>>>
>>> I think that looks good. I like it much better than doing the
>>> static method check in the default method processing.
>>> My only suggestion is that it would be nice to encode new parameter
>>> to uncached_lookup_method to be some sort of enum instead of a
>>> boolean, so that it is obvious from the call-site what the behavior
>>> should be (having just "false" in the parameter list requires you to
>>> reference back to the declaration to figure out what that "false"
>>> means).
>>>
>>> So instead of:
>>> uncached_lookup_method(field_name, field_sig, false);
>>> It'd be:
>>> uncached_lookup_method(field_name, field_sig, NORMAL); or
>>> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>>>
>>> (or something like that -- I'm no good at names).
>>
>> Thank you Keith. Good suggestion. I will implement and repost an
>> updated webrev for review.
>> Lois
>>
>>>
>>> --
>>> - Keith
>>>
>>>
>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan >> > wrote:
>>>
>>> Hi,
>>>
>>> Please review the following fix:
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>>
>>>
>>> Bug: invokestatic: IncompatibleClassChangeError trying to invoke
>>> static method from a parent in presence of conflicting defaults
>>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>>
>>> Summary of fix:
>>> During default method processing, determine_target(), is
>>> responsible for making decisions on whether
>>> to create and add an overpass method to the current class for
>>> issues that have been encountered during the walk
>>> of the default methods. The routine
>>> defaultMethods.cpp/has_matching_static() helped determine this
>>> decision by looking within the current class for a static method
>>> that should be preferred during method
>>> resolution over an overpass method being created. However,
>>> has_matching_static() did not continue to
>>> look for a static method in current class' superclasses which
>>> JDK-8033150 exposed.
>>>
>>> After looking at the code more closely, the has
>>> _matching_static() concept is being moved out out of default
>>> method processing and into method resolution processing. The
>>> primary reason for this is to allow
>>> default method processing to match method selection where
>>> statics are and should be ignored. According
>>> to JVMS, static methods should only be preferred over an
>>> overpass method at method and interface
>>> method resolution time. To enable method resolution to
>>> potentially find a static method over an overpass
>>> method, a new parameter "ignore_overpass" was added to
>>> InstanceKlass::uncached_lookup_method().
>>> It has the affect of indicating to find_method_index() to ignore
>>> overpass methods and continue the search
>>> in case a static method of the same name and signature is
>>> present in the current class or its superclasses.
>>>
>>> Tests:
>>> - jtreg hotspot/test/*, JDK java.lang & java.util,
>>> vm.quick.testlist, JCK lang & vm, defmeth tests
>>> - Test will be added to the defmeth test system
>>>
>>> Thank you,
>>> Lois
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lois.foltan at oracle.com Fri Apr 11 14:06:10 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 10:06:10 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction
is not checked since class version 50
In-Reply-To:
References: <5347EBD0.4080906@oracle.com>
Message-ID: <5347F6D2.8050101@oracle.com>
On 4/11/2014 9:54 AM, Keith McGuigan wrote:
> D'oh! That'd be my bad. Darn off-by-one errors. Fix looks good,
> thanks for doing it!
Hi Keith,
No problem. Thanks for reviewing!
Lois
>
> --
> - Keith
>
>
> On Fri, Apr 11, 2014 at 9:19 AM, Lois Foltan > wrote:
>
> Hello,
>
> Please review the following fix:
>
> Webrev:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
>
>
> Bug: constraint on multianewarray instruction is not checked since
> class version 50
> https://bugs.openjdk.java.net/browse/JDK-8038076
>
> Summary of fix:
> The incorrect placement of a post increment operator was causing
> the calculated dimensions of a multianewarray bytecode to be 1
> greater than reality. The end result of this bug was that a
> VerifyError would not be correctly generated if the multianewarray
> bytecode contained an array type descriptor that was 1 dimension
> smaller than the number of dimensions specified. Thank you to
> Christian Tornqvist for writing the test case included.
>
> Tests:
> - jtreg hotspot/test/*, JDK java.lang & java.util,
> vm.quick.testlist, JCK lang tests
> - JCK vm in progress
>
> Thank you,
> Lois
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lois.foltan at oracle.com Fri Apr 11 14:06:34 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 10:06:34 -0400
Subject: RFR (XS) JDK-8038076: constraint on multianewarray instruction
is not checked since class version 50
In-Reply-To: <5347F4EB.3050502@oracle.com>
References: <5347EBD0.4080906@oracle.com> <5347F4EB.3050502@oracle.com>
Message-ID: <5347F6EA.7060603@oracle.com>
Thanks Coleen!
Lois
On 4/11/2014 9:58 AM, Coleen Phillimore wrote:
>
> Looks good.
> Coleen
>
> On 4/11/14, 9:19 AM, Lois Foltan wrote:
>> Hello,
>>
>> Please review the following fix:
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8038076/
>>
>> Bug: constraint on multianewarray instruction is not checked since
>> class version 50
>> https://bugs.openjdk.java.net/browse/JDK-8038076
>>
>> Summary of fix:
>> The incorrect placement of a post increment operator was causing the
>> calculated dimensions of a multianewarray bytecode to be 1 greater
>> than reality. The end result of this bug was that a VerifyError
>> would not be correctly generated if the multianewarray bytecode
>> contained an array type descriptor that was 1 dimension smaller than
>> the number of dimensions specified. Thank you to Christian Tornqvist
>> for writing the test case included.
>>
>> Tests:
>> - jtreg hotspot/test/*, JDK java.lang & java.util,
>> vm.quick.testlist, JCK lang tests
>> - JCK vm in progress
>>
>> Thank you,
>> Lois
>
From lois.foltan at oracle.com Fri Apr 11 14:07:11 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 10:07:11 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic:
IncompatibleClassChangeError
trying to invoke static method from a parent in presence of conflicting
defaults
In-Reply-To:
References: <5339A511.7000202@oracle.com>
<5339C72A.8040405@oracle.com> <5347E84D.60304@oracle.com>
Message-ID: <5347F70F.5020401@oracle.com>
On 4/11/2014 9:51 AM, Keith McGuigan wrote:
> Hi Lois,
>
> Looks good, thanks for making that change!
Thank you Keith for reviewing.
Lois
>
> --
> - Keith
>
>
> On Fri, Apr 11, 2014 at 9:04 AM, Lois Foltan > wrote:
>
>
> Please review the updated fix, webrev at:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
>
>
> This includes Keith's suggestion below. All testing has been
> rerun successfully.
>
> Thank you,
> Lois
>
>
> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>>
>> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>>> Hi Lois,
>>>
>>> I think that looks good. I like it much better than doing the
>>> static method check in the default method processing.
>>> My only suggestion is that it would be nice to encode new
>>> parameter to uncached_lookup_method to be some sort of enum
>>> instead of a boolean, so that it is obvious from the call-site
>>> what the behavior should be (having just "false" in the
>>> parameter list requires you to reference back to the declaration
>>> to figure out what that "false" means).
>>>
>>> So instead of:
>>> uncached_lookup_method(field_name, field_sig, false);
>>> It'd be:
>>> uncached_lookup_method(field_name, field_sig, NORMAL); or
>>> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>>>
>>> (or something like that -- I'm no good at names).
>>
>> Thank you Keith. Good suggestion. I will implement and repost
>> an updated webrev for review.
>> Lois
>>
>>>
>>> --
>>> - Keith
>>>
>>>
>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan
>>> > wrote:
>>>
>>> Hi,
>>>
>>> Please review the following fix:
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>>
>>>
>>> Bug: invokestatic: IncompatibleClassChangeError trying to
>>> invoke static method from a parent in presence of
>>> conflicting defaults
>>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>>
>>> Summary of fix:
>>> During default method processing, determine_target(), is
>>> responsible for making decisions on whether
>>> to create and add an overpass method to the current class
>>> for issues that have been encountered during the walk
>>> of the default methods. The routine
>>> defaultMethods.cpp/has_matching_static() helped determine this
>>> decision by looking within the current class for a static
>>> method that should be preferred during method
>>> resolution over an overpass method being created. However,
>>> has_matching_static() did not continue to
>>> look for a static method in current class' superclasses
>>> which JDK-8033150 exposed.
>>>
>>> After looking at the code more closely, the has
>>> _matching_static() concept is being moved out out of default
>>> method processing and into method resolution processing.
>>> The primary reason for this is to allow
>>> default method processing to match method selection where
>>> statics are and should be ignored. According
>>> to JVMS, static methods should only be preferred over an
>>> overpass method at method and interface
>>> method resolution time. To enable method resolution to
>>> potentially find a static method over an overpass
>>> method, a new parameter "ignore_overpass" was added to
>>> InstanceKlass::uncached_lookup_method().
>>> It has the affect of indicating to find_method_index() to
>>> ignore overpass methods and continue the search
>>> in case a static method of the same name and signature is
>>> present in the current class or its superclasses.
>>>
>>> Tests:
>>> - jtreg hotspot/test/*, JDK java.lang & java.util,
>>> vm.quick.testlist, JCK lang & vm, defmeth tests
>>> - Test will be added to the defmeth test system
>>>
>>> Thank you,
>>> Lois
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lois.foltan at oracle.com Fri Apr 11 14:09:54 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 10:09:54 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic:
IncompatibleClassChangeError
trying to invoke static method from a parent in presence of conflicting
defaults
In-Reply-To: <5347F5FB.20309@oracle.com>
References: <5339A511.7000202@oracle.com> <5339C72A.8040405@oracle.com>
<5347E84D.60304@oracle.com> <5347F5FB.20309@oracle.com>
Message-ID: <5347F7B2.5030704@oracle.com>
On 4/11/2014 10:02 AM, Coleen Phillimore wrote:
>
> This code looks good. The MethodLookupMode enum is a nice
> improvement. It's a good warning of the complexity of this code.
> Did something part of the build complain about MethodLookupMode not
> being in vmStructs?
> I'd prefer the serviceability agent not be tempted to duplicate the
> method lookup code in the JVM, so not have this change.
Hi Coleen,
Thanks for the review. The vmStructs.cpp change was a cautionary move
on my part to include the new enum MethodLookupMode. The build did not
complain without it. From your comments sounds like it would be better
to leave this change to vmStructs.cpp out. I can do that and run
through some minor testing. Are you okay with me going forward with
this change and not sending it out for another round of review?
Lois
>
> Thanks,
> Coleen
>
> On 4/11/14, 9:04 AM, Lois Foltan wrote:
>>
>> Please review the updated fix, webrev at:
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
>>
>> This includes Keith's suggestion below. All testing has been rerun
>> successfully.
>>
>> Thank you,
>> Lois
>>
>>
>> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>>>
>>> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>>>> Hi Lois,
>>>>
>>>> I think that looks good. I like it much better than doing the
>>>> static method check in the default method processing.
>>>> My only suggestion is that it would be nice to encode new parameter
>>>> to uncached_lookup_method to be some sort of enum instead of a
>>>> boolean, so that it is obvious from the call-site what the behavior
>>>> should be (having just "false" in the parameter list requires you
>>>> to reference back to the declaration to figure out what that
>>>> "false" means).
>>>>
>>>> So instead of:
>>>> uncached_lookup_method(field_name, field_sig, false);
>>>> It'd be:
>>>> uncached_lookup_method(field_name, field_sig, NORMAL); or
>>>> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>>>>
>>>> (or something like that -- I'm no good at names).
>>>
>>> Thank you Keith. Good suggestion. I will implement and repost an
>>> updated webrev for review.
>>> Lois
>>>
>>>>
>>>> --
>>>> - Keith
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan
>>>> > wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review the following fix:
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>>>
>>>>
>>>> Bug: invokestatic: IncompatibleClassChangeError trying to
>>>> invoke static method from a parent in presence of conflicting
>>>> defaults
>>>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>>>
>>>> Summary of fix:
>>>> During default method processing, determine_target(), is
>>>> responsible for making decisions on whether
>>>> to create and add an overpass method to the current class for
>>>> issues that have been encountered during the walk
>>>> of the default methods. The routine
>>>> defaultMethods.cpp/has_matching_static() helped determine this
>>>> decision by looking within the current class for a static
>>>> method that should be preferred during method
>>>> resolution over an overpass method being created. However,
>>>> has_matching_static() did not continue to
>>>> look for a static method in current class' superclasses which
>>>> JDK-8033150 exposed.
>>>>
>>>> After looking at the code more closely, the has
>>>> _matching_static() concept is being moved out out of default
>>>> method processing and into method resolution processing. The
>>>> primary reason for this is to allow
>>>> default method processing to match method selection where
>>>> statics are and should be ignored. According
>>>> to JVMS, static methods should only be preferred over an
>>>> overpass method at method and interface
>>>> method resolution time. To enable method resolution to
>>>> potentially find a static method over an overpass
>>>> method, a new parameter "ignore_overpass" was added to
>>>> InstanceKlass::uncached_lookup_method().
>>>> It has the affect of indicating to find_method_index() to
>>>> ignore overpass methods and continue the search
>>>> in case a static method of the same name and signature is
>>>> present in the current class or its superclasses.
>>>>
>>>> Tests:
>>>> - jtreg hotspot/test/*, JDK java.lang & java.util,
>>>> vm.quick.testlist, JCK lang & vm, defmeth tests
>>>> - Test will be added to the defmeth test system
>>>>
>>>> Thank you,
>>>> Lois
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Fri Apr 11 14:48:17 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 11 Apr 2014 10:48:17 -0400
Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with
"assert(s > 0) failed: Bad size calculated"
Message-ID: <534800B1.5060201@oracle.com>
Summary: Dtrace monitoring uses size before mirror size is set.
The refactoring I did for bug
https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug. The
size of the mirror is filled in by the InstanceMirrorKlass allocation
but was used for dtrace probes before it in the normal allocation pass.
Pass the allocated size to dtrace function instead.
Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist also.
open webrev at http://cr.openjdk.java.net/~coleenp/8039904/
bug link https://bugs.openjdk.java.net/browse/JDK-8039904
Thanks,
Coleen
From coleen.phillimore at oracle.com Fri Apr 11 14:50:27 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 11 Apr 2014 10:50:27 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic:
IncompatibleClassChangeError
trying to invoke static method from a parent in presence of conflicting
defaults
In-Reply-To: <5347F7B2.5030704@oracle.com>
References: <5339A511.7000202@oracle.com> <5339C72A.8040405@oracle.com>
<5347E84D.60304@oracle.com> <5347F5FB.20309@oracle.com>
<5347F7B2.5030704@oracle.com>
Message-ID: <53480133.2060704@oracle.com>
On 4/11/14, 10:09 AM, Lois Foltan wrote:
>
> On 4/11/2014 10:02 AM, Coleen Phillimore wrote:
>>
>> This code looks good. The MethodLookupMode enum is a nice
>> improvement. It's a good warning of the complexity of this code.
>> Did something part of the build complain about MethodLookupMode not
>> being in vmStructs?
>> I'd prefer the serviceability agent not be tempted to duplicate the
>> method lookup code in the JVM, so not have this change.
>
> Hi Coleen,
>
> Thanks for the review. The vmStructs.cpp change was a cautionary move
> on my part to include the new enum MethodLookupMode. The build did
> not complain without it. From your comments sounds like it would be
> better to leave this change to vmStructs.cpp out. I can do that and
> run through some minor testing. Are you okay with me going forward
> with this change and not sending it out for another round of review?
Yes, I'm fine with the change if you revert the change to vmStructs. I
don't need another round of review. If vmStructs actually needed this
new type, then there'd be changes in the serviceability agent required.
I'm glad that isn't the case.
Thanks!
Coleen
>
> Lois
>
>
>>
>> Thanks,
>> Coleen
>>
>> On 4/11/14, 9:04 AM, Lois Foltan wrote:
>>>
>>> Please review the updated fix, webrev at:
>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
>>>
>>> This includes Keith's suggestion below. All testing has been rerun
>>> successfully.
>>>
>>> Thank you,
>>> Lois
>>>
>>>
>>> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>>>>
>>>> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>>>>> Hi Lois,
>>>>>
>>>>> I think that looks good. I like it much better than doing the
>>>>> static method check in the default method processing.
>>>>> My only suggestion is that it would be nice to encode new
>>>>> parameter to uncached_lookup_method to be some sort of enum
>>>>> instead of a boolean, so that it is obvious from the call-site
>>>>> what the behavior should be (having just "false" in the parameter
>>>>> list requires you to reference back to the declaration to figure
>>>>> out what that "false" means).
>>>>>
>>>>> So instead of:
>>>>> uncached_lookup_method(field_name, field_sig, false);
>>>>> It'd be:
>>>>> uncached_lookup_method(field_name, field_sig, NORMAL); or
>>>>> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>>>>>
>>>>> (or something like that -- I'm no good at names).
>>>>
>>>> Thank you Keith. Good suggestion. I will implement and repost an
>>>> updated webrev for review.
>>>> Lois
>>>>
>>>>>
>>>>> --
>>>>> - Keith
>>>>>
>>>>>
>>>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan
>>>>> > wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please review the following fix:
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>>>>
>>>>>
>>>>> Bug: invokestatic: IncompatibleClassChangeError trying to
>>>>> invoke static method from a parent in presence of conflicting
>>>>> defaults
>>>>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>>>>
>>>>> Summary of fix:
>>>>> During default method processing, determine_target(), is
>>>>> responsible for making decisions on whether
>>>>> to create and add an overpass method to the current class for
>>>>> issues that have been encountered during the walk
>>>>> of the default methods. The routine
>>>>> defaultMethods.cpp/has_matching_static() helped determine this
>>>>> decision by looking within the current class for a static
>>>>> method that should be preferred during method
>>>>> resolution over an overpass method being created. However,
>>>>> has_matching_static() did not continue to
>>>>> look for a static method in current class' superclasses which
>>>>> JDK-8033150 exposed.
>>>>>
>>>>> After looking at the code more closely, the has
>>>>> _matching_static() concept is being moved out out of default
>>>>> method processing and into method resolution processing. The
>>>>> primary reason for this is to allow
>>>>> default method processing to match method selection where
>>>>> statics are and should be ignored. According
>>>>> to JVMS, static methods should only be preferred over an
>>>>> overpass method at method and interface
>>>>> method resolution time. To enable method resolution to
>>>>> potentially find a static method over an overpass
>>>>> method, a new parameter "ignore_overpass" was added to
>>>>> InstanceKlass::uncached_lookup_method().
>>>>> It has the affect of indicating to find_method_index() to
>>>>> ignore overpass methods and continue the search
>>>>> in case a static method of the same name and signature is
>>>>> present in the current class or its superclasses.
>>>>>
>>>>> Tests:
>>>>> - jtreg hotspot/test/*, JDK java.lang & java.util,
>>>>> vm.quick.testlist, JCK lang & vm, defmeth tests
>>>>> - Test will be added to the defmeth test system
>>>>>
>>>>> Thank you,
>>>>> Lois
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From kmcguigan at twitter.com Fri Apr 11 16:00:02 2014
From: kmcguigan at twitter.com (Keith McGuigan)
Date: Fri, 11 Apr 2014 12:00:02 -0400
Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with
"assert(s > 0) failed: Bad size calculated"
In-Reply-To: <534800B1.5060201@oracle.com>
References: <534800B1.5060201@oracle.com>
Message-ID:
Looks good, but why are you not using a newer version of webrev with "next"
links??
--
- Keith
On Fri, Apr 11, 2014 at 10:48 AM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:
> Summary: Dtrace monitoring uses size before mirror size is set.
>
> The refactoring I did for bug https://bugs.openjdk.java.net/
> browse/JDK-8028497 caused this bug. The size of the mirror is filled in
> by the InstanceMirrorKlass allocation but was used for dtrace probes before
> it in the normal allocation pass. Pass the allocated size to dtrace
> function instead.
>
> Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist also.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8039904/
> bug link https://bugs.openjdk.java.net/browse/JDK-8039904
>
> Thanks,
> Coleen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Fri Apr 11 16:22:28 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 11 Apr 2014 12:22:28 -0400
Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with
"assert(s > 0) failed: Bad size calculated"
In-Reply-To:
References: <534800B1.5060201@oracle.com>
Message-ID: <534816C4.9070904@oracle.com>
On 4/11/14, 12:00 PM, Keith McGuigan wrote:
> Looks good, but why are you not using a newer version of webrev with
> "next" links??
Thanks Keith. The private copy I had of the "next" link webrev that I
had broke for me for some mysterious reason. I filed a bug to see if
the "official" version of webrev could have "next" links instead of
debugging my own.
Thanks!
Coleen
>
> --
> - Keith
>
>
> On Fri, Apr 11, 2014 at 10:48 AM, Coleen Phillimore
> >
> wrote:
>
> Summary: Dtrace monitoring uses size before mirror size is set.
>
> The refactoring I did for bug
> https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug.
> The size of the mirror is filled in by the InstanceMirrorKlass
> allocation but was used for dtrace probes before it in the normal
> allocation pass. Pass the allocated size to dtrace function instead.
>
> Tested by dtrace tests on solaris sparcv9, testbase
> vm.quick.testlist also.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8039904/
>
> bug link https://bugs.openjdk.java.net/browse/JDK-8039904
>
> Thanks,
> Coleen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From harold.seigel at oracle.com Fri Apr 11 16:25:48 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 11 Apr 2014 12:25:48 -0400
Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with
"assert(s > 0) failed: Bad size calculated"
In-Reply-To: <534816C4.9070904@oracle.com>
References: <534800B1.5060201@oracle.com>
<534816C4.9070904@oracle.com>
Message-ID: <5348178C.4090105@oracle.com>
Hi Coleen,
You changes look good.
Harold
On 4/11/2014 12:22 PM, Coleen Phillimore wrote:
>
> On 4/11/14, 12:00 PM, Keith McGuigan wrote:
>> Looks good, but why are you not using a newer version of webrev with
>> "next" links??
>
> Thanks Keith. The private copy I had of the "next" link webrev that I
> had broke for me for some mysterious reason. I filed a bug to see if
> the "official" version of webrev could have "next" links instead of
> debugging my own.
> Thanks!
> Coleen
>
>>
>> --
>> - Keith
>>
>>
>> On Fri, Apr 11, 2014 at 10:48 AM, Coleen Phillimore
>> >
>> wrote:
>>
>> Summary: Dtrace monitoring uses size before mirror size is set.
>>
>> The refactoring I did for bug
>> https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug.
>> The size of the mirror is filled in by the InstanceMirrorKlass
>> allocation but was used for dtrace probes before it in the normal
>> allocation pass. Pass the allocated size to dtrace function instead.
>>
>> Tested by dtrace tests on solaris sparcv9, testbase
>> vm.quick.testlist also.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8039904/
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8039904
>>
>> Thanks,
>> Coleen
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From karen.kinnear at oracle.com Fri Apr 11 16:58:18 2014
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 11 Apr 2014 12:58:18 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic:
IncompatibleClassChangeError trying to invoke static method
from a parent in presence of conflicting defaults
In-Reply-To: <5347E84D.60304@oracle.com>
References: <5339A511.7000202@oracle.com>
<5339C72A.8040405@oracle.com> <5347E84D.60304@oracle.com>
Message-ID: <38577856-7CA1-41CB-9D57-73D625FBE14C@oracle.com>
Lois,
I like the enum change. I agree with Coleen's suggestion of leaving out the vmstructs change.
I had one question - instanceKlass.cll uncached_lookup_method -
would it make sense to have a local holding the mode rather than overwriting the input argument of
mode? Wouldn't that be better as a const input argument?
thanks,
Karen
On Apr 11, 2014, at 9:04 AM, Lois Foltan wrote:
>
> Please review the updated fix, webrev at:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
>
> This includes Keith's suggestion below. All testing has been rerun successfully.
>
> Thank you,
> Lois
>
>
> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>>
>> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>>> Hi Lois,
>>>
>>> I think that looks good. I like it much better than doing the static method check in the default method processing.
>>> My only suggestion is that it would be nice to encode new parameter to uncached_lookup_method to be some sort of enum instead of a boolean, so that it is obvious from the call-site what the behavior should be (having just "false" in the parameter list requires you to reference back to the declaration to figure out what that "false" means).
>>>
>>> So instead of:
>>> uncached_lookup_method(field_name, field_sig, false);
>>> It'd be:
>>> uncached_lookup_method(field_name, field_sig, NORMAL); or
>>> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>>>
>>> (or something like that -- I'm no good at names).
>>
>> Thank you Keith. Good suggestion. I will implement and repost an updated webrev for review.
>> Lois
>>
>>>
>>> --
>>> - Keith
>>>
>>>
>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan wrote:
>>> Hi,
>>>
>>> Please review the following fix:
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>>
>>> Bug: invokestatic: IncompatibleClassChangeError trying to invoke static method from a parent in presence of conflicting defaults
>>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>>
>>> Summary of fix:
>>> During default method processing, determine_target(), is responsible for making decisions on whether
>>> to create and add an overpass method to the current class for issues that have been encountered during the walk
>>> of the default methods. The routine defaultMethods.cpp/has_matching_static() helped determine this
>>> decision by looking within the current class for a static method that should be preferred during method
>>> resolution over an overpass method being created. However, has_matching_static() did not continue to
>>> look for a static method in current class' superclasses which JDK-8033150 exposed.
>>>
>>> After looking at the code more closely, the has _matching_static() concept is being moved out out of default
>>> method processing and into method resolution processing. The primary reason for this is to allow
>>> default method processing to match method selection where statics are and should be ignored. According
>>> to JVMS, static methods should only be preferred over an overpass method at method and interface
>>> method resolution time. To enable method resolution to potentially find a static method over an overpass
>>> method, a new parameter "ignore_overpass" was added to InstanceKlass::uncached_lookup_method().
>>> It has the affect of indicating to find_method_index() to ignore overpass methods and continue the search
>>> in case a static method of the same name and signature is present in the current class or its superclasses.
>>>
>>> Tests:
>>> - jtreg hotspot/test/*, JDK java.lang & java.util, vm.quick.testlist, JCK lang & vm, defmeth tests
>>> - Test will be added to the defmeth test system
>>>
>>> Thank you,
>>> Lois
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Fri Apr 11 19:38:36 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 11 Apr 2014 15:38:36 -0400
Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with
"assert(s > 0) failed: Bad size calculated"
In-Reply-To: <5348178C.4090105@oracle.com>
References: <534800B1.5060201@oracle.com> <534816C4.9070904@oracle.com>
<5348178C.4090105@oracle.com>
Message-ID: <534844BC.4050300@oracle.com>
Thanks Harold.
Coleen
On 4/11/14, 12:25 PM, harold seigel wrote:
> Hi Coleen,
>
> You changes look good.
>
> Harold
>
> On 4/11/2014 12:22 PM, Coleen Phillimore wrote:
>>
>> On 4/11/14, 12:00 PM, Keith McGuigan wrote:
>>> Looks good, but why are you not using a newer version of webrev with
>>> "next" links??
>>
>> Thanks Keith. The private copy I had of the "next" link webrev that
>> I had broke for me for some mysterious reason. I filed a bug to see
>> if the "official" version of webrev could have "next" links instead
>> of debugging my own.
>> Thanks!
>> Coleen
>>
>>>
>>> --
>>> - Keith
>>>
>>>
>>> On Fri, Apr 11, 2014 at 10:48 AM, Coleen Phillimore
>>> >
>>> wrote:
>>>
>>> Summary: Dtrace monitoring uses size before mirror size is set.
>>>
>>> The refactoring I did for bug
>>> https://bugs.openjdk.java.net/browse/JDK-8028497 caused this
>>> bug. The size of the mirror is filled in by the
>>> InstanceMirrorKlass allocation but was used for dtrace probes
>>> before it in the normal allocation pass. Pass the allocated
>>> size to dtrace function instead.
>>>
>>> Tested by dtrace tests on solaris sparcv9, testbase
>>> vm.quick.testlist also.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8039904/
>>>
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8039904
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From serguei.spitsyn at oracle.com Fri Apr 11 19:49:18 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 11 Apr 2014 12:49:18 -0700
Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with
"assert(s > 0) failed: Bad size calculated"
In-Reply-To: <534800B1.5060201@oracle.com>
References: <534800B1.5060201@oracle.com>
Message-ID: <5348473E.3070701@oracle.com>
The fix looks good.
Thanks,
Serguei
On 4/11/14 7:48 AM, Coleen Phillimore wrote:
> Summary: Dtrace monitoring uses size before mirror size is set.
>
> The refactoring I did for bug
> https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug. The
> size of the mirror is filled in by the InstanceMirrorKlass allocation
> but was used for dtrace probes before it in the normal allocation
> pass. Pass the allocated size to dtrace function instead.
>
> Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist
> also.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8039904/
> bug link https://bugs.openjdk.java.net/browse/JDK-8039904
>
> Thanks,
> Coleen
From lois.foltan at oracle.com Fri Apr 11 20:08:23 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 11 Apr 2014 16:08:23 -0400
Subject: RFR (M) JDK-8033150 (#2): invokestatic:
IncompatibleClassChangeError
trying to invoke static method from a parent in presence of conflicting
defaults
In-Reply-To: <38577856-7CA1-41CB-9D57-73D625FBE14C@oracle.com>
References: <5339A511.7000202@oracle.com>
<5339C72A.8040405@oracle.com> <5347E84D.60304@oracle.com>
<38577856-7CA1-41CB-9D57-73D625FBE14C@oracle.com>
Message-ID: <53484BB7.4090305@oracle.com>
On 4/11/2014 12:58 PM, Karen Kinnear wrote:
> Lois,
>
> I like the enum change. I agree with Coleen's suggestion of leaving
> out the vmstructs change.
>
> I had one question - instanceKlass.cll uncached_lookup_method -
> would it make sense to have a local holding the mode rather than
> overwriting the input argument of
> mode? Wouldn't that be better as a const input argument?
Hi Karen,
Thanks for the review! Glad the enum change seems to be well liked. I
have completed removing the vmStructs change. I have also taken your
suggestion and implemented a local variable within
InstanceKlass::uncached_lookup_method() to contain the incoming
MethodLookupMode parameter. So far my sanity testing on these minor
changes is going well.
In case anyone wants to view the updated webrev, it is at
http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.2/
Lois
>
> thanks,
> Karen
>
> On Apr 11, 2014, at 9:04 AM, Lois Foltan wrote:
>
>>
>> Please review the updated fix, webrev at:
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150.1/
>>
>> This includes Keith's suggestion below. All testing has been rerun
>> successfully.
>>
>> Thank you,
>> Lois
>>
>>
>> On 3/31/2014 3:51 PM, Lois Foltan wrote:
>>>
>>> On 3/31/2014 2:08 PM, Keith McGuigan wrote:
>>>> Hi Lois,
>>>>
>>>> I think that looks good. I like it much better than doing the
>>>> static method check in the default method processing.
>>>> My only suggestion is that it would be nice to encode new parameter
>>>> to uncached_lookup_method to be some sort of enum instead of a
>>>> boolean, so that it is obvious from the call-site what the behavior
>>>> should be (having just "false" in the parameter list requires you
>>>> to reference back to the declaration to figure out what that
>>>> "false" means).
>>>>
>>>> So instead of:
>>>> uncached_lookup_method(field_name, field_sig, false);
>>>> It'd be:
>>>> uncached_lookup_method(field_name, field_sig, NORMAL); or
>>>> uncached_lookup_method(field_name, field_sig, IGNORE_OVERPASS);
>>>>
>>>> (or something like that -- I'm no good at names).
>>>
>>> Thank you Keith. Good suggestion. I will implement and repost an
>>> updated webrev for review.
>>> Lois
>>>
>>>>
>>>> --
>>>> - Keith
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 1:25 PM, Lois Foltan
>>>> > wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review the following fix:
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8033150/
>>>>
>>>>
>>>> Bug: invokestatic: IncompatibleClassChangeError trying to
>>>> invoke static method from a parent in presence of conflicting
>>>> defaults
>>>> https://bugs.openjdk.java.net/browse/JDK-8033150
>>>>
>>>> Summary of fix:
>>>> During default method processing, determine_target(), is
>>>> responsible for making decisions on whether
>>>> to create and add an overpass method to the current class for
>>>> issues that have been encountered during the walk
>>>> of the default methods. The routine
>>>> defaultMethods.cpp/has_matching_static() helped determine this
>>>> decision by looking within the current class for a static
>>>> method that should be preferred during method
>>>> resolution over an overpass method being created. However,
>>>> has_matching_static() did not continue to
>>>> look for a static method in current class' superclasses which
>>>> JDK-8033150 exposed.
>>>>
>>>> After looking at the code more closely, the has
>>>> _matching_static() concept is being moved out out of default
>>>> method processing and into method resolution processing. The
>>>> primary reason for this is to allow
>>>> default method processing to match method selection where
>>>> statics are and should be ignored. According
>>>> to JVMS, static methods should only be preferred over an
>>>> overpass method at method and interface
>>>> method resolution time. To enable method resolution to
>>>> potentially find a static method over an overpass
>>>> method, a new parameter "ignore_overpass" was added to
>>>> InstanceKlass::uncached_lookup_method().
>>>> It has the affect of indicating to find_method_index() to
>>>> ignore overpass methods and continue the search
>>>> in case a static method of the same name and signature is
>>>> present in the current class or its superclasses.
>>>>
>>>> Tests:
>>>> - jtreg hotspot/test/*, JDK java.lang & java.util,
>>>> vm.quick.testlist, JCK lang & vm, defmeth tests
>>>> - Test will be added to the defmeth test system
>>>>
>>>> Thank you,
>>>> Lois
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Fri Apr 11 20:42:42 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 11 Apr 2014 16:42:42 -0400
Subject: RFR (S) 8039904: dtrace/hotspot/Monitors/Monitors001 fails with
"assert(s > 0) failed: Bad size calculated"
In-Reply-To: <5348473E.3070701@oracle.com>
References: <534800B1.5060201@oracle.com> <5348473E.3070701@oracle.com>
Message-ID: <534853C2.60007@oracle.com>
Thank you Serguei.
Coleen
On 4/11/14, 3:49 PM, serguei.spitsyn at oracle.com wrote:
> The fix looks good.
>
> Thanks,
> Serguei
>
> On 4/11/14 7:48 AM, Coleen Phillimore wrote:
>> Summary: Dtrace monitoring uses size before mirror size is set.
>>
>> The refactoring I did for bug
>> https://bugs.openjdk.java.net/browse/JDK-8028497 caused this bug. The
>> size of the mirror is filled in by the InstanceMirrorKlass allocation
>> but was used for dtrace probes before it in the normal allocation
>> pass. Pass the allocated size to dtrace function instead.
>>
>> Tested by dtrace tests on solaris sparcv9, testbase vm.quick.testlist
>> also.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8039904/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8039904
>>
>> Thanks,
>> Coleen
>
From mandy.chung at oracle.com Sun Apr 13 02:48:42 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 12 Apr 2014 19:48:42 -0700
Subject: Any native library calling JNI_FindClass from JNI_OnUnload?
Message-ID: <5349FB0A.6020204@oracle.com>
Does anyone know of a native library whose JNI_OnUnload calls
JNI_FindClass?
I'm wondering how much existing code out there depends on the
existing behavior that is unsupported.
During the investigation of JDK-4240589, I found that the implementation
JNI_FindClass has a special handling that calls
ClassLoader.NativeLibrary.getFromClass method to determine
if JNI_FindClass is being called by JNI_OnLoad and JNI_OnUnload
directly or indirectly. This special handling makes sense for
JNI_OnLoad, i.e. when the native library is loaded, that
may call JNI_FindClass.
I don't think this should apply to JNI_OnUnload. When a native library
is being unloaded, it means that the ClassLoader has become
unreachable and GC'ed. When JNI_OnUnloader, there is no guarantee
that the class loader still exists for doing any class loading.
The JNI spec of JNI_OnUnload [1] also makes it clear:
The VM calls JNI_OnUnload when the class loader containing the native
library is garbage collected. This function can be used to perform
cleanup operations. Because this function is called in an unknown
context (such as from a finalizer), the programmer should be
conservative on using Java VM services, and refrain from arbitrary Java
call-backs.
A little more background about this: The current ClassLoader
uses finalizer to clean up and unload the native library, if any.
I'm considering to replace the finalizer with phantom reference
which is generally a good change and discover this VM/JNI/libs
dependency.
Any data would be appreciated.
Mandy
[1] http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#JNI_OnUnload
From rednaxelafx at gmail.com Mon Apr 14 01:53:56 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Sun, 13 Apr 2014 18:53:56 -0700
Subject: Unable to start VM with JDK8 on Linux/x64
In-Reply-To:
References:
<53467FBF.4040501@oracle.com>
Message-ID:
Hi Stefan,
Unfortunately, overcommit_memory=2 isn't the cause. The original bug
reporter ran the test again in a 3GB virtual machine [1], and saw:
$ cat /proc/sys/vm/overcommit_memory
0
$ cat /proc/sys/vm/overcommit_ratio
50
$ ~/jdk1.8.0/bin/java
Error occurred during initialization of VM
Could not allocate metaspace: 1073741824 bytes
- Kris
[1]: http://hllvm.group.iteye.com/group/topic/39890?page=2#post-260951
On Thu, Apr 10, 2014 at 12:54 PM, Krystal Mok wrote:
> Hi Stefan,
>
> Thank you for your explanation. The overcommit_memory=2 theory looks
> reasonable.
> Let me pass it back to the original discussion thread and see if that's
> the case.
>
> Anyway, it'd still be nice if Java could start in a more graceful way.
>
> Thanks,
> Kris
>
>
> On Thu, Apr 10, 2014 at 4:25 AM, Stefan Karlsson <
> stefan.karlsson at oracle.com> wrote:
>
>>
>> On 2014-04-10 11:29, Krystal Mok wrote:
>>
>>> Hi HotSpot runtime team,
>>>
>>> I'd like to report a bug on behave of someone from a discussion thread
>>> [1] from the HLLVM forum that I run.
>>>
>>> This is the symptom he reported:
>>>
>>> $ uname -a
>>> Linux IS-CDSM-166 2.6.32.61-cds-64 #1 SMP PREEMPT Tue Feb 25 20:23:18
>>> PST 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> $ java -version
>>> Error occurred during initialization of VM
>>> Could not allocate metaspace: 1073741824 bytes
>>>
>>> $ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version
>>> Error occurred during initialization of VM
>>> Could not allocate metaspace: 1073741824 bytes
>>>
>>> Apparently the error message says it's trying to allocate a 1GB
>>> metaspace, but failed. This seems to be related to JDK-8003424: Enable
>>> Class Data Sharing for CompressedOops [2].
>>>
>>> He further tested working around with -XX:-UseCompressedClassPointers,
>>> and it worked:
>>>
>>> # java -XX:ClassMetaspaceSize=512m -version
>>> Unrecognized VM option 'ClassMetaspaceSize=512m'
>>> Did you mean 'MetaspaceSize='?
>>> Error: Could not create the Java Virtual Machine.
>>> Error: A fatal exception has occurred. Program will exit.
>>>
>>
>> The correct flag to use is: -XX:CompressedClassSpaceSize=512m
>>
>>
>>
>>> $ java -XX:-UseCompressedClassPointers -version
>>> java version "1.8.0"
>>> Java(TM) SE Runtime Environment (build 1.8.0-b132)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
>>>
>>> The tests above were run in a virtual machine with 3GB of memory.
>>> When he bumped up the memory for his virtual machine to 8GB, the VM is
>>> able to start without the workaround.
>>>
>>> Has this behavior been seen before?
>>>
>>
>> I think you'll see this behavior if overcommit_memory is set to 2.
>>
>> $ man 5 proc
>> ---
>> /proc/sys/vm/overcommit_memory
>> This file contains the kernel virtual memory accounting
>> mode. Values are:
>>
>> 0: heuristic overcommit (this is the default)
>> 1: always overcommit, never check
>> 2: always check, never overcommit
>>
>> In mode 0, calls of mmap(2) with MAP_NORESERVE are not
>> checked, and the default check is very weak, leading to the risk of getting
>> a process "OOM-killed". Under Linux 2.4 any nonzero value implies mode 1.
>> In mode 2
>> (available since Linux 2.6), the total virtual address
>> space on the system is limited to (SS + RAM*(r/100)), where SS is the size
>> of the swap space, and RAM is the size of the physical memory, and r is the
>> contents of
>> the file /proc/sys/vm/overcommit_ratio.
>> ---
>>
>> Could this be the reason why we fail to reserve the 1 GB large
>> compressed class space?
>>
>> StefanK
>>
>>
>>
>>> Best regards,
>>> Kris
>>>
>>> [1]: http://hllvm.group.iteye.com/group/topic/39890
>>> [2]: https://bugs.openjdk.java.net/browse/JDK-8003424
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.holmes at oracle.com Mon Apr 14 04:26:20 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Apr 2014 14:26:20 +1000
Subject: 8u Trivial RFR: 8039891: Remove ppcsflt builds from JPRT
Message-ID: <534B636C.2020309@oracle.com>
This is the 8u version. It is different to the 9 version as the
jprt.properties file differs from release to release.
http://cr.openjdk.java.net/~dholmes/8039891/webrev.8u/
Pushing to jdk8u/hs-dev/hotspot
Thanks,
David
From stefan.karlsson at oracle.com Mon Apr 14 06:37:43 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 14 Apr 2014 08:37:43 +0200
Subject: Unable to start VM with JDK8 on Linux/x64
In-Reply-To:
References: <53467FBF.4040501@oracle.com>
Message-ID: <534B8237.2040404@oracle.com>
Hi Kris,
On 2014-04-14 03:53, Krystal Mok wrote:
> Hi Stefan,
>
> Unfortunately, overcommit_memory=2 isn't the cause. The original bug
> reporter ran the test again in a 3GB virtual machine [1], and saw:
>
> $ cat /proc/sys/vm/overcommit_memory
> 0
> $ cat /proc/sys/vm/overcommit_ratio
> 50
> $ ~/jdk1.8.0/bin/java
> Error occurred during initialization of VM
> Could not allocate metaspace: 1073741824 bytes
Then I don't know. Maybe the virtualization layer prevents the overcommit?
StefanK
>
> - Kris
>
> [1]: http://hllvm.group.iteye.com/group/topic/39890?page=2#post-260951
>
>
> On Thu, Apr 10, 2014 at 12:54 PM, Krystal Mok > wrote:
>
> Hi Stefan,
>
> Thank you for your explanation. The overcommit_memory=2 theory
> looks reasonable.
> Let me pass it back to the original discussion thread and see if
> that's the case.
>
> Anyway, it'd still be nice if Java could start in a more graceful way.
>
> Thanks,
> Kris
>
>
> On Thu, Apr 10, 2014 at 4:25 AM, Stefan Karlsson
> >
> wrote:
>
>
> On 2014-04-10 11:29, Krystal Mok wrote:
>
> Hi HotSpot runtime team,
>
> I'd like to report a bug on behave of someone from a
> discussion thread [1] from the HLLVM forum that I run.
>
> This is the symptom he reported:
>
> $ uname -a
> Linux IS-CDSM-166 2.6.32.61-cds-64 #1 SMP PREEMPT Tue Feb
> 25 20:23:18 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> $ java -version
> Error occurred during initialization of VM
> Could not allocate metaspace: 1073741824 bytes
>
> $ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version
> Error occurred during initialization of VM
> Could not allocate metaspace: 1073741824 bytes
>
> Apparently the error message says it's trying to allocate
> a 1GB metaspace, but failed. This seems to be related to
> JDK-8003424: Enable Class Data Sharing for CompressedOops [2].
>
> He further tested working around with
> -XX:-UseCompressedClassPointers, and it worked:
>
> # java -XX:ClassMetaspaceSize=512m -version
> Unrecognized VM option 'ClassMetaspaceSize=512m'
> Did you mean 'MetaspaceSize='?
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
>
>
> The correct flag to use is: -XX:CompressedClassSpaceSize=512m
>
>
>
> $ java -XX:-UseCompressedClassPointers -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
>
> The tests above were run in a virtual machine with 3GB of
> memory.
> When he bumped up the memory for his virtual machine to
> 8GB, the VM is able to start without the workaround.
>
> Has this behavior been seen before?
>
>
> I think you'll see this behavior if overcommit_memory is set to 2.
>
> $ man 5 proc
> ---
> /proc/sys/vm/overcommit_memory
> This file contains the kernel virtual memory
> accounting mode. Values are:
>
> 0: heuristic overcommit (this is the default)
> 1: always overcommit, never check
> 2: always check, never overcommit
>
> In mode 0, calls of mmap(2) with MAP_NORESERVE
> are not checked, and the default check is very weak, leading
> to the risk of getting a process "OOM-killed". Under Linux
> 2.4 any nonzero value implies mode 1. In mode 2
> (available since Linux 2.6), the total virtual
> address space on the system is limited to (SS + RAM*(r/100)),
> where SS is the size of the swap space, and RAM is the size of
> the physical memory, and r is the contents of
> the file /proc/sys/vm/overcommit_ratio.
> ---
>
> Could this be the reason why we fail to reserve the 1 GB
> large compressed class space?
>
> StefanK
>
>
>
> Best regards,
> Kris
>
> [1]: http://hllvm.group.iteye.com/group/topic/39890
> [2]: https://bugs.openjdk.java.net/browse/JDK-8003424
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mikael.gerdin at oracle.com Mon Apr 14 06:50:55 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 14 Apr 2014 08:50:55 +0200
Subject: Unable to start VM with JDK8 on Linux/x64
In-Reply-To:
References:
Message-ID: <1665594.Oe3DkkAfJh@mgerdin03>
Kris,
On Sunday 13 April 2014 18.53.56 Krystal Mok wrote:
> Hi Stefan,
>
> Unfortunately, overcommit_memory=2 isn't the cause. The original bug
> reporter ran the test again in a 3GB virtual machine [1], and saw:
>
> $ cat /proc/sys/vm/overcommit_memory
> 0
> $ cat /proc/sys/vm/overcommit_ratio
> 50
> $ ~/jdk1.8.0/bin/java
> Error occurred during initialization of VM
> Could not allocate metaspace: 1073741824 bytes
Is there a virtual memory ulimit set? (ulimit -v)
What heap sizing command line flags are set?
There is (AFAIK) nothing special with the way we reserve memory for the
compressed class space compared to how we reserve memory for the main Java
heap.
Running with -XX:-UseCompressedClassPointers and increasing the maximum heap
size with 1G should give the same problems I think.
/Mikael
>
> - Kris
>
> [1]: http://hllvm.group.iteye.com/group/topic/39890?page=2#post-260951
>
> On Thu, Apr 10, 2014 at 12:54 PM, Krystal Mok wrote:
> > Hi Stefan,
> >
> > Thank you for your explanation. The overcommit_memory=2 theory looks
> > reasonable.
> > Let me pass it back to the original discussion thread and see if that's
> > the case.
> >
> > Anyway, it'd still be nice if Java could start in a more graceful way.
> >
> > Thanks,
> > Kris
> >
> >
> > On Thu, Apr 10, 2014 at 4:25 AM, Stefan Karlsson <
> >
> > stefan.karlsson at oracle.com> wrote:
> >> On 2014-04-10 11:29, Krystal Mok wrote:
> >>> Hi HotSpot runtime team,
> >>>
> >>> I'd like to report a bug on behave of someone from a discussion thread
> >>> [1] from the HLLVM forum that I run.
> >>>
> >>> This is the symptom he reported:
> >>>
> >>> $ uname -a
> >>> Linux IS-CDSM-166 2.6.32.61-cds-64 #1 SMP PREEMPT Tue Feb 25 20:23:18
> >>> PST 2014 x86_64 x86_64 x86_64 GNU/Linux
> >>>
> >>> $ java -version
> >>> Error occurred during initialization of VM
> >>> Could not allocate metaspace: 1073741824 bytes
> >>>
> >>> $ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version
> >>> Error occurred during initialization of VM
> >>> Could not allocate metaspace: 1073741824 bytes
> >>>
> >>> Apparently the error message says it's trying to allocate a 1GB
> >>> metaspace, but failed. This seems to be related to JDK-8003424: Enable
> >>> Class Data Sharing for CompressedOops [2].
> >>>
> >>> He further tested working around with -XX:-UseCompressedClassPointers,
> >>> and it worked:
> >>>
> >>> # java -XX:ClassMetaspaceSize=512m -version
> >>> Unrecognized VM option 'ClassMetaspaceSize=512m'
> >>> Did you mean 'MetaspaceSize='?
> >>> Error: Could not create the Java Virtual Machine.
> >>> Error: A fatal exception has occurred. Program will exit.
> >>
> >> The correct flag to use is: -XX:CompressedClassSpaceSize=512m
> >>
> >>> $ java -XX:-UseCompressedClassPointers -version
> >>> java version "1.8.0"
> >>> Java(TM) SE Runtime Environment (build 1.8.0-b132)
> >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
> >>>
> >>> The tests above were run in a virtual machine with 3GB of memory.
> >>> When he bumped up the memory for his virtual machine to 8GB, the VM is
> >>> able to start without the workaround.
> >>>
> >>> Has this behavior been seen before?
> >>
> >> I think you'll see this behavior if overcommit_memory is set to 2.
> >>
> >> $ man 5 proc
> >> ---
> >>
> >> /proc/sys/vm/overcommit_memory
> >>
> >> This file contains the kernel virtual memory accounting
> >>
> >> mode. Values are:
> >> 0: heuristic overcommit (this is the default)
> >> 1: always overcommit, never check
> >> 2: always check, never overcommit
> >>
> >> In mode 0, calls of mmap(2) with MAP_NORESERVE are not
> >>
> >> checked, and the default check is very weak, leading to the risk of
> >> getting
> >> a process "OOM-killed". Under Linux 2.4 any nonzero value implies mode
> >> 1.
> >>
> >> In mode 2
> >>
> >> (available since Linux 2.6), the total virtual address
> >>
> >> space on the system is limited to (SS + RAM*(r/100)), where SS is the
> >> size
> >> of the swap space, and RAM is the size of the physical memory, and r is
> >> the
> >> contents of
> >>
> >> the file /proc/sys/vm/overcommit_ratio.
> >>
> >> ---
> >>
> >> Could this be the reason why we fail to reserve the 1 GB large
> >> compressed class space?
> >>
> >> StefanK
> >>
> >>> Best regards,
> >>> Kris
> >>>
> >>> [1]: http://hllvm.group.iteye.com/group/topic/39890
> >>> [2]: https://bugs.openjdk.java.net/browse/JDK-8003424
From markus.gronlund at oracle.com Mon Apr 14 08:42:47 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Mon, 14 Apr 2014 01:42:47 -0700 (PDT)
Subject: RFR(S): 8039458: Ensure consistency of Monitor/Mutex lock
acquisitions in relation to safepoint protocol
In-Reply-To: <53466BAA.4060809@oracle.com>
References:
<53466BAA.4060809@oracle.com>
Message-ID: <2c051ef3-4340-4e44-a48d-95e86d27020f@default>
Many thanks for taking a look David.
I will add another accessor which will allow for some easier read:
...
+ if (acquired_with_safepoint_check()) {
+ if (locks->acquired_with_no_safepoint_check()) {
...
I will also ensure to get some larger scale testing for detecting any existing potentially broken behaviour.
Thanks again
Markus
-----Original Message-----
From: David Holmes
Sent: den 10 april 2014 12:00
To: Markus Gr?nlund; hotspot-runtime-dev; serviceability-dev at openjdk.net; hotspot-compiler-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(S): 8039458: Ensure consistency of Monitor/Mutex lock acquisitions in relation to safepoint protocol
Hi Markus,
Not sure about the need to set _acquired_with_no_safepoint_check = false in unlock, but otherwise this looks okay to me. You only need to check the most recently acquired lock, because when you acquired it you would have checked the previously acquired lock and so forth.
The double negation, !_acquired_with_no_safepoint_check, does make this a little hard to think about. :)
I think you may need some additional test coverage to see if this is going to expose existing potentially broken behaviour.
Thanks,
David
On 9/04/2014 10:04 PM, Markus Gr?nlund wrote:
> Greetings,
>
> Kindly asking for reviews for the following bug fix/enhancement
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8039458/webrev01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8039458
>
> Problem:
>
> VM code acquire Monitor/Mutex locks by respecting the correct lock
> order, which is enforced in debug builds (asserts). This is great.
>
> However, you could be taking locks in the correct order and everything
> might work just fine during development and testing (even product) but
> depending on runtime circumstances (load/concurrency), the way the
> lock(s) was acquired, i.e. the lock acquisition /mode/, can lead to
> very hard to debug problems (hangs/deadlocks). This is primarily
> related to the lock acquisition mode option
> "Mutex::_no_safepoint_check_flag" by which you inform your intent to
> respect or not-respect the safepoint protocol during lock acquisition/ownership.
>
>
> If a lock has already been acquired by a thread by passing the
> Mutex::_no_safepoint_check_flag to circumvent the safepoint protocol,
> the thread must *not* be allowed to attempt taking yet another lock on
> which it *might* block ( a lock which was not acquired by passing
> Mutex::_no_safepoint_check_flag in its acquisition operation), as such
> a lock would be participating in the safepoint protocol.
>
> Today, doing this mistake will work just fine _/if the lock is
> currently uncontended_ /which it normally is in development/testing
> situations*.* However, once the lock then becomes contended (highly
> volatile pressured/concurrent product deployment) you might get the
> worst kind of issues to debug (hangs/deadlocks).
>
> Naturally and as always, you have to very careful when you are taking
> locks using the Mutex::_no_safepoint_check_flag -however it can be
> very hard to determine what other code you can safely call once you
> are the owner of a Mutex::_no_safepoint_check_flag:ed lock - and
> today there is nothing but the developers attention to details that
> will find/help stay clear of this. I think we can do better here in
> enforcing some invariants in code for preempting potential deadlock prone situations.
>
> Description:
>
> Add debug assertions that enforce correct usages of the
> Mutex::_no_safepoint_check_flag when taking multiple locks.
>
>
> This suggestion leverages much of the existing code targeting
> enforcement of lock ordering- this is a simple additive change to also
> add invariant checking on "lock acquisition mode".
>
> Do note this primarily targets Java Threads running in the VM.
>
> Also included code comment:
>
> /*
> * Ensure consistency of Monitor/Mutex lock acquisitions
> * for Java Threads running inside the VM.
> *
> * If a thread has already acquired lock(s) using
> * "Mutex::_no_safepoint_check_flag" (effectively going outside the
> * safepoint protocol), the thread should be disallowed to acquire any
> * additional lock which _is_ participating in the safepoint protocol.
> *
> * If a "safepoint protocol aware" lock is contended, and the thread
> entering
> * is unable to "fast acquire" the lock using cas/try_spin,
> * it will need to block/park. Blocking on a contended lock involves a
> * state transition and a potential SafepointSynchronize::block() call.
> * Transitioning to a blocked state still holding
> "Mutex::_no_safepoint_check_flag"
> * acquired locks is allowed, but is *very* deadlock prone.
> *
> * The effect of allowing this state to happen without checking is subtle
> * and hard to debug since a problem might only appear under heavy
> load and
> * only in situations with increased concurrency levels (product builds).
> *
> */
>
> Testing:
>
> Artificial code changes to MutexLocker and
> Mutex::_no_safepoint_check_flag on certain locks for detecting
> potential deadlock situations.
>
> Speccjbb2005
>
> Kitchensink
>
> Thank you
>
> Markus
>
From aph at redhat.com Mon Apr 14 08:38:35 2014
From: aph at redhat.com (Andrew Haley)
Date: Mon, 14 Apr 2014 09:38:35 +0100
Subject: Unable to start VM with JDK8 on Linux/x64
In-Reply-To: <534B8237.2040404@oracle.com>
References: <53467FBF.4040501@oracle.com>
<534B8237.2040404@oracle.com>
Message-ID: <534B9E8B.5020100@redhat.com>
Hi,
On 04/14/2014 07:37 AM, Stefan Karlsson wrote:
> On 2014-04-14 03:53, Krystal Mok wrote:
>> Hi Stefan,
>>
>> Unfortunately, overcommit_memory=2 isn't the cause. The original bug
>> reporter ran the test again in a 3GB virtual machine [1], and saw:
>>
>> $ cat /proc/sys/vm/overcommit_memory
>> 0
>> $ cat /proc/sys/vm/overcommit_ratio
>> 50
>> $ ~/jdk1.8.0/bin/java
>> Error occurred during initialization of VM
>> Could not allocate metaspace: 1073741824 bytes
>
> Then I don't know. Maybe the virtualization layer prevents the overcommit?
That is certainly possible. I know for certain that some virtualization
layers effectively disable overcommit.
Andrew.
From staffan.larsen at oracle.com Mon Apr 14 14:55:20 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 14 Apr 2014 16:55:20 +0200
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
Message-ID:
The current implementation of System.nanoTime() on OS X uses gettimeofday() which has only microsecond precision and no guarantees on being monotonic.
The proposal is to use the system call mach_absolute_time() instead of gettimeofday() and to add safeguard to guarantee that the time is monotonic (similar to what we already have on solaris).
mach_absolute_time() is essentially a direct call to RDTSC, but with conversion factor to offset for any system sleeps and frequency changes. The call returns something that can be converted to nanoseconds using information from mach_timebase_info(). Calls to mach_absolute_time() do not enter the kernel and are very fast. The resulting time has nanosecond precision and as good accuracy as one can get.
Since the value from RDTSC can be subject to drifting between CPUs, we implement safeguards for this to make sure we never return a lower value than the previous values. This adds some overhead to nanoTime() but guards us against possible bugs in the OS. For users who are willing to trust the OS and need the fastest possible calls to System.nanoTime(), we add a flag to disable this safeguard: -XX:+AssumeMonotonicOSTimers.
This change also adds support for AssumeMonotonicOSTimers to the solaris code (see JDK-6864866) and removes the use of Atmoic::load() for a 64-bit value which was necessary on 32-bit platforms (which we don?t support any longer).
This change has been proposed earlier at: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-May/009496.html
webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8040140
Thanks,
/Staffan
From serguei.spitsyn at oracle.com Mon Apr 14 18:38:55 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 14 Apr 2014 11:38:55 -0700
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To:
References:
Message-ID: <534C2B3F.3020806@oracle.com>
*
*
*src/os/bsd/vm/os_bsd.cpp*
In the comments at 1032-1043:
1. Would it be better to consistently name vars as obsv/prev, not obs/prv ?
I had no problem to understand comments however my mind tries to associate 'obs' with 'obsolete'.
2. The linkhttp://blogs.sun.com/dave/entry/cas_and_cache_trivia_invalidate
is resolved to https://blogs.oracle.com/ which is not very useful.
||
Thanks,
Serguei
On 4/14/14 7:55 AM, Staffan Larsen wrote:
> The current implementation of System.nanoTime() on OS X uses gettimeofday() which has only microsecond precision and no guarantees on being monotonic.
>
> The proposal is to use the system call mach_absolute_time() instead of gettimeofday() and to add safeguard to guarantee that the time is monotonic (similar to what we already have on solaris).
>
> mach_absolute_time() is essentially a direct call to RDTSC, but with conversion factor to offset for any system sleeps and frequency changes. The call returns something that can be converted to nanoseconds using information from mach_timebase_info(). Calls to mach_absolute_time() do not enter the kernel and are very fast. The resulting time has nanosecond precision and as good accuracy as one can get.
>
> Since the value from RDTSC can be subject to drifting between CPUs, we implement safeguards for this to make sure we never return a lower value than the previous values. This adds some overhead to nanoTime() but guards us against possible bugs in the OS. For users who are willing to trust the OS and need the fastest possible calls to System.nanoTime(), we add a flag to disable this safeguard: -XX:+AssumeMonotonicOSTimers.
>
> This change also adds support for AssumeMonotonicOSTimers to the solaris code (see JDK-6864866) and removes the use of Atmoic::load() for a 64-bit value which was necessary on 32-bit platforms (which we don?t support any longer).
>
> This change has been proposed earlier at: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-May/009496.html
>
> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>
> Thanks,
> /Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From serguei.spitsyn at oracle.com Mon Apr 14 18:45:15 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 14 Apr 2014 11:45:15 -0700
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To: <534C2B3F.3020806@oracle.com>
References:
<534C2B3F.3020806@oracle.com>
Message-ID: <534C2CBB.9010202@oracle.com>
Sorry, forgot to tell that the fix is good. :)
Thanks,
Serguei
On 4/14/14 11:38 AM, serguei.spitsyn at oracle.com wrote:
>
> *src/os/bsd/vm/os_bsd.cpp*
>
> In the comments at 1032-1043:
>
> 1. Would it be better to consistently name vars as obsv/prev, not obs/prv ?
> I had no problem to understand comments however my mind tries to associate 'obs' with 'obsolete'.
>
> 2. The linkhttp://blogs.sun.com/dave/entry/cas_and_cache_trivia_invalidate
> is resolved tohttps://blogs.oracle.com/ which is not very useful.
>
> ||
> Thanks,
> Serguei
>
>
> On 4/14/14 7:55 AM, Staffan Larsen wrote:
>> The current implementation of System.nanoTime() on OS X uses gettimeofday() which has only microsecond precision and no guarantees on being monotonic.
>>
>> The proposal is to use the system call mach_absolute_time() instead of gettimeofday() and to add safeguard to guarantee that the time is monotonic (similar to what we already have on solaris).
>>
>> mach_absolute_time() is essentially a direct call to RDTSC, but with conversion factor to offset for any system sleeps and frequency changes. The call returns something that can be converted to nanoseconds using information from mach_timebase_info(). Calls to mach_absolute_time() do not enter the kernel and are very fast. The resulting time has nanosecond precision and as good accuracy as one can get.
>>
>> Since the value from RDTSC can be subject to drifting between CPUs, we implement safeguards for this to make sure we never return a lower value than the previous values. This adds some overhead to nanoTime() but guards us against possible bugs in the OS. For users who are willing to trust the OS and need the fastest possible calls to System.nanoTime(), we add a flag to disable this safeguard: -XX:+AssumeMonotonicOSTimers.
>>
>> This change also adds support for AssumeMonotonicOSTimers to the solaris code (see JDK-6864866) and removes the use of Atmoic::load() for a 64-bit value which was necessary on 32-bit platforms (which we don?t support any longer).
>>
>> This change has been proposed earlier at:http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-May/009496.html
>>
>> webrev:http://cr.openjdk.java.net/~sla/8040140/webrev.00/
>> bug:https://bugs.openjdk.java.net/browse/JDK-8040140
>>
>> Thanks,
>> /Staffan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From aleksey.shipilev at oracle.com Mon Apr 14 19:08:46 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 14 Apr 2014 23:08:46 +0400
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To:
References:
Message-ID: <534C323E.2040809@oracle.com>
On 04/14/2014 06:55 PM, Staffan Larsen wrote:
> mach_absolute_time() is essentially a direct call to RDTSC, but with
> conversion factor to offset for any system sleeps and frequency
> changes. The call returns something that can be converted to
> nanoseconds using information from mach_timebase_info(). Calls to
> mach_absolute_time() do not enter the kernel and are very fast. The
> resulting time has nanosecond precision and as good accuracy as one
> can get.
Some numbers would be good on the public list :) I know the numbers
already, but others on this list don't.
> Since the value from RDTSC can be subject to drifting between CPUs,
> we implement safeguards for this to make sure we never return a lower
> value than the previous values. This adds some overhead to nanoTime()
> but guards us against possible bugs in the OS. For users who are
> willing to trust the OS and need the fastest possible calls to
> System.nanoTime(), we add a flag to disable this safeguard:
> -XX:+AssumeMonotonicOSTimers.
I now wonder if this safeguard can produce a stream of exactly the same
timestamps if local clock is lagging behind. But considering the
alternative of answering the retrograde time, and the observation the
current Mac OS X mach_absolute_time() *appears* monotonic, having this
safeguard seems OK.
> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
This looks good to me.
And, since this question will inevitably pop up, do we plan to bring it
into 8uX? I think many Mac users will be happy about that.
Thanks,
-Aleksey.
From jon.masamitsu at oracle.com Mon Apr 14 22:58:28 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 14 Apr 2014 15:58:28 -0700
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <53468C96.6080107@gmail.com>
References: <5345498F.20904@gmail.com> <5345C0F0.7020606@oracle.com>
<53468C96.6080107@gmail.com>
Message-ID: <534C6814.4050202@oracle.com>
Yasumasa,
It's hard to describe what this parameter is in a single
sentence. "high-water-mark" doesn't mean much unless
you know about how it is used in the GC. Although
"initial" is not right in the description, "minimum" might
be closer to a good description. I'm really not sure.
Jon
On 04/10/2014 05:20 AM, Yasumasa Suenaga wrote:
> I uploaded webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.00/
>
> Please review and sponsoring!
>
>
> Yasumasa
>
>
> On 04/10/2014 12:37 PM, Yasumasa Suenaga wrote:
>> Hi Jon,
>> Thank you for replying.
>>
>> I filed this issue as JDK-8039867: Incorrect description:
>> -XX:MetaspaceSize .
>>
>> I attached a patch to this entry.
>> I will upload webrev later.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>>
>> 2014-04-10 6:51 GMT+09:00, Jon Masamitsu :
>>> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> I checked initial metaspace size through jcmd PerfCounter.print .
>>>> However, it seems to be incorrect:
>>>>
>>>> - Java command:
>>>> java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>>>
>>>> - Output from -XX:+PrintFlagsFinal:
>>>> uintx MetaspaceSize =
>>>> 21807104 {pd product}
>>>>
>>>> - Result of "PerfCounter.print"
>>>> sun.gc.metaspace.capacity=4194304
>>>> sun.gc.metaspace.maxCapacity=8388608
>>>> sun.gc.metaspace.minCapacity=0
>>>>
>>>>
>>>> I checked metaspace.cpp, initial size of metaspace is detected by
>>>> InitialBootClassLoaderMetaspaceSize.
>>>> However, description of MetaspaceSize in globals.hpp is
>>>> "Initial size of Metaspaces (in bytes)" .
>>>>
>>>> Is description of MetaspaceSize is correct?
>>> Description is not correct.
>>>
>>>> And this behavior is correct?
>>> Behavior is correct.
>>>
>>>> I have two plan for this mismatch:
>>>>
>>>> A) Change description of MetaspaceSize
>>>> MetaspaceSize is used to HWM in metaspace.cpp .
>>>> So we should change description for this behavior.
>>>> ------------
>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>>>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>>>> @@ -3160,7 +3156,7 @@
>>>> "non-daemon thread (in
>>>> bytes)") \
>>>> \
>>>> product_pd(uintx,
>>>> MetaspaceSize, \
>>>> - "Initial size of Metaspaces (in
>>>> bytes)") \
>>>> + "Initial HWM of Metaspaces (in
>>>> bytes)") \
>>> Explain what HWM is if you're going to use it.
>>>
>>>> \
>>>> product(uintx, MaxMetaspaceSize,
>>>> max_uintx, \
>>>> "Maximum size of Metaspaces (in
>>>> bytes)") \
>>>> ------------
>>>>
>>>> B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>>> In currently, InitialBootClassLoaderMetaspaceSize is used to
>>>> initialize
>>>> metaspace.
>>>> InitialBootClassLoaderMetaspaceSize is only to use for it.
>>>> Thus we should remove this option and use MetaspaceSize to
>>>> initialize
>>>> metaspace.
>>> InitialBootClassLoaderMetaspaceSize is an optimization. It allows
>>> approximately
>>> enough space for the system classes without repeated allocations of
>>> Metaspaces.
>>> Not everyone agrees with this optimization but I would like it kept.
>>>
>>>> ------------
>>>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>>>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>>>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>>>> @@ -3172,7 +3172,7 @@
>>>> #endif
>>>>
>>>> // Initialize these before initializing the VirtualSpaceList
>>>> - _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>>>> BytesPerWord;
>>>> + _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>>> _first_chunk_word_size =
>>>> align_word_size_up(_first_chunk_word_size);
>>>> // Make the first class chunk bigger than a medium chunk so it's
>>>> not put
>>>> // on the medium chunk list. The next chunk will be small and
>>>> progress
>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>>>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>>>> @@ -2333,10 +2333,6 @@
>>>> develop(bool, TraceClassLoaderData,
>>>> false, \
>>>> "Trace class loader loader_data
>>>> lifetime") \
>>>> \
>>>> - product(uintx,
>>>> InitialBootClassLoaderMetaspaceSize, \
>>>> - NOT_LP64(2200*K)
>>>> LP64_ONLY(4*M), \
>>>> - "Initial size of the boot class loader data
>>>> metaspace") \
>>>> - \
>>>> product(bool, TraceGen0Time,
>>>> false, \
>>>> "Trace accumulated time for Gen 0
>>>> collection") \
>>>> \
>>>> ------------
>>>>
>>>> I prefer "B" .
>>>> Because, I guess many users think MetaspaceSize decides initial
>>>> metaspace size.
>>>>
>>>> If my idea is correct, I will file this to JBS and upload patch to
>>>> webrev.
>>> Please only correct the description of MetaspaceSize.
>>>
>>> Jon
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>
>
From mikael.vidstedt at oracle.com Tue Apr 15 00:45:21 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 14 Apr 2014 17:45:21 -0700
Subject: 8u Trivial RFR: 8039891: Remove ppcsflt builds from JPRT
In-Reply-To: <534B636C.2020309@oracle.com>
References: <534B636C.2020309@oracle.com>
Message-ID: <534C8121.5040203@oracle.com>
Looks good!
Cheers,
Mikael
On 2014-04-13 21:26, David Holmes wrote:
> This is the 8u version. It is different to the 9 version as the
> jprt.properties file differs from release to release.
>
> http://cr.openjdk.java.net/~dholmes/8039891/webrev.8u/
>
> Pushing to jdk8u/hs-dev/hotspot
>
> Thanks,
> David
From christian.tornqvist at oracle.com Tue Apr 15 02:41:58 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 14 Apr 2014 22:41:58 -0400
Subject: RFR(M): [TESTBUG] runtime/threads/CancellableThreadTest fails with
OOM on windows-i586
Message-ID: <002301cf5854$46132270$d2396750$@oracle.com>
Hi everyone,
This is a port (and fix) of CancellableThreadTest from one of our internal
harnesses to jtreg in OpenJDK. The original test suffered from issues with
spawning too many threads on 32bit Windows, when running with WoW64 we have
2 stacks for each thread and usually ran out of process space.
I cleaned the test up a bit but the functionality of the test should be the
same, also limited the number of threads to 256 (128 pairs) down from 2048
(1024 pairs).
Webrev can be found at:
http://cr.openjdk.java.net/~ctornqvi/webrev/8035173/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8035173
Thanks,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From yasuenag at gmail.com Tue Apr 15 03:48:40 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 15 Apr 2014 12:48:40 +0900
Subject: -XX:MetaspaceSize is correct?
In-Reply-To: <534C6814.4050202@oracle.com>
References: <5345498F.20904@gmail.com> <5345C0F0.7020606@oracle.com>
<53468C96.6080107@gmail.com> <534C6814.4050202@oracle.com>
Message-ID:
Jon,
I agree with you.
MetaspaceSize is used as minimum value when JVM shrink capacity in
MetaspaceGC::compute_new_size() .
So I will change description to "minimum" and upload new webrev.
Yasumasa
2014-04-15 7:58 GMT+09:00, Jon Masamitsu :
> Yasumasa,
>
> It's hard to describe what this parameter is in a single
> sentence. "high-water-mark" doesn't mean much unless
> you know about how it is used in the GC. Although
> "initial" is not right in the description, "minimum" might
> be closer to a good description. I'm really not sure.
>
> Jon
>
> On 04/10/2014 05:20 AM, Yasumasa Suenaga wrote:
>> I uploaded webrev:
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8039867/webrev.00/
>>
>> Please review and sponsoring!
>>
>>
>> Yasumasa
>>
>>
>> On 04/10/2014 12:37 PM, Yasumasa Suenaga wrote:
>>> Hi Jon,
>>> Thank you for replying.
>>>
>>> I filed this issue as JDK-8039867: Incorrect description:
>>> -XX:MetaspaceSize .
>>>
>>> I attached a patch to this entry.
>>> I will upload webrev later.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>>
>>> 2014-04-10 6:51 GMT+09:00, Jon Masamitsu :
>>>> On 04/09/2014 06:22 AM, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I checked initial metaspace size through jcmd PerfCounter.print .
>>>>> However, it seems to be incorrect:
>>>>>
>>>>> - Java command:
>>>>> java -XX:-UseCompressedClassPointers -XX:+PrintFlagsFinal LongSleep
>>>>>
>>>>> - Output from -XX:+PrintFlagsFinal:
>>>>> uintx MetaspaceSize =
>>>>> 21807104 {pd product}
>>>>>
>>>>> - Result of "PerfCounter.print"
>>>>> sun.gc.metaspace.capacity=4194304
>>>>> sun.gc.metaspace.maxCapacity=8388608
>>>>> sun.gc.metaspace.minCapacity=0
>>>>>
>>>>>
>>>>> I checked metaspace.cpp, initial size of metaspace is detected by
>>>>> InitialBootClassLoaderMetaspaceSize.
>>>>> However, description of MetaspaceSize in globals.hpp is
>>>>> "Initial size of Metaspaces (in bytes)" .
>>>>>
>>>>> Is description of MetaspaceSize is correct?
>>>> Description is not correct.
>>>>
>>>>> And this behavior is correct?
>>>> Behavior is correct.
>>>>
>>>>> I have two plan for this mismatch:
>>>>>
>>>>> A) Change description of MetaspaceSize
>>>>> MetaspaceSize is used to HWM in metaspace.cpp .
>>>>> So we should change description for this behavior.
>>>>> ------------
>>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>>>>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>>>>> @@ -3160,7 +3156,7 @@
>>>>> "non-daemon thread (in
>>>>> bytes)") \
>>>>> \
>>>>> product_pd(uintx,
>>>>> MetaspaceSize, \
>>>>> - "Initial size of Metaspaces (in
>>>>> bytes)") \
>>>>> + "Initial HWM of Metaspaces (in
>>>>> bytes)") \
>>>> Explain what HWM is if you're going to use it.
>>>>
>>>>> \
>>>>> product(uintx, MaxMetaspaceSize,
>>>>> max_uintx, \
>>>>> "Maximum size of Metaspaces (in
>>>>> bytes)") \
>>>>> ------------
>>>>>
>>>>> B) Remove InitialBootClassLoaderMetaspaceSize and use MetaspaceSize
>>>>> In currently, InitialBootClassLoaderMetaspaceSize is used to
>>>>> initialize
>>>>> metaspace.
>>>>> InitialBootClassLoaderMetaspaceSize is only to use for it.
>>>>> Thus we should remove this option and use MetaspaceSize to
>>>>> initialize
>>>>> metaspace.
>>>> InitialBootClassLoaderMetaspaceSize is an optimization. It allows
>>>> approximately
>>>> enough space for the system classes without repeated allocations of
>>>> Metaspaces.
>>>> Not everyone agrees with this optimization but I would like it kept.
>>>>
>>>>> ------------
>>>>> diff -r 48ce2e6e1add src/share/vm/memory/metaspace.cpp
>>>>> --- a/src/share/vm/memory/metaspace.cpp Fri Apr 04 10:04:44 2014 -0700
>>>>> +++ b/src/share/vm/memory/metaspace.cpp Wed Apr 09 22:05:18 2014 +0900
>>>>> @@ -3172,7 +3172,7 @@
>>>>> #endif
>>>>>
>>>>> // Initialize these before initializing the VirtualSpaceList
>>>>> - _first_chunk_word_size = InitialBootClassLoaderMetaspaceSize /
>>>>> BytesPerWord;
>>>>> + _first_chunk_word_size = MetaspaceSize / BytesPerWord;
>>>>> _first_chunk_word_size =
>>>>> align_word_size_up(_first_chunk_word_size);
>>>>> // Make the first class chunk bigger than a medium chunk so it's
>>>>> not put
>>>>> // on the medium chunk list. The next chunk will be small and
>>>>> progress
>>>>> diff -r 48ce2e6e1add src/share/vm/runtime/globals.hpp
>>>>> --- a/src/share/vm/runtime/globals.hpp Fri Apr 04 10:04:44 2014 -0700
>>>>> +++ b/src/share/vm/runtime/globals.hpp Wed Apr 09 22:05:18 2014 +0900
>>>>> @@ -2333,10 +2333,6 @@
>>>>> develop(bool, TraceClassLoaderData,
>>>>> false, \
>>>>> "Trace class loader loader_data
>>>>> lifetime") \
>>>>> \
>>>>> - product(uintx,
>>>>> InitialBootClassLoaderMetaspaceSize, \
>>>>> - NOT_LP64(2200*K)
>>>>> LP64_ONLY(4*M), \
>>>>> - "Initial size of the boot class loader data
>>>>> metaspace") \
>>>>> - \
>>>>> product(bool, TraceGen0Time,
>>>>> false, \
>>>>> "Trace accumulated time for Gen 0
>>>>> collection") \
>>>>> \
>>>>> ------------
>>>>>
>>>>> I prefer "B" .
>>>>> Because, I guess many users think MetaspaceSize decides initial
>>>>> metaspace size.
>>>>>
>>>>> If my idea is correct, I will file this to JBS and upload patch to
>>>>> webrev.
>>>> Please only correct the description of MetaspaceSize.
>>>>
>>>> Jon
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>
>>
>
>
From staffan.larsen at oracle.com Tue Apr 15 05:50:22 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 15 Apr 2014 07:50:22 +0200
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To: <534C2B3F.3020806@oracle.com>
References:
<534C2B3F.3020806@oracle.com>
Message-ID: <7AD8ACBC-9E7F-454A-BC4B-79A181D9BAB3@oracle.com>
Thanks Serguei.
The comments were copied from the solaris code, but I agree that they could be cleaned up.
/Staffan
On 14 apr 2014, at 20:38, serguei.spitsyn at oracle.com wrote:
>
> src/os/bsd/vm/os_bsd.cpp
>
> In the comments at 1032-1043:
>
> 1. Would it be better to consistently name vars as obsv/prev, not obs/prv ?
> I had no problem to understand comments however my mind tries to associate 'obs' with 'obsolete'.
>
> 2. The link http://blogs.sun.com/dave/entry/cas_and_cache_trivia_invalidate
> is resolved to https://blogs.oracle.com/ which is not very useful.
>
>
>
> Thanks,
> Serguei
>
>
> On 4/14/14 7:55 AM, Staffan Larsen wrote:
>> The current implementation of System.nanoTime() on OS X uses gettimeofday() which has only microsecond precision and no guarantees on being monotonic.
>>
>> The proposal is to use the system call mach_absolute_time() instead of gettimeofday() and to add safeguard to guarantee that the time is monotonic (similar to what we already have on solaris).
>>
>> mach_absolute_time() is essentially a direct call to RDTSC, but with conversion factor to offset for any system sleeps and frequency changes. The call returns something that can be converted to nanoseconds using information from mach_timebase_info(). Calls to mach_absolute_time() do not enter the kernel and are very fast. The resulting time has nanosecond precision and as good accuracy as one can get.
>>
>> Since the value from RDTSC can be subject to drifting between CPUs, we implement safeguards for this to make sure we never return a lower value than the previous values. This adds some overhead to nanoTime() but guards us against possible bugs in the OS. For users who are willing to trust the OS and need the fastest possible calls to System.nanoTime(), we add a flag to disable this safeguard: -XX:+AssumeMonotonicOSTimers.
>>
>> This change also adds support for AssumeMonotonicOSTimers to the solaris code (see JDK-6864866) and removes the use of Atmoic::load() for a 64-bit value which was necessary on 32-bit platforms (which we don?t support any longer).
>>
>> This change has been proposed earlier at: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-May/009496.html
>>
>> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>>
>> Thanks,
>> /Staffan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Tue Apr 15 05:52:18 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 15 Apr 2014 07:52:18 +0200
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To: <534C323E.2040809@oracle.com>
References:
<534C323E.2040809@oracle.com>
Message-ID:
On 14 apr 2014, at 21:08, Aleksey Shipilev wrote:
> On 04/14/2014 06:55 PM, Staffan Larsen wrote:
>> mach_absolute_time() is essentially a direct call to RDTSC, but with
>> conversion factor to offset for any system sleeps and frequency
>> changes. The call returns something that can be converted to
>> nanoseconds using information from mach_timebase_info(). Calls to
>> mach_absolute_time() do not enter the kernel and are very fast. The
>> resulting time has nanosecond precision and as good accuracy as one
>> can get.
>
> Some numbers would be good on the public list :) I know the numbers
> already, but others on this list don?t.
I posted the numbers in the bug, but forgot to say so here...
>
>> Since the value from RDTSC can be subject to drifting between CPUs,
>> we implement safeguards for this to make sure we never return a lower
>> value than the previous values. This adds some overhead to nanoTime()
>> but guards us against possible bugs in the OS. For users who are
>> willing to trust the OS and need the fastest possible calls to
>> System.nanoTime(), we add a flag to disable this safeguard:
>> -XX:+AssumeMonotonicOSTimers.
>
> I now wonder if this safeguard can produce a stream of exactly the same
> timestamps if local clock is lagging behind. But considering the
> alternative of answering the retrograde time, and the observation the
> current Mac OS X mach_absolute_time() *appears* monotonic, having this
> safeguard seems OK.
>
>> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>
> This looks good to me.
Thanks.
> And, since this question will inevitably pop up, do we plan to bring it
> into 8uX? I think many Mac users will be happy about that.
I would like to do so, but I would also like to have it sit and bake for a while in 9 before that. I think the 8u20 train has left the station, but perhaps 8u40?
/Staffan
From staffan.larsen at oracle.com Tue Apr 15 06:00:23 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 15 Apr 2014 08:00:23 +0200
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To:
References:
<534C323E.2040809@oracle.com>
Message-ID:
Here is an updated webrev with changes to the comments in os_bsd.cpp and os_solaris.cpp.
- obs -> obsv
- fixed URL to blog entry
http://cr.openjdk.java.net/~sla/8040140/webrev.01/
/Staffan
On 15 apr 2014, at 07:52, Staffan Larsen wrote:
>
> On 14 apr 2014, at 21:08, Aleksey Shipilev wrote:
>
>> On 04/14/2014 06:55 PM, Staffan Larsen wrote:
>>> mach_absolute_time() is essentially a direct call to RDTSC, but with
>>> conversion factor to offset for any system sleeps and frequency
>>> changes. The call returns something that can be converted to
>>> nanoseconds using information from mach_timebase_info(). Calls to
>>> mach_absolute_time() do not enter the kernel and are very fast. The
>>> resulting time has nanosecond precision and as good accuracy as one
>>> can get.
>>
>> Some numbers would be good on the public list :) I know the numbers
>> already, but others on this list don?t.
>
> I posted the numbers in the bug, but forgot to say so here...
>
>>
>>> Since the value from RDTSC can be subject to drifting between CPUs,
>>> we implement safeguards for this to make sure we never return a lower
>>> value than the previous values. This adds some overhead to nanoTime()
>>> but guards us against possible bugs in the OS. For users who are
>>> willing to trust the OS and need the fastest possible calls to
>>> System.nanoTime(), we add a flag to disable this safeguard:
>>> -XX:+AssumeMonotonicOSTimers.
>>
>> I now wonder if this safeguard can produce a stream of exactly the same
>> timestamps if local clock is lagging behind. But considering the
>> alternative of answering the retrograde time, and the observation the
>> current Mac OS X mach_absolute_time() *appears* monotonic, having this
>> safeguard seems OK.
>>
>>> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>>
>> This looks good to me.
>
> Thanks.
>
>> And, since this question will inevitably pop up, do we plan to bring it
>> into 8uX? I think many Mac users will be happy about that.
>
> I would like to do so, but I would also like to have it sit and bake for a while in 9 before that. I think the 8u20 train has left the station, but perhaps 8u40?
>
> /Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Tue Apr 15 06:07:24 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 15 Apr 2014 08:07:24 +0200
Subject: RFR(M): [TESTBUG] runtime/threads/CancellableThreadTest fails
with OOM on windows-i586
In-Reply-To: <002301cf5854$46132270$d2396750$@oracle.com>
References: <002301cf5854$46132270$d2396750$@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
On 15 apr 2014, at 04:41, Christian Tornqvist wrote:
> Hi everyone,
>
> This is a port (and fix) of CancellableThreadTest from one of our internal harnesses to jtreg in OpenJDK. The original test suffered from issues with spawning too many threads on 32bit Windows, when running with WoW64 we have 2 stacks for each thread and usually ran out of process space.
>
> I cleaned the test up a bit but the functionality of the test should be the same, also limited the number of threads to 256 (128 pairs) down from 2048 (1024 pairs).
>
> Webrev can be found at:
> http://cr.openjdk.java.net/~ctornqvi/webrev/8035173/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8035173
>
> Thanks,
> Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.holmes at oracle.com Tue Apr 15 06:54:54 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Apr 2014 16:54:54 +1000
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To: <534C323E.2040809@oracle.com>
References:
<534C323E.2040809@oracle.com>
Message-ID: <534CD7BE.30203@oracle.com>
On 15/04/2014 5:08 AM, Aleksey Shipilev wrote:
> On 04/14/2014 06:55 PM, Staffan Larsen wrote:
>> mach_absolute_time() is essentially a direct call to RDTSC, but with
>> conversion factor to offset for any system sleeps and frequency
>> changes. The call returns something that can be converted to
>> nanoseconds using information from mach_timebase_info(). Calls to
>> mach_absolute_time() do not enter the kernel and are very fast. The
>> resulting time has nanosecond precision and as good accuracy as one
>> can get.
>
> Some numbers would be good on the public list :) I know the numbers
> already, but others on this list don't.
>
>> Since the value from RDTSC can be subject to drifting between CPUs,
>> we implement safeguards for this to make sure we never return a lower
>> value than the previous values. This adds some overhead to nanoTime()
>> but guards us against possible bugs in the OS. For users who are
>> willing to trust the OS and need the fastest possible calls to
>> System.nanoTime(), we add a flag to disable this safeguard:
>> -XX:+AssumeMonotonicOSTimers.
>
> I now wonder if this safeguard can produce a stream of exactly the same
> timestamps if local clock is lagging behind. But considering the
> alternative of answering the retrograde time, and the observation the
> current Mac OS X mach_absolute_time() *appears* monotonic, having this
> safeguard seems OK.
Yes this can happen. Time "standing still" was deemed better than time
going backwards (there have been a number of "bugs" filed when this is
observed). Ultimately if the OS clock source is broken there is little
the VM can do to make it right.
David
>> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>
> This looks good to me.
>
> And, since this question will inevitably pop up, do we plan to bring it
> into 8uX? I think many Mac users will be happy about that.
>
> Thanks,
> -Aleksey.
>
From david.holmes at oracle.com Tue Apr 15 07:14:42 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Apr 2014 17:14:42 +1000
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To:
References: <534C323E.2040809@oracle.com>
Message-ID: <534CDC62.6010906@oracle.com>
Hi Staffan,
Generally looks okay.
os_bsd.cpp still shows the old URL for Dave Dice's article
os_solaris.cpp:
In the Solaris changes there is a lot of old code with inaccurate
comments, but I suppose cleaning that up (oldgetTimeNanos()) is out of
scope. You only added the check for AssumeMonotonicOSTimers in the
supports_cx8 path, but the other path is now dead code.
globals.hpp
Do we need to document this only affects OSX and Solaris? (Though
implicitly this acts as-if true on Linux and Windows in the common case.)
os.hpp:
#ifdef TARGET_OS_FAMILY_bsd
# include "jvm_bsd.h"
# include
+ # include
#endif
I think this include needs to be in a OSX/Apple specific conditional.
--
We should really fix the non-monotonic-clock path in the Linux and
Windows implementations too ... but 32-bit is problematic
Thanks,
David
On 15/04/2014 4:00 PM, Staffan Larsen wrote:
> Here is an updated webrev with changes to the comments in os_bsd.cpp and
> os_solaris.cpp.
> - obs -> obsv
> - fixed URL to blog entry
>
> http://cr.openjdk.java.net/~sla/8040140/webrev.01/
>
> /Staffan
>
> On 15 apr 2014, at 07:52, Staffan Larsen > wrote:
>
>>
>> On 14 apr 2014, at 21:08, Aleksey Shipilev
>> > wrote:
>>
>>> On 04/14/2014 06:55 PM, Staffan Larsen wrote:
>>>> mach_absolute_time() is essentially a direct call to RDTSC, but with
>>>> conversion factor to offset for any system sleeps and frequency
>>>> changes. The call returns something that can be converted to
>>>> nanoseconds using information from mach_timebase_info(). Calls to
>>>> mach_absolute_time() do not enter the kernel and are very fast. The
>>>> resulting time has nanosecond precision and as good accuracy as one
>>>> can get.
>>>
>>> Some numbers would be good on the public list :) I know the numbers
>>> already, but others on this list don?t.
>>
>> I posted the numbers in the bug, but forgot to say so here...
>>
>>>
>>>> Since the value from RDTSC can be subject to drifting between CPUs,
>>>> we implement safeguards for this to make sure we never return a lower
>>>> value than the previous values. This adds some overhead to nanoTime()
>>>> but guards us against possible bugs in the OS. For users who are
>>>> willing to trust the OS and need the fastest possible calls to
>>>> System.nanoTime(), we add a flag to disable this safeguard:
>>>> -XX:+AssumeMonotonicOSTimers.
>>>
>>> I now wonder if this safeguard can produce a stream of exactly the same
>>> timestamps if local clock is lagging behind. But considering the
>>> alternative of answering the retrograde time, and the observation the
>>> current Mac OS X mach_absolute_time() *appears* monotonic, having this
>>> safeguard seems OK.
>>>
>>>> webrev: http://cr.openjdk.java.net/~sla/8040140/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8040140
>>>
>>> This looks good to me.
>>
>> Thanks.
>>
>>> And, since this question will inevitably pop up, do we plan to bring it
>>> into 8uX? I think many Mac users will be happy about that.
>>
>> I would like to do so, but I would also like to have it sit and bake
>> for a while in 9 before that. I think the 8u20 train has left the
>> station, but perhaps 8u40?
>>
>> /Staffan
>
From serguei.spitsyn at oracle.com Tue Apr 15 07:46:45 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 15 Apr 2014 00:46:45 -0700
Subject: RFR: 8040140 System.nanoTime() is slow and non-monotonic on OS X
In-Reply-To:
References: <534C323E.2040809@oracle.com>
Message-ID: <534CE3E5.7010402@oracle.com>
Somehow the 'obs', 'prv' and the old link are still in new webrev:
1033 // If the CAS failed and the observed value "obs" is >= now then
1034 // we should return "obs". If the CAS failed and now > obs > prv then
1037 // or (c) just return obs. We use (c). No loop is required although in some cases
1041 // We might also condition (c) on the magnitude of the delta between obs and now.
1043 // See http://blogs.sun.com/dave/entry/cas_and_cache_trivia_invalidate
But I believe, you really fixed it in the repo. :)
Thanks,
Serguei
On 4/14/14 11:00 PM, Staffan Larsen wrote:
> Here is an updated webrev with changes to the comments in os_bsd.cpp
> and os_solaris.cpp.
> - obs -> obsv
> - fixed URL to blog entry
>
> http://cr.openjdk.java.net/~sla/8040140/webrev.01/
>