From erik.joelsson at oracle.com Wed Apr 1 07:56:35 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 01 Apr 2015 09:56:35 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551ACDBD.6000703@oracle.com>
References: <551ACDBD.6000703@oracle.com>
Message-ID: <551BA4B3.7010105@oracle.com>
Hello,
(Adding build-dev since this touches makefiles and jigsaw-dev since this
touches modules.xml)
In general, the build changes look pretty good. I much appreciate moving
the OS specific source into OS specific source dirs. A few notes
however. Though I realize you followed existing patterns, we have some
more current best practices that I would like to incorporate in new code.
jdk/make/lib/Lib-jdk.management.gmk:
The variables BUILD_LIBJDKMANAGEMENT_SRC and
BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While it
works, it makes them unnecessarily long and it risks conflicting with
internal variables created in the SetupNativeCompilation call.
BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed.
The EXCLUDE_FILES parameter too.
LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special construct
for libmanagement used for a while until cmm was split into a separate
module. Just inline the mapfile line into the macro call.
jdk/make/lib/Lib-java.management.gmk:
BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well.
LIBMANAGEMENT_MAPFILE should be inlined here as well.
While you are at it, might as well fix the BUILD_ prefix on the SRC and
CFLAGS variables here too if you don't mind.
Is the need for low optimization when debug symbols are active still
valid for both libmanagement and libmanagement_ext?
/Erik
On 2015-03-31 18:39, shanliang wrote:
> Please review this fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>
> Some code within the module java.management is separated and moved to
> the new module jdk.management, the new module takes the implementation
> code for Oracle Corporation's platform extension to the implementation
> of the java.lang.management API and also the management interface for
> some other components for the platform.
>
> Thanks,
> Shanliang
>
From jaroslav.bachorik at oracle.com Wed Apr 1 08:56:29 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 01 Apr 2015 10:56:29 +0200
Subject: RFR 8076344: serviceability/dcmd/vm/SetVMFlagTest.java test fails
with "java.lang.Error: 'MaxHeapSize' flag is not available or
immutable"
Message-ID: <551BB2BD.6030306@oracle.com>
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8076344
Webrev: http://cr.openjdk.java.net/~jbachorik/8076344/webrev.00
Originally, the test used some well known flags to assert the correct
functionality. I didn't expect eg. 'MaxHeapSize' flag to go away so
quickly :)
The solution is to pick whichever mutable/immutable flag of a certain
type and carry on the test using this flag. This way the test will
always use only the available flags.
Thanks,
-JB-
From staffan.larsen at oracle.com Wed Apr 1 09:04:11 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 1 Apr 2015 11:04:11 +0200
Subject: RFR 8076344: serviceability/dcmd/vm/SetVMFlagTest.java test fails
with "java.lang.Error: 'MaxHeapSize' flag is not available or
immutable"
In-Reply-To: <551BB2BD.6030306@oracle.com>
References: <551BB2BD.6030306@oracle.com>
Message-ID:
Looks good!
nit: L133: ?existeng? -> ?existing"
Thanks,
/Staffan
> On 1 apr 2015, at 10:56, Jaroslav Bachorik wrote:
>
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8076344
> Webrev: http://cr.openjdk.java.net/~jbachorik/8076344/webrev.00
>
> Originally, the test used some well known flags to assert the correct functionality. I didn't expect eg. 'MaxHeapSize' flag to go away so quickly :)
>
> The solution is to pick whichever mutable/immutable flag of a certain type and carry on the test using this flag. This way the test will always use only the available flags.
>
> Thanks,
>
> -JB-
From jaroslav.bachorik at oracle.com Wed Apr 1 12:07:30 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 01 Apr 2015 14:07:30 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551ACDBD.6000703@oracle.com>
References: <551ACDBD.6000703@oracle.com>
Message-ID: <551BDF82.4010908@oracle.com>
Hi Shanliang,
Looks good! A lot of work here ...
Just a nit -
*
jdk/src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java
- superfluous import @L28 (and the copyright year change)
I suppose all reg-tests and related JCK tests are still passing.
-JB-
On 31.3.2015 18:39, shanliang wrote:
> Please review this fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>
> Some code within the module java.management is separated and moved to
> the new module jdk.management, the new module takes the implementation
> code for Oracle Corporation's platform extension to the implementation
> of the java.lang.management API and also the management interface for
> some other components for the platform.
>
> Thanks,
> Shanliang
>
From staffan.larsen at oracle.com Wed Apr 1 14:02:15 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 1 Apr 2015 16:02:15 +0200
Subject: JEP 240: Remove the JVM TI hprof Agent
In-Reply-To:
References: <20150213004635.5F2514DB85@eggemoggin.niobe.net>
<54E1E6FE.8030706@redhat.com>
<54E759C5.9040301@redhat.com>
Message-ID:
Thanks for the feedback. I still think that the cost and drawbacks of the hprof agent outweighs the benefits and will move ahead with the JEP.
It can be noted that since the hprof agent uses the standardized JVMTI interface, it should be perfectly possible to use the library shipped with a previous version of the JDK. Still a bit messy, but workable.
Thanks,
/Staffan
From shanliang.jiang at oracle.com Wed Apr 1 14:24:38 2015
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 01 Apr 2015 16:24:38 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551BDF82.4010908@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551BDF82.4010908@oracle.com>
Message-ID: <551BFFA6.3040504@oracle.com>
Jaroslav Bachorik wrote:
> Hi Shanliang,
>
> Looks good! A lot of work here ...
>
> Just a nit -
>
> *
> jdk/src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandInfo.java
>
> - superfluous import @L28 (and the copyright year change)
Yes the import of L28 is unnecessary.
The copyright year was changed because the package was changed.
>
> I suppose all reg-tests and related JCK tests are still passing.
I passed svc/core/hotspot unit tests with jprt, and JMX JCK tests.
Thanks for the review.
Shanliang
>
> -JB-
>
> On 31.3.2015 18:39, shanliang wrote:
>> Please review this fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>>
>> Some code within the module java.management is separated and moved to
>> the new module jdk.management, the new module takes the implementation
>> code for Oracle Corporation's platform extension to the implementation
>> of the java.lang.management API and also the management interface for
>> some other components for the platform.
>>
>> Thanks,
>> Shanliang
>>
>
From daniel.fuchs at oracle.com Wed Apr 1 16:58:20 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 01 Apr 2015 18:58:20 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551ACDBD.6000703@oracle.com>
References: <551ACDBD.6000703@oracle.com>
Message-ID: <551C23AC.9000209@oracle.com>
Hi Shanliang,
Impressive work! I know how long it took you and how much
effort went into this!
This does look good.
One minor remark is that it might have been good to have a simple
mechanical rule to transform the name of the MBean concrete
implementation from the java.management module to the
jdk.management module, since these concrete class names may
need to be referred to in an application policy file.
For instance - if we could say:
<<
Implementation class names of MBeans which do not have a
com.sun.management extension are unchanged (that is still
true - I think).
Implementation class names of MBeans which do have a
com.sun.management extension are changed so that their
package name moves from
sun.management. to com.sun.management.internal.
>>
At this point however there doesn't seem to be such a simple
pattern, apart from the fact that the implementation have moved to
com.sun.management.internal.
For instance we have:
before:
sun.management.OperatingSystemImpl
after:
java.management: sun.management.BaseOperatingSystemImpl
jdk.management: com.sun.management.internal.OperatingSystemImpl
before:
sun.management.GarbageCollectorImpl
after:
java.management: sun.management.GarbageCollectorImpl
jdk.management: com.sun.management.internal.GarbageCollectorExtImpl
before:
sun.management.ThreadImpl
after:
java.management: sun.management.ThreadImpl
jdk.management: com.sun.management.internal.HotSpotThreadImpl
But this is minor compared to the rest of the work, and maybe
that could be left over for later - if that's ever needed.
best regards,
-- daniel
On 31/03/15 18:39, shanliang wrote:
> Please review this fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>
> Some code within the module java.management is separated and moved to
> the new module jdk.management, the new module takes the implementation
> code for Oracle Corporation's platform extension to the implementation
> of the java.lang.management API and also the management interface for
> some other components for the platform.
>
> Thanks,
> Shanliang
>
From shanliang.jiang at oracle.com Wed Apr 1 18:03:04 2015
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 01 Apr 2015 20:03:04 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551BA4B3.7010105@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551BA4B3.7010105@oracle.com>
Message-ID: <551C32D8.3020100@oracle.com>
Erik Joelsson wrote:
> Hello,
>
> (Adding build-dev since this touches makefiles and jigsaw-dev since
> this touches modules.xml)
>
> In general, the build changes look pretty good. I much appreciate
> moving the OS specific source into OS specific source dirs. A few
> notes however. Though I realize you followed existing patterns, we
> have some more current best practices that I would like to incorporate
> in new code.
>
> jdk/make/lib/Lib-jdk.management.gmk:
>
> The variables BUILD_LIBJDKMANAGEMENT_SRC and
> BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While
> it works, it makes them unnecessarily long and it risks conflicting
> with internal variables created in the SetupNativeCompilation call.
Done.
>
> BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed.
> The EXCLUDE_FILES parameter too.
Done.
>
> LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special
> construct for libmanagement used for a while until cmm was split into
> a separate module. Just inline the mapfile line into the macro call.
Done.
>
>
> jdk/make/lib/Lib-java.management.gmk:
>
> BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well.
Removed.
>
> LIBMANAGEMENT_MAPFILE should be inlined here as well.
Done.
>
> While you are at it, might as well fix the BUILD_ prefix on the SRC
> and CFLAGS variables here too if you don't mind.
Done.
>
>
> Is the need for low optimization when debug symbols are active still
> valid for both libmanagement and libmanagement_ext?
Sorry I do not know, I did not touch that flag stting in libmanagement,
and I copied it for libmanagement_ext.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8042901/01/
Thanks for the review.
Shanliang
>
> /Erik
>
> On 2015-03-31 18:39, shanliang wrote:
>> Please review this fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>>
>> Some code within the module java.management is separated and moved to
>> the new module jdk.management, the new module takes the
>> implementation code for Oracle Corporation's platform extension to
>> the implementation of the java.lang.management API and also the
>> management interface for some other components for the platform.
>>
>> Thanks,
>> Shanliang
>>
>
From mandy.chung at oracle.com Wed Apr 1 21:41:54 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 01 Apr 2015 14:41:54 -0700
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551ACDBD.6000703@oracle.com>
References: <551ACDBD.6000703@oracle.com>
Message-ID: <551C6622.1020609@oracle.com>
On 3/31/2015 9:39 AM, shanliang wrote:
> Please review this fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
Thank you for doing this big change to separate com.sun.management
API from java.management module. Looking really good.
Also thanks for fixing the tests to eliminate the unnecessary use of
JDK internal APIs.
modules.xml change looks good to me.
sun/management/ThreadImpl.java
35 /**
36 * Implementation class for the thread subsystem.
37 * Standard and committed hotspot-specific metrics if any.
38 *
39 * ManagementFactory.getThreadMXBean() returns an instance
40 * of this class.
41 */
42 // the implementation for com.sun.management.ThreadMXBean can
43 // be moved to jdk.management in the future.
What about:
Implementation for java.lang.management.ThreadMXBean as well as
providing the supporting method for com.sun.management.ThreadMXBean.
The supporting method for com.sun.management.ThreadMXBean can
be moved to jdk.management in the future.
CheckSomeMXBeanImplPackage.java
Thanks for adding this test.
Iterating jrt file system to find jdk.management module is one way.
Another simpler alternative is to call:
Class.forName("com.sun.management.GarbageCollectorMXBean");
and catch CNFE to determine if it's present or not.
You should also call ManagementFactory.getPlatformMXBeans on
com.sun.management.GarbageCollectorMXBean if present.
VMOptionOpenDataTest.java
copyright header year is wrong.
PlatformMBeanProviderConstructorCheck.java
The test needs to restore the original policy and security manager
before the test exits in case this case runs in agent vm mode.
The static permName and accepted variables are more appropriate
in MyPolicy class. Perhaps rename "accepted" to an instance
"denied" or "allowed" variable of MyPolicy class to reflect
what it intends to mean.
I'm okay if you make the change before the push. No need for a new
webrev.
Mandy
From david.holmes at oracle.com Wed Apr 1 22:26:48 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 02 Apr 2015 08:26:48 +1000
Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with
vm_exit_during_initialization()
when an incorrect class is found on the bootclasspath
In-Reply-To: <55186449.4050606@oracle.com>
References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com>
<55186449.4050606@oracle.com>
Message-ID: <551C70A8.6080304@oracle.com>
On 30/03/2015 6:44 AM, David Holmes wrote:
> On 27/03/2015 5:36 PM, cheleswer sahu wrote:
>> Hi,
>> Please review the code changes for
>> https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9
>> with fix successfully. As I do not have account for OpenJDK, David Buck
>> will push
>> the fix into jdk9/hs-rt/.
>>
>> Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/
>
> Is it possible to include information about where the class was loaded
> from in the message that precedes the exit:
>
> 121 tty->print_cr("Invalid layout of %s at %s",
> ik->external_name(), name_symbol->as_C_string());
>
> The main cause of this problem is android.jar on the bootclasspath. It
> would be good to make that explicit as well. Otherwise we will still get
> bug reports because noone will know what this error means.
I had a good look and it seems the information is not preserved once the
class has been loaded.
Can I suggest this simple addition instead:
vm_exit_during_initialization("Invalid layout of preloaded class: use
-XX:+TraceClassLoading to see the origin of the problem class");
Thanks,
David
> Thanks,
> David
>
>
>> Regards,
>> Cheleswer
>>
>>
>>
>>
From erik.joelsson at oracle.com Thu Apr 2 07:43:34 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 09:43:34 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551C32D8.3020100@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551BA4B3.7010105@oracle.com>
<551C32D8.3020100@oracle.com>
Message-ID: <551CF326.5010402@oracle.com>
Looks good, thanks!
/Erik
On 2015-04-01 20:03, shanliang wrote:
> Erik Joelsson wrote:
>> Hello,
>>
>> (Adding build-dev since this touches makefiles and jigsaw-dev since
>> this touches modules.xml)
>>
>> In general, the build changes look pretty good. I much appreciate
>> moving the OS specific source into OS specific source dirs. A few
>> notes however. Though I realize you followed existing patterns, we
>> have some more current best practices that I would like to
>> incorporate in new code.
>>
>> jdk/make/lib/Lib-jdk.management.gmk:
>>
>> The variables BUILD_LIBJDKMANAGEMENT_SRC and
>> BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While
>> it works, it makes them unnecessarily long and it risks conflicting
>> with internal variables created in the SetupNativeCompilation call.
> Done.
>>
>> BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed.
>> The EXCLUDE_FILES parameter too.
> Done.
>>
>> LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special
>> construct for libmanagement used for a while until cmm was split into
>> a separate module. Just inline the mapfile line into the macro call.
> Done.
>>
>>
>> jdk/make/lib/Lib-java.management.gmk:
>>
>> BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well.
> Removed.
>>
>> LIBMANAGEMENT_MAPFILE should be inlined here as well.
> Done.
>>
>> While you are at it, might as well fix the BUILD_ prefix on the SRC
>> and CFLAGS variables here too if you don't mind.
> Done.
>>
>>
>> Is the need for low optimization when debug symbols are active still
>> valid for both libmanagement and libmanagement_ext?
> Sorry I do not know, I did not touch that flag stting in
> libmanagement, and I copied it for libmanagement_ext.
>
> Here is the new version:
> http://cr.openjdk.java.net/~sjiang/JDK-8042901/01/
>
> Thanks for the review.
> Shanliang
>
>>
>> /Erik
>>
>> On 2015-03-31 18:39, shanliang wrote:
>>> Please review this fix:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
>>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>>>
>>> Some code within the module java.management is separated and moved
>>> to the new module jdk.management, the new module takes the
>>> implementation code for Oracle Corporation's platform extension to
>>> the implementation of the java.lang.management API and also the
>>> management interface for some other components for the platform.
>>>
>>> Thanks,
>>> Shanliang
>>>
>>
>
From dmitry.samersoff at oracle.com Thu Apr 2 11:27:31 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 02 Apr 2015 14:27:31 +0300
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
Message-ID: <551D27A3.1040606@oracle.com>
Everybody,
Please review a small fix.
The fix goes to 9 and 8u at the same time.
http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
-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 david.holmes at oracle.com Thu Apr 2 11:45:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 02 Apr 2015 21:45:25 +1000
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
In-Reply-To: <551D27A3.1040606@oracle.com>
References: <551D27A3.1040606@oracle.com>
Message-ID: <551D2BD5.6010206@oracle.com>
Hi Dmitry,
On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
> Everybody,
>
> Please review a small fix.
>
> The fix goes to 9 and 8u at the same time.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
Not sure I understand the bug synopsis in relation to the fix. Sounds
like FindBugs complained about using a protected static field that was
set directly via a subclass. Not sure why. So now we have a private
field that can be set by anyone via a public method. Maybe the
setInstance method should be protected not public?
But do we really care? Either ways seems fine to me if it silences FindBugs.
David
> -Dmitry
>
From dmitry.samersoff at oracle.com Thu Apr 2 12:05:54 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 02 Apr 2015 15:05:54 +0300
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
In-Reply-To: <551D2BD5.6010206@oracle.com>
References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com>
Message-ID: <551D30A2.4070003@oracle.com>
David,
On 2015-04-02 14:45, David Holmes wrote:
> Hi Dmitry,
>
> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please review a small fix.
>>
>> The fix goes to 9 and 8u at the same time.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
>
> Not sure I understand the bug synopsis in relation to the fix. Sounds
> like FindBugs complained about using a protected static field that was
> set directly via a subclass. Not sure why. So now we have a private
> field that can be set by anyone via a public method. Maybe the
> setInstance method should be protected not public?
Agree - I'll update the fix.
> But do we really care? Either ways seems fine to me if it silences
> FindBugs.
Yes, this is the goal.
-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 yekaterina.kantserova at oracle.com Thu Apr 2 12:16:43 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Thu, 02 Apr 2015 14:16:43 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
Message-ID: <551D332B.3060002@oracle.com>
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8027668
webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
The tests can still contain a race. There is a possibility the jstad is
not really started though there is a pid for the process. The suggestion
is to let jstatd notify it's started and for the test wait until this
notification.
Thanks,
Katja
From dmitry.samersoff at oracle.com Thu Apr 2 12:35:33 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 02 Apr 2015 15:35:33 +0300
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
In-Reply-To: <551D30A2.4070003@oracle.com>
References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com>
<551D30A2.4070003@oracle.com>
Message-ID: <551D3795.1050002@oracle.com>
Fix updated.
On 2015-04-02 15:05, Dmitry Samersoff wrote:
> David,
>
>
> On 2015-04-02 14:45, David Holmes wrote:
>> Hi Dmitry,
>>
>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please review a small fix.
>>>
>>> The fix goes to 9 and 8u at the same time.
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
>>
>> Not sure I understand the bug synopsis in relation to the fix. Sounds
>> like FindBugs complained about using a protected static field that was
>> set directly via a subclass. Not sure why. So now we have a private
>> field that can be set by anyone via a public method. Maybe the
>> setInstance method should be protected not public?
>
> Agree - I'll update the fix.
>
>> But do we really care? Either ways seems fine to me if it silences
>> FindBugs.
>
> Yes, this is the goal.
>
> -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 jaroslav.bachorik at oracle.com Thu Apr 2 12:44:36 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 02 Apr 2015 14:44:36 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <551D332B.3060002@oracle.com>
References: <551D332B.3060002@oracle.com>
Message-ID: <551D39B4.70506@oracle.com>
Hi Katja,
On 2.4.2015 14:16, Yekaterina Kantserova wrote:
> Hi,
>
> Could I please have a review of this fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would
suggest adding System.out.flush() after printing "jstatd is started on
..." to make sure the output is actually committed to stdout.
Please, update the copyright years.
-JB-
>
> The tests can still contain a race. There is a possibility the jstad is
> not really started though there is a pid for the process. The suggestion
> is to let jstatd notify it's started and for the test wait until this
> notification.
>
> Thanks,
> Katja
From jaroslav.bachorik at oracle.com Thu Apr 2 12:45:50 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 02 Apr 2015 14:45:50 +0200
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
In-Reply-To: <551D3795.1050002@oracle.com>
References: <551D27A3.1040606@oracle.com>
<551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com>
<551D3795.1050002@oracle.com>
Message-ID: <551D39FE.20402@oracle.com>
On 2.4.2015 14:35, Dmitry Samersoff wrote:
> Fix updated.
I like this better. Still rather convoluted but it seems to be as good
as we can get without a bigger rewrite.
I'm ok with this change.
Cheers,
-JB-
>
> On 2015-04-02 15:05, Dmitry Samersoff wrote:
>> David,
>>
>>
>> On 2015-04-02 14:45, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>>>> Everybody,
>>>>
>>>> Please review a small fix.
>>>>
>>>> The fix goes to 9 and 8u at the same time.
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
>>>
>>> Not sure I understand the bug synopsis in relation to the fix. Sounds
>>> like FindBugs complained about using a protected static field that was
>>> set directly via a subclass. Not sure why. So now we have a private
>>> field that can be set by anyone via a public method. Maybe the
>>> setInstance method should be protected not public?
>>
>> Agree - I'll update the fix.
>>
>>> But do we really care? Either ways seems fine to me if it silences
>>> FindBugs.
>>
>> Yes, this is the goal.
>>
>> -Dmitry
>>
>>
>
>
From dmitry.samersoff at oracle.com Thu Apr 2 12:51:57 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 02 Apr 2015 15:51:57 +0300
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
In-Reply-To: <551D39FE.20402@oracle.com>
References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com> <551D3795.1050002@oracle.com>
<551D39FE.20402@oracle.com>
Message-ID: <551D3B6D.2040300@oracle.com>
Jaroslav,
Thank you!
-Dmitry
On 2015-04-02 15:45, Jaroslav Bachorik wrote:
> On 2.4.2015 14:35, Dmitry Samersoff wrote:
>> Fix updated.
>
> I like this better. Still rather convoluted but it seems to be as good
> as we can get without a bigger rewrite.
>
> I'm ok with this change.
>
> Cheers,
>
> -JB-
>
>>
>> On 2015-04-02 15:05, Dmitry Samersoff wrote:
>>> David,
>>>
>>>
>>> On 2015-04-02 14:45, David Holmes wrote:
>>>> Hi Dmitry,
>>>>
>>>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>>>>> Everybody,
>>>>>
>>>>> Please review a small fix.
>>>>>
>>>>> The fix goes to 9 and 8u at the same time.
>>>>>
>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
>>>>
>>>> Not sure I understand the bug synopsis in relation to the fix. Sounds
>>>> like FindBugs complained about using a protected static field that was
>>>> set directly via a subclass. Not sure why. So now we have a private
>>>> field that can be set by anyone via a public method. Maybe the
>>>> setInstance method should be protected not public?
>>>
>>> Agree - I'll update the fix.
>>>
>>>> But do we really care? Either ways seems fine to me if it silences
>>>> FindBugs.
>>>
>>> Yes, this is the goal.
>>>
>>> -Dmitry
>>>
>>>
>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From dmitry.samersoff at oracle.com Thu Apr 2 12:54:35 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 02 Apr 2015 15:54:35 +0300
Subject: RFR(XS): JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI
some methods need final protect
Message-ID: <551D3C0B.3080803@oracle.com>
Everybody,
Please review a small fix:
The fix goes to 9 and 8u at the same time.
http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
-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 yekaterina.kantserova at oracle.com Thu Apr 2 12:56:13 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Thu, 02 Apr 2015 14:56:13 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <551D39B4.70506@oracle.com>
References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com>
Message-ID: <551D3C6D.2060000@oracle.com>
Jaroslav,
thanks, will do!
// Katja
On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote:
> Hi Katja,
>
> On 2.4.2015 14:16, Yekaterina Kantserova wrote:
>> Hi,
>>
>> Could I please have a review of this fix.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
>
> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would
> suggest adding System.out.flush() after printing "jstatd is started on
> ..." to make sure the output is actually committed to stdout.
>
> Please, update the copyright years.
>
> -JB-
>
>>
>> The tests can still contain a race. There is a possibility the jstad is
>> not really started though there is a pid for the process. The suggestion
>> is to let jstatd notify it's started and for the test wait until this
>> notification.
>>
>> Thanks,
>> Katja
>
From jaroslav.bachorik at oracle.com Thu Apr 2 12:56:45 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 02 Apr 2015 14:56:45 +0200
Subject: RFR(XS): JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI
some methods need final protect
In-Reply-To: <551D3C0B.3080803@oracle.com>
References: <551D3C0B.3080803@oracle.com>
Message-ID: <551D3C8D.8000008@oracle.com>
Hi,
Looks good. Just update the copyright year.
-JB-
On 2.4.2015 14:54, Dmitry Samersoff wrote:
> Everybody,
>
> Please review a small fix:
>
> The fix goes to 9 and 8u at the same time.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
>
> -Dmitry
>
From staffan.larsen at oracle.com Thu Apr 2 13:04:20 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 2 Apr 2015 15:04:20 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <551D3C6D.2060000@oracle.com>
References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com>
<551D3C6D.2060000@oracle.com>
Message-ID: <5F5A2830-48E0-4520-8C76-99A1F6C1CCA3@oracle.com>
What does the name.toString() look like? Should the message be ?jstatd listening on ???
> On 2 apr 2015, at 14:56, Yekaterina Kantserova wrote:
>
> Jaroslav,
>
> thanks, will do!
>
> // Katja
>
>
>
> On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote:
>> Hi Katja,
>>
>> On 2.4.2015 14:16, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> Could I please have a review of this fix.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
>>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
>>
>> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would suggest adding System.out.flush() after printing "jstatd is started on ..." to make sure the output is actually committed to stdout.
>>
>> Please, update the copyright years.
>>
>> -JB-
>>
>>>
>>> The tests can still contain a race. There is a possibility the jstad is
>>> not really started though there is a pid for the process. The suggestion
>>> is to let jstatd notify it's started and for the test wait until this
>>> notification.
>>>
>>> Thanks,
>>> Katja
>>
>
From yekaterina.kantserova at oracle.com Thu Apr 2 13:29:22 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Thu, 02 Apr 2015 15:29:22 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <5F5A2830-48E0-4520-8C76-99A1F6C1CCA3@oracle.com>
References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com>
<551D3C6D.2060000@oracle.com>
<5F5A2830-48E0-4520-8C76-99A1F6C1CCA3@oracle.com>
Message-ID: <551D4432.3000700@oracle.com>
name is a combination of:
rmi name = Name to which the remote RMI object is bound in the RMI registry
port = Port number where the RMI registry is expected to be found
"jstatd is bound to ..."?
// Katja
> What does the name.toString() look like? Should the message be ?jstatd listening on ???
>
>> On 2 apr 2015, at 14:56, Yekaterina Kantserova wrote:
>>
>> Jaroslav,
>>
>> thanks, will do!
>>
>> // Katja
>>
>>
>>
>> On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote:
>>> Hi Katja,
>>>
>>> On 2.4.2015 14:16, Yekaterina Kantserova wrote:
>>>> Hi,
>>>>
>>>> Could I please have a review of this fix.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
>>>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
>>> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would suggest adding System.out.flush() after printing "jstatd is started on ..." to make sure the output is actually committed to stdout.
>>>
>>> Please, update the copyright years.
>>>
>>> -JB-
>>>
>>>> The tests can still contain a race. There is a possibility the jstad is
>>>> not really started though there is a pid for the process. The suggestion
>>>> is to let jstatd notify it's started and for the test wait until this
>>>> notification.
>>>>
>>>> Thanks,
>>>> Katja
From cheleswer.sahu at oracle.com Thu Apr 2 15:31:24 2015
From: cheleswer.sahu at oracle.com (cheleswer sahu)
Date: Thu, 02 Apr 2015 21:01:24 +0530
Subject: RFR[ 9u-dev] JDK-8072863 - Replace fatal() with
vm_exit_during_initialization()
when an incorrect class is found on the bootclasspath
In-Reply-To: <55186449.4050606@oracle.com>
References: <55141556.1070005@oracle.com> <5515086B.7050907@oracle.com>
<55186449.4050606@oracle.com>
Message-ID: <551D60CC.10909@oracle.com>
Hi,
Please review the new code changes. I have incorporated the suggestion
received from 'David Holmes' in code and built successfully. As I do
not have account for OpenJDK, David Buck will push the fix into jdk9/hs-rt/.
web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.02/
Regards,
Cheleswer
On 3/30/2015 2:14 AM, David Holmes wrote:
> On 27/03/2015 5:36 PM, cheleswer sahu wrote:
>> Hi,
>> Please review the code changes for
>> https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9
>> with fix successfully. As I do not have account for OpenJDK, David Buck
>> will push
>> the fix into jdk9/hs-rt/.
>>
>> Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/
>
> Is it possible to include information about where the class was loaded
> from in the message that precedes the exit:
>
> 121 tty->print_cr("Invalid layout of %s at %s",
> ik->external_name(), name_symbol->as_C_string());
>
> The main cause of this problem is android.jar on the bootclasspath. It
> would be good to make that explicit as well. Otherwise we will still
> get bug reports because noone will know what this error means.
>
> Thanks,
> David
>
>
>> Regards,
>> Cheleswer
>>
>>
>>
>>
From serguei.spitsyn at oracle.com Thu Apr 2 19:44:26 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 02 Apr 2015 12:44:26 -0700
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
In-Reply-To: <551D3795.1050002@oracle.com>
References: <551D27A3.1040606@oracle.com>
<551D2BD5.6010206@oracle.com> <551D30A2.4070003@oracle.com>
<551D3795.1050002@oracle.com>
Message-ID: <551D9C1A.5030008@oracle.com>
Looks good.
Thanks,
Serguei
On 4/2/15 5:35 AM, Dmitry Samersoff wrote:
> Fix updated.
>
> On 2015-04-02 15:05, Dmitry Samersoff wrote:
>> David,
>>
>>
>> On 2015-04-02 14:45, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>>>> Everybody,
>>>>
>>>> Please review a small fix.
>>>>
>>>> The fix goes to 9 and 8u at the same time.
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
>>> Not sure I understand the bug synopsis in relation to the fix. Sounds
>>> like FindBugs complained about using a protected static field that was
>>> set directly via a subclass. Not sure why. So now we have a private
>>> field that can be set by anyone via a public method. Maybe the
>>> setInstance method should be protected not public?
>> Agree - I'll update the fix.
>>
>>> But do we really care? Either ways seems fine to me if it silences
>>> FindBugs.
>> Yes, this is the goal.
>>
>> -Dmitry
>>
>>
>
From serguei.spitsyn at oracle.com Thu Apr 2 19:46:58 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 02 Apr 2015 12:46:58 -0700
Subject: RFR(XS): JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI
some methods need final protect
In-Reply-To: <551D3C0B.3080803@oracle.com>
References: <551D3C0B.3080803@oracle.com>
Message-ID: <551D9CB2.3070405@oracle.com>
Looks good.
Thanks,
Serguei
On 4/2/15 5:54 AM, Dmitry Samersoff wrote:
> Everybody,
>
> Please review a small fix:
>
> The fix goes to 9 and 8u at the same time.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
>
> -Dmitry
>
From shanliang.jiang at oracle.com Thu Apr 2 19:58:14 2015
From: shanliang.jiang at oracle.com (Shanliang Jiang)
Date: Thu, 02 Apr 2015 21:58:14 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551C6622.1020609@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com>
Message-ID: <551D9F56.4050201@oracle.com>
Hi,
I have to ask the review again because I need to modify:
langtools/src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java
The issue was found when langtools tests were added into my test list.
The new version is:
http://cr.openjdk.java.net/~sjiang/JDK-8042901/02/
which integrated also the Mandy's comments in the following mail.
Thanks,
Shanliang
Mandy Chung wrote:
> On 3/31/2015 9:39 AM, shanliang wrote:
>> Please review this fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>
> Thank you for doing this big change to separate com.sun.management
> API from java.management module. Looking really good.
>
> Also thanks for fixing the tests to eliminate the unnecessary use of
> JDK internal APIs.
>
> modules.xml change looks good to me.
>
> sun/management/ThreadImpl.java
> 35 /**
> 36 * Implementation class for the thread subsystem.
> 37 * Standard and committed hotspot-specific metrics if any.
> 38 *
> 39 * ManagementFactory.getThreadMXBean() returns an instance
> 40 * of this class.
> 41 */
> 42 // the implementation for com.sun.management.ThreadMXBean can
> 43 // be moved to jdk.management in the future.
>
> What about:
> Implementation for java.lang.management.ThreadMXBean as well as
> providing the supporting method for com.sun.management.ThreadMXBean.
> The supporting method for com.sun.management.ThreadMXBean can
> be moved to jdk.management in the future.
>
> CheckSomeMXBeanImplPackage.java
> Thanks for adding this test.
>
> Iterating jrt file system to find jdk.management module is one way.
> Another simpler alternative is to call:
> Class.forName("com.sun.management.GarbageCollectorMXBean");
> and catch CNFE to determine if it's present or not.
>
> You should also call ManagementFactory.getPlatformMXBeans on
> com.sun.management.GarbageCollectorMXBean if present.
>
> VMOptionOpenDataTest.java
> copyright header year is wrong.
>
> PlatformMBeanProviderConstructorCheck.java
> The test needs to restore the original policy and security manager
> before the test exits in case this case runs in agent vm mode.
> The static permName and accepted variables are more appropriate
> in MyPolicy class. Perhaps rename "accepted" to an instance
> "denied" or "allowed" variable of MyPolicy class to reflect
> what it intends to mean.
>
> I'm okay if you make the change before the push. No need for a new
> webrev.
>
> Mandy
>
From mandy.chung at oracle.com Thu Apr 2 20:09:08 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 02 Apr 2015 13:09:08 -0700
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551D9F56.4050201@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com>
<551D9F56.4050201@oracle.com>
Message-ID: <551DA1E4.6070709@oracle.com>
On 4/2/15 12:58 PM, Shanliang Jiang wrote:
> Hi,
>
> I have to ask the review again because I need to modify:
> langtools/src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java
>
> The issue was found when langtools tests were added into my test list.
>
> The new version is:
> http://cr.openjdk.java.net/~sjiang/JDK-8042901/02/
>
Thanks for catching the jdeps change. Profile.java change looks okay
and this list is temporary. jdeps will be updated to determine the
exported APIs at runtime when the module system is moving along.
> which integrated also the Mandy's comments in the following mail.
>
CheckSomeMXBeanImplPackage.java
line 45-50 & 58-60: should be called unconditionally since they
should pass if java.management is present.
Okay to push once the test is updated.
Mandy
From serguei.spitsyn at oracle.com Fri Apr 3 00:03:07 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 02 Apr 2015 17:03:07 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException: Method
name is null" from StackTraceElement.
Message-ID: <551DD8BB.5040001@oracle.com>
Please, review the jdk 8u60 backport for:
https://bugs.openjdk.java.net/browse/JDK-8067662
8u60 hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
8u60 webrev for unit test update (the fix applies cleanly):
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
9 hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
9 webrev for unit test update:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
Summary:
The 9 fix can not be applied cleanly so that I have to rework the fix
a little bit.
An NPE is trown in a thread dumping via JMX when doing CPU profiling
in NetBeans Profiler and VisualVM.
The issue is that the methods and related klass versions are not kept
alive if a class redefinition
takes place between catching a Throwable and taking a thread dump.
It can result in loosing an obsolete method, and so, the
reconstruction of method name becomes impossible.
In such a case, the null reference is returned instead of a valid
method name.
The solution is to use current klass version and method orig_idnum
instead of ordinary method idnum
to find required method pointer. In the worst case when the related
klass version is gone
(was not included to or was removed from the previous_versions linked
list), a saved method name
CP index of the latest klass version can be used to restore the
method name.
The footprint extra overhead for this approach is u2 per stack frame.
Testing in progress:
In progress: nsk redefine classes tests, JTREG java/lang/instrument
Thanks,
Serguei
From david.holmes at oracle.com Fri Apr 3 01:00:06 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 03 Apr 2015 11:00:06 +1000
Subject: RFR(S): JDK-8068007 [Findbugs] SA
com.sun.java.swing.action.ActionManager.manager
should be package protect
In-Reply-To: <551D3795.1050002@oracle.com>
References: <551D27A3.1040606@oracle.com> <551D2BD5.6010206@oracle.com>
<551D30A2.4070003@oracle.com> <551D3795.1050002@oracle.com>
Message-ID: <551DE616.4060609@oracle.com>
Looks good.
Thanks,
David
On 2/04/2015 10:35 PM, Dmitry Samersoff wrote:
> Fix updated.
>
> On 2015-04-02 15:05, Dmitry Samersoff wrote:
>> David,
>>
>>
>> On 2015-04-02 14:45, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>>>> Everybody,
>>>>
>>>> Please review a small fix.
>>>>
>>>> The fix goes to 9 and 8u at the same time.
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
>>>
>>> Not sure I understand the bug synopsis in relation to the fix. Sounds
>>> like FindBugs complained about using a protected static field that was
>>> set directly via a subclass. Not sure why. So now we have a private
>>> field that can be set by anyone via a public method. Maybe the
>>> setInstance method should be protected not public?
>>
>> Agree - I'll update the fix.
>>
>>> But do we really care? Either ways seems fine to me if it silences
>>> FindBugs.
>>
>> Yes, this is the goal.
>>
>> -Dmitry
>>
>>
>
>
From shanliang.jiang at oracle.com Fri Apr 3 07:30:52 2015
From: shanliang.jiang at oracle.com (Shanliang Jiang)
Date: Fri, 03 Apr 2015 09:30:52 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
to java.lang.management
In-Reply-To: <551DA1E4.6070709@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com>
<551D9F56.4050201@oracle.com> <551DA1E4.6070709@oracle.com>
Message-ID: <551E41AC.6000407@oracle.com>
Mandy Chung wrote:
> CheckSomeMXBeanImplPackage.java
> line 45-50 & 58-60: should be called unconditionally since they
> should pass if java.management is present.
The method "check" checks that an MBean implementation must be from
"com.sun.management.internal", so even we look for an MXBean with its
standard MXBean class (java.lang.management.*), do "check" still needs
jdk.management module to be present.
We need more unit tests for the case when jdk.management is absent.
Thanks,
Shanliang
From jaroslav.bachorik at oracle.com Fri Apr 3 14:31:03 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 03 Apr 2015 16:31:03 +0200
Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when called
with empty array for thread ids
Message-ID: <551EA427.3030409@oracle.com>
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8074368
Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00
Invoking ThreadMXBean.getThreadInfo(long[] ids, int maxdepth) with an
empty array for 'ids' and positive number for 'maxdepth' can result in
memory corruption. Basically, the native routine (VM_ThreadDump)
considers the empty ids array as a signal to process all the available
threads and put their information to the pre-allocated array while the
pre-allocated array's size is 0.
The solution is to modify 'management.cpp' and check for 'num_threads'
before actually attempting to do the thread dump.
As a defense-in-depth the ThreadMXBean.getThreadInfo(*) methods are
modified to adhere to their specification and return 'an array of the
ThreadInfo objects, each containing information about a thread whose ID
is in the corresponding element of the input array of IDs' - meaning
that an empty ids array will result in an empty ThreadInfo array.
Thanks,
-JB-
From me at basilcrow.com Fri Apr 3 17:27:33 2015
From: me at basilcrow.com (Basil Crow)
Date: Fri, 3 Apr 2015 10:27:33 -0700
Subject: Unable to create hprof heap dump from core file with jmap on Oracle
Solaris
Message-ID:
Hi all,
I'm having trouble using jmap(1) to create an hprof heap dump from a
core file on Oracle Solaris with version 8 of the Oracle JDK. This
worked with version 7 of the Oracle JDK:
$ cat Sleep.java
public class Sleep {
public static void main(String[] args) throws InterruptedException {
Thread.sleep(300000);
}
}
$ /opt/jdk1.7.0_76/bin/javac Sleep.java
$ /opt/jdk1.7.0_76/bin/java Sleep &
[1] 1348
$ gcore 1348
gcore: core.1348 dumped
$ jmap -dump:format=b,file=core1348.hprof /opt/jdk1.7.0_76/bin/java \
core.1348
Attaching to core core.1348 from executable /opt/jdk1.7.0_76/bin/java
Debugger attached successfully.
Client compiler detected.
JVM version is 24.76-b04
Dumping heap to core1348.hprof ...
Heap dump file created
This also works with version 8 of the Oracle JDK when lambdas are not
used:
$ /opt/jdk1.8.0_40/bin/javac Sleep.java
$ /opt/jdk1.8.0_40/bin/java Sleep &
[1] 1398
$ gcore 1398
gcore: core.1398 dumped
$ jmap -dump:format=b,file=core1398.hprof /opt/jdk1.8.0_40/bin/java \
core.1398
Attaching to core core.1398 from executable /opt/jdk1.8.0_40/bin/java
Debugger attached successfully.
Server compiler detected.
JVM version is 25.40-b25
Dumping heap to core1398.hprof ...
Heap dump file created
However, this no longer works with version 8 of the Oracle JDK when
lambdas are used:
$ cat LambdaSleep.java
import java.util.Arrays;
public class LambdaSleep {
public static void main(String[] args) throws InterruptedException {
String[] words = new String[] { "longer", "short" };
Arrays.sort(words, (first, second) ->
Integer.compare(first.length(), second.length()));
Thread.sleep(300000);
}
}
$ javac LambdaSleep.java
$ java LambdaSleep &
[1] 1416
$ gcore 1416
gcore: core.1416 dumped
$ jmap -dump:format=b,file=core1416.hprof /opt/jdk1.8.0_40/bin/java \
core.1416
Attaching to core core.1416 from executable /opt/jdk1.8.0_40/bin/java
Debugger attached successfully.
Server compiler detected.
JVM version is 25.40-b25
Dumping heap to core1416.hprof ...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at sun.tools.jmap.JMap.runTool(JMap.java:201)
at sun.tools.jmap.JMap.main(JMap.java:130)
Caused by: sun.jvm.hotspot.utilities.AssertionFailure: can not get class
data for LambdaSleep$$Lambda$10x0000000100071828
at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeInstance(
HeapHprofBinWriter.java:803)
at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj(
AbstractHeapGraphWriter.java:95)
at sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(
ObjectHeap.java:353)
at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:171)
at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(
AbstractHeapGraphWriter.java:51)
at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(
HeapHprofBinWriter.java:433)
at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62)
at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)
... 6 more
Note that this problem only occurs when creating an hprof heap dump from
a core file. It doesn't occur when creating an hprof heap dump from a
live process:
$ java LambdaSleep &
[1] 1421
$ jmap -dump:format=b,file=core1421.hprof 1421
Dumping heap to core1421.hprof ...
Heap dump file created
I have reproduced this issue with Java version 1.8.0_40 (JVM version
25.40-b25) on the following platforms:
Oracle Solaris 10 9/10 s10x_u9wos_14a X86
Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
Oracle Solaris 11.1 X86
Oracle Solaris 11.2 X86
I found a similar issue in the JDK bug system (JDK-8044416), but the
last update there stated that JDK-8044416 "is about the -F
functionality" and to "please file a different bug for problems when
running without -F." I am running without -F, but I haven't been able to
find another bug that tracks the issue described above.
An update would be appreciated, as this bug greatly hampers our ability
to debug memory leaks in production.
Thanks,
Basil
From dmitry.samersoff at oracle.com Fri Apr 3 21:27:49 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sat, 04 Apr 2015 00:27:49 +0300
Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA
com.sun.java.swing.ui.CommonUI some methods need final protect
In-Reply-To: <551D3C0B.3080803@oracle.com>
References: <551D3C0B.3080803@oracle.com>
Message-ID: <551F05D5.9080601@oracle.com>
Everybody,
Please, review updated webrev:
http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/
Fixed a compilation error that wasn't caught during incremental build.
-Dmitry
On 2015-04-02 15:54, Dmitry Samersoff wrote:
> Everybody,
>
> Please review a small fix:
>
> The fix goes to 9 and 8u at the same time.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
>
> -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 mandy.chung at oracle.com Fri Apr 3 21:35:52 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 03 Apr 2015 14:35:52 -0700
Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when
called with empty array for thread ids
In-Reply-To: <551EA427.3030409@oracle.com>
References: <551EA427.3030409@oracle.com>
Message-ID: <551F07B8.2010006@oracle.com>
On 4/3/15 7:31 AM, Jaroslav Bachorik wrote:
> Please, review the following change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8074368
> Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00
>
Looks okay to me.
Minor comment on ThreadInfoArray.java test:
You can have one single @bug line with multiple bug numbers
line 57, 90: can you rename "direct" to mbean?
line 59, 92: formatting - indent to the right
Mandy
From serguei.spitsyn at oracle.com Fri Apr 3 22:52:58 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 03 Apr 2015 15:52:58 -0700
Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA
com.sun.java.swing.ui.CommonUI some methods need final protect
In-Reply-To: <551F05D5.9080601@oracle.com>
References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com>
Message-ID: <551F19CA.4010204@oracle.com>
Dmitry,
I'm puzzled a little bit with the webrev.02:
agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java
- buttonSize = new Dimension(CommonUI.buttconPrefSize);
+ buttonSize = new Dimension(CommonUI.getButtonPrefSize());
Why do you replace the CommonUI.buttconPrefSize with the
CommonUI.getButtonPrefSize() ?
It looks like a typo, did you really want to do one of the following:
- buttonSize = new Dimension(CommonUI.buttconPrefSize);
+ buttonSize = new Dimension(CommonUI.getButtconPrefSize());
In such a case, the fix must be updated in the
agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java
+ public static Dimension getButtonPrefSize()
+ {
+ return buttonPrefSize;
+ }
=>
+ public static Dimension getButtconPrefSize()
+ {
+ return buttconPrefSize;
+ }
Thanks,
Serguei
On 4/3/15 2:27 PM, Dmitry Samersoff wrote:
> Everybody,
>
> Please, review updated webrev:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/
>
> Fixed a compilation error that wasn't caught during incremental build.
>
> -Dmitry
>
>
>
> On 2015-04-02 15:54, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please review a small fix:
>>
>> The fix goes to 9 and 8u at the same time.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
>>
>> -Dmitry
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dmitry.samersoff at oracle.com Sat Apr 4 07:06:36 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sat, 04 Apr 2015 10:06:36 +0300
Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA
com.sun.java.swing.ui.CommonUI some methods need final protect
In-Reply-To: <551F19CA.4010204@oracle.com>
References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com>
<551F19CA.4010204@oracle.com>
Message-ID: <551F8D7C.7080407@oracle.com>
Serguei,
Yes, it's a typeo. Time to buy glasses.
Thank you for catching it.
Webrev updated in-place (press shift-reload).
-Dmitry
On 2015-04-04 01:52, serguei.spitsyn at oracle.com wrote:
> Dmitry,
>
> I'm puzzled a little bit with the webrev.02:
>
> agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java
>
> - buttonSize = new Dimension(CommonUI.buttconPrefSize);
> + buttonSize = new Dimension(CommonUI.getButtonPrefSize());
>
>
> Why do you replace the CommonUI.buttconPrefSize with the
> CommonUI.getButtonPrefSize() ?
> It looks like a typo, did you really want to do one of the following:
>
> - buttonSize = new Dimension(CommonUI.buttconPrefSize);
> + buttonSize = new Dimension(CommonUI.getButtconPrefSize());
>
>
> In such a case, the fix must be updated in the
> agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java
>
> + public static Dimension getButtonPrefSize()
> + {
> + return buttonPrefSize;
> + }
>
> =>
>
> + public static Dimension getButtconPrefSize()
> + {
> + return buttconPrefSize;
> + }
>
>
>
> Thanks,
> Serguei
>
> On 4/3/15 2:27 PM, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please, review updated webrev:
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/
>>
>> Fixed a compilation error that wasn't caught during incremental build.
>>
>> -Dmitry
>>
>>
>>
>> On 2015-04-02 15:54, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please review a small fix:
>>>
>>> The fix goes to 9 and 8u at the same time.
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
>>>
>>> -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 serguei.spitsyn at oracle.com Sat Apr 4 08:58:34 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Sat, 04 Apr 2015 01:58:34 -0700
Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA
com.sun.java.swing.ui.CommonUI some methods need final protect
In-Reply-To: <551F8D7C.7080407@oracle.com>
References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com>
<551F19CA.4010204@oracle.com> <551F8D7C.7080407@oracle.com>
Message-ID: <551FA7BA.4020405@oracle.com>
Dmitry,
I think, no re-review is necessary after fixing this typo.
You had addressed the review comments.
Thanks,
Serguei
On 4/4/15 12:06 AM, Dmitry Samersoff wrote:
> Serguei,
>
> Yes, it's a typeo. Time to buy glasses.
>
> Thank you for catching it.
>
> Webrev updated in-place (press shift-reload).
>
> -Dmitry
>
>
> On 2015-04-04 01:52, serguei.spitsyn at oracle.com wrote:
>> Dmitry,
>>
>> I'm puzzled a little bit with the webrev.02:
>>
>> agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java
>>
>> - buttonSize = new Dimension(CommonUI.buttconPrefSize);
>> + buttonSize = new Dimension(CommonUI.getButtonPrefSize());
>>
>>
>> Why do you replace the CommonUI.buttconPrefSize with the
>> CommonUI.getButtonPrefSize() ?
>> It looks like a typo, did you really want to do one of the following:
>>
>> - buttonSize = new Dimension(CommonUI.buttconPrefSize);
>> + buttonSize = new Dimension(CommonUI.getButtconPrefSize());
>>
>>
>> In such a case, the fix must be updated in the
>> agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java
>>
>> + public static Dimension getButtonPrefSize()
>> + {
>> + return buttonPrefSize;
>> + }
>>
>> =>
>>
>> + public static Dimension getButtconPrefSize()
>> + {
>> + return buttconPrefSize;
>> + }
>>
>>
>>
>> Thanks,
>> Serguei
>>
>> On 4/3/15 2:27 PM, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please, review updated webrev:
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/
>>>
>>> Fixed a compilation error that wasn't caught during incremental build.
>>>
>>> -Dmitry
>>>
>>>
>>>
>>> On 2015-04-02 15:54, Dmitry Samersoff wrote:
>>>> Everybody,
>>>>
>>>> Please review a small fix:
>>>>
>>>> The fix goes to 9 and 8u at the same time.
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
>>>>
>>>> -Dmitry
>>>>
>
From dmitry.samersoff at oracle.com Sat Apr 4 09:23:19 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sat, 04 Apr 2015 12:23:19 +0300
Subject: RFR(XS)v2: JDK-8067991 [Findbugs] SA
com.sun.java.swing.ui.CommonUI some methods need final protect
In-Reply-To: <551FA7BA.4020405@oracle.com>
References: <551D3C0B.3080803@oracle.com> <551F05D5.9080601@oracle.com>
<551F19CA.4010204@oracle.com> <551F8D7C.7080407@oracle.com>
<551FA7BA.4020405@oracle.com>
Message-ID: <551FAD87.6070201@oracle.com>
Serguei,
Thanks!
-Dmitry
On 2015-04-04 11:58, serguei.spitsyn at oracle.com wrote:
> Dmitry,
>
> I think, no re-review is necessary after fixing this typo.
> You had addressed the review comments.
>
> Thanks,
> Serguei
>
> On 4/4/15 12:06 AM, Dmitry Samersoff wrote:
>> Serguei,
>>
>> Yes, it's a typeo. Time to buy glasses.
>>
>> Thank you for catching it.
>>
>> Webrev updated in-place (press shift-reload).
>>
>> -Dmitry
>>
>>
>> On 2015-04-04 01:52, serguei.spitsyn at oracle.com wrote:
>>> Dmitry,
>>>
>>> I'm puzzled a little bit with the webrev.02:
>>>
>>> agent/src/share/classes/com/sun/java/swing/ui/CommonToolBar.java
>>>
>>> - buttonSize = new Dimension(CommonUI.buttconPrefSize);
>>> + buttonSize = new Dimension(CommonUI.getButtonPrefSize());
>>>
>>>
>>> Why do you replace the CommonUI.buttconPrefSize with the
>>> CommonUI.getButtonPrefSize() ?
>>> It looks like a typo, did you really want to do one of the following:
>>>
>>> - buttonSize = new Dimension(CommonUI.buttconPrefSize);
>>> + buttonSize = new Dimension(CommonUI.getButtconPrefSize());
>>>
>>>
>>> In such a case, the fix must be updated in the
>>> agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java
>>>
>>> + public static Dimension getButtonPrefSize()
>>> + {
>>> + return buttonPrefSize;
>>> + }
>>>
>>> =>
>>>
>>> + public static Dimension getButtconPrefSize()
>>> + {
>>> + return buttconPrefSize;
>>> + }
>>>
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 4/3/15 2:27 PM, Dmitry Samersoff wrote:
>>>> Everybody,
>>>>
>>>> Please, review updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/
>>>>
>>>> Fixed a compilation error that wasn't caught during incremental build.
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>>
>>>> On 2015-04-02 15:54, Dmitry Samersoff wrote:
>>>>> Everybody,
>>>>>
>>>>> Please review a small fix:
>>>>>
>>>>> The fix goes to 9 and 8u at the same time.
>>>>>
>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
>>>>> -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 Sun Apr 5 08:01:59 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sun, 05 Apr 2015 11:01:59 +0300
Subject: Unable to create hprof heap dump from core file with jmap on
Oracle Solaris
In-Reply-To:
References:
Message-ID: <5520EBF7.6030808@oracle.com>
Basil,
jmap uses SA backend to extract data from coredump and it doesn't
support lambda.
See JDK-8073604
-Dmitry
On 2015-04-03 20:27, Basil Crow wrote:
> Hi all,
>
> I'm having trouble using jmap(1) to create an hprof heap dump from a
> core file on Oracle Solaris with version 8 of the Oracle JDK. This
> worked with version 7 of the Oracle JDK:
>
> $ cat Sleep.java
> public class Sleep {
> public static void main(String[] args) throws InterruptedException {
> Thread.sleep(300000);
> }
> }
> $ /opt/jdk1.7.0_76/bin/javac Sleep.java
> $ /opt/jdk1.7.0_76/bin/java Sleep &
> [1] 1348
> $ gcore 1348
> gcore: core.1348 dumped
> $ jmap -dump:format=b,file=core1348.hprof /opt/jdk1.7.0_76/bin/java \
> core.1348
> Attaching to core core.1348 from executable /opt/jdk1.7.0_76/bin/java
> Debugger attached successfully.
> Client compiler detected.
> JVM version is 24.76-b04
> Dumping heap to core1348.hprof ...
> Heap dump file created
>
> This also works with version 8 of the Oracle JDK when lambdas are not
> used:
>
> $ /opt/jdk1.8.0_40/bin/javac Sleep.java
> $ /opt/jdk1.8.0_40/bin/java Sleep &
> [1] 1398
> $ gcore 1398
> gcore: core.1398 dumped
> $ jmap -dump:format=b,file=core1398.hprof /opt/jdk1.8.0_40/bin/java \
> core.1398
> Attaching to core core.1398 from executable /opt/jdk1.8.0_40/bin/java
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.40-b25
> Dumping heap to core1398.hprof ...
> Heap dump file created
>
> However, this no longer works with version 8 of the Oracle JDK when
> lambdas are used:
>
> $ cat LambdaSleep.java
> import java.util.Arrays;
>
> public class LambdaSleep {
> public static void main(String[] args) throws InterruptedException {
> String[] words = new String[] { "longer", "short" };
> Arrays.sort(words, (first, second) ->
> Integer.compare(first.length(), second.length()));
> Thread.sleep(300000);
> }
> }
> $ javac LambdaSleep.java
> $ java LambdaSleep &
> [1] 1416
> $ gcore 1416
> gcore: core.1416 dumped
> $ jmap -dump:format=b,file=core1416.hprof /opt/jdk1.8.0_40/bin/java \
> core.1416
> Attaching to core core.1416 from executable /opt/jdk1.8.0_40/bin/java
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 25.40-b25
> Dumping heap to core1416.hprof ...
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at sun.tools.jmap.JMap.runTool(JMap.java:201)
> at sun.tools.jmap.JMap.main(JMap.java:130)
> Caused by: sun.jvm.hotspot.utilities.AssertionFailure: can not get class
> data for LambdaSleep$$Lambda$10x0000000100071828
> at sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
> at sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeInstance(
> HeapHprofBinWriter.java:803)
> at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter$1.doObj(
> AbstractHeapGraphWriter.java:95)
> at sun.jvm.hotspot.oops.ObjectHeap.iterateLiveRegions(
> ObjectHeap.java:353)
> at sun.jvm.hotspot.oops.ObjectHeap.iterate(ObjectHeap.java:171)
> at sun.jvm.hotspot.utilities.AbstractHeapGraphWriter.write(
> AbstractHeapGraphWriter.java:51)
> at sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(
> HeapHprofBinWriter.java:433)
> at sun.jvm.hotspot.tools.HeapDumper.run(HeapDumper.java:62)
> at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
> at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
> at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
> at sun.jvm.hotspot.tools.HeapDumper.main(HeapDumper.java:83)
> ... 6 more
>
> Note that this problem only occurs when creating an hprof heap dump from
> a core file. It doesn't occur when creating an hprof heap dump from a
> live process:
>
> $ java LambdaSleep &
> [1] 1421
> $ jmap -dump:format=b,file=core1421.hprof 1421
> Dumping heap to core1421.hprof ...
> Heap dump file created
>
> I have reproduced this issue with Java version 1.8.0_40 (JVM version
> 25.40-b25) on the following platforms:
>
> Oracle Solaris 10 9/10 s10x_u9wos_14a X86
> Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
> Oracle Solaris 11.1 X86
> Oracle Solaris 11.2 X86
>
> I found a similar issue in the JDK bug system (JDK-8044416), but the
> last update there stated that JDK-8044416 "is about the -F
> functionality" and to "please file a different bug for problems when
> running without -F." I am running without -F, but I haven't been able to
> find another bug that tracks the issue described above.
>
> An update would be appreciated, as this bug greatly hampers our ability
> to debug memory leaks in production.
>
> Thanks,
> Basil
>
--
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 yasuenag at gmail.com Sun Apr 5 12:49:18 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sun, 05 Apr 2015 21:49:18 +0900
Subject: PING: RFR: JDK-8076212: AllocateHeap() and ReallocateHeap() should
be inlined.
In-Reply-To: <5516316B.6000100@gmail.com>
References: <5506277B.4000902@oracle.com> <5516316B.6000100@gmail.com>
Message-ID: <55212F4E.9080401@gmail.com>
Hi all,
I need more reviewer.
Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/
Thanks,
Yasumasa
On 2015/03/28 13:43, Yasumasa Suenaga wrote:
> Sorry for the delay.
>
> I filed it to JBS and uploaded webrev:
>
> JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined.
> http://cr.openjdk.java.net/~ysuenaga/JDK-8076212/webrev.00/
>
> Could you review it?
>
>
>> Yasumasa you will need to file a CR and you will need a sponsor to push
>> your changeset through JPRT once you have created it. I can do the
>> latter, just email me the final changeset directly.
>
> Thanks, David.
> I'll send it to you after reviewing.
>
>
> Yasumasa
>
>
> On 2015?03?16? 09:44, David Holmes wrote:
>> On 14/03/2015 9:29 AM, Coleen Phillimore wrote:
>>>
>>> There are other inline and noinline directives in allocation.hpp. We
>>> always assume that AllocateHeap and others are inlined. NMT is touchy
>>> with respect to how it walks the stack and it took a bit of work and
>>> testing to get just the most useful frames saved. I don't really want
>>> to risk this breaking!
>>>
>>> I think the gcc directive is acceptable in this case.
>>
>> Okay I'll follow Coleen's guidance on this. The original patch is fine.
>>
>> Yasumasa you will need to file a CR and you will need a sponsor to push
>> your changeset through JPRT once you have created it. I can do the
>> latter, just email me the final changeset directly.
>>
>> Thanks,
>> David
>>
>>> Coleen
>>>
>>>
>>> On 3/13/15, 9:16 AM, Yasumasa Suenaga wrote:
>>>> Hi,
>>>>
>>>>> That would require more significant changes to NMT I think
>>>>
>>>> I think two changes:
>>>>
>>>> 1. Remove AllocateHeap(size_t, MEMFLAGS, AllocFailType) .
>>>> 2. Add "const NativeCallStack&" to argument of ReallocateHeap() .
>>>>
>>>> I think that caller of AllocateHeap() and ReallocateHeap() should
>>>> give
>>>> PC to them.
>>>> However, it is significant changes.
>>>> Thus I proposed to add always_inline .
>>>>
>>>>
>>>>> I don't see how it will help if you have to know a-priori whether
>>>>> inlining has occurred or not. ??
>>>>
>>>> I think we can use SA.
>>>> In case of Linux,
>>>> sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal#lookup()
>>>> can lookup symbol from target process - we can check whether the
>>>> function has been
>>>> inlined (cannot lookup) or not (can lookup).
>>>> So I think that we can write jtreg testcase.
>>>>
>>>> BTW, should I file it to JBS?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2015/03/13 17:35, David Holmes wrote:
>>>>> On 13/03/2015 6:13 PM, Thomas St?fe wrote:
>>>>>> Hi Yasumasa, David,
>>>>>>
>>>>>> Maybe it would make sense to make the
>>>>>> number-of-frames-to-skip-parameter
>>>>>> configurable?
>>>>>
>>>>> That would require more significant changes to NMT I think - plus I
>>>>> don't see how it will help if you have to know a-priori whether
>>>>> inlining has occurred or not. ??
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Because the direct caller of AllocateHeap or os::malloc may also
>>>>>> not be
>>>>>> interesting but still a generic wrapper. So, the user doing the
>>>>>> allocation trace could finetune this parameter to fit his needs.
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 13, 2015 at 6:40 AM, David Holmes >>>>> oracle.com
>>>>>> > wrote:
>>>>>>
>>>>>> Hi Yasumasa,
>>>>>>
>>>>>> On 12/03/2015 9:58 PM, Yasumasa Suenaga wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I tried to use NMT with details option on OpenJDK7 on
>>>>>> RHEL6.6,
>>>>>> but I got
>>>>>> address at AllocateHeap() as malloc() caller.
>>>>>>
>>>>>> I checked symbol in libjvm.so in
>>>>>> OracleJDK8u40 Linux
>>>>>> x64, it has AllocateHeap()
>>>>>> symbol.
>>>>>>
>>>>>> AllocateHeap() is defined as inline function, and it gives
>>>>>> CURRENT_PC to
>>>>>> os::malloc(). I guess that implementation expects
>>>>>> AllocateHeap()
>>>>>> will be
>>>>>> inlined.
>>>>>>
>>>>>>
>>>>>> It seems so.
>>>>>>
>>>>>> It may occur with GCC (g++) optimization only, however I
>>>>>> want to
>>>>>> fix it to
>>>>>> analyze native memory with NMT on Linux.
>>>>>>
>>>>>>
>>>>>> According to the docs [1]:
>>>>>>
>>>>>> "GCC does not inline any functions when not optimizing unless
>>>>>> you
>>>>>> specify the ?always_inline? attribute for the function"
>>>>>>
>>>>>> I applied patch as below. This patch makes AllocateHeap()
>>>>>> as
>>>>>> inline
>>>>>> function.
>>>>>> --------------
>>>>>> diff -r af3b0db91659
>>>>>> src/share/vm/memory/__allocation.inline.hpp
>>>>>> --- a/src/share/vm/memory/__allocation.inline.hpp Mon Mar
>>>>>> 09
>>>>>> 09:30:16 2015
>>>>>> -0700
>>>>>> +++ b/src/share/vm/memory/__allocation.inline.hpp Thu Mar
>>>>>> 12
>>>>>> 20:45:57 2015
>>>>>> +0900
>>>>>> @@ -62,11 +62,18 @@
>>>>>> }
>>>>>> return p;
>>>>>> }
>>>>>> +
>>>>>> +#ifdef __GNUC__
>>>>>> +__attribute__((always_inline)__)
>>>>>> +#endif
>>>>>>
>>>>>>
>>>>>> I dislike seeing the gcc specific directives in common code.
>>>>>> I'm
>>>>>> wondering whether we should perhaps only use CURRENT_PC in
>>>>>> product
>>>>>> (and optimized?) builds and use CALLER_PC otherwise. That would
>>>>>> be
>>>>>> imperfect of course It also makes me wonder whether the
>>>>>> inlining is
>>>>>> occurring as expected on other platforms.
>>>>>>
>>>>>> I'd like to get other people's views on this.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> [1] https://gcc.gnu.org/__onlinedocs/gcc/Inline.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> inline char* AllocateHeap(size_t size, MEMFLAGS flags,
>>>>>> AllocFailType alloc_failmode =
>>>>>> AllocFailStrategy::EXIT_OOM) {
>>>>>> return AllocateHeap(size, flags, CURRENT_PC,
>>>>>> alloc_failmode);
>>>>>> }
>>>>>>
>>>>>> +#ifdef __GNUC__
>>>>>> +__attribute__((always_inline)__)
>>>>>> +#endif
>>>>>> inline char* ReallocateHeap(char *old, size_t size,
>>>>>> MEMFLAGS
>>>>>> flag,
>>>>>> AllocFailType alloc_failmode =
>>>>>> AllocFailStrategy::EXIT_OOM) {
>>>>>> char* p = (char*) os::realloc(old, size, flag,
>>>>>> CURRENT_PC);
>>>>>> --------------
>>>>>>
>>>>>> If this patch is accepted, I will file it to JBS and will
>>>>>> upload
>>>>>> webrev.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
From serguei.spitsyn at oracle.com Mon Apr 6 23:50:07 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 06 Apr 2015 16:50:07 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <551DD8BB.5040001@oracle.com>
References: <551DD8BB.5040001@oracle.com>
Message-ID: <55231BAF.3030601@oracle.com>
Coleen and Dan,
I'm asking you as the jdk 9 reviewers...
Please, let me know if you have any chance and plans to review this.
Would it be enough to have just one (R) reviewer for a non-clean backport?
Thanks,
Serguei
On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the jdk 8u60 backport for:
> https://bugs.openjdk.java.net/browse/JDK-8067662
>
> 8u60 hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>
>
> 8u60 webrev for unit test update (the fix applies cleanly):
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>
>
>
>
> 9 hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>
>
> 9 webrev for unit test update:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>
>
>
> Summary:
> The 9 fix can not be applied cleanly so that I have to rework the
> fix a little bit.
>
> An NPE is trown in a thread dumping via JMX when doing CPU profiling
> in NetBeans Profiler and VisualVM.
> The issue is that the methods and related klass versions are not
> kept alive if a class redefinition
> takes place between catching a Throwable and taking a thread dump.
> It can result in loosing an obsolete method, and so, the
> reconstruction of method name becomes impossible.
> In such a case, the null reference is returned instead of a valid
> method name.
>
> The solution is to use current klass version and method orig_idnum
> instead of ordinary method idnum
> to find required method pointer. In the worst case when the related
> klass version is gone
> (was not included to or was removed from the previous_versions
> linked list), a saved method name
> CP index of the latest klass version can be used to restore the
> method name.
> The footprint extra overhead for this approach is u2 per stack frame.
>
> Testing in progress:
> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>
>
> Thanks,
> Serguei
>
From coleen.phillimore at oracle.com Tue Apr 7 01:49:38 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 06 Apr 2015 21:49:38 -0400
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55231BAF.3030601@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com>
Message-ID: <552337B2.2080306@oracle.com>
This backport looks good. Why didn't the patch apply cleanly? It seems
mostly the same to me.
Thanks,
Coleen
On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
> Coleen and Dan,
>
> I'm asking you as the jdk 9 reviewers...
>
> Please, let me know if you have any chance and plans to review this.
> Would it be enough to have just one (R) reviewer for a non-clean
> backport?
>
> Thanks,
> Serguei
>
>
>
> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the jdk 8u60 backport for:
>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>
>> 8u60 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>
>>
>> 8u60 webrev for unit test update (the fix applies cleanly):
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>
>>
>>
>>
>> 9 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>
>>
>> 9 webrev for unit test update:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>
>>
>>
>> Summary:
>> The 9 fix can not be applied cleanly so that I have to rework the
>> fix a little bit.
>>
>> An NPE is trown in a thread dumping via JMX when doing CPU
>> profiling in NetBeans Profiler and VisualVM.
>> The issue is that the methods and related klass versions are not
>> kept alive if a class redefinition
>> takes place between catching a Throwable and taking a thread dump.
>> It can result in loosing an obsolete method, and so, the
>> reconstruction of method name becomes impossible.
>> In such a case, the null reference is returned instead of a valid
>> method name.
>>
>> The solution is to use current klass version and method orig_idnum
>> instead of ordinary method idnum
>> to find required method pointer. In the worst case when the related
>> klass version is gone
>> (was not included to or was removed from the previous_versions
>> linked list), a saved method name
>> CP index of the latest klass version can be used to restore the
>> method name.
>> The footprint extra overhead for this approach is u2 per stack frame.
>>
>> Testing in progress:
>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>
>>
>> Thanks,
>> Serguei
>>
>
From serguei.spitsyn at oracle.com Tue Apr 7 05:09:13 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 06 Apr 2015 22:09:13 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <552337B2.2080306@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com>
<552337B2.2080306@oracle.com>
Message-ID: <55236679.1040807@oracle.com>
Coleen,
Thank you for looking at this!
The main difference is in instanceKlass.cpp and instanceKlass.hpp.
8u60:
+Method* InstanceKlass::method_with_orig_idnum(int idnum) {
+ if (idnum >= methods()->length()) {
+ return NULL;
+ }
+ Method* m = methods()->at(idnum);
+ if (m != NULL && m->orig_method_idnum() == idnum) {
+ return m;
+ }
+ // Obsolete method idnum does not match the original idnum
+ for (int index = 0; index < methods()->length(); ++index) {
+ m = methods()->at(index);
+ if (m->orig_method_idnum() == idnum) {
+ return m;
+ }
+ }
+ // None found, return null for the caller to handle.
+ return NULL;
+}
+
+
+Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
+ if (constants()->version() == version) {
+ return method_with_orig_idnum(idnum);
+ }
+ ConstantPoolCache* cp_cache = NULL;
+ PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
+ for (PreviousVersionNode * pv_node = pvw.next_previous_version();
+ pv_node != NULL; pv_node = pvw.next_previous_version()) {
+ ConstantPool* prev_cp = pv_node->prev_constant_pool();
+ if (prev_cp->version() == version) {
+ cp_cache = prev_cp->cache();
+ break;
+ }
+ }
+ if (cp_cache == NULL) {
+ return NULL; // The pv_node is gone, no method is found
+ }
+ Method* method = NULL;
+ for (int i = 0; i < cp_cache->length(); i++) {
+ ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
+ method = entry->get_interesting_method_entry(this);
+ if (method == NULL) {
+ continue; // skip uninteresting entries
+ }
+ if (method->orig_method_idnum() == idnum) {
+ return method;
+ }
+ }
+ // None found, return null for the caller to handle.
+ return NULL;
+}
jdk 9:
+Method* InstanceKlass::method_with_orig_idnum(int idnum) {
+ if (idnum >= methods()->length()) {
+ return NULL;
+ }
+ Method* m = methods()->at(idnum);
+ if (m != NULL && m->orig_method_idnum() == idnum) {
+ return m;
+ }
+ // Obsolete method idnum does not match the original idnum
+ for (int index = 0; index < methods()->length(); ++index) {
+ m = methods()->at(index);
+ if (m->orig_method_idnum() == idnum) {
+ return m;
+ }
+ }
+ // None found, return null for the caller to handle.
+ return NULL;
+}
+
+
+Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
+ InstanceKlass* holder = get_klass_version(version);
+ if (holder == NULL) {
+ return NULL; // The version of klass is gone, no method is found
+ }
+ Method* method = holder->method_with_orig_idnum(idnum);
+ return method;
+}
Thanks,
Serguei
On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>
> This backport looks good. Why didn't the patch apply cleanly? It
> seems mostly the same to me.
> Thanks,
> Coleen
>
> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>> Coleen and Dan,
>>
>> I'm asking you as the jdk 9 reviewers...
>>
>> Please, let me know if you have any chance and plans to review this.
>> Would it be enough to have just one (R) reviewer for a non-clean
>> backport?
>>
>> Thanks,
>> Serguei
>>
>>
>>
>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the jdk 8u60 backport for:
>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>
>>> 8u60 hotspot webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>
>>>
>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>
>>>
>>>
>>>
>>> 9 hotspot webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>
>>>
>>> 9 webrev for unit test update:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>
>>>
>>>
>>> Summary:
>>> The 9 fix can not be applied cleanly so that I have to rework the
>>> fix a little bit.
>>>
>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>> profiling in NetBeans Profiler and VisualVM.
>>> The issue is that the methods and related klass versions are not
>>> kept alive if a class redefinition
>>> takes place between catching a Throwable and taking a thread dump.
>>> It can result in loosing an obsolete method, and so, the
>>> reconstruction of method name becomes impossible.
>>> In such a case, the null reference is returned instead of a valid
>>> method name.
>>>
>>> The solution is to use current klass version and method orig_idnum
>>> instead of ordinary method idnum
>>> to find required method pointer. In the worst case when the
>>> related klass version is gone
>>> (was not included to or was removed from the previous_versions
>>> linked list), a saved method name
>>> CP index of the latest klass version can be used to restore the
>>> method name.
>>> The footprint extra overhead for this approach is u2 per stack frame.
>>>
>>> Testing in progress:
>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From yekaterina.kantserova at oracle.com Tue Apr 7 12:52:59 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Tue, 07 Apr 2015 14:52:59 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <551D39B4.70506@oracle.com>
References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com>
Message-ID: <5523D32B.1080406@oracle.com>
Hi,
The updated webrev can be found here:
http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/
Thanks,
Katja
On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote:
> Hi Katja,
>
> On 2.4.2015 14:16, Yekaterina Kantserova wrote:
>> Hi,
>>
>> Could I please have a review of this fix.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
>
> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would
> suggest adding System.out.flush() after printing "jstatd is started on
> ..." to make sure the output is actually committed to stdout.
>
> Please, update the copyright years.
>
> -JB-
>
>>
>> The tests can still contain a race. There is a possibility the jstad is
>> not really started though there is a pid for the process. The suggestion
>> is to let jstatd notify it's started and for the test wait until this
>> notification.
>>
>> Thanks,
>> Katja
>
From staffan.larsen at oracle.com Tue Apr 7 13:03:09 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 7 Apr 2015 15:03:09 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <5523D32B.1080406@oracle.com>
References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com>
<5523D32B.1080406@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 7 apr 2015, at 14:52, Yekaterina Kantserova wrote:
>
> Hi,
>
> The updated webrev can be found here: http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/
>
> Thanks,
> Katja
>
>
>
> On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote:
>> Hi Katja,
>>
>> On 2.4.2015 14:16, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> Could I please have a review of this fix.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
>>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
>>
>> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would suggest adding System.out.flush() after printing "jstatd is started on ..." to make sure the output is actually committed to stdout.
>>
>> Please, update the copyright years.
>>
>> -JB-
>>
>>>
>>> The tests can still contain a race. There is a possibility the jstad is
>>> not really started though there is a pid for the process. The suggestion
>>> is to let jstatd notify it's started and for the test wait until this
>>> notification.
>>>
>>> Thanks,
>>> Katja
>>
>
From jaroslav.bachorik at oracle.com Tue Apr 7 13:55:56 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 07 Apr 2015 15:55:56 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <5523D32B.1080406@oracle.com>
References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com>
<5523D32B.1080406@oracle.com>
Message-ID: <5523E1EC.6080608@oracle.com>
Looks fine!
You might want to convert the 'jstatd started (bound to' string to a
constant to make it easier to track any changes in the future but it is
up to you. I am fine with the changes anyway.
-JB-
On 7.4.2015 14:52, Yekaterina Kantserova wrote:
> Hi,
>
> The updated webrev can be found here:
> http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/
>
> Thanks,
> Katja
>
>
>
> On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote:
>> Hi Katja,
>>
>> On 2.4.2015 14:16, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> Could I please have a review of this fix.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
>>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
>>
>> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would
>> suggest adding System.out.flush() after printing "jstatd is started on
>> ..." to make sure the output is actually committed to stdout.
>>
>> Please, update the copyright years.
>>
>> -JB-
>>
>>>
>>> The tests can still contain a race. There is a possibility the jstad is
>>> not really started though there is a pid for the process. The suggestion
>>> is to let jstatd notify it's started and for the test wait until this
>>> notification.
>>>
>>> Thanks,
>>> Katja
>>
>
From yekaterina.kantserova at oracle.com Tue Apr 7 14:28:13 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Tue, 07 Apr 2015 16:28:13 +0200
Subject: RFR(XS): 8027668: sun/tools/jstatd/TestJstatdPort.java:
java.net.ConnectException: Connection refused: connect
In-Reply-To: <5523E1EC.6080608@oracle.com>
References: <551D332B.3060002@oracle.com> <551D39B4.70506@oracle.com>
<5523D32B.1080406@oracle.com> <5523E1EC.6080608@oracle.com>
Message-ID: <5523E97D.8030409@oracle.com>
Jaroslav, Staffan,
Thanks for the reviews!
// Katja
On 04/07/2015 03:55 PM, Jaroslav Bachorik wrote:
> Looks fine!
>
> You might want to convert the 'jstatd started (bound to' string to a
> constant to make it easier to track any changes in the future but it
> is up to you. I am fine with the changes anyway.
>
> -JB-
>
>
> On 7.4.2015 14:52, Yekaterina Kantserova wrote:
>> Hi,
>>
>> The updated webrev can be found here:
>> http://cr.openjdk.java.net/~ykantser/8027668/webrev.01/
>>
>> Thanks,
>> Katja
>>
>>
>>
>> On 04/02/2015 02:44 PM, Jaroslav Bachorik wrote:
>>> Hi Katja,
>>>
>>> On 2.4.2015 14:16, Yekaterina Kantserova wrote:
>>>> Hi,
>>>>
>>>> Could I please have a review of this fix.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8027668
>>>> webrev: http://cr.openjdk.java.net/~ykantser/8027668/webrev.00/
>>>
>>> In src/jdk.jvmstat/share/classes/sun/tools/jstatd/Jstatd.java I would
>>> suggest adding System.out.flush() after printing "jstatd is started on
>>> ..." to make sure the output is actually committed to stdout.
>>>
>>> Please, update the copyright years.
>>>
>>> -JB-
>>>
>>>>
>>>> The tests can still contain a race. There is a possibility the
>>>> jstad is
>>>> not really started though there is a pid for the process. The
>>>> suggestion
>>>> is to let jstatd notify it's started and for the test wait until this
>>>> notification.
>>>>
>>>> Thanks,
>>>> Katja
>>>
>>
>
From erik.joelsson at oracle.com Tue Apr 7 15:15:56 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 07 Apr 2015 17:15:56 +0200
Subject: RFR
Message-ID: <5523F4AC.9050007@oracle.com>
Hello,
When upgrading the toolchain to VS2013, management.dll stopped working
on certain Windows hosts. I've identified this to be related to the call
to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the
problem goes away.
Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
Patch inline:
diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
--- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100
+++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200
@@ -38,6 +38,11 @@
$(LIBJAVA_HEADER_FLAGS) \
#
+# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
+# a binary that is compatible with windows versions older than 7/2008R2.
+# See MSDN documentation for GetProcessMemoryInfo for more information.
+BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
+
BUILD_LIBMANAGEMENT_EXCLUDES :=
ifneq ($(OPENJDK_TARGET_OS), solaris)
/Erik
From erik.joelsson at oracle.com Tue Apr 7 15:21:02 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 07 Apr 2015 17:21:02 +0200
Subject: RFR: JDK-8076557: The specified procedure could not be found in
management.dll
In-Reply-To: <5523F4AC.9050007@oracle.com>
References: <5523F4AC.9050007@oracle.com>
Message-ID: <5523F5DE.9030601@oracle.com>
(corrected subject)
On 2015-04-07 17:15, Erik Joelsson wrote:
> Hello,
>
> When upgrading the toolchain to VS2013, management.dll stopped working
> on certain Windows hosts. I've identified this to be related to the
> call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS,
> the problem goes away.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
> Patch inline:
>
> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
> --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100
> +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200
> @@ -38,6 +38,11 @@
> $(LIBJAVA_HEADER_FLAGS) \
> #
>
> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to
> generate
> +# a binary that is compatible with windows versions older than 7/2008R2.
> +# See MSDN documentation for GetProcessMemoryInfo for more information.
> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
> +
> BUILD_LIBMANAGEMENT_EXCLUDES :=
>
> ifneq ($(OPENJDK_TARGET_OS), solaris)
>
>
> /Erik
From jaroslav.bachorik at oracle.com Tue Apr 7 16:06:02 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 07 Apr 2015 18:06:02 +0200
Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when
called with empty array for thread ids
In-Reply-To: <551F07B8.2010006@oracle.com>
References: <551EA427.3030409@oracle.com> <551F07B8.2010006@oracle.com>
Message-ID: <5524006A.4070109@oracle.com>
Hi Mandy,
On 3.4.2015 23:35, Mandy Chung wrote:
> On 4/3/15 7:31 AM, Jaroslav Bachorik wrote:
>> Please, review the following change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8074368
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00
>>
> Looks okay to me.
>
> Minor comment on ThreadInfoArray.java test:
> You can have one single @bug line with multiple bug numbers
> line 57, 90: can you rename "direct" to mbean?
> line 59, 92: formatting - indent to the right
Only the test parts updated -
http://cr.openjdk.java.net/~jbachorik/8074368/webrev.01/
-JB-
>
> Mandy
>
>
From daniel.daugherty at oracle.com Tue Apr 7 16:44:37 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 07 Apr 2015 10:44:37 -0600
Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs
must match
In-Reply-To: <55135DE5.2010705@oracle.com>
References: <55135DE5.2010705@oracle.com>
Message-ID: <55240975.4080009@oracle.com>
On 3/25/15 7:16 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> https://bugs.openjdk.java.net/browse/JDK-8066679
>
>
> Open hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/
>
src/share/vm/prims/jvmtiRedefineClasses.cpp
I concur that the old assertions are bad. They assume that
the cached class file bytes on the scratch_class must match
the cached class file bytes on the target class. That's a
valid assumption in a RedefineClasses() only world, but that's
not true when RetransformClasses() is used.
This will be hard to test. I think the race can only happen
on the first retransform of a class. If you have two parallel
retransform threads, both see that there are no cached bytes
so both cache the initial bytes and then both have to update
the cached bytes pointer at about the same time... Very hard
to do...
Thumbs up.
Dan
>
>
> Summary:
>
> There can be multiple concurrent RetransformClasses calls on
> different threads.
> So that, the assert "cache ptrs must match" is incorrect as it was
> based on wrong assumptions.
> The fix removes two related asserts and also frees the scratch_class
> cached_class_file_bytes
> if it is necessary to avoid leaking the memory.
>
>
> Testing:
> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>
>
> Thanks,
> Serguei
>
From daniel.daugherty at oracle.com Tue Apr 7 16:54:34 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 07 Apr 2015 10:54:34 -0600
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <551DD8BB.5040001@oracle.com>
References: <551DD8BB.5040001@oracle.com>
Message-ID: <55240BC9.8070500@oracle.com>
On 4/2/15 6:03 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the jdk 8u60 backport for:
> https://bugs.openjdk.java.net/browse/JDK-8067662
>
> 8u60 hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>
Nit - please update copyright years as needed before you push.
src/share/vm/classfile/javaClasses.hpp
No comments.
src/share/vm/classfile/javaClasses.cpp
No comments.
src/share/vm/oops/instanceKlass.hpp
No comments.
src/share/vm/oops/instanceKlass.cpp
No comments.
Thumbs up.
Dan
>
> 8u60 webrev for unit test update (the fix applies cleanly):
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>
>
>
>
> 9 hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>
>
> 9 webrev for unit test update:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>
>
>
> Summary:
> The 9 fix can not be applied cleanly so that I have to rework the
> fix a little bit.
>
> An NPE is trown in a thread dumping via JMX when doing CPU profiling
> in NetBeans Profiler and VisualVM.
> The issue is that the methods and related klass versions are not
> kept alive if a class redefinition
> takes place between catching a Throwable and taking a thread dump.
> It can result in loosing an obsolete method, and so, the
> reconstruction of method name becomes impossible.
> In such a case, the null reference is returned instead of a valid
> method name.
>
> The solution is to use current klass version and method orig_idnum
> instead of ordinary method idnum
> to find required method pointer. In the worst case when the related
> klass version is gone
> (was not included to or was removed from the previous_versions
> linked list), a saved method name
> CP index of the latest klass version can be used to restore the
> method name.
> The footprint extra overhead for this approach is u2 per stack frame.
>
> Testing in progress:
> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>
>
> Thanks,
> Serguei
>
>
>
From daniel.daugherty at oracle.com Tue Apr 7 16:59:54 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 07 Apr 2015 10:59:54 -0600
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55231BAF.3030601@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com>
Message-ID: <55240D0A.7000801@oracle.com>
I _think_ you're OK with a single (R)eviewer for a backport even
when minor changes are required, but I can never remember all these
rules for sure...
Dan
On 4/6/15 5:50 PM, serguei.spitsyn at oracle.com wrote:
> Coleen and Dan,
>
> I'm asking you as the jdk 9 reviewers...
>
> Please, let me know if you have any chance and plans to review this.
> Would it be enough to have just one (R) reviewer for a non-clean
> backport?
>
> Thanks,
> Serguei
>
>
>
> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the jdk 8u60 backport for:
>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>
>> 8u60 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>
>>
>> 8u60 webrev for unit test update (the fix applies cleanly):
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>
>>
>>
>>
>> 9 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>
>>
>> 9 webrev for unit test update:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>
>>
>>
>> Summary:
>> The 9 fix can not be applied cleanly so that I have to rework the
>> fix a little bit.
>>
>> An NPE is trown in a thread dumping via JMX when doing CPU
>> profiling in NetBeans Profiler and VisualVM.
>> The issue is that the methods and related klass versions are not
>> kept alive if a class redefinition
>> takes place between catching a Throwable and taking a thread dump.
>> It can result in loosing an obsolete method, and so, the
>> reconstruction of method name becomes impossible.
>> In such a case, the null reference is returned instead of a valid
>> method name.
>>
>> The solution is to use current klass version and method orig_idnum
>> instead of ordinary method idnum
>> to find required method pointer. In the worst case when the related
>> klass version is gone
>> (was not included to or was removed from the previous_versions
>> linked list), a saved method name
>> CP index of the latest klass version can be used to restore the
>> method name.
>> The footprint extra overhead for this approach is u2 per stack frame.
>>
>> Testing in progress:
>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>
>>
>> Thanks,
>> Serguei
>>
>
>
From tim.bell at oracle.com Tue Apr 7 17:08:37 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 07 Apr 2015 10:08:37 -0700
Subject: RFR: JDK-8076557: The specified procedure could not be found
in management.dll
In-Reply-To: <5523F5DE.9030601@oracle.com>
References: <5523F4AC.9050007@oracle.com> <5523F5DE.9030601@oracle.com>
Message-ID: <55240F15.7060406@oracle.com>
Erik-
Looks good to me.
Tim
On 04/07/15 08:21, Erik Joelsson wrote:
> (corrected subject)
>
> On 2015-04-07 17:15, Erik Joelsson wrote:
>> Hello,
>>
>> When upgrading the toolchain to VS2013, management.dll stopped
>> working on certain Windows hosts. I've identified this to be related
>> to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to
>> CFLAGS, the problem goes away.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
>> Patch inline:
>>
>> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
>> --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100
>> +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200
>> @@ -38,6 +38,11 @@
>> $(LIBJAVA_HEADER_FLAGS) \
>> #
>>
>> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to
>> generate
>> +# a binary that is compatible with windows versions older than
>> 7/2008R2.
>> +# See MSDN documentation for GetProcessMemoryInfo for more information.
>> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
>> +
>> BUILD_LIBMANAGEMENT_EXCLUDES :=
>>
>> ifneq ($(OPENJDK_TARGET_OS), solaris)
>>
>>
>> /Erik
>
From coleen.phillimore at oracle.com Tue Apr 7 18:20:39 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 07 Apr 2015 14:20:39 -0400
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55236679.1040807@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com>
<552337B2.2080306@oracle.com> <55236679.1040807@oracle.com>
Message-ID: <55241FF7.3060801@oracle.com>
I see. The PreviousVersionWalker is gone in 9 and you're using it to
find the method.
But this is only going to find the method if it happens to be in the
cpCache somewhere. I think
pv_node->prev_constant_pool()->pool_holder() is scratch_class (not 100%
sure). In which case, you can look at that class to find the method
with idnum.
Coleen
On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
> Coleen,
>
> Thank you for looking at this!
>
> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>
> 8u60:
> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
> + if (idnum >= methods()->length()) {
> + return NULL;
> + }
> + Method* m = methods()->at(idnum);
> + if (m != NULL && m->orig_method_idnum() == idnum) {
> + return m;
> + }
> + // Obsolete method idnum does not match the original idnum
> + for (int index = 0; index < methods()->length(); ++index) {
> + m = methods()->at(index);
> + if (m->orig_method_idnum() == idnum) {
> + return m;
> + }
> + }
> + // None found, return null for the caller to handle.
> + return NULL;
> +}
> +
> +
> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
> + if (constants()->version() == version) {
> + return method_with_orig_idnum(idnum);
> + }
> + ConstantPoolCache* cp_cache = NULL;
> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
> + if (prev_cp->version() == version) {
> + cp_cache = prev_cp->cache();
> + break;
> + }
> + }
> + if (cp_cache == NULL) {
> + return NULL; // The pv_node is gone, no method is found
> + }
> + Method* method = NULL;
> + for (int i = 0; i < cp_cache->length(); i++) {
> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
> + method = entry->get_interesting_method_entry(this);
> + if (method == NULL) {
> + continue; // skip uninteresting entries
> + }
> + if (method->orig_method_idnum() == idnum) {
> + return method;
> + }
> + }
> + // None found, return null for the caller to handle.
> + return NULL;
> +}
>
>
> jdk 9:
>
> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
> + if (idnum >= methods()->length()) {
> + return NULL;
> + }
> + Method* m = methods()->at(idnum);
> + if (m != NULL && m->orig_method_idnum() == idnum) {
> + return m;
> + }
> + // Obsolete method idnum does not match the original idnum
> + for (int index = 0; index < methods()->length(); ++index) {
> + m = methods()->at(index);
> + if (m->orig_method_idnum() == idnum) {
> + return m;
> + }
> + }
> + // None found, return null for the caller to handle.
> + return NULL;
> +}
> +
> +
> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
> + InstanceKlass* holder = get_klass_version(version);
> + if (holder == NULL) {
> + return NULL; // The version of klass is gone, no method is found
> + }
> + Method* method = holder->method_with_orig_idnum(idnum);
> + return method;
> +}
>
>
> Thanks,
> Serguei
>
>
> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>
>> This backport looks good. Why didn't the patch apply cleanly? It
>> seems mostly the same to me.
>> Thanks,
>> Coleen
>>
>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>> Coleen and Dan,
>>>
>>> I'm asking you as the jdk 9 reviewers...
>>>
>>> Please, let me know if you have any chance and plans to review this.
>>> Would it be enough to have just one (R) reviewer for a non-clean
>>> backport?
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>>
>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the jdk 8u60 backport for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>
>>>> 8u60 hotspot webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>
>>>>
>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>
>>>>
>>>>
>>>>
>>>> 9 hotspot webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>
>>>>
>>>> 9 webrev for unit test update:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>
>>>>
>>>>
>>>> Summary:
>>>> The 9 fix can not be applied cleanly so that I have to rework the
>>>> fix a little bit.
>>>>
>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>> profiling in NetBeans Profiler and VisualVM.
>>>> The issue is that the methods and related klass versions are not
>>>> kept alive if a class redefinition
>>>> takes place between catching a Throwable and taking a thread dump.
>>>> It can result in loosing an obsolete method, and so, the
>>>> reconstruction of method name becomes impossible.
>>>> In such a case, the null reference is returned instead of a valid
>>>> method name.
>>>>
>>>> The solution is to use current klass version and method
>>>> orig_idnum instead of ordinary method idnum
>>>> to find required method pointer. In the worst case when the
>>>> related klass version is gone
>>>> (was not included to or was removed from the previous_versions
>>>> linked list), a saved method name
>>>> CP index of the latest klass version can be used to restore the
>>>> method name.
>>>> The footprint extra overhead for this approach is u2 per stack
>>>> frame.
>>>>
>>>> Testing in progress:
>>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Tue Apr 7 18:49:06 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 7 Apr 2015 20:49:06 +0200
Subject: RFR
In-Reply-To: <5523F4AC.9050007@oracle.com>
References: <5523F4AC.9050007@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 7 apr 2015, at 17:15, Erik Joelsson wrote:
>
> Hello,
>
> When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
> Patch inline:
>
> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
> --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100
> +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200
> @@ -38,6 +38,11 @@
> $(LIBJAVA_HEADER_FLAGS) \
> #
>
> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
> +# a binary that is compatible with windows versions older than 7/2008R2.
> +# See MSDN documentation for GetProcessMemoryInfo for more information.
> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
> +
> BUILD_LIBMANAGEMENT_EXCLUDES :=
>
> ifneq ($(OPENJDK_TARGET_OS), solaris)
>
>
> /Erik
From mandy.chung at oracle.com Tue Apr 7 19:00:44 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 07 Apr 2015 12:00:44 -0700
Subject: RFR 8074368: ThreadMXBean.getThreadInfo() corrupts memory when
called with empty array for thread ids
In-Reply-To: <5524006A.4070109@oracle.com>
References: <551EA427.3030409@oracle.com> <551F07B8.2010006@oracle.com>
<5524006A.4070109@oracle.com>
Message-ID: <5524295C.10606@oracle.com>
On 4/7/15 9:06 AM, Jaroslav Bachorik wrote:
> Hi Mandy,
>
> On 3.4.2015 23:35, Mandy Chung wrote:
>> On 4/3/15 7:31 AM, Jaroslav Bachorik wrote:
>>> Please, review the following change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8074368
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8074368/webrev.00
>>>
>> Looks okay to me.
>>
>> Minor comment on ThreadInfoArray.java test:
>> You can have one single @bug line with multiple bug numbers
>> line 57, 90: can you rename "direct" to mbean?
>> line 59, 92: formatting - indent to the right
>
> Only the test parts updated -
> http://cr.openjdk.java.net/~jbachorik/8074368/webrev.01/
>
Looks good.
thanks
Mandy
From serguei.spitsyn at oracle.com Tue Apr 7 20:14:18 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 07 Apr 2015 13:14:18 -0700
Subject: RFR (XS) 8066679: jvmtiRedefineClasses.cpp assert cache ptrs
must match
In-Reply-To: <55240975.4080009@oracle.com>
References: <55135DE5.2010705@oracle.com> <55240975.4080009@oracle.com>
Message-ID: <55243A9A.6060603@oracle.com>
Great
Thanks, Dan!
Serguei
On 4/7/15 9:44 AM, Daniel D. Daugherty wrote:
> On 3/25/15 7:16 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8066679
>>
>>
>> Open hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8066679-JVMTI-cache.1/
>>
>
> src/share/vm/prims/jvmtiRedefineClasses.cpp
> I concur that the old assertions are bad. They assume that
> the cached class file bytes on the scratch_class must match
> the cached class file bytes on the target class. That's a
> valid assumption in a RedefineClasses() only world, but that's
> not true when RetransformClasses() is used.
>
> This will be hard to test. I think the race can only happen
> on the first retransform of a class. If you have two parallel
> retransform threads, both see that there are no cached bytes
> so both cache the initial bytes and then both have to update
> the cached bytes pointer at about the same time... Very hard
> to do...
>
> Thumbs up.
>
> Dan
>
>
>>
>>
>> Summary:
>>
>> There can be multiple concurrent RetransformClasses calls on
>> different threads.
>> So that, the assert "cache ptrs must match" is incorrect as it was
>> based on wrong assumptions.
>> The fix removes two related asserts and also frees the
>> scratch_class cached_class_file_bytes
>> if it is necessary to avoid leaking the memory.
>>
>>
>> Testing:
>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>
>>
>> Thanks,
>> Serguei
>>
>
From serguei.spitsyn at oracle.com Tue Apr 7 20:15:37 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 07 Apr 2015 13:15:37 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55240BC9.8070500@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55240BC9.8070500@oracle.com>
Message-ID: <55243AE9.9090502@oracle.com>
Dan, thank you for the review!
On 4/7/15 9:54 AM, Daniel D. Daugherty wrote:
> On 4/2/15 6:03 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the jdk 8u60 backport for:
>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>
>> 8u60 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>
>
> Nit - please update copyright years as needed before you push.
Sure, that's the plan.
Thanks,
Serguei
>
> src/share/vm/classfile/javaClasses.hpp
> No comments.
>
> src/share/vm/classfile/javaClasses.cpp
> No comments.
>
> src/share/vm/oops/instanceKlass.hpp
> No comments.
>
> src/share/vm/oops/instanceKlass.cpp
> No comments.
>
>
> Thumbs up.
>
> Dan
>
>
>
>
>>
>> 8u60 webrev for unit test update (the fix applies cleanly):
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>
>>
>>
>>
>> 9 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>
>>
>> 9 webrev for unit test update:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>
>>
>>
>> Summary:
>> The 9 fix can not be applied cleanly so that I have to rework the
>> fix a little bit.
>>
>> An NPE is trown in a thread dumping via JMX when doing CPU
>> profiling in NetBeans Profiler and VisualVM.
>> The issue is that the methods and related klass versions are not
>> kept alive if a class redefinition
>> takes place between catching a Throwable and taking a thread dump.
>> It can result in loosing an obsolete method, and so, the
>> reconstruction of method name becomes impossible.
>> In such a case, the null reference is returned instead of a valid
>> method name.
>>
>> The solution is to use current klass version and method orig_idnum
>> instead of ordinary method idnum
>> to find required method pointer. In the worst case when the related
>> klass version is gone
>> (was not included to or was removed from the previous_versions
>> linked list), a saved method name
>> CP index of the latest klass version can be used to restore the
>> method name.
>> The footprint extra overhead for this approach is u2 per stack frame.
>>
>> Testing in progress:
>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>
>>
>> Thanks,
>> Serguei
>>
>>
>>
>
From serguei.spitsyn at oracle.com Tue Apr 7 20:17:28 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 07 Apr 2015 13:17:28 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55240D0A.7000801@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com>
<55240D0A.7000801@oracle.com>
Message-ID: <55243B58.8040709@oracle.com>
Ok, thanks!
Serguei
On 4/7/15 9:59 AM, Daniel D. Daugherty wrote:
> I _think_ you're OK with a single (R)eviewer for a backport even
> when minor changes are required, but I can never remember all these
> rules for sure...
>
> Dan
>
>
> On 4/6/15 5:50 PM, serguei.spitsyn at oracle.com wrote:
>> Coleen and Dan,
>>
>> I'm asking you as the jdk 9 reviewers...
>>
>> Please, let me know if you have any chance and plans to review this.
>> Would it be enough to have just one (R) reviewer for a non-clean
>> backport?
>>
>> Thanks,
>> Serguei
>>
>>
>>
>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the jdk 8u60 backport for:
>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>
>>> 8u60 hotspot webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>
>>>
>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>
>>>
>>>
>>>
>>> 9 hotspot webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>
>>>
>>> 9 webrev for unit test update:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>
>>>
>>>
>>> Summary:
>>> The 9 fix can not be applied cleanly so that I have to rework the
>>> fix a little bit.
>>>
>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>> profiling in NetBeans Profiler and VisualVM.
>>> The issue is that the methods and related klass versions are not
>>> kept alive if a class redefinition
>>> takes place between catching a Throwable and taking a thread dump.
>>> It can result in loosing an obsolete method, and so, the
>>> reconstruction of method name becomes impossible.
>>> In such a case, the null reference is returned instead of a valid
>>> method name.
>>>
>>> The solution is to use current klass version and method orig_idnum
>>> instead of ordinary method idnum
>>> to find required method pointer. In the worst case when the
>>> related klass version is gone
>>> (was not included to or was removed from the previous_versions
>>> linked list), a saved method name
>>> CP index of the latest klass version can be used to restore the
>>> method name.
>>> The footprint extra overhead for this approach is u2 per stack frame.
>>>
>>> Testing in progress:
>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>
>>
>
From serguei.spitsyn at oracle.com Tue Apr 7 21:01:35 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 07 Apr 2015 14:01:35 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55241FF7.3060801@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com>
<552337B2.2080306@oracle.com> <55236679.1040807@oracle.com>
<55241FF7.3060801@oracle.com>
Message-ID: <552445AF.50209@oracle.com>
On 4/7/15 11:20 AM, Coleen Phillimore wrote:
>
> ?I see. The PreviousVersionWalker is gone in 9 and you're using it to
> find the method.
>
> But this is only going to find the method if it happens to be in the
> cpCache somewhere. I think
> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not
> 100% sure). In which case, you can look at that class to find the
> method with idnum.
I'm not 100% sure either.
Ok, I will check if using the prev_constant_pool()->pool_holder() is
going to work.
It'd make it more consistent with the jdk 9 fix.
Important part is that at least the saved cpref can be used to find
method name in the
the_class cpool if the attempt to find in the previous list cpCaches was
unsuccessful.
Thanks,
Serguei
>
> Coleen
>
> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
>> Coleen,
>>
>> Thank you for looking at this!
>>
>> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>>
>> 8u60:
>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>> + if (idnum >= methods()->length()) {
>> + return NULL;
>> + }
>> + Method* m = methods()->at(idnum);
>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>> + return m;
>> + }
>> + // Obsolete method idnum does not match the original idnum
>> + for (int index = 0; index < methods()->length(); ++index) {
>> + m = methods()->at(index);
>> + if (m->orig_method_idnum() == idnum) {
>> + return m;
>> + }
>> + }
>> + // None found, return null for the caller to handle.
>> + return NULL;
>> +}
>> +
>> +
>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>> + if (constants()->version() == version) {
>> + return method_with_orig_idnum(idnum);
>> + }
>> + ConstantPoolCache* cp_cache = NULL;
>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
>> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
>> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
>> + if (prev_cp->version() == version) {
>> + cp_cache = prev_cp->cache();
>> + break;
>> + }
>> + }
>> + if (cp_cache == NULL) {
>> + return NULL; // The pv_node is gone, no method is found
>> + }
>> + Method* method = NULL;
>> + for (int i = 0; i < cp_cache->length(); i++) {
>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
>> + method = entry->get_interesting_method_entry(this);
>> + if (method == NULL) {
>> + continue; // skip uninteresting entries
>> + }
>> + if (method->orig_method_idnum() == idnum) {
>> + return method;
>> + }
>> + }
>> + // None found, return null for the caller to handle.
>> + return NULL;
>> +}
>>
>>
>> jdk 9:
>>
>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>> + if (idnum >= methods()->length()) {
>> + return NULL;
>> + }
>> + Method* m = methods()->at(idnum);
>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>> + return m;
>> + }
>> + // Obsolete method idnum does not match the original idnum
>> + for (int index = 0; index < methods()->length(); ++index) {
>> + m = methods()->at(index);
>> + if (m->orig_method_idnum() == idnum) {
>> + return m;
>> + }
>> + }
>> + // None found, return null for the caller to handle.
>> + return NULL;
>> +}
>> +
>> +
>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>> + InstanceKlass* holder = get_klass_version(version);
>> + if (holder == NULL) {
>> + return NULL; // The version of klass is gone, no method is found
>> + }
>> + Method* method = holder->method_with_orig_idnum(idnum);
>> + return method;
>> +}
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>>
>>> This backport looks good. Why didn't the patch apply cleanly? It
>>> seems mostly the same to me.
>>> Thanks,
>>> Coleen
>>>
>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>>> Coleen and Dan,
>>>>
>>>> I'm asking you as the jdk 9 reviewers...
>>>>
>>>> Please, let me know if you have any chance and plans to review this.
>>>> Would it be enough to have just one (R) reviewer for a non-clean
>>>> backport?
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>
>>>>
>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the jdk 8u60 backport for:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>>
>>>>> 8u60 hotspot webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>>
>>>>>
>>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 9 hotspot webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>>
>>>>>
>>>>> 9 webrev for unit test update:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>> The 9 fix can not be applied cleanly so that I have to rework
>>>>> the fix a little bit.
>>>>>
>>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>>> profiling in NetBeans Profiler and VisualVM.
>>>>> The issue is that the methods and related klass versions are not
>>>>> kept alive if a class redefinition
>>>>> takes place between catching a Throwable and taking a thread dump.
>>>>> It can result in loosing an obsolete method, and so, the
>>>>> reconstruction of method name becomes impossible.
>>>>> In such a case, the null reference is returned instead of a
>>>>> valid method name.
>>>>>
>>>>> The solution is to use current klass version and method
>>>>> orig_idnum instead of ordinary method idnum
>>>>> to find required method pointer. In the worst case when the
>>>>> related klass version is gone
>>>>> (was not included to or was removed from the previous_versions
>>>>> linked list), a saved method name
>>>>> CP index of the latest klass version can be used to restore the
>>>>> method name.
>>>>> The footprint extra overhead for this approach is u2 per stack
>>>>> frame.
>>>>>
>>>>> Testing in progress:
>>>>> In progress: nsk redefine classes tests, JTREG java/lang/instrument
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From serguei.spitsyn at oracle.com Wed Apr 8 01:07:57 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 07 Apr 2015 18:07:57 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <552445AF.50209@oracle.com>
References: <551DD8BB.5040001@oracle.com> <55231BAF.3030601@oracle.com>
<552337B2.2080306@oracle.com> <55236679.1040807@oracle.com>
<55241FF7.3060801@oracle.com> <552445AF.50209@oracle.com>
Message-ID: <55247F6D.5090003@oracle.com>
On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote:
> On 4/7/15 11:20 AM, Coleen Phillimore wrote:
>>
>> ?I see. The PreviousVersionWalker is gone in 9 and you're using it
>> to find the method.
>>
>> But this is only going to find the method if it happens to be in the
>> cpCache somewhere. I think
>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not
>> 100% sure). In which case, you can look at that class to find the
>> method with idnum.
> I'm not 100% sure either.
> Ok, I will check if using the prev_constant_pool()->pool_holder() is
> going to work.
> It'd make it more consistent with the jdk 9 fix.
This is the updated webrev.
It is more consistent with the jdk 9 fix.
Thank you for the suggestion!
Thanks,
Serguei
>
> Important part is that at least the saved cpref can be used to find
> method name in the
> the_class cpool if the attempt to find in the previous list cpCaches
> was unsuccessful.
>
> Thanks,
> Serguei
>
>>
>> Coleen
>>
>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
>>> Coleen,
>>>
>>> Thank you for looking at this!
>>>
>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>>>
>>> 8u60:
>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>> + if (idnum >= methods()->length()) {
>>> + return NULL;
>>> + }
>>> + Method* m = methods()->at(idnum);
>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>> + return m;
>>> + }
>>> + // Obsolete method idnum does not match the original idnum
>>> + for (int index = 0; index < methods()->length(); ++index) {
>>> + m = methods()->at(index);
>>> + if (m->orig_method_idnum() == idnum) {
>>> + return m;
>>> + }
>>> + }
>>> + // None found, return null for the caller to handle.
>>> + return NULL;
>>> +}
>>> +
>>> +
>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>> + if (constants()->version() == version) {
>>> + return method_with_orig_idnum(idnum);
>>> + }
>>> + ConstantPoolCache* cp_cache = NULL;
>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
>>> + if (prev_cp->version() == version) {
>>> + cp_cache = prev_cp->cache();
>>> + break;
>>> + }
>>> + }
>>> + if (cp_cache == NULL) {
>>> + return NULL; // The pv_node is gone, no method is found
>>> + }
>>> + Method* method = NULL;
>>> + for (int i = 0; i < cp_cache->length(); i++) {
>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
>>> + method = entry->get_interesting_method_entry(this);
>>> + if (method == NULL) {
>>> + continue; // skip uninteresting entries
>>> + }
>>> + if (method->orig_method_idnum() == idnum) {
>>> + return method;
>>> + }
>>> + }
>>> + // None found, return null for the caller to handle.
>>> + return NULL;
>>> +}
>>>
>>>
>>> jdk 9:
>>>
>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>> + if (idnum >= methods()->length()) {
>>> + return NULL;
>>> + }
>>> + Method* m = methods()->at(idnum);
>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>> + return m;
>>> + }
>>> + // Obsolete method idnum does not match the original idnum
>>> + for (int index = 0; index < methods()->length(); ++index) {
>>> + m = methods()->at(index);
>>> + if (m->orig_method_idnum() == idnum) {
>>> + return m;
>>> + }
>>> + }
>>> + // None found, return null for the caller to handle.
>>> + return NULL;
>>> +}
>>> +
>>> +
>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>> + InstanceKlass* holder = get_klass_version(version);
>>> + if (holder == NULL) {
>>> + return NULL; // The version of klass is gone, no method is found
>>> + }
>>> + Method* method = holder->method_with_orig_idnum(idnum);
>>> + return method;
>>> +}
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>>>
>>>> This backport looks good. Why didn't the patch apply cleanly? It
>>>> seems mostly the same to me.
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Coleen and Dan,
>>>>>
>>>>> I'm asking you as the jdk 9 reviewers...
>>>>>
>>>>> Please, let me know if you have any chance and plans to review this.
>>>>> Would it be enough to have just one (R) reviewer for a non-clean
>>>>> backport?
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>
>>>>>
>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Please, review the jdk 8u60 backport for:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>>>
>>>>>> 8u60 hotspot webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>>>
>>>>>>
>>>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 9 hotspot webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>>>
>>>>>>
>>>>>> 9 webrev for unit test update:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>>>
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>> The 9 fix can not be applied cleanly so that I have to rework
>>>>>> the fix a little bit.
>>>>>>
>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>>>> profiling in NetBeans Profiler and VisualVM.
>>>>>> The issue is that the methods and related klass versions are
>>>>>> not kept alive if a class redefinition
>>>>>> takes place between catching a Throwable and taking a thread dump.
>>>>>> It can result in loosing an obsolete method, and so, the
>>>>>> reconstruction of method name becomes impossible.
>>>>>> In such a case, the null reference is returned instead of a
>>>>>> valid method name.
>>>>>>
>>>>>> The solution is to use current klass version and method
>>>>>> orig_idnum instead of ordinary method idnum
>>>>>> to find required method pointer. In the worst case when the
>>>>>> related klass version is gone
>>>>>> (was not included to or was removed from the previous_versions
>>>>>> linked list), a saved method name
>>>>>> CP index of the latest klass version can be used to restore the
>>>>>> method name.
>>>>>> The footprint extra overhead for this approach is u2 per stack
>>>>>> frame.
>>>>>>
>>>>>> Testing in progress:
>>>>>> In progress: nsk redefine classes tests, JTREG
>>>>>> java/lang/instrument
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From serguei.spitsyn at oracle.com Wed Apr 8 01:09:31 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 07 Apr 2015 18:09:31 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55247F6D.5090003@oracle.com>
References: <551DD8BB.5040001@oracle.com>
<55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com>
<55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com>
<552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com>
Message-ID: <55247FCB.6050000@oracle.com>
On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote:
>
>
> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote:
>> On 4/7/15 11:20 AM, Coleen Phillimore wrote:
>>>
>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using it
>>> to find the method.
>>>
>>> But this is only going to find the method if it happens to be in the
>>> cpCache somewhere. I think
>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not
>>> 100% sure). In which case, you can look at that class to find the
>>> method with idnum.
>> I'm not 100% sure either.
>> Ok, I will check if using the prev_constant_pool()->pool_holder() is
>> going to work.
>> It'd make it more consistent with the jdk 9 fix.
>
> This is the updated webrev.
Sorry, forgot to paste the link:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/
Thanks,
Serguei
> It is more consistent with the jdk 9 fix.
> Thank you for the suggestion!
>
> Thanks,
> Serguei
>
>>
>> Important part is that at least the saved cpref can be used to find
>> method name in the
>> the_class cpool if the attempt to find in the previous list cpCaches
>> was unsuccessful.
>>
>> Thanks,
>> Serguei
>>
>>>
>>> Coleen
>>>
>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
>>>> Coleen,
>>>>
>>>> Thank you for looking at this!
>>>>
>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>>>>
>>>> 8u60:
>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>> + if (idnum >= methods()->length()) {
>>>> + return NULL;
>>>> + }
>>>> + Method* m = methods()->at(idnum);
>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>> + return m;
>>>> + }
>>>> + // Obsolete method idnum does not match the original idnum
>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>> + m = methods()->at(index);
>>>> + if (m->orig_method_idnum() == idnum) {
>>>> + return m;
>>>> + }
>>>> + }
>>>> + // None found, return null for the caller to handle.
>>>> + return NULL;
>>>> +}
>>>> +
>>>> +
>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>> + if (constants()->version() == version) {
>>>> + return method_with_orig_idnum(idnum);
>>>> + }
>>>> + ConstantPoolCache* cp_cache = NULL;
>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
>>>> + if (prev_cp->version() == version) {
>>>> + cp_cache = prev_cp->cache();
>>>> + break;
>>>> + }
>>>> + }
>>>> + if (cp_cache == NULL) {
>>>> + return NULL; // The pv_node is gone, no method is found
>>>> + }
>>>> + Method* method = NULL;
>>>> + for (int i = 0; i < cp_cache->length(); i++) {
>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
>>>> + method = entry->get_interesting_method_entry(this);
>>>> + if (method == NULL) {
>>>> + continue; // skip uninteresting entries
>>>> + }
>>>> + if (method->orig_method_idnum() == idnum) {
>>>> + return method;
>>>> + }
>>>> + }
>>>> + // None found, return null for the caller to handle.
>>>> + return NULL;
>>>> +}
>>>>
>>>>
>>>> jdk 9:
>>>>
>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>> + if (idnum >= methods()->length()) {
>>>> + return NULL;
>>>> + }
>>>> + Method* m = methods()->at(idnum);
>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>> + return m;
>>>> + }
>>>> + // Obsolete method idnum does not match the original idnum
>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>> + m = methods()->at(index);
>>>> + if (m->orig_method_idnum() == idnum) {
>>>> + return m;
>>>> + }
>>>> + }
>>>> + // None found, return null for the caller to handle.
>>>> + return NULL;
>>>> +}
>>>> +
>>>> +
>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>> + InstanceKlass* holder = get_klass_version(version);
>>>> + if (holder == NULL) {
>>>> + return NULL; // The version of klass is gone, no method is found
>>>> + }
>>>> + Method* method = holder->method_with_orig_idnum(idnum);
>>>> + return method;
>>>> +}
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>
>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>>>>
>>>>> This backport looks good. Why didn't the patch apply cleanly? It
>>>>> seems mostly the same to me.
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Coleen and Dan,
>>>>>>
>>>>>> I'm asking you as the jdk 9 reviewers...
>>>>>>
>>>>>> Please, let me know if you have any chance and plans to review this.
>>>>>> Would it be enough to have just one (R) reviewer for a non-clean
>>>>>> backport?
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Please, review the jdk 8u60 backport for:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>>>>
>>>>>>> 8u60 hotspot webrev:
>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>>>>
>>>>>>>
>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 9 hotspot webrev:
>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>>>>
>>>>>>>
>>>>>>> 9 webrev for unit test update:
>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Summary:
>>>>>>> The 9 fix can not be applied cleanly so that I have to rework
>>>>>>> the fix a little bit.
>>>>>>>
>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>>>>> profiling in NetBeans Profiler and VisualVM.
>>>>>>> The issue is that the methods and related klass versions are
>>>>>>> not kept alive if a class redefinition
>>>>>>> takes place between catching a Throwable and taking a thread
>>>>>>> dump.
>>>>>>> It can result in loosing an obsolete method, and so, the
>>>>>>> reconstruction of method name becomes impossible.
>>>>>>> In such a case, the null reference is returned instead of a
>>>>>>> valid method name.
>>>>>>>
>>>>>>> The solution is to use current klass version and method
>>>>>>> orig_idnum instead of ordinary method idnum
>>>>>>> to find required method pointer. In the worst case when the
>>>>>>> related klass version is gone
>>>>>>> (was not included to or was removed from the previous_versions
>>>>>>> linked list), a saved method name
>>>>>>> CP index of the latest klass version can be used to restore
>>>>>>> the method name.
>>>>>>> The footprint extra overhead for this approach is u2 per stack
>>>>>>> frame.
>>>>>>>
>>>>>>> Testing in progress:
>>>>>>> In progress: nsk redefine classes tests, JTREG
>>>>>>> java/lang/instrument
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From magnus.ihse.bursie at oracle.com Wed Apr 8 06:39:46 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 8 Apr 2015 08:39:46 +0200
Subject: RFR: JDK-8076557: The specified procedure could not be found in
management.dll
In-Reply-To: <5523F5DE.9030601@oracle.com>
References: <5523F4AC.9050007@oracle.com> <5523F5DE.9030601@oracle.com>
Message-ID:
Looks good to me.
/Magnus
> 7 apr 2015 kl. 17:21 skrev Erik Joelsson :
>
> (corrected subject)
>
>> On 2015-04-07 17:15, Erik Joelsson wrote:
>> Hello,
>>
>> When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
>> Patch inline:
>>
>> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
>> --- a/make/lib/Lib-java.management.gmk Tue Apr 07 10:33:08 2015 +0100
>> +++ b/make/lib/Lib-java.management.gmk Tue Apr 07 17:11:29 2015 +0200
>> @@ -38,6 +38,11 @@
>> $(LIBJAVA_HEADER_FLAGS) \
>> #
>>
>> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
>> +# a binary that is compatible with windows versions older than 7/2008R2.
>> +# See MSDN documentation for GetProcessMemoryInfo for more information.
>> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
>> +
>> BUILD_LIBMANAGEMENT_EXCLUDES :=
>>
>> ifneq ($(OPENJDK_TARGET_OS), solaris)
>>
>>
>> /Erik
>
From staffan.larsen at oracle.com Wed Apr 8 10:21:14 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 8 Apr 2015 12:21:14 +0200
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9
Message-ID: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
Please review these small changes to support an addition of closed code to the java.instrument module.
webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/
Thanks,
/Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From erik.joelsson at oracle.com Wed Apr 8 10:32:07 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 08 Apr 2015 12:32:07 +0200
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk
9
In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
Message-ID: <552503A7.9080901@oracle.com>
Looks good to me.
/Erik
On 2015-04-08 12:21, Staffan Larsen wrote:
> Please review these small changes to support an addition of closed code to the java.instrument module.
>
> webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/
>
> Thanks,
> /Staffan
From staffan.larsen at oracle.com Wed Apr 8 11:40:29 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 8 Apr 2015 13:40:29 +0200
Subject: RFR: 8075331 jdb eval java.util.Arrays.asList(array) shows
inconsistent behaviour
Message-ID: <71FA7EA6-34FE-421A-8ED7-869CF30ED3E1@oracle.com>
Hi,
When calling varargs methods from JDI, we end up in MethodImpl.handleVarArgs() which has some logic to figure out how to call the varargs method with the parameters given. It depends on InvokeableType.isAssignableTo() to do this. This patch fixes a bug in isAssignableTo() where the implementation would say that an interface type was not assignable to java.lang.Object. With that fix in place, the reproducer from the bug and the new test passes.
Testing: all com/sun/jdi test and nsk.jdi.testlist on all platforms.
bug: https://bugs.openjdk.java.net/browse/JDK-8075331
webrev: http://cr.openjdk.java.net/~sla/8075331/webrev.00/
Thanks,
/Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jaroslav.bachorik at oracle.com Wed Apr 8 12:25:18 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 08 Apr 2015 14:25:18 +0200
Subject: RFR: 8075331 jdb eval java.util.Arrays.asList(array) shows
inconsistent behaviour
In-Reply-To: <71FA7EA6-34FE-421A-8ED7-869CF30ED3E1@oracle.com>
References: <71FA7EA6-34FE-421A-8ED7-869CF30ED3E1@oracle.com>
Message-ID: <55251E2E.40605@oracle.com>
Looks good!
Just update the copyright year in InterfaceTypeImpl.java
-JB-
On 8.4.2015 13:40, Staffan Larsen wrote:
> Hi,
>
> When calling varargs methods from JDI, we end up in
> MethodImpl.handleVarArgs() which has some logic to figure out how to
> call the varargs method with the parameters given. It depends on
> InvokeableType.isAssignableTo() to do this. This patch fixes a bug in
> isAssignableTo() where the implementation would say that an interface
> type was not assignable to java.lang.Object. With that fix in place, the
> reproducer from the bug and the new test passes.
>
> Testing: all com/sun/jdi test and nsk.jdi.testlist on all platforms.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8075331
> webrev: http://cr.openjdk.java.net/~sla/8075331/webrev.00/
>
> Thanks,
> /Staffan
From daniel.daugherty at oracle.com Wed Apr 8 13:54:26 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 08 Apr 2015 07:54:26 -0600
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55247FCB.6050000@oracle.com>
References: <551DD8BB.5040001@oracle.com>
<55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com>
<55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com>
<552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com>
<55247FCB.6050000@oracle.com>
Message-ID: <55253312.7040105@oracle.com>
On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote:
> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote:
>>
>>
>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote:
>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote:
>>>>
>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using it
>>>> to find the method.
>>>>
>>>> But this is only going to find the method if it happens to be in
>>>> the cpCache somewhere. I think
>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not
>>>> 100% sure). In which case, you can look at that class to find the
>>>> method with idnum.
>>> I'm not 100% sure either.
>>> Ok, I will check if using the prev_constant_pool()->pool_holder() is
>>> going to work.
>>> It'd make it more consistent with the jdk 9 fix.
>>
>> This is the updated webrev.
> Sorry, forgot to paste the link:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/
Comparing the two patch files looks good. A couple of nits:
src/share/vm/classfile/javaClasses.cpp
L1451: // Use specific ik version...
L1884: // Use specific ik version...
grammar: 'Use a specific ik version...'
L1452: // refer to version that...
L1885: // refer to version that...
grammar: 'refer to a version that...'
src/share/vm/classfile/javaClasses.hpp
No comments.
src/share/vm/oops/instanceKlass.cpp
No comments.
src/share/vm/oops/instanceKlass.hpp
No comments.
Thumbs up.
Dan
>
> Thanks,
> Serguei
>
>> It is more consistent with the jdk 9 fix.
>> Thank you for the suggestion!
>>
>> Thanks,
>> Serguei
>>
>>>
>>> Important part is that at least the saved cpref can be used to find
>>> method name in the
>>> the_class cpool if the attempt to find in the previous list cpCaches
>>> was unsuccessful.
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> Coleen
>>>>
>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
>>>>> Coleen,
>>>>>
>>>>> Thank you for looking at this!
>>>>>
>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>>>>>
>>>>> 8u60:
>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>> + if (idnum >= methods()->length()) {
>>>>> + return NULL;
>>>>> + }
>>>>> + Method* m = methods()->at(idnum);
>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>> + return m;
>>>>> + }
>>>>> + // Obsolete method idnum does not match the original idnum
>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>> + m = methods()->at(index);
>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>> + return m;
>>>>> + }
>>>>> + }
>>>>> + // None found, return null for the caller to handle.
>>>>> + return NULL;
>>>>> +}
>>>>> +
>>>>> +
>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>> + if (constants()->version() == version) {
>>>>> + return method_with_orig_idnum(idnum);
>>>>> + }
>>>>> + ConstantPoolCache* cp_cache = NULL;
>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
>>>>> + if (prev_cp->version() == version) {
>>>>> + cp_cache = prev_cp->cache();
>>>>> + break;
>>>>> + }
>>>>> + }
>>>>> + if (cp_cache == NULL) {
>>>>> + return NULL; // The pv_node is gone, no method is found
>>>>> + }
>>>>> + Method* method = NULL;
>>>>> + for (int i = 0; i < cp_cache->length(); i++) {
>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
>>>>> + method = entry->get_interesting_method_entry(this);
>>>>> + if (method == NULL) {
>>>>> + continue; // skip uninteresting entries
>>>>> + }
>>>>> + if (method->orig_method_idnum() == idnum) {
>>>>> + return method;
>>>>> + }
>>>>> + }
>>>>> + // None found, return null for the caller to handle.
>>>>> + return NULL;
>>>>> +}
>>>>>
>>>>>
>>>>> jdk 9:
>>>>>
>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>> + if (idnum >= methods()->length()) {
>>>>> + return NULL;
>>>>> + }
>>>>> + Method* m = methods()->at(idnum);
>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>> + return m;
>>>>> + }
>>>>> + // Obsolete method idnum does not match the original idnum
>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>> + m = methods()->at(index);
>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>> + return m;
>>>>> + }
>>>>> + }
>>>>> + // None found, return null for the caller to handle.
>>>>> + return NULL;
>>>>> +}
>>>>> +
>>>>> +
>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>> + InstanceKlass* holder = get_klass_version(version);
>>>>> + if (holder == NULL) {
>>>>> + return NULL; // The version of klass is gone, no method is found
>>>>> + }
>>>>> + Method* method = holder->method_with_orig_idnum(idnum);
>>>>> + return method;
>>>>> +}
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>
>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>>>>>
>>>>>> This backport looks good. Why didn't the patch apply cleanly?
>>>>>> It seems mostly the same to me.
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Coleen and Dan,
>>>>>>>
>>>>>>> I'm asking you as the jdk 9 reviewers...
>>>>>>>
>>>>>>> Please, let me know if you have any chance and plans to review
>>>>>>> this.
>>>>>>> Would it be enough to have just one (R) reviewer for a non-clean
>>>>>>> backport?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Please, review the jdk 8u60 backport for:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>>>>>
>>>>>>>> 8u60 hotspot webrev:
>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>>>>>
>>>>>>>>
>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 9 hotspot webrev:
>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>>>>>
>>>>>>>>
>>>>>>>> 9 webrev for unit test update:
>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>> The 9 fix can not be applied cleanly so that I have to rework
>>>>>>>> the fix a little bit.
>>>>>>>>
>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>>>>>> profiling in NetBeans Profiler and VisualVM.
>>>>>>>> The issue is that the methods and related klass versions are
>>>>>>>> not kept alive if a class redefinition
>>>>>>>> takes place between catching a Throwable and taking a thread
>>>>>>>> dump.
>>>>>>>> It can result in loosing an obsolete method, and so, the
>>>>>>>> reconstruction of method name becomes impossible.
>>>>>>>> In such a case, the null reference is returned instead of a
>>>>>>>> valid method name.
>>>>>>>>
>>>>>>>> The solution is to use current klass version and method
>>>>>>>> orig_idnum instead of ordinary method idnum
>>>>>>>> to find required method pointer. In the worst case when the
>>>>>>>> related klass version is gone
>>>>>>>> (was not included to or was removed from the
>>>>>>>> previous_versions linked list), a saved method name
>>>>>>>> CP index of the latest klass version can be used to restore
>>>>>>>> the method name.
>>>>>>>> The footprint extra overhead for this approach is u2 per
>>>>>>>> stack frame.
>>>>>>>>
>>>>>>>> Testing in progress:
>>>>>>>> In progress: nsk redefine classes tests, JTREG
>>>>>>>> java/lang/instrument
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mandy.chung at oracle.com Wed Apr 8 15:12:29 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 08 Apr 2015 08:12:29 -0700
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk
9
In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
Message-ID: <5525455D.7000501@oracle.com>
On 4/8/2015 3:21 AM, Staffan Larsen wrote:
> Please review these small changes to support an addition of closed code to the java.instrument module.
>
> webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/
The change looks fine.
Mandy
From serguei.spitsyn at oracle.com Wed Apr 8 18:38:21 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 08 Apr 2015 11:38:21 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55253312.7040105@oracle.com>
References: <551DD8BB.5040001@oracle.com>
<55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com>
<55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com>
<552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com>
<55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com>
Message-ID: <5525759D.8090506@oracle.com>
Thanks, Dan!
I will correct the grammar before the push..
Thanks,
Serguei
On 4/8/15 6:54 AM, Daniel D. Daugherty wrote:
> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote:
>> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote:
>>>
>>>
>>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote:
>>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote:
>>>>>
>>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using
>>>>> it to find the method.
>>>>>
>>>>> But this is only going to find the method if it happens to be in
>>>>> the cpCache somewhere. I think
>>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class (not
>>>>> 100% sure). In which case, you can look at that class to find the
>>>>> method with idnum.
>>>> I'm not 100% sure either.
>>>> Ok, I will check if using the prev_constant_pool()->pool_holder()
>>>> is going to work.
>>>> It'd make it more consistent with the jdk 9 fix.
>>>
>>> This is the updated webrev.
>> Sorry, forgot to paste the link:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/
>
> Comparing the two patch files looks good. A couple of nits:
>
> src/share/vm/classfile/javaClasses.cpp
> L1451: // Use specific ik version...
> L1884: // Use specific ik version...
> grammar: 'Use a specific ik version...'
>
> L1452: // refer to version that...
> L1885: // refer to version that...
> grammar: 'refer to a version that...'
>
> src/share/vm/classfile/javaClasses.hpp
> No comments.
>
> src/share/vm/oops/instanceKlass.cpp
> No comments.
>
> src/share/vm/oops/instanceKlass.hpp
> No comments.
>
> Thumbs up.
>
> Dan
>
>
>>
>> Thanks,
>> Serguei
>>
>>> It is more consistent with the jdk 9 fix.
>>> Thank you for the suggestion!
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> Important part is that at least the saved cpref can be used to find
>>>> method name in the
>>>> the_class cpool if the attempt to find in the previous list
>>>> cpCaches was unsuccessful.
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>>
>>>>> Coleen
>>>>>
>>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
>>>>>> Coleen,
>>>>>>
>>>>>> Thank you for looking at this!
>>>>>>
>>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>>>>>>
>>>>>> 8u60:
>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>>> + if (idnum >= methods()->length()) {
>>>>>> + return NULL;
>>>>>> + }
>>>>>> + Method* m = methods()->at(idnum);
>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>>> + return m;
>>>>>> + }
>>>>>> + // Obsolete method idnum does not match the original idnum
>>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>>> + m = methods()->at(index);
>>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>>> + return m;
>>>>>> + }
>>>>>> + }
>>>>>> + // None found, return null for the caller to handle.
>>>>>> + return NULL;
>>>>>> +}
>>>>>> +
>>>>>> +
>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>>> + if (constants()->version() == version) {
>>>>>> + return method_with_orig_idnum(idnum);
>>>>>> + }
>>>>>> + ConstantPoolCache* cp_cache = NULL;
>>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
>>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
>>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
>>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
>>>>>> + if (prev_cp->version() == version) {
>>>>>> + cp_cache = prev_cp->cache();
>>>>>> + break;
>>>>>> + }
>>>>>> + }
>>>>>> + if (cp_cache == NULL) {
>>>>>> + return NULL; // The pv_node is gone, no method is found
>>>>>> + }
>>>>>> + Method* method = NULL;
>>>>>> + for (int i = 0; i < cp_cache->length(); i++) {
>>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
>>>>>> + method = entry->get_interesting_method_entry(this);
>>>>>> + if (method == NULL) {
>>>>>> + continue; // skip uninteresting entries
>>>>>> + }
>>>>>> + if (method->orig_method_idnum() == idnum) {
>>>>>> + return method;
>>>>>> + }
>>>>>> + }
>>>>>> + // None found, return null for the caller to handle.
>>>>>> + return NULL;
>>>>>> +}
>>>>>>
>>>>>>
>>>>>> jdk 9:
>>>>>>
>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>>> + if (idnum >= methods()->length()) {
>>>>>> + return NULL;
>>>>>> + }
>>>>>> + Method* m = methods()->at(idnum);
>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>>> + return m;
>>>>>> + }
>>>>>> + // Obsolete method idnum does not match the original idnum
>>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>>> + m = methods()->at(index);
>>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>>> + return m;
>>>>>> + }
>>>>>> + }
>>>>>> + // None found, return null for the caller to handle.
>>>>>> + return NULL;
>>>>>> +}
>>>>>> +
>>>>>> +
>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>>> + InstanceKlass* holder = get_klass_version(version);
>>>>>> + if (holder == NULL) {
>>>>>> + return NULL; // The version of klass is gone, no method is found
>>>>>> + }
>>>>>> + Method* method = holder->method_with_orig_idnum(idnum);
>>>>>> + return method;
>>>>>> +}
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>>
>>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>>>>>>
>>>>>>> This backport looks good. Why didn't the patch apply cleanly?
>>>>>>> It seems mostly the same to me.
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Coleen and Dan,
>>>>>>>>
>>>>>>>> I'm asking you as the jdk 9 reviewers...
>>>>>>>>
>>>>>>>> Please, let me know if you have any chance and plans to review
>>>>>>>> this.
>>>>>>>> Would it be enough to have just one (R) reviewer for a
>>>>>>>> non-clean backport?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Please, review the jdk 8u60 backport for:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>>>>>>
>>>>>>>>> 8u60 hotspot webrev:
>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 9 hotspot webrev:
>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 9 webrev for unit test update:
>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Summary:
>>>>>>>>> The 9 fix can not be applied cleanly so that I have to
>>>>>>>>> rework the fix a little bit.
>>>>>>>>>
>>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>>>>>>> profiling in NetBeans Profiler and VisualVM.
>>>>>>>>> The issue is that the methods and related klass versions are
>>>>>>>>> not kept alive if a class redefinition
>>>>>>>>> takes place between catching a Throwable and taking a thread
>>>>>>>>> dump.
>>>>>>>>> It can result in loosing an obsolete method, and so, the
>>>>>>>>> reconstruction of method name becomes impossible.
>>>>>>>>> In such a case, the null reference is returned instead of a
>>>>>>>>> valid method name.
>>>>>>>>>
>>>>>>>>> The solution is to use current klass version and method
>>>>>>>>> orig_idnum instead of ordinary method idnum
>>>>>>>>> to find required method pointer. In the worst case when the
>>>>>>>>> related klass version is gone
>>>>>>>>> (was not included to or was removed from the
>>>>>>>>> previous_versions linked list), a saved method name
>>>>>>>>> CP index of the latest klass version can be used to restore
>>>>>>>>> the method name.
>>>>>>>>> The footprint extra overhead for this approach is u2 per
>>>>>>>>> stack frame.
>>>>>>>>>
>>>>>>>>> Testing in progress:
>>>>>>>>> In progress: nsk redefine classes tests, JTREG
>>>>>>>>> java/lang/instrument
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From coleen.phillimore at oracle.com Wed Apr 8 18:49:28 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 08 Apr 2015 14:49:28 -0400
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <5525759D.8090506@oracle.com>
References: <551DD8BB.5040001@oracle.com>
<55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com>
<55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com>
<552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com>
<55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com>
<5525759D.8090506@oracle.com>
Message-ID: <55257838.8080605@oracle.com>
Serguei, This latest version looks great.
Coleen
On 4/8/15, 2:38 PM, serguei.spitsyn at oracle.com wrote:
> Thanks, Dan!
>
> I will correct the grammar before the push..
>
> Thanks,
> Serguei
>
> On 4/8/15 6:54 AM, Daniel D. Daugherty wrote:
>> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote:
>>> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote:
>>>>
>>>>
>>>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote:
>>>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using
>>>>>> it to find the method.
>>>>>>
>>>>>> But this is only going to find the method if it happens to be in
>>>>>> the cpCache somewhere. I think
>>>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class
>>>>>> (not 100% sure). In which case, you can look at that class to
>>>>>> find the method with idnum.
>>>>> I'm not 100% sure either.
>>>>> Ok, I will check if using the prev_constant_pool()->pool_holder()
>>>>> is going to work.
>>>>> It'd make it more consistent with the jdk 9 fix.
>>>>
>>>> This is the updated webrev.
>>> Sorry, forgot to paste the link:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/
>>
>> Comparing the two patch files looks good. A couple of nits:
>>
>> src/share/vm/classfile/javaClasses.cpp
>> L1451: // Use specific ik version...
>> L1884: // Use specific ik version...
>> grammar: 'Use a specific ik version...'
>>
>> L1452: // refer to version that...
>> L1885: // refer to version that...
>> grammar: 'refer to a version that...'
>>
>> src/share/vm/classfile/javaClasses.hpp
>> No comments.
>>
>> src/share/vm/oops/instanceKlass.cpp
>> No comments.
>>
>> src/share/vm/oops/instanceKlass.hpp
>> No comments.
>>
>> Thumbs up.
>>
>> Dan
>>
>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>> It is more consistent with the jdk 9 fix.
>>>> Thank you for the suggestion!
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>>
>>>>> Important part is that at least the saved cpref can be used to
>>>>> find method name in the
>>>>> the_class cpool if the attempt to find in the previous list
>>>>> cpCaches was unsuccessful.
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Coleen,
>>>>>>>
>>>>>>> Thank you for looking at this!
>>>>>>>
>>>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>>>>>>>
>>>>>>> 8u60:
>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>>>> + if (idnum >= methods()->length()) {
>>>>>>> + return NULL;
>>>>>>> + }
>>>>>>> + Method* m = methods()->at(idnum);
>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>>>> + return m;
>>>>>>> + }
>>>>>>> + // Obsolete method idnum does not match the original idnum
>>>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>>>> + m = methods()->at(index);
>>>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>>>> + return m;
>>>>>>> + }
>>>>>>> + }
>>>>>>> + // None found, return null for the caller to handle.
>>>>>>> + return NULL;
>>>>>>> +}
>>>>>>> +
>>>>>>> +
>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>>>> + if (constants()->version() == version) {
>>>>>>> + return method_with_orig_idnum(idnum);
>>>>>>> + }
>>>>>>> + ConstantPoolCache* cp_cache = NULL;
>>>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
>>>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
>>>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
>>>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
>>>>>>> + if (prev_cp->version() == version) {
>>>>>>> + cp_cache = prev_cp->cache();
>>>>>>> + break;
>>>>>>> + }
>>>>>>> + }
>>>>>>> + if (cp_cache == NULL) {
>>>>>>> + return NULL; // The pv_node is gone, no method is found
>>>>>>> + }
>>>>>>> + Method* method = NULL;
>>>>>>> + for (int i = 0; i < cp_cache->length(); i++) {
>>>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
>>>>>>> + method = entry->get_interesting_method_entry(this);
>>>>>>> + if (method == NULL) {
>>>>>>> + continue; // skip uninteresting entries
>>>>>>> + }
>>>>>>> + if (method->orig_method_idnum() == idnum) {
>>>>>>> + return method;
>>>>>>> + }
>>>>>>> + }
>>>>>>> + // None found, return null for the caller to handle.
>>>>>>> + return NULL;
>>>>>>> +}
>>>>>>>
>>>>>>>
>>>>>>> jdk 9:
>>>>>>>
>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>>>> + if (idnum >= methods()->length()) {
>>>>>>> + return NULL;
>>>>>>> + }
>>>>>>> + Method* m = methods()->at(idnum);
>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>>>> + return m;
>>>>>>> + }
>>>>>>> + // Obsolete method idnum does not match the original idnum
>>>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>>>> + m = methods()->at(index);
>>>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>>>> + return m;
>>>>>>> + }
>>>>>>> + }
>>>>>>> + // None found, return null for the caller to handle.
>>>>>>> + return NULL;
>>>>>>> +}
>>>>>>> +
>>>>>>> +
>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>>>> + InstanceKlass* holder = get_klass_version(version);
>>>>>>> + if (holder == NULL) {
>>>>>>> + return NULL; // The version of klass is gone, no method is found
>>>>>>> + }
>>>>>>> + Method* method = holder->method_with_orig_idnum(idnum);
>>>>>>> + return method;
>>>>>>> +}
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>>
>>>>>>>
>>>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>>>>>>>
>>>>>>>> This backport looks good. Why didn't the patch apply cleanly?
>>>>>>>> It seems mostly the same to me.
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Coleen and Dan,
>>>>>>>>>
>>>>>>>>> I'm asking you as the jdk 9 reviewers...
>>>>>>>>>
>>>>>>>>> Please, let me know if you have any chance and plans to review
>>>>>>>>> this.
>>>>>>>>> Would it be enough to have just one (R) reviewer for a
>>>>>>>>> non-clean backport?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>> Please, review the jdk 8u60 backport for:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>>>>>>>
>>>>>>>>>> 8u60 hotspot webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 9 hotspot webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 9 webrev for unit test update:
>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Summary:
>>>>>>>>>> The 9 fix can not be applied cleanly so that I have to
>>>>>>>>>> rework the fix a little bit.
>>>>>>>>>>
>>>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>>>>>>>> profiling in NetBeans Profiler and VisualVM.
>>>>>>>>>> The issue is that the methods and related klass versions
>>>>>>>>>> are not kept alive if a class redefinition
>>>>>>>>>> takes place between catching a Throwable and taking a
>>>>>>>>>> thread dump.
>>>>>>>>>> It can result in loosing an obsolete method, and so, the
>>>>>>>>>> reconstruction of method name becomes impossible.
>>>>>>>>>> In such a case, the null reference is returned instead of a
>>>>>>>>>> valid method name.
>>>>>>>>>>
>>>>>>>>>> The solution is to use current klass version and method
>>>>>>>>>> orig_idnum instead of ordinary method idnum
>>>>>>>>>> to find required method pointer. In the worst case when the
>>>>>>>>>> related klass version is gone
>>>>>>>>>> (was not included to or was removed from the
>>>>>>>>>> previous_versions linked list), a saved method name
>>>>>>>>>> CP index of the latest klass version can be used to restore
>>>>>>>>>> the method name.
>>>>>>>>>> The footprint extra overhead for this approach is u2 per
>>>>>>>>>> stack frame.
>>>>>>>>>>
>>>>>>>>>> Testing in progress:
>>>>>>>>>> In progress: nsk redefine classes tests, JTREG
>>>>>>>>>> java/lang/instrument
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Serguei
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From serguei.spitsyn at oracle.com Wed Apr 8 18:58:07 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 08 Apr 2015 11:58:07 -0700
Subject: 8u60 backport RFR (M) 8067662: "java.lang.NullPointerException:
Method name is null" from StackTraceElement.
In-Reply-To: <55257838.8080605@oracle.com>
References: <551DD8BB.5040001@oracle.com>
<55231BAF.3030601@oracle.com> <552337B2.2080306@oracle.com>
<55236679.1040807@oracle.com> <55241FF7.3060801@oracle.com>
<552445AF.50209@oracle.com> <55247F6D.5090003@oracle.com>
<55247FCB.6050000@oracle.com> <55253312.7040105@oracle.com>
<5525759D.8090506@oracle.com> <55257838.8080605@oracle.com>
Message-ID: <55257A3F.5020700@oracle.com>
Thanks, Collen!
It was a great suggestion. :)
Thanks,
Serguei
On 4/8/15 11:49 AM, Coleen Phillimore wrote:
>
> Serguei, This latest version looks great.
> Coleen
>
> On 4/8/15, 2:38 PM, serguei.spitsyn at oracle.com wrote:
>> Thanks, Dan!
>>
>> I will correct the grammar before the push..
>>
>> Thanks,
>> Serguei
>>
>> On 4/8/15 6:54 AM, Daniel D. Daugherty wrote:
>>> On 4/7/15 7:09 PM, serguei.spitsyn at oracle.com wrote:
>>>> On 4/7/15 6:07 PM, serguei.spitsyn at oracle.com wrote:
>>>>>
>>>>>
>>>>> On 4/7/15 2:01 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> On 4/7/15 11:20 AM, Coleen Phillimore wrote:
>>>>>>>
>>>>>>> ?I see. The PreviousVersionWalker is gone in 9 and you're using
>>>>>>> it to find the method.
>>>>>>>
>>>>>>> But this is only going to find the method if it happens to be in
>>>>>>> the cpCache somewhere. I think
>>>>>>> pv_node->prev_constant_pool()->pool_holder() is scratch_class
>>>>>>> (not 100% sure). In which case, you can look at that class to
>>>>>>> find the method with idnum.
>>>>>> I'm not 100% sure either.
>>>>>> Ok, I will check if using the prev_constant_pool()->pool_holder()
>>>>>> is going to work.
>>>>>> It'd make it more consistent with the jdk 9 fix.
>>>>>
>>>>> This is the updated webrev.
>>>> Sorry, forgot to paste the link:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60.2/
>>>
>>> Comparing the two patch files looks good. A couple of nits:
>>>
>>> src/share/vm/classfile/javaClasses.cpp
>>> L1451: // Use specific ik version...
>>> L1884: // Use specific ik version...
>>> grammar: 'Use a specific ik version...'
>>>
>>> L1452: // refer to version that...
>>> L1885: // refer to version that...
>>> grammar: 'refer to a version that...'
>>>
>>> src/share/vm/classfile/javaClasses.hpp
>>> No comments.
>>>
>>> src/share/vm/oops/instanceKlass.cpp
>>> No comments.
>>>
>>> src/share/vm/oops/instanceKlass.hpp
>>> No comments.
>>>
>>> Thumbs up.
>>>
>>> Dan
>>>
>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>> It is more consistent with the jdk 9 fix.
>>>>> Thank you for the suggestion!
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>>
>>>>>> Important part is that at least the saved cpref can be used to
>>>>>> find method name in the
>>>>>> the_class cpool if the attempt to find in the previous list
>>>>>> cpCaches was unsuccessful.
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>>>
>>>>>>> Coleen
>>>>>>>
>>>>>>> On 4/7/15, 1:09 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Coleen,
>>>>>>>>
>>>>>>>> Thank you for looking at this!
>>>>>>>>
>>>>>>>> The main difference is in instanceKlass.cpp and instanceKlass.hpp.
>>>>>>>>
>>>>>>>> 8u60:
>>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>>>>> + if (idnum >= methods()->length()) {
>>>>>>>> + return NULL;
>>>>>>>> + }
>>>>>>>> + Method* m = methods()->at(idnum);
>>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>>>>> + return m;
>>>>>>>> + }
>>>>>>>> + // Obsolete method idnum does not match the original idnum
>>>>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>>>>> + m = methods()->at(index);
>>>>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>>>>> + return m;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + // None found, return null for the caller to handle.
>>>>>>>> + return NULL;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +
>>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>>>>> + if (constants()->version() == version) {
>>>>>>>> + return method_with_orig_idnum(idnum);
>>>>>>>> + }
>>>>>>>> + ConstantPoolCache* cp_cache = NULL;
>>>>>>>> + PreviousVersionWalker pvw(Thread::current(), (InstanceKlass*)this);
>>>>>>>> + for (PreviousVersionNode * pv_node = pvw.next_previous_version();
>>>>>>>> + pv_node != NULL; pv_node = pvw.next_previous_version()) {
>>>>>>>> + ConstantPool* prev_cp = pv_node->prev_constant_pool();
>>>>>>>> + if (prev_cp->version() == version) {
>>>>>>>> + cp_cache = prev_cp->cache();
>>>>>>>> + break;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + if (cp_cache == NULL) {
>>>>>>>> + return NULL; // The pv_node is gone, no method is found
>>>>>>>> + }
>>>>>>>> + Method* method = NULL;
>>>>>>>> + for (int i = 0; i < cp_cache->length(); i++) {
>>>>>>>> + ConstantPoolCacheEntry* entry = cp_cache->entry_at(i);
>>>>>>>> + method = entry->get_interesting_method_entry(this);
>>>>>>>> + if (method == NULL) {
>>>>>>>> + continue; // skip uninteresting entries
>>>>>>>> + }
>>>>>>>> + if (method->orig_method_idnum() == idnum) {
>>>>>>>> + return method;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + // None found, return null for the caller to handle.
>>>>>>>> + return NULL;
>>>>>>>> +}
>>>>>>>>
>>>>>>>>
>>>>>>>> jdk 9:
>>>>>>>>
>>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum) {
>>>>>>>> + if (idnum >= methods()->length()) {
>>>>>>>> + return NULL;
>>>>>>>> + }
>>>>>>>> + Method* m = methods()->at(idnum);
>>>>>>>> + if (m != NULL && m->orig_method_idnum() == idnum) {
>>>>>>>> + return m;
>>>>>>>> + }
>>>>>>>> + // Obsolete method idnum does not match the original idnum
>>>>>>>> + for (int index = 0; index < methods()->length(); ++index) {
>>>>>>>> + m = methods()->at(index);
>>>>>>>> + if (m->orig_method_idnum() == idnum) {
>>>>>>>> + return m;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> + // None found, return null for the caller to handle.
>>>>>>>> + return NULL;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> +
>>>>>>>> +Method* InstanceKlass::method_with_orig_idnum(int idnum, int version) {
>>>>>>>> + InstanceKlass* holder = get_klass_version(version);
>>>>>>>> + if (holder == NULL) {
>>>>>>>> + return NULL; // The version of klass is gone, no method is found
>>>>>>>> + }
>>>>>>>> + Method* method = holder->method_with_orig_idnum(idnum);
>>>>>>>> + return method;
>>>>>>>> +}
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/6/15 6:49 PM, Coleen Phillimore wrote:
>>>>>>>>>
>>>>>>>>> This backport looks good. Why didn't the patch apply
>>>>>>>>> cleanly? It seems mostly the same to me.
>>>>>>>>> Thanks,
>>>>>>>>> Coleen
>>>>>>>>>
>>>>>>>>> On 4/6/15, 7:50 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>> Coleen and Dan,
>>>>>>>>>>
>>>>>>>>>> I'm asking you as the jdk 9 reviewers...
>>>>>>>>>>
>>>>>>>>>> Please, let me know if you have any chance and plans to
>>>>>>>>>> review this.
>>>>>>>>>> Would it be enough to have just one (R) reviewer for a
>>>>>>>>>> non-clean backport?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Serguei
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/2/15 5:03 PM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>> Please, review the jdk 8u60 backport for:
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8067662
>>>>>>>>>>>
>>>>>>>>>>> 8u60 hotspot webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.8u60
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 8u60 webrev for unit test update (the fix applies cleanly):
>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.8u60
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 9 hotspot webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8067662-JVMTI-trace.2
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 9 webrev for unit test update:
>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8067662-JVMTI-trace-test.2
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Summary:
>>>>>>>>>>> The 9 fix can not be applied cleanly so that I have to
>>>>>>>>>>> rework the fix a little bit.
>>>>>>>>>>>
>>>>>>>>>>> An NPE is trown in a thread dumping via JMX when doing CPU
>>>>>>>>>>> profiling in NetBeans Profiler and VisualVM.
>>>>>>>>>>> The issue is that the methods and related klass versions
>>>>>>>>>>> are not kept alive if a class redefinition
>>>>>>>>>>> takes place between catching a Throwable and taking a
>>>>>>>>>>> thread dump.
>>>>>>>>>>> It can result in loosing an obsolete method, and so, the
>>>>>>>>>>> reconstruction of method name becomes impossible.
>>>>>>>>>>> In such a case, the null reference is returned instead of
>>>>>>>>>>> a valid method name.
>>>>>>>>>>>
>>>>>>>>>>> The solution is to use current klass version and method
>>>>>>>>>>> orig_idnum instead of ordinary method idnum
>>>>>>>>>>> to find required method pointer. In the worst case when
>>>>>>>>>>> the related klass version is gone
>>>>>>>>>>> (was not included to or was removed from the
>>>>>>>>>>> previous_versions linked list), a saved method name
>>>>>>>>>>> CP index of the latest klass version can be used to
>>>>>>>>>>> restore the method name.
>>>>>>>>>>> The footprint extra overhead for this approach is u2 per
>>>>>>>>>>> stack frame.
>>>>>>>>>>>
>>>>>>>>>>> Testing in progress:
>>>>>>>>>>> In progress: nsk redefine classes tests, JTREG
>>>>>>>>>>> java/lang/instrument
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Serguei
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From magnus.ihse.bursie at oracle.com Thu Apr 9 13:56:13 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 09 Apr 2015 15:56:13 +0200
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk
9
In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
Message-ID: <552684FD.2070100@oracle.com>
On 2015-04-08 12:21, Staffan Larsen wrote:
> Please review these small changes to support an addition of closed code to the java.instrument module.
>
> webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/
Looks good to me.
/Magnus
From dmitry.samersoff at oracle.com Thu Apr 9 15:54:52 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 09 Apr 2015 18:54:52 +0300
Subject: RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java
fails with AssertionFailure: can not get class data for
java/lang/UNIXProcess$Platform$$Lambda
Message-ID: <5526A0CC.5010801@oracle.com>
Everybody,
Please, review the fix.
http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/
When dumping a heap, SA agent iterates over SystemDictionary first and
store object information to internal cache. Lambda classes is not
present in SystemDictionary so they don't cached.
-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 jaroslav.bachorik at oracle.com Thu Apr 9 16:12:22 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 09 Apr 2015 18:12:22 +0200
Subject: RFR(S): JDK-8044416
serviceability/sa/jmap-hashcode/Test8028623.java
fails with AssertionFailure: can not get class data for
java/lang/UNIXProcess$Platform$$Lambda
In-Reply-To: <5526A0CC.5010801@oracle.com>
References: <5526A0CC.5010801@oracle.com>
Message-ID: <5526A4E6.20004@oracle.com>
Hi Dmitry,
Indentation should be 4 spaces.
Copyright year will need update.
Otherwise looks good!
-JB-
On 9.4.2015 17:54, Dmitry Samersoff wrote:
> Everybody,
>
> Please, review the fix.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/
>
> When dumping a heap, SA agent iterates over SystemDictionary first and
> store object information to internal cache. Lambda classes is not
> present in SystemDictionary so they don't cached.
>
>
> -Dmitry
>
From dmitry.samersoff at oracle.com Thu Apr 9 17:01:21 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 09 Apr 2015 20:01:21 +0300
Subject: RFR(S): JDK-8044416
serviceability/sa/jmap-hashcode/Test8028623.java
fails with AssertionFailure: can not get class data for
java/lang/UNIXProcess$Platform$$Lambda
In-Reply-To: <5526A4E6.20004@oracle.com>
References: <5526A0CC.5010801@oracle.com> <5526A4E6.20004@oracle.com>
Message-ID: <5526B061.1020306@oracle.com>
Jaroslav,
Thank you!
Nits fixed in-place (press shift-reload)
-Dmitry
On 2015-04-09 19:12, Jaroslav Bachorik wrote:
> Hi Dmitry,
>
> Indentation should be 4 spaces.
> Copyright year will need update.
>
> Otherwise looks good!
>
> -JB-
>
> On 9.4.2015 17:54, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please, review the fix.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/
>>
>> When dumping a heap, SA agent iterates over SystemDictionary first and
>> store object information to internal cache. Lambda classes is not
>> present in SystemDictionary so they don't cached.
>>
>>
>> -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 jaroslav.bachorik at oracle.com Thu Apr 9 17:55:33 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 09 Apr 2015 19:55:33 +0200
Subject: RFR(S): JDK-8044416
serviceability/sa/jmap-hashcode/Test8028623.java
fails with AssertionFailure: can not get class data for
java/lang/UNIXProcess$Platform$$Lambda
In-Reply-To: <5526B061.1020306@oracle.com>
References: <5526A0CC.5010801@oracle.com> <5526A4E6.20004@oracle.com>
<5526B061.1020306@oracle.com>
Message-ID: <5526BD15.6010301@oracle.com>
Thanks, good to go!
-JB-
On 9.4.2015 19:01, Dmitry Samersoff wrote:
> Jaroslav,
>
> Thank you!
>
> Nits fixed in-place (press shift-reload)
>
> -Dmitry
>
> On 2015-04-09 19:12, Jaroslav Bachorik wrote:
>> Hi Dmitry,
>>
>> Indentation should be 4 spaces.
>> Copyright year will need update.
>>
>> Otherwise looks good!
>>
>> -JB-
>>
>> On 9.4.2015 17:54, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please, review the fix.
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/
>>>
>>> When dumping a heap, SA agent iterates over SystemDictionary first and
>>> store object information to internal cache. Lambda classes is not
>>> present in SystemDictionary so they don't cached.
>>>
>>>
>>> -Dmitry
>>>
>>
>
>
From jaroslav.bachorik at oracle.com Thu Apr 9 18:11:40 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 09 Apr 2015 20:11:40 +0200
Subject: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread
expected to have BLOCKED but got RUNNABLE
Message-ID: <5526C0DC.7000502@oracle.com>
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
This fix is for an intermittent failure due to timing issues. The test
is using an arbitrary waiting period to allow the tested thread to
arrive to the requested state. Usually it works fine but under eg. heavy
load this strategy will fail. The proposed solution is to explicitly
check for the test thread arriving to the requested state instead of
waiting eg. 10ms.
I also took the liberty of removing the custom Semaphore implementation
and replacing its usage with java.util.concurrent.Phaser
Thanks,
-JB-
From jaroslav.bachorik at oracle.com Thu Apr 9 18:33:22 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 09 Apr 2015 20:33:22 +0200
Subject: RFR 8076050:
java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java
fails intermittently
Message-ID: <5526C5F2.1010905@oracle.com>
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8076050
Webrev: http://cr.openjdk.java.net/~jbachorik/8076050/webrev.00
This is another intermittently failing test due to timing problems.
The test thread is requested to move to "TIMED_WAITING" state and the
main thread then performs the asserts. The test thread will stay in
"TIMED_WAITING" state 10s (lock.wait(10000) in
test/java/lang/Thread/ThreadStateController.java#168) and after this
timeout it moves on. The wait may be cancelled by the main thread after
it has performed the asserts.
This timeout might turn out insufficient. The proposed solution is to do
`lock.wait(Integer.MAX_VALUE)` instead. Aside of this change I also
introduced the usage of `Utils.adjustTimeout(timeout)` to adjust the
requested timeouts to the test timeout scaling factor.
The change in
test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is
purely for the purpose of improving the log output - currently, when the
test fails the output is ignored; and this was fixed.
Thanks,
-JB-
From staffan.larsen at oracle.com Thu Apr 9 18:54:20 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 9 Apr 2015 20:54:20 +0200
Subject: RFR(S): JDK-8044416
serviceability/sa/jmap-hashcode/Test8028623.java fails with
AssertionFailure: can not get class data for
java/lang/UNIXProcess$Platform$$Lambda
In-Reply-To: <5526B061.1020306@oracle.com>
References: <5526A0CC.5010801@oracle.com> <5526A4E6.20004@oracle.com>
<5526B061.1020306@oracle.com>
Message-ID: <65F796FD-239E-451A-9F19-7D64D7F5C7FD@oracle.com>
Looks good!
Thanks,
/Staffan
> On 9 apr 2015, at 19:01, Dmitry Samersoff wrote:
>
> Jaroslav,
>
> Thank you!
>
> Nits fixed in-place (press shift-reload)
>
> -Dmitry
>
> On 2015-04-09 19:12, Jaroslav Bachorik wrote:
>> Hi Dmitry,
>>
>> Indentation should be 4 spaces.
>> Copyright year will need update.
>>
>> Otherwise looks good!
>>
>> -JB-
>>
>> On 9.4.2015 17:54, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please, review the fix.
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8044416/webrev.01/
>>>
>>> When dumping a heap, SA agent iterates over SystemDictionary first and
>>> store object information to internal cache. Lambda classes is not
>>> present in SystemDictionary so they don't cached.
>>>
>>>
>>> -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 staffan.larsen at oracle.com Thu Apr 9 19:00:16 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 9 Apr 2015 21:00:16 +0200
Subject: RFR 8076050:
java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java
fails intermittently
In-Reply-To: <5526C5F2.1010905@oracle.com>
References: <5526C5F2.1010905@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 9 apr 2015, at 20:33, Jaroslav Bachorik wrote:
>
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8076050
> Webrev: http://cr.openjdk.java.net/~jbachorik/8076050/webrev.00
>
> This is another intermittently failing test due to timing problems.
>
> The test thread is requested to move to "TIMED_WAITING" state and the main thread then performs the asserts. The test thread will stay in "TIMED_WAITING" state 10s (lock.wait(10000) in test/java/lang/Thread/ThreadStateController.java#168) and after this timeout it moves on. The wait may be cancelled by the main thread after it has performed the asserts.
>
> This timeout might turn out insufficient. The proposed solution is to do `lock.wait(Integer.MAX_VALUE)` instead. Aside of this change I also introduced the usage of `Utils.adjustTimeout(timeout)` to adjust the requested timeouts to the test timeout scaling factor.
>
> The change in test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java is purely for the purpose of improving the log output - currently, when the test fails the output is ignored; and this was fixed.
>
>
> Thanks,
>
> -JB-
From serguei.spitsyn at oracle.com Fri Apr 10 20:29:35 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 10 Apr 2015 13:29:35 -0700
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <5514C2C1.9040302@oracle.com>
References: <5514C2C1.9040302@oracle.com>
Message-ID: <552832AF.8080204@oracle.com>
Hi Coleen and Dan,
This is the second class redefinition scalability/optimization fix that
is in my queue to push into 9 and 8u60.
The approach is similar to the first one but much smaller.
For convenience, these are the links to the first scalability fix:
Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
Please, let me know if you have any chance to review this.
This is the last one that is waiting for your attention! :)
Thanks,
Serguei
On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> https://bugs.openjdk.java.net/browse/JDK-8073705
>
>
> Open hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>
>
>
> Summary:
>
> This is the 2-nd round of performance/calability fixes in class
> redefinition.
> This time, the two remaining issues that were left alone in the
> first round fix:
> - optimized ConstantPoolCache::adjust_method_entries() is used
> for previous versions
> - the MemberNameTable::adjust_method_entries() has been optimized
> too
> - some cleanup
>
>
> Testing:
> In progress: nsk redefine classes tests, JTREG java/lang/instrument,
> com/sun/jdi
>
>
> Thanks,
> Serguei
>
From jaroslav.bachorik at oracle.com Mon Apr 13 08:07:06 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 13 Apr 2015 10:07:06 +0200
Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception:
BlockedThread expected to have BLOCKED but got RUNNABLE
In-Reply-To: <5526C0DC.7000502@oracle.com>
References: <5526C0DC.7000502@oracle.com>
Message-ID: <552B792A.6000308@oracle.com>
On 9.4.2015 20:11, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>
> This fix is for an intermittent failure due to timing issues. The test
> is using an arbitrary waiting period to allow the tested thread to
> arrive to the requested state. Usually it works fine but under eg. heavy
> load this strategy will fail. The proposed solution is to explicitly
> check for the test thread arriving to the requested state instead of
> waiting eg. 10ms.
>
> I also took the liberty of removing the custom Semaphore implementation
> and replacing its usage with java.util.concurrent.Phaser
>
> Thanks,
>
> -JB-
From jaroslav.bachorik at oracle.com Mon Apr 13 09:43:34 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 13 Apr 2015 11:43:34 +0200
Subject: RFR 8041565: JMX ObjectName could be refactored to save memory
Message-ID: <552B8FC6.6030409@oracle.com>
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00
In situations when there are 10s of thousands ObjectNname instances
around (enterprise setups etc.) the 3 separate internal boolean fields
can lead to a noticeable memory waste. Adding insult to the injury, with
the current field layout it is necessary to align the instances by 4 bytes.
When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to
inspect the object layout we can see this:
Before optimization (JDK8u40):
---
javax.management.ObjectName object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header)| N/A
12 4 int ObjectName._domain_length N/A
16 1 boolean ObjectName._domain_pattern N/A
17 1 boolean ObjectName._property_list_pattern N/A
18 1 boolean ObjectName._property_value_pattern N/A
19 1 (alignment/padding gap) N/A
20 4 String ObjectName._canonicalName N/A
24 4 Property[] ObjectName._kp_array N/A
28 4 Property[] ObjectName._ca_array N/A
32 4 Map ObjectName._propertyList N/A
36 4 (loss due to the next object alignment)
Instance size: 40 bytes (estimated, the sample instance is not available)
Space losses: 1 bytes internal + 4 bytes external = 5 bytes total
{noformat}
After optimization (JDK9 internal build):
---
javax.management.ObjectName object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 2 short ObjectName._domain_length N/A
14 1 byte ObjectName._pattern_flag N/A
15 1 (alignment/padding gap) N/A
16 4 String ObjectName._canonicalName N/A
20 4 Property[] ObjectName._kp_array N/A
24 4 Property[] ObjectName._ca_array N/A
28 4 Map ObjectName._propertyList N/A
Instance size: 32 bytes (estimated, the sample instance is not available)
Space losses: 1 bytes internal + 0 bytes external = 1 bytes total
After optimization we can save 8 bytes per instance which can translate
to very interesting numbers on large installations.
To achieve this the domain name length is set to be *short* instead of
*int* and the three booleans kept for the performance purposes are
encoded into one byte value (as proposed by the reporter, Jean-Francois
Denise).
All the regression and JCK tests are passing after this change.
Thanks,
-JB-
From shanliang.jiang at oracle.com Mon Apr 13 09:45:15 2015
From: shanliang.jiang at oracle.com (Shanliang Jiang)
Date: Mon, 13 Apr 2015 11:45:15 +0200
Subject: RFR: 8077408
javax/management/remote/mandatory/notif/NotSerializableNotifTest.java
fails due to Port already in use: 2468
Message-ID: <552B902B.4010503@oracle.com>
Hi,
Please review this test fix.
Instead to specify a port, we use "0" to get a free port.
I also remove the test waiting time variable, better to reply on
directly the test harness timeout.
bug: https://bugs.openjdk.java.net/browse/JDK-8077408
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8077408/00/
Thanks,
Shanliang
From jaroslav.bachorik at oracle.com Mon Apr 13 09:49:06 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 13 Apr 2015 11:49:06 +0200
Subject: RFR: 8077408
javax/management/remote/mandatory/notif/NotSerializableNotifTest.java
fails due to Port already in use: 2468
In-Reply-To: <552B902B.4010503@oracle.com>
References: <552B902B.4010503@oracle.com>
Message-ID: <552B9112.7030801@oracle.com>
Looks good!
-JB-
On 13.4.2015 11:45, Shanliang Jiang wrote:
> Hi,
>
> Please review this test fix.
>
> Instead to specify a port, we use "0" to get a free port.
>
> I also remove the test waiting time variable, better to reply on
> directly the test harness timeout.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8077408
> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8077408/00/
>
>
> Thanks,
> Shanliang
From olivier.lagneau at oracle.com Mon Apr 13 12:09:28 2015
From: olivier.lagneau at oracle.com (Olivier Lagneau)
Date: Mon, 13 Apr 2015 14:09:28 +0200
Subject: RFR 8041565: JMX ObjectName could be refactored to save memory
In-Reply-To: <552B8FC6.6030409@oracle.com>
References: <552B8FC6.6030409@oracle.com>
Message-ID: <552BB1F8.1090103@oracle.com>
Hi Jaroslav,
Looks good to me.
Nice to save 8 bytes on object name insatnces (~ 20%) !
Olivier
Le 13/04/2015 11:43, Jaroslav Bachorik a ?crit :
> Please, review the following change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00
>
> In situations when there are 10s of thousands ObjectNname instances
> around (enterprise setups etc.) the 3 separate internal boolean fields
> can lead to a noticeable memory waste. Adding insult to the injury,
> with the current field layout it is necessary to align the instances
> by 4 bytes.
>
> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to
> inspect the object layout we can see this:
>
> Before optimization (JDK8u40):
> ---
> javax.management.ObjectName object internals:
> OFFSET SIZE TYPE DESCRIPTION VALUE
> 0 12 (object header)| N/A
> 12 4 int ObjectName._domain_length N/A
> 16 1 boolean ObjectName._domain_pattern N/A
> 17 1 boolean ObjectName._property_list_pattern N/A
> 18 1 boolean ObjectName._property_value_pattern N/A
> 19 1 (alignment/padding gap) N/A
> 20 4 String ObjectName._canonicalName N/A
> 24 4 Property[] ObjectName._kp_array N/A
> 28 4 Property[] ObjectName._ca_array N/A
> 32 4 Map ObjectName._propertyList N/A
> 36 4 (loss due to the next object alignment)
> Instance size: 40 bytes (estimated, the sample instance is not available)
> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total
> {noformat}
>
> After optimization (JDK9 internal build):
> ---
>
> javax.management.ObjectName object internals:
> OFFSET SIZE TYPE DESCRIPTION VALUE
> 0 12 (object header) N/A
> 12 2 short ObjectName._domain_length N/A
> 14 1 byte ObjectName._pattern_flag N/A
> 15 1 (alignment/padding gap) N/A
> 16 4 String ObjectName._canonicalName N/A
> 20 4 Property[] ObjectName._kp_array N/A
> 24 4 Property[] ObjectName._ca_array N/A
> 28 4 Map ObjectName._propertyList N/A
> Instance size: 32 bytes (estimated, the sample instance is not available)
> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total
>
>
> After optimization we can save 8 bytes per instance which can
> translate to very interesting numbers on large installations.
>
>
> To achieve this the domain name length is set to be *short* instead of
> *int* and the three booleans kept for the performance purposes are
> encoded into one byte value (as proposed by the reporter,
> Jean-Francois Denise).
>
> All the regression and JCK tests are passing after this change.
>
>
> Thanks,
>
> -JB-
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Roger.Riggs at Oracle.com Mon Apr 13 14:07:45 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 13 Apr 2015 10:07:45 -0400
Subject: RFR 8041565: JMX ObjectName could be refactored to save memory
In-Reply-To: <552B8FC6.6030409@oracle.com>
References: <552B8FC6.6030409@oracle.com>
Message-ID: <552BCDB1.704@Oracle.com>
Hi Jaroslav,
Minor comments:
1488+: In forms like:
_pattern_flag &= (~PROPLIST_PATTERN & 0xff);"
The &0xff seems unnecessary since the store is to a byte field.
1644: the ? and : operators should be surrounded by spaces.
There are other style issues, such as then statements on the same line
as the 'if' but that
may be beyond the scope of this change.
Otherwise looks fine (as a 9 reviewer, but not specifically a
serviceability reviewer).
Thanks, Roger
On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote:
> Please, review the following change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00
>
> In situations when there are 10s of thousands ObjectNname instances
> around (enterprise setups etc.) the 3 separate internal boolean fields
> can lead to a noticeable memory waste. Adding insult to the injury,
> with the current field layout it is necessary to align the instances
> by 4 bytes.
>
> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to
> inspect the object layout we can see this:
>
> Before optimization (JDK8u40):
> ---
> javax.management.ObjectName object internals:
> OFFSET SIZE TYPE DESCRIPTION VALUE
> 0 12 (object header)| N/A
> 12 4 int ObjectName._domain_length N/A
> 16 1 boolean ObjectName._domain_pattern N/A
> 17 1 boolean ObjectName._property_list_pattern N/A
> 18 1 boolean ObjectName._property_value_pattern N/A
> 19 1 (alignment/padding gap) N/A
> 20 4 String ObjectName._canonicalName N/A
> 24 4 Property[] ObjectName._kp_array N/A
> 28 4 Property[] ObjectName._ca_array N/A
> 32 4 Map ObjectName._propertyList N/A
> 36 4 (loss due to the next object alignment)
> Instance size: 40 bytes (estimated, the sample instance is not available)
> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total
> {noformat}
>
> After optimization (JDK9 internal build):
> ---
>
> javax.management.ObjectName object internals:
> OFFSET SIZE TYPE DESCRIPTION VALUE
> 0 12 (object header) N/A
> 12 2 short ObjectName._domain_length N/A
> 14 1 byte ObjectName._pattern_flag N/A
> 15 1 (alignment/padding gap) N/A
> 16 4 String ObjectName._canonicalName N/A
> 20 4 Property[] ObjectName._kp_array N/A
> 24 4 Property[] ObjectName._ca_array N/A
> 28 4 Map ObjectName._propertyList N/A
> Instance size: 32 bytes (estimated, the sample instance is not available)
> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total
>
>
> After optimization we can save 8 bytes per instance which can
> translate to very interesting numbers on large installations.
>
>
> To achieve this the domain name length is set to be *short* instead of
> *int* and the three booleans kept for the performance purposes are
> encoded into one byte value (as proposed by the reporter,
> Jean-Francois Denise).
>
> All the regression and JCK tests are passing after this change.
>
>
> Thanks,
>
> -JB-
From jaroslav.bachorik at oracle.com Mon Apr 13 15:07:30 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 13 Apr 2015 17:07:30 +0200
Subject: RFR 8041565: JMX ObjectName could be refactored to save memory
In-Reply-To: <552BCDB1.704@Oracle.com>
References: <552B8FC6.6030409@oracle.com> <552BCDB1.704@Oracle.com>
Message-ID: <552BDBB2.1050503@oracle.com>
Hi Roger,
On 13.4.2015 16:07, Roger Riggs wrote:
> Hi Jaroslav,
>
> Minor comments:
>
> 1488+: In forms like:
>
> _pattern_flag &= (~PROPLIST_PATTERN & 0xff);"
>
> The &0xff seems unnecessary since the store is to a byte field.
Fixed: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.01
>
> 1644: the ? and : operators should be surrounded by spaces.
>
> There are other style issues, such as then statements on the same line
> as the 'if' but that
> may be beyond the scope of this change.
I know but these style issue have been around since the file was first
committed. I didn't address them because it didn't feel right to mix
style changes with the actual functionality.
Cheers,
-JB-
>
> Otherwise looks fine (as a 9 reviewer, but not specifically a
> serviceability reviewer).
>
> Thanks, Roger
>
>
> On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote:
>> Please, review the following change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00
>>
>> In situations when there are 10s of thousands ObjectNname instances
>> around (enterprise setups etc.) the 3 separate internal boolean fields
>> can lead to a noticeable memory waste. Adding insult to the injury,
>> with the current field layout it is necessary to align the instances
>> by 4 bytes.
>>
>> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to
>> inspect the object layout we can see this:
>>
>> Before optimization (JDK8u40):
>> ---
>> javax.management.ObjectName object internals:
>> OFFSET SIZE TYPE DESCRIPTION VALUE
>> 0 12 (object header)| N/A
>> 12 4 int ObjectName._domain_length N/A
>> 16 1 boolean ObjectName._domain_pattern N/A
>> 17 1 boolean ObjectName._property_list_pattern N/A
>> 18 1 boolean ObjectName._property_value_pattern N/A
>> 19 1 (alignment/padding gap) N/A
>> 20 4 String ObjectName._canonicalName N/A
>> 24 4 Property[] ObjectName._kp_array N/A
>> 28 4 Property[] ObjectName._ca_array N/A
>> 32 4 Map ObjectName._propertyList N/A
>> 36 4 (loss due to the next object alignment)
>> Instance size: 40 bytes (estimated, the sample instance is not available)
>> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total
>> {noformat}
>>
>> After optimization (JDK9 internal build):
>> ---
>>
>> javax.management.ObjectName object internals:
>> OFFSET SIZE TYPE DESCRIPTION VALUE
>> 0 12 (object header) N/A
>> 12 2 short ObjectName._domain_length N/A
>> 14 1 byte ObjectName._pattern_flag N/A
>> 15 1 (alignment/padding gap) N/A
>> 16 4 String ObjectName._canonicalName N/A
>> 20 4 Property[] ObjectName._kp_array N/A
>> 24 4 Property[] ObjectName._ca_array N/A
>> 28 4 Map ObjectName._propertyList N/A
>> Instance size: 32 bytes (estimated, the sample instance is not available)
>> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total
>>
>>
>> After optimization we can save 8 bytes per instance which can
>> translate to very interesting numbers on large installations.
>>
>>
>> To achieve this the domain name length is set to be *short* instead of
>> *int* and the three booleans kept for the performance purposes are
>> encoded into one byte value (as proposed by the reporter,
>> Jean-Francois Denise).
>>
>> All the regression and JCK tests are passing after this change.
>>
>>
>> Thanks,
>>
>> -JB-
>
From serguei.spitsyn at oracle.com Tue Apr 14 03:42:39 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 13 Apr 2015 20:42:39 -0700
Subject: RFR 8077327: ThreadStackTrace.java throws exception: BlockedThread
expected to have BLOCKED but got RUNNABLE
In-Reply-To: <5526C0DC.7000502@oracle.com>
References: <5526C0DC.7000502@oracle.com>
Message-ID: <552C8CAF.4080706@oracle.com>
Jaroslav,
Nice fix.
I've checked all the synchronization/check points and they look correct.
I hope, the test will be stable now!
Thanks,
Serguei
On 4/9/15 11:11 AM, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>
> This fix is for an intermittent failure due to timing issues. The test
> is using an arbitrary waiting period to allow the tested thread to
> arrive to the requested state. Usually it works fine but under eg.
> heavy load this strategy will fail. The proposed solution is to
> explicitly check for the test thread arriving to the requested state
> instead of waiting eg. 10ms.
>
> I also took the liberty of removing the custom Semaphore
> implementation and replacing its usage with java.util.concurrent.Phaser
>
> Thanks,
>
> -JB-
From daniel.fuchs at oracle.com Tue Apr 14 07:38:03 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2015 09:38:03 +0200
Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception:
BlockedThread expected to have BLOCKED but got RUNNABLE
In-Reply-To: <552B792A.6000308@oracle.com>
References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com>
Message-ID: <552CC3DB.80606@oracle.com>
Hi Jaroslav,
Shouldn't you also wait for the blockedThread to be blocked on
lockA at around line 252?
(I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
best regards,
-- daniel
On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>> Please, review the following test change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>
>> This fix is for an intermittent failure due to timing issues. The test
>> is using an arbitrary waiting period to allow the tested thread to
>> arrive to the requested state. Usually it works fine but under eg. heavy
>> load this strategy will fail. The proposed solution is to explicitly
>> check for the test thread arriving to the requested state instead of
>> waiting eg. 10ms.
>>
>> I also took the liberty of removing the custom Semaphore implementation
>> and replacing its usage with java.util.concurrent.Phaser
>>
>> Thanks,
>>
>> -JB-
>
From jaroslav.bachorik at oracle.com Tue Apr 14 09:28:29 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 14 Apr 2015 11:28:29 +0200
Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception:
BlockedThread expected to have BLOCKED but got RUNNABLE
In-Reply-To: <552CC3DB.80606@oracle.com>
References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com>
<552CC3DB.80606@oracle.com>
Message-ID: <552CDDBD.5010102@oracle.com>
Hi Daniel,
On 14.4.2015 09:38, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> Shouldn't you also wait for the blockedThread to be blocked on
> lockA at around line 252?
> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
Yes, nice catch. Thanks!
http://cr.openjdk.java.net/~jbachorik/8077327/webrev.01
-JB-
>
> best regards,
>
> -- daniel
>
> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
>> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>>> Please, review the following test change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>>
>>> This fix is for an intermittent failure due to timing issues. The test
>>> is using an arbitrary waiting period to allow the tested thread to
>>> arrive to the requested state. Usually it works fine but under eg. heavy
>>> load this strategy will fail. The proposed solution is to explicitly
>>> check for the test thread arriving to the requested state instead of
>>> waiting eg. 10ms.
>>>
>>> I also took the liberty of removing the custom Semaphore implementation
>>> and replacing its usage with java.util.concurrent.Phaser
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>
From yekaterina.kantserova at oracle.com Tue Apr 14 09:44:59 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Tue, 14 Apr 2015 11:44:59 +0200
Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be
unquarantined
Message-ID: <552CE19B.4050903@oracle.com>
Hi,
Could I please have a review of this very small fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8077611
webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00
Thanks,
Katja
From daniel.fuchs at oracle.com Tue Apr 14 11:59:37 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2015 13:59:37 +0200
Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception:
BlockedThread expected to have BLOCKED but got RUNNABLE
In-Reply-To: <552CDDBD.5010102@oracle.com>
References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com>
<552CC3DB.80606@oracle.com> <552CDDBD.5010102@oracle.com>
Message-ID: <552D0129.1060506@oracle.com>
On 14/04/15 11:28, Jaroslav Bachorik wrote:
> Hi Daniel,
>
> On 14.4.2015 09:38, Daniel Fuchs wrote:
>> Hi Jaroslav,
>>
>> Shouldn't you also wait for the blockedThread to be blocked on
>> lockA at around line 252?
>> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
>
> Yes, nice catch. Thanks!
>
> http://cr.openjdk.java.net/~jbachorik/8077327/webrev.01
Looks good!
-- daniel
>
> -JB-
>
>>
>> best regards,
>>
>> -- daniel
>>
>> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
>>> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>>>> Please, review the following test change
>>>>
>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>>>
>>>> This fix is for an intermittent failure due to timing issues. The test
>>>> is using an arbitrary waiting period to allow the tested thread to
>>>> arrive to the requested state. Usually it works fine but under eg.
>>>> heavy
>>>> load this strategy will fail. The proposed solution is to explicitly
>>>> check for the test thread arriving to the requested state instead of
>>>> waiting eg. 10ms.
>>>>
>>>> I also took the liberty of removing the custom Semaphore implementation
>>>> and replacing its usage with java.util.concurrent.Phaser
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>
>>
>
From serguei.spitsyn at oracle.com Tue Apr 14 12:37:36 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 14 Apr 2015 05:37:36 -0700
Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception:
BlockedThread expected to have BLOCKED but got RUNNABLE
In-Reply-To: <552CC3DB.80606@oracle.com>
References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com>
<552CC3DB.80606@oracle.com>
Message-ID: <552D0A10.4090605@oracle.com>
On 4/14/15 12:38 AM, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> Shouldn't you also wait for the blockedThread to be blocked on
> lockA at around line 252?
> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
I guess, it is about these lines:
255 Utils.checkThreadState(blockedThread,
Thread.State.BLOCKED);
256 checkStack(blockedThread, blockedStack, bsDepth);
The implementation of the Utils.checkThreadState() from Utils.java:
public static void checkThreadState(Thread t, Thread.State expected) {
waitForThreadState(t, expected); <=== It does the call to the
waitForThreadState
Thread.State state = tm.getThreadInfo(t.getId()).getThreadState();
if (state == null) {
throw new RuntimeException(t.getName() + " expected to have " +
expected + " but got null.");
}
if (state != expected) {
t.dumpStack();
throw new RuntimeException(t.getName() +
" expected to have " + expected + " but got " + state);
}
}
Thanks,
Serguei
>
> best regards,
>
> -- daniel
>
> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
>> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>>> Please, review the following test change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>>
>>> This fix is for an intermittent failure due to timing issues. The test
>>> is using an arbitrary waiting period to allow the tested thread to
>>> arrive to the requested state. Usually it works fine but under eg.
>>> heavy
>>> load this strategy will fail. The proposed solution is to explicitly
>>> check for the test thread arriving to the requested state instead of
>>> waiting eg. 10ms.
>>>
>>> I also took the liberty of removing the custom Semaphore implementation
>>> and replacing its usage with java.util.concurrent.Phaser
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From daniel.fuchs at oracle.com Tue Apr 14 12:56:05 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2015 14:56:05 +0200
Subject: RFR 8041565: JMX ObjectName could be refactored to save memory
In-Reply-To: <552BDBB2.1050503@oracle.com>
References: <552B8FC6.6030409@oracle.com> <552BCDB1.704@Oracle.com>
<552BDBB2.1050503@oracle.com>
Message-ID: <552D0E65.1020805@oracle.com>
Hi Jaroslav,
I like this change, but it does introduce an incompatibility,
so it probably needs a CCC and some release notes.
For instance, this test passes with the current version of
ObjectName:
public class StringLengthTest {
final static int smax = Short.MAX_VALUE;
final static int smore = smax + 126;
public static void main(String[] args) throws
MalformedObjectNameException {
char[] chars = new char[smore];
Arrays.fill(chars, 0, smax, 'a');
Arrays.fill(chars, smax, smore, 'b');
System.out.println(new ObjectName(new String(chars), "type",
"Test"));
}
}
I'm not sure what it will do with your changes :-)
With that in mind I believe you should consider throwing
InternalError - or IllegalArgumentException - instead of
using 'assert' statements.
BTW have you run the JCK?
best regards,
-- daniel
On 13/04/15 17:07, Jaroslav Bachorik wrote:
> Hi Roger,
>
> On 13.4.2015 16:07, Roger Riggs wrote:
>> Hi Jaroslav,
>>
>> Minor comments:
>>
>> 1488+: In forms like:
>>
>> _pattern_flag &= (~PROPLIST_PATTERN & 0xff);"
>>
>> The &0xff seems unnecessary since the store is to a byte field.
>
> Fixed: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.01
>
>>
>> 1644: the ? and : operators should be surrounded by spaces.
>>
>> There are other style issues, such as then statements on the same line
>> as the 'if' but that
>> may be beyond the scope of this change.
>
> I know but these style issue have been around since the file was first
> committed. I didn't address them because it didn't feel right to mix
> style changes with the actual functionality.
>
> Cheers,
>
> -JB-
>
>>
>> Otherwise looks fine (as a 9 reviewer, but not specifically a
>> serviceability reviewer).
>>
>> Thanks, Roger
>>
>>
>> On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote:
>>> Please, review the following change
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00
>>>
>>> In situations when there are 10s of thousands ObjectNname instances
>>> around (enterprise setups etc.) the 3 separate internal boolean fields
>>> can lead to a noticeable memory waste. Adding insult to the injury,
>>> with the current field layout it is necessary to align the instances
>>> by 4 bytes.
>>>
>>> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to
>>> inspect the object layout we can see this:
>>>
>>> Before optimization (JDK8u40):
>>> ---
>>> javax.management.ObjectName object internals:
>>> OFFSET SIZE TYPE DESCRIPTION VALUE
>>> 0 12 (object header)| N/A
>>> 12 4 int ObjectName._domain_length N/A
>>> 16 1 boolean ObjectName._domain_pattern N/A
>>> 17 1 boolean ObjectName._property_list_pattern N/A
>>> 18 1 boolean ObjectName._property_value_pattern N/A
>>> 19 1 (alignment/padding gap) N/A
>>> 20 4 String ObjectName._canonicalName N/A
>>> 24 4 Property[] ObjectName._kp_array N/A
>>> 28 4 Property[] ObjectName._ca_array N/A
>>> 32 4 Map ObjectName._propertyList N/A
>>> 36 4 (loss due to the next object alignment)
>>> Instance size: 40 bytes (estimated, the sample instance is not
>>> available)
>>> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total
>>> {noformat}
>>>
>>> After optimization (JDK9 internal build):
>>> ---
>>>
>>> javax.management.ObjectName object internals:
>>> OFFSET SIZE TYPE DESCRIPTION VALUE
>>> 0 12 (object header) N/A
>>> 12 2 short ObjectName._domain_length N/A
>>> 14 1 byte ObjectName._pattern_flag N/A
>>> 15 1 (alignment/padding gap) N/A
>>> 16 4 String ObjectName._canonicalName N/A
>>> 20 4 Property[] ObjectName._kp_array N/A
>>> 24 4 Property[] ObjectName._ca_array N/A
>>> 28 4 Map ObjectName._propertyList N/A
>>> Instance size: 32 bytes (estimated, the sample instance is not
>>> available)
>>> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total
>>>
>>>
>>> After optimization we can save 8 bytes per instance which can
>>> translate to very interesting numbers on large installations.
>>>
>>>
>>> To achieve this the domain name length is set to be *short* instead of
>>> *int* and the three booleans kept for the performance purposes are
>>> encoded into one byte value (as proposed by the reporter,
>>> Jean-Francois Denise).
>>>
>>> All the regression and JCK tests are passing after this change.
>>>
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>
From daniel.fuchs at oracle.com Tue Apr 14 12:58:42 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 14 Apr 2015 14:58:42 +0200
Subject: RFR 8041565: JMX ObjectName could be refactored to save memory
In-Reply-To: <552D0E65.1020805@oracle.com>
References: <552B8FC6.6030409@oracle.com>
<552BCDB1.704@Oracle.com> <552BDBB2.1050503@oracle.com>
<552D0E65.1020805@oracle.com>
Message-ID: <552D0F02.2020903@oracle.com>
On 14/04/15 14:56, Daniel Fuchs wrote:
> With that in mind I believe you should consider throwing
> InternalError - or IllegalArgumentException - instead of
> using 'assert' statements.
Actually - MalformedObjectNameException would be more appropriate.
Stupid me.
-- daniel
From jaroslav.bachorik at oracle.com Tue Apr 14 14:44:30 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 14 Apr 2015 16:44:30 +0200
Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception:
BlockedThread expected to have BLOCKED but got RUNNABLE
In-Reply-To: <552D0A10.4090605@oracle.com>
References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com>
<552CC3DB.80606@oracle.com> <552D0A10.4090605@oracle.com>
Message-ID: <552D27CE.1080902@oracle.com>
On 14.4.2015 14:37, serguei.spitsyn at oracle.com wrote:
> On 4/14/15 12:38 AM, Daniel Fuchs wrote:
>> Hi Jaroslav,
>>
>> Shouldn't you also wait for the blockedThread to be blocked on
>> lockA at around line 252?
>> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
> I guess, it is about these lines:
>
> 255 Utils.checkThreadState(blockedThread,
> Thread.State.BLOCKED);
> 256 checkStack(blockedThread, blockedStack, bsDepth);
>
> The implementation of the Utils.checkThreadState() from Utils.java:
>
> public static void checkThreadState(Thread t, Thread.State expected) {
> waitForThreadState(t, expected); <=== It does the call to the
> waitForThreadState
>
> Thread.State state = tm.getThreadInfo(t.getId()).getThreadState();
> if (state == null) {
> throw new RuntimeException(t.getName() + " expected to have " +
> expected + " but got null.");
> }
> if (state != expected) {
> t.dumpStack();
> throw new RuntimeException(t.getName() +
> " expected to have " + expected + " but got " + state);
> }
> }
Yes, that's true. On the other hand the original code did call
"blockedThread.waitUntilBlocked()" explicitly - so I decided to keep the
semantics to minimize the chance of any regressions.
-JB-
>
> Thanks,
> Serguei
>
>
>>
>> best regards,
>>
>> -- daniel
>>
>> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
>>> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>>>> Please, review the following test change
>>>>
>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>>>
>>>> This fix is for an intermittent failure due to timing issues. The test
>>>> is using an arbitrary waiting period to allow the tested thread to
>>>> arrive to the requested state. Usually it works fine but under eg.
>>>> heavy
>>>> load this strategy will fail. The proposed solution is to explicitly
>>>> check for the test thread arriving to the requested state instead of
>>>> waiting eg. 10ms.
>>>>
>>>> I also took the liberty of removing the custom Semaphore implementation
>>>> and replacing its usage with java.util.concurrent.Phaser
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>
>>
>
From jaroslav.bachorik at oracle.com Tue Apr 14 14:58:08 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 14 Apr 2015 16:58:08 +0200
Subject: RFR 8041565: JMX ObjectName could be refactored to save memory
In-Reply-To: <552D0E65.1020805@oracle.com>
References: <552B8FC6.6030409@oracle.com> <552BCDB1.704@Oracle.com>
<552BDBB2.1050503@oracle.com> <552D0E65.1020805@oracle.com>
Message-ID: <552D2B00.4090805@oracle.com>
On 14.4.2015 14:56, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> I like this change, but it does introduce an incompatibility,
> so it probably needs a CCC and some release notes.
>
> For instance, this test passes with the current version of
> ObjectName:
>
> public class StringLengthTest {
>
> final static int smax = Short.MAX_VALUE;
> final static int smore = smax + 126;
> public static void main(String[] args) throws
> MalformedObjectNameException {
> char[] chars = new char[smore];
> Arrays.fill(chars, 0, smax, 'a');
> Arrays.fill(chars, smax, smore, 'b');
>
> System.out.println(new ObjectName(new String(chars), "type",
> "Test"));
> }
>
> }
>
> I'm not sure what it will do with your changes :-)
It will fail with assert (if enabled). Or truncate the domain name, I
suppose.
>
> With that in mind I believe you should consider throwing
> InternalError - or IllegalArgumentException - instead of
> using 'assert' statements.
This would probably be better.
>
> BTW have you run the JCK?
Yes. All passed. I don't think JCK is testing for unrealistic values :)
I don't see how one could come up with a domain name 32767 characters long.
-JB-
>
> best regards,
>
> -- daniel
>
> On 13/04/15 17:07, Jaroslav Bachorik wrote:
>> Hi Roger,
>>
>> On 13.4.2015 16:07, Roger Riggs wrote:
>>> Hi Jaroslav,
>>>
>>> Minor comments:
>>>
>>> 1488+: In forms like:
>>>
>>> _pattern_flag &= (~PROPLIST_PATTERN & 0xff);"
>>>
>>> The &0xff seems unnecessary since the store is to a byte field.
>>
>> Fixed: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.01
>>
>>>
>>> 1644: the ? and : operators should be surrounded by spaces.
>>>
>>> There are other style issues, such as then statements on the same line
>>> as the 'if' but that
>>> may be beyond the scope of this change.
>>
>> I know but these style issue have been around since the file was first
>> committed. I didn't address them because it didn't feel right to mix
>> style changes with the actual functionality.
>>
>> Cheers,
>>
>> -JB-
>>
>>>
>>> Otherwise looks fine (as a 9 reviewer, but not specifically a
>>> serviceability reviewer).
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 4/13/2015 5:43 AM, Jaroslav Bachorik wrote:
>>>> Please, review the following change
>>>>
>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8041565
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8041565/webrev.00
>>>>
>>>> In situations when there are 10s of thousands ObjectNname instances
>>>> around (enterprise setups etc.) the 3 separate internal boolean fields
>>>> can lead to a noticeable memory waste. Adding insult to the injury,
>>>> with the current field layout it is necessary to align the instances
>>>> by 4 bytes.
>>>>
>>>> When using JOL (http://openjdk.java.net/projects/code-tools/jol/) to
>>>> inspect the object layout we can see this:
>>>>
>>>> Before optimization (JDK8u40):
>>>> ---
>>>> javax.management.ObjectName object internals:
>>>> OFFSET SIZE TYPE DESCRIPTION VALUE
>>>> 0 12 (object header)| N/A
>>>> 12 4 int ObjectName._domain_length N/A
>>>> 16 1 boolean ObjectName._domain_pattern N/A
>>>> 17 1 boolean ObjectName._property_list_pattern N/A
>>>> 18 1 boolean ObjectName._property_value_pattern N/A
>>>> 19 1 (alignment/padding gap) N/A
>>>> 20 4 String ObjectName._canonicalName N/A
>>>> 24 4 Property[] ObjectName._kp_array N/A
>>>> 28 4 Property[] ObjectName._ca_array N/A
>>>> 32 4 Map ObjectName._propertyList N/A
>>>> 36 4 (loss due to the next object alignment)
>>>> Instance size: 40 bytes (estimated, the sample instance is not
>>>> available)
>>>> Space losses: 1 bytes internal + 4 bytes external = 5 bytes total
>>>> {noformat}
>>>>
>>>> After optimization (JDK9 internal build):
>>>> ---
>>>>
>>>> javax.management.ObjectName object internals:
>>>> OFFSET SIZE TYPE DESCRIPTION VALUE
>>>> 0 12 (object header) N/A
>>>> 12 2 short ObjectName._domain_length N/A
>>>> 14 1 byte ObjectName._pattern_flag N/A
>>>> 15 1 (alignment/padding gap) N/A
>>>> 16 4 String ObjectName._canonicalName N/A
>>>> 20 4 Property[] ObjectName._kp_array N/A
>>>> 24 4 Property[] ObjectName._ca_array N/A
>>>> 28 4 Map ObjectName._propertyList N/A
>>>> Instance size: 32 bytes (estimated, the sample instance is not
>>>> available)
>>>> Space losses: 1 bytes internal + 0 bytes external = 1 bytes total
>>>>
>>>>
>>>> After optimization we can save 8 bytes per instance which can
>>>> translate to very interesting numbers on large installations.
>>>>
>>>>
>>>> To achieve this the domain name length is set to be *short* instead of
>>>> *int* and the three booleans kept for the performance purposes are
>>>> encoded into one byte value (as proposed by the reporter,
>>>> Jean-Francois Denise).
>>>>
>>>> All the regression and JCK tests are passing after this change.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>
>>
>
From serguei.spitsyn at oracle.com Tue Apr 14 20:06:35 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 14 Apr 2015 13:06:35 -0700
Subject: [ping] Re: RFR 8077327: ThreadStackTrace.java throws exception:
BlockedThread expected to have BLOCKED but got RUNNABLE
In-Reply-To: <552D27CE.1080902@oracle.com>
References: <5526C0DC.7000502@oracle.com> <552B792A.6000308@oracle.com>
<552CC3DB.80606@oracle.com> <552D0A10.4090605@oracle.com>
<552D27CE.1080902@oracle.com>
Message-ID: <552D734B.50802@oracle.com>
On 4/14/15 7:44 AM, Jaroslav Bachorik wrote:
> On 14.4.2015 14:37, serguei.spitsyn at oracle.com wrote:
>> On 4/14/15 12:38 AM, Daniel Fuchs wrote:
>>> Hi Jaroslav,
>>>
>>> Shouldn't you also wait for the blockedThread to be blocked on
>>> lockA at around line 252?
>>> (I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
>> I guess, it is about these lines:
>>
>> 255 Utils.checkThreadState(blockedThread,
>> Thread.State.BLOCKED);
>> 256 checkStack(blockedThread, blockedStack,
>> bsDepth);
>>
>> The implementation of the Utils.checkThreadState() from Utils.java:
>>
>> public static void checkThreadState(Thread t, Thread.State
>> expected) {
>> waitForThreadState(t, expected); <=== It does the call to the
>> waitForThreadState
>>
>> Thread.State state =
>> tm.getThreadInfo(t.getId()).getThreadState();
>> if (state == null) {
>> throw new RuntimeException(t.getName() + " expected to
>> have " +
>> expected + " but got null.");
>> }
>> if (state != expected) {
>> t.dumpStack();
>> throw new RuntimeException(t.getName() +
>> " expected to have " + expected + " but got " +
>> state);
>> }
>> }
>
> Yes, that's true. On the other hand the original code did call
> "blockedThread.waitUntilBlocked()" explicitly - so I decided to keep
> the semantics to minimize the chance of any regressions.
That's Ok. :)
Thanks,
Serguei
>
> -JB-
>
>>
>> Thanks,
>> Serguei
>>
>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
>>>> On 9.4.2015 20:11, Jaroslav Bachorik wrote:
>>>>> Please, review the following test change
>>>>>
>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8077327
>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8077327/webrev.00
>>>>>
>>>>> This fix is for an intermittent failure due to timing issues. The
>>>>> test
>>>>> is using an arbitrary waiting period to allow the tested thread to
>>>>> arrive to the requested state. Usually it works fine but under eg.
>>>>> heavy
>>>>> load this strategy will fail. The proposed solution is to explicitly
>>>>> check for the test thread arriving to the requested state instead of
>>>>> waiting eg. 10ms.
>>>>>
>>>>> I also took the liberty of removing the custom Semaphore
>>>>> implementation
>>>>> and replacing its usage with java.util.concurrent.Phaser
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -JB-
>>>>
>>>
>>
>
From roland.westrelin at oracle.com Wed Apr 15 09:48:49 2015
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 15 Apr 2015 11:48:49 +0200
Subject: RFR(S): 8077832: SA's dumpreplaydata,
dumpcfg and buildreplayjars are broken
Message-ID:
http://cr.openjdk.java.net/~roland/8077832/webrev.00/
I found 3 locations where the SA code is out of sync with the hotspot code.
Roland.
From staffan.larsen at oracle.com Wed Apr 15 11:03:14 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 15 Apr 2015 13:03:14 +0200
Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be
unquarantined
In-Reply-To: <552CE19B.4050903@oracle.com>
References: <552CE19B.4050903@oracle.com>
Message-ID: <1A5499B9-3F39-4FC1-AE80-983E6156C43D@oracle.com>
Looks good!
Thanks,
/Staffan
> On 14 apr 2015, at 11:44, Yekaterina Kantserova wrote:
>
> Hi,
>
> Could I please have a review of this very small fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8077611
> webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00
>
> Thanks,
> Katja
From yekaterina.kantserova at oracle.com Wed Apr 15 11:23:35 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 15 Apr 2015 13:23:35 +0200
Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be
unquarantined
In-Reply-To: <1A5499B9-3F39-4FC1-AE80-983E6156C43D@oracle.com>
References: <552CE19B.4050903@oracle.com>
<1A5499B9-3F39-4FC1-AE80-983E6156C43D@oracle.com>
Message-ID: <552E4A37.2050702@oracle.com>
Staffan, thanks!
On 04/15/2015 01:03 PM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
>> On 14 apr 2015, at 11:44, Yekaterina Kantserova wrote:
>>
>> Hi,
>>
>> Could I please have a review of this very small fix.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8077611
>> webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00
>>
>> Thanks,
>> Katja
From serguei.spitsyn at oracle.com Wed Apr 15 11:47:28 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 15 Apr 2015 04:47:28 -0700
Subject: RFR(XXS): 8077611: com/sun/jdi/ConnectedVMs.java should be
unquarantined
In-Reply-To: <552CE19B.4050903@oracle.com>
References: <552CE19B.4050903@oracle.com>
Message-ID: <552E4FD0.4080004@oracle.com>
Look good.
Thanks,
Serguei
On 4/14/15 2:44 AM, Yekaterina Kantserova wrote:
> Hi,
>
> Could I please have a review of this very small fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8077611
> webrev: http://cr.openjdk.java.net/~ykantser/8077611/webrev.00
>
> Thanks,
> Katja
From dmitry.samersoff at oracle.com Wed Apr 15 14:24:11 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 15 Apr 2015 17:24:11 +0300
Subject: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars
are broken
In-Reply-To:
References:
Message-ID: <552E748B.4090202@oracle.com>
Roland,
Looks good to me.
-Dmitry
On 2015-04-15 12:48, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8077832/webrev.00/
>
> I found 3 locations where the SA code is out of sync with the hotspot code.
>
> Roland.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From staffan.larsen at oracle.com Wed Apr 15 14:28:06 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 15 Apr 2015 16:28:06 +0200
Subject: RFR(S): 8077832: SA's dumpreplaydata,
dumpcfg and buildreplayjars are broken
In-Reply-To:
References:
Message-ID: <04E2ECF6-B209-48C8-8B8D-7B28FB1ABCEC@oracle.com>
Looks good!
Thanks,
/Staffan
> On 15 apr 2015, at 11:48, Roland Westrelin wrote:
>
> http://cr.openjdk.java.net/~roland/8077832/webrev.00/
>
> I found 3 locations where the SA code is out of sync with the hotspot code.
>
> Roland.
From yekaterina.kantserova at oracle.com Wed Apr 15 14:46:18 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 15 Apr 2015 16:46:18 +0200
Subject: RFR(XS): 8077423: jstatd is not terminated even though it cannot
contact or bind to RMI Registry
In-Reply-To: <5029010A-8192-4D0D-A771-80C8FAA9806A@oracle.com>
References: <5527E38C.4090603@oracle.com>
<5029010A-8192-4D0D-A771-80C8FAA9806A@oracle.com>
Message-ID: <552E79BA.2050309@oracle.com>
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8077423
webrev: http://cr.openjdk.java.net/~ykantser/8077423/webrev.00/
A couple of comments about changes in sun/tools/jstatd/JstatdTest.java.
If the suggested fix will be accepted there will be no need of
waitForJstatdRMI(), because jstad will either be started properly or
will terminate.
A check has been added that there is no RMi Registry already running on
default port. Otherwise the test will fail fast.
A sanity check for "-nr" option has been added as well.
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html
"-nr
Do not attempt to create an internal RMI registry within the jstatd
process when an existing RMI registry is not found."
Thanks,
Katja
From staffan.larsen at oracle.com Wed Apr 15 14:55:21 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 15 Apr 2015 16:55:21 +0200
Subject: RFR(XS): 8077423: jstatd is not terminated even though it cannot
contact or bind to RMI Registry
In-Reply-To: <552E79BA.2050309@oracle.com>
References: <5527E38C.4090603@oracle.com>
<5029010A-8192-4D0D-A771-80C8FAA9806A@oracle.com>
<552E79BA.2050309@oracle.com>
Message-ID: <87312687-D97E-4306-880B-CD395D565064@oracle.com>
Looks good!
Thanks,
/Staffan
> On 15 apr 2015, at 16:46, Yekaterina Kantserova wrote:
>
> Hi,
>
> Could I please have a review of this fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8077423
> webrev: http://cr.openjdk.java.net/~ykantser/8077423/webrev.00/
>
> A couple of comments about changes in sun/tools/jstatd/JstatdTest.java. If the suggested fix will be accepted there will be no need of waitForJstatdRMI(), because jstad will either be started properly or will terminate.
>
> A check has been added that there is no RMi Registry already running on default port. Otherwise the test will fail fast.
>
> A sanity check for "-nr" option has been added as well.
>
> http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html
> "-nr
> Do not attempt to create an internal RMI registry within the jstatd process when an existing RMI registry is not found."
>
>
> Thanks,
> Katja
From vladimir.kozlov at oracle.com Wed Apr 15 17:24:01 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 15 Apr 2015 10:24:01 -0700
Subject: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars
are broken
In-Reply-To:
References:
Message-ID: <552E9EB1.6070607@oracle.com>
Looks good.
Thanks,
Vladimir
On 4/15/15 2:48 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8077832/webrev.00/
>
> I found 3 locations where the SA code is out of sync with the hotspot code.
>
> Roland.
>
From joe.darcy at oracle.com Thu Apr 16 02:47:09 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 15 Apr 2015 19:47:09 -0700
Subject: JDK 9 RFR of JDK-8077923: Add missing doclint in javax.management
Message-ID: <552F22AD.4030104@oracle.com>
Hello,
While trying to turn on doclint checking in the build on more modules,
it came to my attention that various parts of the javax.management
package are missing javadoc. Please review the straightforward changes
to add the missing javadoc:
JDK-8077923: Add missing doclint in javax.management
http://cr.openjdk.java.net/~darcy/8077923.0/
Patch below.
Once this issue is resolved, I'll do the follow-up work necessary to
enable doclint checking on the java.management module.
Thanks,
-Joe
---
old/src/java.management/share/classes/javax/management/AttributeValueExp.java
2015-04-15 19:40:40.296525183 -0700
+++
new/src/java.management/share/classes/javax/management/AttributeValueExp.java
2015-04-15 19:40:40.116615181 -0700
@@ -93,11 +93,10 @@
*
* @return The ValueExp
.
*
- * @exception BadAttributeValueExpException
- * @exception InvalidApplicationException
- * @exception BadStringOperationException
- * @exception BadBinaryOpValueExpException
- *
+ * @throws BadStringOperationException {@inheritDoc}
+ * @throws BadBinaryOpValueExpException {@inheritDoc}
+ * @throws BadAttributeValueExpException {@inheritDoc}
+ * @throws InvalidApplicationException {@inheritDoc}
*/
@Override
public ValueExp apply(ObjectName name) throws
BadStringOperationException, BadBinaryOpValueExpException,
---
old/src/java.management/share/classes/javax/management/DescriptorKey.java 2015-04-15
19:40:40.740303194 -0700
+++
new/src/java.management/share/classes/javax/management/DescriptorKey.java 2015-04-15
19:40:40.564391190 -0700
@@ -168,5 +168,9 @@
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface DescriptorKey {
+ /**
+ * Returns the descriptor key.
+ * @return the descriptor key
+ */
String value();
}
---
old/src/java.management/share/classes/javax/management/DynamicMBean.java
2015-04-15 19:40:41.196075205 -0700
+++
new/src/java.management/share/classes/javax/management/DynamicMBean.java
2015-04-15 19:40:41.016165202 -0700
@@ -43,7 +43,7 @@
*
* @return The value of the attribute retrieved.
*
- * @exception AttributeNotFoundException
+ * @exception AttributeNotFoundException if specified attribute
does not exist or cannot be retrieved
* @exception MBeanException Wraps a
java.lang.Exception
thrown by the MBean's getter.
* @exception ReflectionException Wraps a
java.lang.Exception
thrown while trying to invoke the getter.
*
@@ -58,8 +58,8 @@
* @param attribute The identification of the attribute to
* be set and the value it is to be set to.
*
- * @exception AttributeNotFoundException
- * @exception InvalidAttributeValueException
+ * @exception AttributeNotFoundException if specified attribute
does not exist or cannot be retrieved
+ * @exception InvalidAttributeValueException if value specified is
not valid for the attribute
* @exception MBeanException Wraps a
java.lang.Exception
thrown by the MBean's setter.
* @exception ReflectionException Wraps a
java.lang.Exception
thrown while trying to invoke the
MBean's setter.
*
---
old/src/java.management/share/classes/javax/management/ImmutableDescriptor.java
2015-04-15 19:40:41.639853215 -0700
+++
new/src/java.management/share/classes/javax/management/ImmutableDescriptor.java
2015-04-15 19:40:41.455945211 -0700
@@ -65,6 +65,8 @@
/**
* Construct a descriptor containing the given fields and values.
*
+ * @param fieldNames the field names
+ * @param fieldValues the field values
* @throws IllegalArgumentException if either array is null, or
* if the arrays have different sizes, or
* if a field name is null or empty, or if the same field name
@@ -81,6 +83,7 @@
* is {@code a=b=c} then the field name is {@code a} and its value
* is {@code b=c}.
*
+ * @param fields the field names
* @throws IllegalArgumentException if the parameter is null, or
* if a field name is empty, or if the same field name appears
* more than once, or if one of the strings does not contain
@@ -94,6 +97,7 @@
* Construct a descriptor where the names and values of the fields
* are the keys and values of the given Map.
*
+ * @param fields the field names and values
* @throws IllegalArgumentException if the parameter is null, or
* if a field name is null or empty, or if the same field name appears
* more than once (which can happen because field names are not case
--- old/src/java.management/share/classes/javax/management/QueryExp.java
2015-04-15 19:40:42.099623225 -0700
+++ new/src/java.management/share/classes/javax/management/QueryExp.java
2015-04-15 19:40:41.919713221 -0700
@@ -53,10 +53,13 @@
*
* @return True if the query was successfully applied to the
MBean, false otherwise
*
- * @exception BadStringOperationException
- * @exception BadBinaryOpValueExpException
- * @exception BadAttributeValueExpException
- * @exception InvalidApplicationException
+ * @throws BadStringOperationException when an invalid string
+ * operation is passed to a method for constructing a query
+ * @throws BadBinaryOpValueExpException when an invalid expression
+ * is passed to a method for constructing a query
+ * @throws BadAttributeValueExpException when an invalid MBean
+ * attribute is passed to a query constructing method
+ * @throws InvalidApplicationException when an invalid apply is
attempted
*/
public boolean apply(ObjectName name) throws
BadStringOperationException, BadBinaryOpValueExpException,
BadAttributeValueExpException, InvalidApplicationException ;
---
old/src/java.management/share/classes/javax/management/StandardEmitterMBean.java
2015-04-15 19:40:42.559393236 -0700
+++
new/src/java.management/share/classes/javax/management/StandardEmitterMBean.java
2015-04-15 19:40:42.367489231 -0700
@@ -91,6 +91,7 @@
* that will have no effect on this object's
* {@code getNotificationInfo()}.
*
+ * @param the implementation type of the MBean
* @param implementation the implementation of the MBean interface.
* @param mbeanInterface a Standard MBean interface.
* @param emitter the object that will handle notifications.
@@ -129,6 +130,7 @@
* that will have no effect on this object's
* {@code getNotificationInfo()}.
*
+ * @param the implementation type of the MBean
* @param implementation the implementation of the MBean interface.
* @param mbeanInterface a Standard MBean interface.
* @param isMXBean If true, the {@code mbeanInterface} parameter
---
old/src/java.management/share/classes/javax/management/StringValueExp.java
2015-04-15 19:40:43.015165247 -0700
+++
new/src/java.management/share/classes/javax/management/StringValueExp.java
2015-04-15 19:40:42.839253243 -0700
@@ -95,11 +95,12 @@
*
* @return The ValueExp
.
*
- * @exception BadStringOperationException
- * @exception BadBinaryOpValueExpException
- * @exception BadAttributeValueExpException
- * @exception InvalidApplicationException
+ * @throws BadStringOperationException {@inheritDoc}
+ * @throws BadBinaryOpValueExpException {@inheritDoc}
+ * @throws BadAttributeValueExpException {@inheritDoc}
+ * @throws InvalidApplicationException {@inheritDoc}
*/
+ @Override
public ValueExp apply(ObjectName name) throws
BadStringOperationException, BadBinaryOpValueExpException,
BadAttributeValueExpException, InvalidApplicationException {
return this;
--- old/src/java.management/share/classes/javax/management/ValueExp.java
2015-04-15 19:40:43.466939257 -0700
+++ new/src/java.management/share/classes/javax/management/ValueExp.java
2015-04-15 19:40:43.283031253 -0700
@@ -80,10 +80,13 @@
*
* @return The ValueExp
.
*
- * @exception BadStringOperationException
- * @exception BadBinaryOpValueExpException
- * @exception BadAttributeValueExpException
- * @exception InvalidApplicationException
+ * @throws BadStringOperationException when an invalid string
+ * operation is passed to a method for constructing a query
+ * @throws BadBinaryOpValueExpException when an invalid expression
+ * is passed to a method for constructing a query
+ * @throws BadAttributeValueExpException when an invalid MBean
+ * attribute is passed to a query constructing method
+ * @throws InvalidApplicationException when an invalid apply is
attempted
*/
public ValueExp apply(ObjectName name)
throws BadStringOperationException,
BadBinaryOpValueExpException,
---
old/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
2015-04-15 19:40:43.930707268 -0700
+++
new/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
2015-04-15 19:40:43.746799263 -0700
@@ -307,6 +307,7 @@
/**
* Creates and returns a copy of this object.
+ * @return a copy of this object
*/
public java.lang.Object clone();
---
old/src/java.management/share/classes/javax/management/monitor/Monitor.java
2015-04-15 19:40:44.386479279 -0700
+++
new/src/java.management/share/classes/javax/management/monitor/Monitor.java
2015-04-15 19:40:44.198573274 -0700
@@ -387,7 +387,7 @@
*
* @return The name of the monitor MBean registered.
*
- * @exception Exception
+ * @exception Exception if something goes wrong
*/
public ObjectName preRegister(MBeanServer server, ObjectName name)
throws Exception {
@@ -416,7 +416,7 @@
*
* Stops the monitor.
*
- * @exception Exception
+ * @exception Exception if something goes wrong
*/
public void preDeregister() throws Exception {
---
old/src/java.management/share/classes/javax/management/openmbean/ArrayType.java
2015-04-15 19:40:44.902221290 -0700
+++
new/src/java.management/share/classes/javax/management/openmbean/ArrayType.java
2015-04-15 19:40:44.670337285 -0700
@@ -793,6 +793,7 @@
* array type description = 3-dimension array of java.lang.String
* }
*
+ * @param the Java type that described instances must have
* @param elementType the open type of element values
contained
* in the arrays described by this
ArrayType
* instance; must be an instance of either
@@ -800,7 +801,7 @@
* TabularType or another
ArrayType
* with a SimpleType,
CompositeType
* or TabularType as its
elementType.
- *
+ * @return an {@code ArrayType} instance
* @throws OpenDataException if elementType's className
is not
* one of the allowed Java class names
for open
* data.
@@ -834,12 +835,14 @@
* array type description = 3-dimension array of int
* }
*
+ * @param the Java type that described instances must have
* @param arrayClass a primitive array class such as {@code
int[].class},
* {@code boolean[][].class}, etc. The {@link
* #getElementOpenType()} method of the returned
* {@code ArrayType} returns the {@link SimpleType}
* corresponding to the wrapper type of the
primitive
* type of the array.
+ * @return an {@code ArrayType} instance
*
* @throws IllegalArgumentException if arrayClass is not
* a primitive array.
---
old/src/java.management/share/classes/javax/management/timer/Timer.java
2015-04-15 19:40:45.397973302 -0700
+++
new/src/java.management/share/classes/javax/management/timer/Timer.java
2015-04-15 19:40:45.218063297 -0700
@@ -195,7 +195,7 @@
*
* @return The name of the timer MBean registered.
*
- * @exception java.lang.Exception
+ * @exception java.lang.Exception if something goes wrong
*/
public ObjectName preRegister(MBeanServer server, ObjectName name)
throws java.lang.Exception {
@@ -217,7 +217,7 @@
*
* Stops the timer.
*
- * @exception java.lang.Exception
+ * @exception java.lang.Exception if something goes wrong
*/
public void preDeregister() throws java.lang.Exception {
From daniel.fuchs at oracle.com Thu Apr 16 07:10:52 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 16 Apr 2015 09:10:52 +0200
Subject: JDK 9 RFR of JDK-8077923: Add missing doclint in javax.management
In-Reply-To: <552F22AD.4030104@oracle.com>
References: <552F22AD.4030104@oracle.com>
Message-ID: <552F607C.5080404@oracle.com>
Hi Joe,
Looks good to me!
+1 for doclint :-)
best regards,
-- daniel
On 4/16/15 4:47 AM, joe darcy wrote:
> Hello,
>
> While trying to turn on doclint checking in the build on more modules,
> it came to my attention that various parts of the javax.management
> package are missing javadoc. Please review the straightforward changes
> to add the missing javadoc:
>
> JDK-8077923: Add missing doclint in javax.management
> http://cr.openjdk.java.net/~darcy/8077923.0/
>
> Patch below.
>
> Once this issue is resolved, I'll do the follow-up work necessary to
> enable doclint checking on the java.management module.
>
> Thanks,
>
> -Joe
>
> ---
> old/src/java.management/share/classes/javax/management/AttributeValueExp.java
> 2015-04-15 19:40:40.296525183 -0700
> +++
> new/src/java.management/share/classes/javax/management/AttributeValueExp.java
> 2015-04-15 19:40:40.116615181 -0700
> @@ -93,11 +93,10 @@
> *
> * @return The ValueExp
.
> *
> - * @exception BadAttributeValueExpException
> - * @exception InvalidApplicationException
> - * @exception BadStringOperationException
> - * @exception BadBinaryOpValueExpException
> - *
> + * @throws BadStringOperationException {@inheritDoc}
> + * @throws BadBinaryOpValueExpException {@inheritDoc}
> + * @throws BadAttributeValueExpException {@inheritDoc}
> + * @throws InvalidApplicationException {@inheritDoc}
> */
> @Override
> public ValueExp apply(ObjectName name) throws
> BadStringOperationException, BadBinaryOpValueExpException,
> ---
> old/src/java.management/share/classes/javax/management/DescriptorKey.java
> 2015-04-15 19:40:40.740303194 -0700
> +++
> new/src/java.management/share/classes/javax/management/DescriptorKey.java
> 2015-04-15 19:40:40.564391190 -0700
> @@ -168,5 +168,9 @@
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.METHOD)
> public @interface DescriptorKey {
> + /**
> + * Returns the descriptor key.
> + * @return the descriptor key
> + */
> String value();
> }
> ---
> old/src/java.management/share/classes/javax/management/DynamicMBean.java
> 2015-04-15 19:40:41.196075205 -0700
> +++
> new/src/java.management/share/classes/javax/management/DynamicMBean.java
> 2015-04-15 19:40:41.016165202 -0700
> @@ -43,7 +43,7 @@
> *
> * @return The value of the attribute retrieved.
> *
> - * @exception AttributeNotFoundException
> + * @exception AttributeNotFoundException if specified attribute
> does not exist or cannot be retrieved
> * @exception MBeanException Wraps a
> java.lang.Exception
thrown by the MBean's getter.
> * @exception ReflectionException Wraps a
> java.lang.Exception
thrown while trying to invoke the
> getter.
> *
> @@ -58,8 +58,8 @@
> * @param attribute The identification of the attribute to
> * be set and the value it is to be set to.
> *
> - * @exception AttributeNotFoundException
> - * @exception InvalidAttributeValueException
> + * @exception AttributeNotFoundException if specified attribute
> does not exist or cannot be retrieved
> + * @exception InvalidAttributeValueException if value specified
> is not valid for the attribute
> * @exception MBeanException Wraps a
> java.lang.Exception
thrown by the MBean's setter.
> * @exception ReflectionException Wraps a
> java.lang.Exception
thrown while trying to invoke the
> MBean's setter.
> *
> ---
> old/src/java.management/share/classes/javax/management/ImmutableDescriptor.java
> 2015-04-15 19:40:41.639853215 -0700
> +++
> new/src/java.management/share/classes/javax/management/ImmutableDescriptor.java
> 2015-04-15 19:40:41.455945211 -0700
> @@ -65,6 +65,8 @@
> /**
> * Construct a descriptor containing the given fields and values.
> *
> + * @param fieldNames the field names
> + * @param fieldValues the field values
> * @throws IllegalArgumentException if either array is null, or
> * if the arrays have different sizes, or
> * if a field name is null or empty, or if the same field name
> @@ -81,6 +83,7 @@
> * is {@code a=b=c} then the field name is {@code a} and its value
> * is {@code b=c}.
> *
> + * @param fields the field names
> * @throws IllegalArgumentException if the parameter is null, or
> * if a field name is empty, or if the same field name appears
> * more than once, or if one of the strings does not contain
> @@ -94,6 +97,7 @@
> *
Construct a descriptor where the names and values of the
> fields
> * are the keys and values of the given Map.
> *
> + * @param fields the field names and values
> * @throws IllegalArgumentException if the parameter is null, or
> * if a field name is null or empty, or if the same field name
> appears
> * more than once (which can happen because field names are not case
> ---
> old/src/java.management/share/classes/javax/management/QueryExp.java
> 2015-04-15 19:40:42.099623225 -0700
> +++
> new/src/java.management/share/classes/javax/management/QueryExp.java
> 2015-04-15 19:40:41.919713221 -0700
> @@ -53,10 +53,13 @@
> *
> * @return True if the query was successfully applied to the
> MBean, false otherwise
> *
> - * @exception BadStringOperationException
> - * @exception BadBinaryOpValueExpException
> - * @exception BadAttributeValueExpException
> - * @exception InvalidApplicationException
> + * @throws BadStringOperationException when an invalid string
> + * operation is passed to a method for constructing a query
> + * @throws BadBinaryOpValueExpException when an invalid expression
> + * is passed to a method for constructing a query
> + * @throws BadAttributeValueExpException when an invalid MBean
> + * attribute is passed to a query constructing method
> + * @throws InvalidApplicationException when an invalid apply is
> attempted
> */
> public boolean apply(ObjectName name) throws
> BadStringOperationException, BadBinaryOpValueExpException,
> BadAttributeValueExpException, InvalidApplicationException ;
> ---
> old/src/java.management/share/classes/javax/management/StandardEmitterMBean.java
> 2015-04-15 19:40:42.559393236 -0700
> +++
> new/src/java.management/share/classes/javax/management/StandardEmitterMBean.java
> 2015-04-15 19:40:42.367489231 -0700
> @@ -91,6 +91,7 @@
> * that will have no effect on this object's
> * {@code getNotificationInfo()}.
> *
> + * @param the implementation type of the MBean
> * @param implementation the implementation of the MBean interface.
> * @param mbeanInterface a Standard MBean interface.
> * @param emitter the object that will handle notifications.
> @@ -129,6 +130,7 @@
> * that will have no effect on this object's
> * {@code getNotificationInfo()}.
> *
> + * @param the implementation type of the MBean
> * @param implementation the implementation of the MBean interface.
> * @param mbeanInterface a Standard MBean interface.
> * @param isMXBean If true, the {@code mbeanInterface} parameter
> ---
> old/src/java.management/share/classes/javax/management/StringValueExp.java
> 2015-04-15 19:40:43.015165247 -0700
> +++
> new/src/java.management/share/classes/javax/management/StringValueExp.java
> 2015-04-15 19:40:42.839253243 -0700
> @@ -95,11 +95,12 @@
> *
> * @return The ValueExp
.
> *
> - * @exception BadStringOperationException
> - * @exception BadBinaryOpValueExpException
> - * @exception BadAttributeValueExpException
> - * @exception InvalidApplicationException
> + * @throws BadStringOperationException {@inheritDoc}
> + * @throws BadBinaryOpValueExpException {@inheritDoc}
> + * @throws BadAttributeValueExpException {@inheritDoc}
> + * @throws InvalidApplicationException {@inheritDoc}
> */
> + @Override
> public ValueExp apply(ObjectName name) throws
> BadStringOperationException, BadBinaryOpValueExpException,
> BadAttributeValueExpException, InvalidApplicationException {
> return this;
> ---
> old/src/java.management/share/classes/javax/management/ValueExp.java
> 2015-04-15 19:40:43.466939257 -0700
> +++
> new/src/java.management/share/classes/javax/management/ValueExp.java
> 2015-04-15 19:40:43.283031253 -0700
> @@ -80,10 +80,13 @@
> *
> * @return The ValueExp
.
> *
> - * @exception BadStringOperationException
> - * @exception BadBinaryOpValueExpException
> - * @exception BadAttributeValueExpException
> - * @exception InvalidApplicationException
> + * @throws BadStringOperationException when an invalid string
> + * operation is passed to a method for constructing a query
> + * @throws BadBinaryOpValueExpException when an invalid expression
> + * is passed to a method for constructing a query
> + * @throws BadAttributeValueExpException when an invalid MBean
> + * attribute is passed to a query constructing method
> + * @throws InvalidApplicationException when an invalid apply is
> attempted
> */
> public ValueExp apply(ObjectName name)
> throws BadStringOperationException,
> BadBinaryOpValueExpException,
> ---
> old/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
> 2015-04-15 19:40:43.930707268 -0700
> +++
> new/src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java
> 2015-04-15 19:40:43.746799263 -0700
> @@ -307,6 +307,7 @@
>
> /**
> * Creates and returns a copy of this object.
> + * @return a copy of this object
> */
> public java.lang.Object clone();
>
> ---
> old/src/java.management/share/classes/javax/management/monitor/Monitor.java
> 2015-04-15 19:40:44.386479279 -0700
> +++
> new/src/java.management/share/classes/javax/management/monitor/Monitor.java
> 2015-04-15 19:40:44.198573274 -0700
> @@ -387,7 +387,7 @@
> *
> * @return The name of the monitor MBean registered.
> *
> - * @exception Exception
> + * @exception Exception if something goes wrong
> */
> public ObjectName preRegister(MBeanServer server, ObjectName name)
> throws Exception {
> @@ -416,7 +416,7 @@
> *
> * Stops the monitor.
> *
> - * @exception Exception
> + * @exception Exception if something goes wrong
> */
> public void preDeregister() throws Exception {
>
> ---
> old/src/java.management/share/classes/javax/management/openmbean/ArrayType.java
> 2015-04-15 19:40:44.902221290 -0700
> +++
> new/src/java.management/share/classes/javax/management/openmbean/ArrayType.java
> 2015-04-15 19:40:44.670337285 -0700
> @@ -793,6 +793,7 @@
> * array type description = 3-dimension array of java.lang.String
> * }
> *
> + * @param the Java type that described instances must have
> * @param elementType the open type of element values
> contained
> * in the arrays described by this
> ArrayType
> * instance; must be an instance of either
> @@ -800,7 +801,7 @@
> * TabularType or another
> ArrayType
> * with a SimpleType,
> CompositeType
> * or TabularType as its
> elementType.
> - *
> + * @return an {@code ArrayType} instance
> * @throws OpenDataException if elementType's
> className is not
> * one of the allowed Java class names
> for open
> * data.
> @@ -834,12 +835,14 @@
> * array type description = 3-dimension array of int
> * }
> *
> + * @param the Java type that described instances must have
> * @param arrayClass a primitive array class such as {@code
> int[].class},
> * {@code boolean[][].class}, etc. The {@link
> * #getElementOpenType()} method of the returned
> * {@code ArrayType} returns the {@link
> SimpleType}
> * corresponding to the wrapper type of the
> primitive
> * type of the array.
> + * @return an {@code ArrayType} instance
> *
> * @throws IllegalArgumentException if arrayClass is not
> * a primitive array.
> ---
> old/src/java.management/share/classes/javax/management/timer/Timer.java 2015-04-15
> 19:40:45.397973302 -0700
> +++
> new/src/java.management/share/classes/javax/management/timer/Timer.java 2015-04-15
> 19:40:45.218063297 -0700
> @@ -195,7 +195,7 @@
> *
> * @return The name of the timer MBean registered.
> *
> - * @exception java.lang.Exception
> + * @exception java.lang.Exception if something goes wrong
> */
> public ObjectName preRegister(MBeanServer server, ObjectName name)
> throws java.lang.Exception {
> @@ -217,7 +217,7 @@
> *
> * Stops the timer.
> *
> - * @exception java.lang.Exception
> + * @exception java.lang.Exception if something goes wrong
> */
> public void preDeregister() throws java.lang.Exception {
>
>
From dmitry.samersoff at oracle.com Thu Apr 16 15:59:55 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 16 Apr 2015 18:59:55 +0300
Subject: RFR(S): JDK-8074146 jdb has succeded to read an unreadable file
Message-ID: <552FDC7B.1020902@oracle.com>
Everybody,
Please review:
http://cr.openjdk.java.net/~dsamersoff/JDK-8074146/webrev.01/
With current testing infrastructure it's hard to make file unreadable
on all platforms.
From the other side codepath triggered by file open error is covered by
the case: "Read a directory - verify the read fails"
So I decide to go with the surgery rather than a therapy and cut out
this test case entirely.
-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 erik.gahlin at oracle.com Thu Apr 16 16:30:47 2015
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 16 Apr 2015 18:30:47 +0200
Subject: RFR(S): JDK-8074146 jdb has succeded to read an unreadable file
In-Reply-To: <552FDC7B.1020902@oracle.com>
References: <552FDC7B.1020902@oracle.com>
Message-ID: <552FE3B7.8000103@oracle.com>
Looks good
Erik
Dmitry Samersoff skrev 2015-04-16 17:59:
> Everybody,
>
> Please review:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8074146/webrev.01/
>
> With current testing infrastructure it's hard to make file unreadable
> on all platforms.
>
> From the other side codepath triggered by file open error is covered by
> the case: "Read a directory - verify the read fails"
>
> So I decide to go with the surgery rather than a therapy and cut out
> this test case entirely.
>
> -Dmitry
>
From daniel.daugherty at oracle.com Thu Apr 16 17:01:29 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 16 Apr 2015 11:01:29 -0600
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <552832AF.8080204@oracle.com>
References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com>
Message-ID: <552FEAE9.6020103@oracle.com>
>
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
src/share/vm/classfile/javaClasses.hpp
No comments.
src/share/vm/classfile/javaClasses.cpp
No comments.
src/share/vm/oops/cpCache.hpp
No comments.
src/share/vm/oops/cpCache.cpp
No comments.
src/share/vm/prims/methodHandles.hpp
No comments.
src/share/vm/prims/methodHandles.cpp
Now we get to the meat of the change. :-)
Instead of the double iteration loop in the old code, you
are now taking advantage of the recent 'orig_method_idnum()'
work. So you are not only reducing the iteration count, you
are also reducing the number of adjustment calls that need
to be made. Cool.
src/share/vm/prims/jvmtiRedefineClasses.cpp
No comments.
Thumbs up.
Do you happen to have any info on perf improvements for this
fix? No big deal if you don't.
Dan
On 4/10/15 2:29 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen and Dan,
>
> This is the second class redefinition scalability/optimization fix
> that is in my queue to push into 9 and 8u60.
>
> The approach is similar to the first one but much smaller.
> For convenience, these are the links to the first scalability fix:
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>
> Please, let me know if you have any chance to review this.
> This is the last one that is waiting for your attention! :)
>
> Thanks,
> Serguei
>
> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8073705
>>
>>
>> Open hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>>
>>
>>
>> Summary:
>>
>> This is the 2-nd round of performance/calability fixes in class
>> redefinition.
>> This time, the two remaining issues that were left alone in the
>> first round fix:
>> - optimized ConstantPoolCache::adjust_method_entries() is used
>> for previous versions
>> - the MemberNameTable::adjust_method_entries() has been
>> optimized too
>> - some cleanup
>>
>>
>> Testing:
>> In progress: nsk redefine classes tests, JTREG
>> java/lang/instrument, com/sun/jdi
>>
>>
>> Thanks,
>> Serguei
>>
>
From staffan.larsen at oracle.com Fri Apr 17 06:27:45 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 17 Apr 2015 08:27:45 +0200
Subject: RFR(S): JDK-8074146 jdb has succeded to read an unreadable file
In-Reply-To: <552FDC7B.1020902@oracle.com>
References: <552FDC7B.1020902@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 16 apr 2015, at 17:59, Dmitry Samersoff wrote:
>
> Everybody,
>
> Please review:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8074146/webrev.01/
>
> With current testing infrastructure it's hard to make file unreadable
> on all platforms.
>
> From the other side codepath triggered by file open error is covered by
> the case: "Read a directory - verify the read fails"
>
> So I decide to go with the surgery rather than a therapy and cut out
> this test case entirely.
>
> -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 fredrik.arvidsson at oracle.com Fri Apr 17 07:32:33 2015
From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson)
Date: Fri, 17 Apr 2015 09:32:33 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
Message-ID: <5530B711.2070009@oracle.com>
Hi
We are planning to release an updated version of JEP-158 very soon. The
work to update this JEP has been going on for some time and we now feel
we are ready to present it to a wider audience.
The JEP for JVM Unified Logging was created back in February 2012. The
requirements for the API and implementation were heavily influenced by
the logging functionality in JRockit JVM. The JEP was updated and
refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
https://bugs.openjdk.java.net/browse/JDK-8046148
During the review process of the JEP some concerns were voiced about the
chosen API and functionality but the conclusion was that the proposal
would work, and the JEP was targeted for JDK 9 and the implementation
work was started.
Early 2015 during pre-reviews and presentations of the API and
implementation concerns were again raised about the formulation of the
JEP, this time with greater force. At this point we decided to take a
time-out and investigate our options going forward.
The time-out led to a modified proposal that can be found here:
http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
and with some illustrations here:
http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
So what have we changed, and why?
In short we have switched from using an hierarchical log subject layout
to something that could be best described as a tag based solution.
The main reason for the change of the logging API is that we have found
that some logging can't easily be ordered under a single hierarchical
subject but can belong to multiple subjects/areas. One example of this
is logging in the 'metaspace' code. The functionality in the 'metaspace
area' can be called from both GC and Runtime code. Another example is
class-unloading. There are more examples on this of course, but these
two we think are very clear and easy to understand.
The core functionality of the logging framework is not changed that much
from the earlier proposal. We have tried to make it leaner and not as
verbose (functionality wise) as before. The scope of the implementation
has been narrowed down some to enable us to deliver good value as soon
as possible.
Our plan is as follows:
After getting initial feedback from the community about the new proposal
we will update the JEP description. We aim to do this early next week.
We are planning to use the JDK9 sandbox repository during development.
This enables us who are implementing it to work in an efficient way and
at the same time it allows any interested party to try out and follow
the work during the implementation phase.
More information about the sandbox repository name and other
practicalities will follow shortly.
Cheers
Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
From mattis.castegren at oracle.com Fri Apr 17 07:55:43 2015
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Fri, 17 Apr 2015 00:55:43 -0700 (PDT)
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <5530B711.2070009@oracle.com>
References: <5530B711.2070009@oracle.com>
Message-ID: <132d6a7d-26a7-466a-b567-0cf662a87d0c@default>
Hi
Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like
log("gc,g1,init", )?
Also, will all tags be defined in one file so that you can see which modules exists?
Kind Regards
/Mattis
-----Original Message-----
From: Fredrik Arvidsson
Sent: den 17 april 2015 09:33
To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
Subject: Updates to JEP-158: JVM Unified Logging are coming...
Hi
We are planning to release an updated version of JEP-158 very soon. The
work to update this JEP has been going on for some time and we now feel
we are ready to present it to a wider audience.
The JEP for JVM Unified Logging was created back in February 2012. The
requirements for the API and implementation were heavily influenced by
the logging functionality in JRockit JVM. The JEP was updated and
refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
https://bugs.openjdk.java.net/browse/JDK-8046148
During the review process of the JEP some concerns were voiced about the
chosen API and functionality but the conclusion was that the proposal
would work, and the JEP was targeted for JDK 9 and the implementation
work was started.
Early 2015 during pre-reviews and presentations of the API and
implementation concerns were again raised about the formulation of the
JEP, this time with greater force. At this point we decided to take a
time-out and investigate our options going forward.
The time-out led to a modified proposal that can be found here:
http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
and with some illustrations here:
http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
So what have we changed, and why?
In short we have switched from using an hierarchical log subject layout
to something that could be best described as a tag based solution.
The main reason for the change of the logging API is that we have found
that some logging can't easily be ordered under a single hierarchical
subject but can belong to multiple subjects/areas. One example of this
is logging in the 'metaspace' code. The functionality in the 'metaspace
area' can be called from both GC and Runtime code. Another example is
class-unloading. There are more examples on this of course, but these
two we think are very clear and easy to understand.
The core functionality of the logging framework is not changed that much
from the earlier proposal. We have tried to make it leaner and not as
verbose (functionality wise) as before. The scope of the implementation
has been narrowed down some to enable us to deliver good value as soon
as possible.
Our plan is as follows:
After getting initial feedback from the community about the new proposal
we will update the JEP description. We aim to do this early next week.
We are planning to use the JDK9 sandbox repository during development.
This enables us who are implementing it to work in an efficient way and
at the same time it allows any interested party to try out and follow
the work during the implementation phase.
More information about the sandbox repository name and other
practicalities will follow shortly.
Cheers
Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
From fredrik.arvidsson at oracle.com Fri Apr 17 08:13:44 2015
From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson)
Date: Fri, 17 Apr 2015 10:13:44 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <132d6a7d-26a7-466a-b567-0cf662a87d0c@default>
References: <5530B711.2070009@oracle.com>
<132d6a7d-26a7-466a-b567-0cf662a87d0c@default>
Message-ID: <5530C0B8.5020701@oracle.com>
Hi Mattis
The hierarchical structure is gone. Each log line in the code should
contain all tags related to the message logged.
In your example below the line would be printed just like before since
the log call contains the gc tag.
All tags will be defined in a single source file. The available tags
will just like before be enumerable in runtime.
/Fredrik
On 2015-04-17 09:55, Mattis Castegren wrote:
> Hi
>
> Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like
> log("gc,g1,init", )?
>
> Also, will all tags be defined in one file so that you can see which modules exists?
>
> Kind Regards
> /Mattis
>
> -----Original Message-----
> From: Fredrik Arvidsson
> Sent: den 17 april 2015 09:33
> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
> Subject: Updates to JEP-158: JVM Unified Logging are coming...
>
> Hi
>
> We are planning to release an updated version of JEP-158 very soon. The
> work to update this JEP has been going on for some time and we now feel
> we are ready to present it to a wider audience.
>
> The JEP for JVM Unified Logging was created back in February 2012. The
> requirements for the API and implementation were heavily influenced by
> the logging functionality in JRockit JVM. The JEP was updated and
> refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
> https://bugs.openjdk.java.net/browse/JDK-8046148
>
> During the review process of the JEP some concerns were voiced about the
> chosen API and functionality but the conclusion was that the proposal
> would work, and the JEP was targeted for JDK 9 and the implementation
> work was started.
>
> Early 2015 during pre-reviews and presentations of the API and
> implementation concerns were again raised about the formulation of the
> JEP, this time with greater force. At this point we decided to take a
> time-out and investigate our options going forward.
>
> The time-out led to a modified proposal that can be found here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
> and with some illustrations here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>
> So what have we changed, and why?
> In short we have switched from using an hierarchical log subject layout
> to something that could be best described as a tag based solution.
>
> The main reason for the change of the logging API is that we have found
> that some logging can't easily be ordered under a single hierarchical
> subject but can belong to multiple subjects/areas. One example of this
> is logging in the 'metaspace' code. The functionality in the 'metaspace
> area' can be called from both GC and Runtime code. Another example is
> class-unloading. There are more examples on this of course, but these
> two we think are very clear and easy to understand.
>
> The core functionality of the logging framework is not changed that much
> from the earlier proposal. We have tried to make it leaner and not as
> verbose (functionality wise) as before. The scope of the implementation
> has been narrowed down some to enable us to deliver good value as soon
> as possible.
>
> Our plan is as follows:
> After getting initial feedback from the community about the new proposal
> we will update the JEP description. We aim to do this early next week.
> We are planning to use the JDK9 sandbox repository during development.
> This enables us who are implementing it to work in an efficient way and
> at the same time it allows any interested party to try out and follow
> the work during the implementation phase.
>
> More information about the sandbox repository name and other
> practicalities will follow shortly.
>
> Cheers
> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
From mattis.castegren at oracle.com Fri Apr 17 08:27:53 2015
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Fri, 17 Apr 2015 01:27:53 -0700 (PDT)
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <5530C0B8.5020701@oracle.com>
References: <5530B711.2070009@oracle.com>
<132d6a7d-26a7-466a-b567-0cf662a87d0c@default>
<5530C0B8.5020701@oracle.com>
Message-ID: <26421508-9c07-45e5-a109-1b148272c862@default>
Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc.
If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like
log ("gc,g1,g1_init", ...)
If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..."
Kind Regards
/Mattis
-----Original Message-----
From: Fredrik Arvidsson
Sent: den 17 april 2015 10:14
To: Mattis Castegren; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
Subject: Re: Updates to JEP-158: JVM Unified Logging are coming...
Hi Mattis
The hierarchical structure is gone. Each log line in the code should
contain all tags related to the message logged.
In your example below the line would be printed just like before since
the log call contains the gc tag.
All tags will be defined in a single source file. The available tags
will just like before be enumerable in runtime.
/Fredrik
On 2015-04-17 09:55, Mattis Castegren wrote:
> Hi
>
> Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like
> log("gc,g1,init", )?
>
> Also, will all tags be defined in one file so that you can see which modules exists?
>
> Kind Regards
> /Mattis
>
> -----Original Message-----
> From: Fredrik Arvidsson
> Sent: den 17 april 2015 09:33
> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
> Subject: Updates to JEP-158: JVM Unified Logging are coming...
>
> Hi
>
> We are planning to release an updated version of JEP-158 very soon. The
> work to update this JEP has been going on for some time and we now feel
> we are ready to present it to a wider audience.
>
> The JEP for JVM Unified Logging was created back in February 2012. The
> requirements for the API and implementation were heavily influenced by
> the logging functionality in JRockit JVM. The JEP was updated and
> refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
> https://bugs.openjdk.java.net/browse/JDK-8046148
>
> During the review process of the JEP some concerns were voiced about the
> chosen API and functionality but the conclusion was that the proposal
> would work, and the JEP was targeted for JDK 9 and the implementation
> work was started.
>
> Early 2015 during pre-reviews and presentations of the API and
> implementation concerns were again raised about the formulation of the
> JEP, this time with greater force. At this point we decided to take a
> time-out and investigate our options going forward.
>
> The time-out led to a modified proposal that can be found here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
> and with some illustrations here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>
> So what have we changed, and why?
> In short we have switched from using an hierarchical log subject layout
> to something that could be best described as a tag based solution.
>
> The main reason for the change of the logging API is that we have found
> that some logging can't easily be ordered under a single hierarchical
> subject but can belong to multiple subjects/areas. One example of this
> is logging in the 'metaspace' code. The functionality in the 'metaspace
> area' can be called from both GC and Runtime code. Another example is
> class-unloading. There are more examples on this of course, but these
> two we think are very clear and easy to understand.
>
> The core functionality of the logging framework is not changed that much
> from the earlier proposal. We have tried to make it leaner and not as
> verbose (functionality wise) as before. The scope of the implementation
> has been narrowed down some to enable us to deliver good value as soon
> as possible.
>
> Our plan is as follows:
> After getting initial feedback from the community about the new proposal
> we will update the JEP description. We aim to do this early next week.
> We are planning to use the JDK9 sandbox repository during development.
> This enables us who are implementing it to work in an efficient way and
> at the same time it allows any interested party to try out and follow
> the work during the implementation phase.
>
> More information about the sandbox repository name and other
> practicalities will follow shortly.
>
> Cheers
> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
From fredrik.arvidsson at oracle.com Fri Apr 17 09:29:58 2015
From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson)
Date: Fri, 17 Apr 2015 11:29:58 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <26421508-9c07-45e5-a109-1b148272c862@default>
References: <5530B711.2070009@oracle.com>
<132d6a7d-26a7-466a-b567-0cf662a87d0c@default>
<5530C0B8.5020701@oracle.com>
<26421508-9c07-45e5-a109-1b148272c862@default>
Message-ID: <5530D296.9000408@oracle.com>
Hi
Ill try to reply in-line below.
On 2015-04-17 10:27, Mattis Castegren wrote:
> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc.
Of course there is a risk that people would forget to add a tag. But I
can't see that this risk is very high. Logging code has to be put
through code review just like any other change and we just have to pay
extra attention to this in the beginning i guess. Using the hierarchical
scheme there is also a risk that the logging topic is set to the wrong one.
There are no recommendations right now on what tags to create or use in
the logging code. We will work with all groups trying to establish some
guidelines I guess to have tag names consistent.
If we see a real need to have 'meta-tags' consisting of several other
tags we could introduce something like that I'm sure, but this is just
something we have discussed briefly.
There will also be a way to list all existing 'tag combinations' used in
the code in runtime. This could maybe be used to spot the ones that are
potentially wrong?
> If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like
>
> log ("gc,g1,g1_init", ...)
>
> If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..."
Yes, this would be the way to handle missed tags in the code. I can't
see that there is another way really :(
Cheers
/Fredrik
> Kind Regards
> /Mattis
>
> -----Original Message-----
> From: Fredrik Arvidsson
> Sent: den 17 april 2015 10:14
> To: Mattis Castegren; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
> Subject: Re: Updates to JEP-158: JVM Unified Logging are coming...
>
> Hi Mattis
>
> The hierarchical structure is gone. Each log line in the code should
> contain all tags related to the message logged.
> In your example below the line would be printed just like before since
> the log call contains the gc tag.
>
> All tags will be defined in a single source file. The available tags
> will just like before be enumerable in runtime.
>
> /Fredrik
>
> On 2015-04-17 09:55, Mattis Castegren wrote:
>> Hi
>>
>> Is the hierarchical thought completely gone, or can one tag be a "sub set" of another? Previously, you had the example of a logging module gc_g1_init. If you add some "g1" logging, would that also be printed is someone runs with Xverbose:gc? Or would the log message need to include all tags, like
>> log("gc,g1,init", )?
>>
>> Also, will all tags be defined in one file so that you can see which modules exists?
>>
>> Kind Regards
>> /Mattis
>>
>> -----Original Message-----
>> From: Fredrik Arvidsson
>> Sent: den 17 april 2015 09:33
>> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
>> Subject: Updates to JEP-158: JVM Unified Logging are coming...
>>
>> Hi
>>
>> We are planning to release an updated version of JEP-158 very soon. The
>> work to update this JEP has been going on for some time and we now feel
>> we are ready to present it to a wider audience.
>>
>> The JEP for JVM Unified Logging was created back in February 2012. The
>> requirements for the API and implementation were heavily influenced by
>> the logging functionality in JRockit JVM. The JEP was updated and
>> refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
>> https://bugs.openjdk.java.net/browse/JDK-8046148
>>
>> During the review process of the JEP some concerns were voiced about the
>> chosen API and functionality but the conclusion was that the proposal
>> would work, and the JEP was targeted for JDK 9 and the implementation
>> work was started.
>>
>> Early 2015 during pre-reviews and presentations of the API and
>> implementation concerns were again raised about the formulation of the
>> JEP, this time with greater force. At this point we decided to take a
>> time-out and investigate our options going forward.
>>
>> The time-out led to a modified proposal that can be found here:
>> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
>> and with some illustrations here:
>> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>>
>> So what have we changed, and why?
>> In short we have switched from using an hierarchical log subject layout
>> to something that could be best described as a tag based solution.
>>
>> The main reason for the change of the logging API is that we have found
>> that some logging can't easily be ordered under a single hierarchical
>> subject but can belong to multiple subjects/areas. One example of this
>> is logging in the 'metaspace' code. The functionality in the 'metaspace
>> area' can be called from both GC and Runtime code. Another example is
>> class-unloading. There are more examples on this of course, but these
>> two we think are very clear and easy to understand.
>>
>> The core functionality of the logging framework is not changed that much
>> from the earlier proposal. We have tried to make it leaner and not as
>> verbose (functionality wise) as before. The scope of the implementation
>> has been narrowed down some to enable us to deliver good value as soon
>> as possible.
>>
>> Our plan is as follows:
>> After getting initial feedback from the community about the new proposal
>> we will update the JEP description. We aim to do this early next week.
>> We are planning to use the JDK9 sandbox repository during development.
>> This enables us who are implementing it to work in an efficient way and
>> at the same time it allows any interested party to try out and follow
>> the work during the implementation phase.
>>
>> More information about the sandbox repository name and other
>> practicalities will follow shortly.
>>
>> Cheers
>> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
From martijnverburg at gmail.com Fri Apr 17 10:12:55 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 17 Apr 2015 12:12:55 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <5530B711.2070009@oracle.com>
References: <5530B711.2070009@oracle.com>
Message-ID:
Hi Fredrik,
Thanks from us (jClarity and some other orgs) for considering the tag based
system, we're really glad you've gone in this direction. One quick bit of
feedback.
Is it possible to add a binary / compressed logging format or an interface/
API to plug one in for high performance Logging? Human readable is nice
for looking at logs immediately, but for some of our customers they'd be
looking to offload that concern to another process/host.
Cheers,
Martijn
On 17 April 2015 at 09:32, Fredrik Arvidsson
wrote:
> Hi
>
> We are planning to release an updated version of JEP-158 very soon. The
> work to update this JEP has been going on for some time and we now feel we
> are ready to present it to a wider audience.
>
> The JEP for JVM Unified Logging was created back in February 2012. The
> requirements for the API and implementation were heavily influenced by the
> logging functionality in JRockit JVM. The JEP was updated and refined in
> mid 2014 and eventually targeted for JDK 9 in late 2014:
> https://bugs.openjdk.java.net/browse/JDK-8046148
>
> During the review process of the JEP some concerns were voiced about the
> chosen API and functionality but the conclusion was that the proposal would
> work, and the JEP was targeted for JDK 9 and the implementation work was
> started.
>
> Early 2015 during pre-reviews and presentations of the API and
> implementation concerns were again raised about the formulation of the JEP,
> this time with greater force. At this point we decided to take a time-out
> and investigate our options going forward.
>
> The time-out led to a modified proposal that can be found here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
> and with some illustrations here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>
> So what have we changed, and why?
> In short we have switched from using an hierarchical log subject layout to
> something that could be best described as a tag based solution.
>
> The main reason for the change of the logging API is that we have found
> that some logging can't easily be ordered under a single hierarchical
> subject but can belong to multiple subjects/areas. One example of this is
> logging in the 'metaspace' code. The functionality in the 'metaspace area'
> can be called from both GC and Runtime code. Another example is
> class-unloading. There are more examples on this of course, but these two
> we think are very clear and easy to understand.
>
> The core functionality of the logging framework is not changed that much
> from the earlier proposal. We have tried to make it leaner and not as
> verbose (functionality wise) as before. The scope of the implementation has
> been narrowed down some to enable us to deliver good value as soon as
> possible.
>
> Our plan is as follows:
> After getting initial feedback from the community about the new proposal
> we will update the JEP description. We aim to do this early next week.
> We are planning to use the JDK9 sandbox repository during development.
> This enables us who are implementing it to work in an efficient way and at
> the same time it allows any interested party to try out and follow the work
> during the implementation phase.
>
> More information about the sandbox repository name and other
> practicalities will follow shortly.
>
> Cheers
> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fredrik.arvidsson at oracle.com Fri Apr 17 12:36:05 2015
From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson)
Date: Fri, 17 Apr 2015 14:36:05 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To:
References: <5530B711.2070009@oracle.com>
Message-ID: <5530FE35.3010107@oracle.com>
Hi Martijn, and the others :)
I'm glad you like what we do. We also think the tag based logging is
something good, and that it will make the logging in the JVM easier to
implement, configure and consume.
Regarding 'binary / compressed' log format. We are not planning to add
any structured log format to the unified logging framework. It is
outside the scope of this JEP. The log data format is a simple string
with some well defined decorations. The logs are primarily meant to be
read by humans.
There will be log output extension points in the framework, but they
will not be accessible publicly and they will not support 3rd party
extensions in runtime. Even if the output extension API would be made
fully accessible, the data fed in to it would still only be a string,
since thats what the developers are adding in the code where the logging
framework is called. I guess one could add compression of log data as an
extension, but I don't think that is really what you are asking for.
As you might know, Oracle offers low latency low intrusive structured
logging in its Java Flight Recorder product. We are not aiming in this
JEP to overlap that functionality more than absolutely needed.
Cheers
/Fredrik
On 2015-04-17 12:12, Martijn Verburg wrote:
> Hi Fredrik,
>
> Thanks from us (jClarity and some other orgs) for considering the tag
> based system, we're really glad you've gone in this direction. One
> quick bit of feedback.
>
> Is it possible to add a binary / compressed logging format or an
> interface/ API to plug one in for high performance Logging? Human
> readable is nice for looking at logs immediately, but for some of our
> customers they'd be looking to offload that concern to another
> process/host.
>
> Cheers,
> Martijn
>
> On 17 April 2015 at 09:32, Fredrik Arvidsson
> >
> wrote:
>
> Hi
>
> We are planning to release an updated version of JEP-158 very
> soon. The work to update this JEP has been going on for some time
> and we now feel we are ready to present it to a wider audience.
>
> The JEP for JVM Unified Logging was created back in February 2012.
> The requirements for the API and implementation were heavily
> influenced by the logging functionality in JRockit JVM. The JEP
> was updated and refined in mid 2014 and eventually targeted for
> JDK 9 in late 2014:
> https://bugs.openjdk.java.net/browse/JDK-8046148
>
> During the review process of the JEP some concerns were voiced
> about the chosen API and functionality but the conclusion was that
> the proposal would work, and the JEP was targeted for JDK 9 and
> the implementation work was started.
>
> Early 2015 during pre-reviews and presentations of the API and
> implementation concerns were again raised about the formulation of
> the JEP, this time with greater force. At this point we decided to
> take a time-out and investigate our options going forward.
>
> The time-out led to a modified proposal that can be found here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
>
> and with some illustrations here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>
>
> So what have we changed, and why?
> In short we have switched from using an hierarchical log subject
> layout to something that could be best described as a tag based
> solution.
>
> The main reason for the change of the logging API is that we have
> found that some logging can't easily be ordered under a single
> hierarchical subject but can belong to multiple subjects/areas.
> One example of this is logging in the 'metaspace' code. The
> functionality in the 'metaspace area' can be called from both GC
> and Runtime code. Another example is class-unloading. There are
> more examples on this of course, but these two we think are very
> clear and easy to understand.
>
> The core functionality of the logging framework is not changed
> that much from the earlier proposal. We have tried to make it
> leaner and not as verbose (functionality wise) as before. The
> scope of the implementation has been narrowed down some to enable
> us to deliver good value as soon as possible.
>
> Our plan is as follows:
> After getting initial feedback from the community about the new
> proposal we will update the JEP description. We aim to do this
> early next week.
> We are planning to use the JDK9 sandbox repository during
> development. This enables us who are implementing it to work in an
> efficient way and at the same time it allows any interested party
> to try out and follow the work during the implementation phase.
>
> More information about the sandbox repository name and other
> practicalities will follow shortly.
>
> Cheers
> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mattis.castegren at oracle.com Fri Apr 17 13:16:32 2015
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Fri, 17 Apr 2015 06:16:32 -0700 (PDT)
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <5530FE35.3010107@oracle.com>
References: <5530B711.2070009@oracle.com>
<5530FE35.3010107@oracle.com>
Message-ID:
I guess it would be a possible later enhancement request to add a new logging tag ?gc_compressed? for example that prints gc output in some easy to parse format. It could be one line of comma separated values per GC for example that you could import to other tools.
?
But I agree with Fredrik, we should look at exactly what problems you try to solve, and see if it instead can be solved in JFR. You could make a recording that only gathers GC data, and you could run it for days and still get a pretty small recording (at least smaller than what a corresponding gc log would be). If you then still feel the need to import the data to some other tool, maybe we should add that tool?s functionality to Mission Control?
?
Kind Regards
/Mattis
?
From: Fredrik Arvidsson
Sent: den 17 april 2015 14:36
To: Martijn Verburg
Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
Subject: Re: Updates to JEP-158: JVM Unified Logging are coming...
?
Hi Martijn, and the others :)
I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume.
Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans.
There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for.
As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed.
Cheers
/Fredrik
On 2015-04-17 12:12, Martijn Verburg wrote:
Hi Fredrik,
?
Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction.? One quick bit of feedback.
?
Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging?? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host.
Cheers,
Martijn
?
On 17 April 2015 at 09:32, Fredrik Arvidsson wrote:
Hi
We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience.
The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
https://bugs.openjdk.java.net/browse/JDK-8046148
During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started.
Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward.
The time-out led to a modified proposal that can be found here:
HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158.html" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
and with some illustrations here:
HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158_Illustration.png" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
So what have we changed, and why?
In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution.
The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand.
The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible.
Our plan is as follows:
After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week.
We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase.
More information about the sandbox repository name and other practicalities will follow shortly.
Cheers
Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From roland.westrelin at oracle.com Fri Apr 17 14:35:18 2015
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 17 Apr 2015 16:35:18 +0200
Subject: RFR(S): 8077832: SA's dumpreplaydata,
dumpcfg and buildreplayjars are broken
In-Reply-To: <552E9EB1.6070607@oracle.com>
References:
<552E9EB1.6070607@oracle.com>
Message-ID:
Thanks for the reviews, Vladimir, Dmitry and Staffan.
Roland.
From serguei.spitsyn at oracle.com Fri Apr 17 20:04:54 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 17 Apr 2015 13:04:54 -0700
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <552FEAE9.6020103@oracle.com>
References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com>
<552FEAE9.6020103@oracle.com>
Message-ID: <55316766.6080901@oracle.com>
On 4/16/15 10:01 AM, Daniel D. Daugherty wrote:
> >
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>
>
> src/share/vm/classfile/javaClasses.hpp
> No comments.
>
> src/share/vm/classfile/javaClasses.cpp
> No comments.
>
> src/share/vm/oops/cpCache.hpp
> No comments.
>
> src/share/vm/oops/cpCache.cpp
> No comments.
>
> src/share/vm/prims/methodHandles.hpp
> No comments.
>
> src/share/vm/prims/methodHandles.cpp
> Now we get to the meat of the change. :-)
>
> Instead of the double iteration loop in the old code, you
> are now taking advantage of the recent 'orig_method_idnum()'
> work. So you are not only reducing the iteration count, you
> are also reducing the number of adjustment calls that need
> to be made. Cool.
Thanks!
>
> src/share/vm/prims/jvmtiRedefineClasses.cpp
> No comments.
>
>
> Thumbs up.
Thanks for the review!
>
> Do you happen to have any info on perf improvements for this
> fix? No big deal if you don't.
I do not have any info on perf improvements for this fix.
The plan is to ask EM team to check if they still have any scalability
issues after both fixes
and see what are the improvements. They report that class
retransformations in the EM
take tens of minutes.
Thanks,
Serguei
>
> Dan
>
>
> On 4/10/15 2:29 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Coleen and Dan,
>>
>> This is the second class redefinition scalability/optimization fix
>> that is in my queue to push into 9 and 8u60.
>>
>> The approach is similar to the first one but much smaller.
>> For convenience, these are the links to the first scalability fix:
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>>
>> Please, let me know if you have any chance to review this.
>> This is the last one that is waiting for your attention! :)
>>
>> Thanks,
>> Serguei
>>
>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8073705
>>>
>>>
>>> Open hotspot webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>>>
>>>
>>>
>>> Summary:
>>>
>>> This is the 2-nd round of performance/calability fixes in class
>>> redefinition.
>>> This time, the two remaining issues that were left alone in the
>>> first round fix:
>>> - optimized ConstantPoolCache::adjust_method_entries() is used
>>> for previous versions
>>> - the MemberNameTable::adjust_method_entries() has been
>>> optimized too
>>> - some cleanup
>>>
>>>
>>> Testing:
>>> In progress: nsk redefine classes tests, JTREG
>>> java/lang/instrument, com/sun/jdi
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>
>
From kirk at kodewerk.com Fri Apr 17 20:34:16 2015
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 17 Apr 2015 22:34:16 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To:
References: <5530B711.2070009@oracle.com>
<5530FE35.3010107@oracle.com>
Message-ID: <3C32C2F5-68F1-4B55-80FD-C62D98A6A996@kodewerk.com>
Hi All,
I?m very happy for a digital solution. As for solving problems in JFR.. great but that is a commercial solution and thus doesn?t work for OpenJDK. Remember? Plus, with all due respect for JFR, not all of us agree that this is the best way to sort out performance issues ;-)
Regards,
Kirk
On Apr 17, 2015, at 3:16 PM, Mattis Castegren wrote:
> I guess it would be a possible later enhancement request to add a new logging tag ?gc_compressed? for example that prints gc output in some easy to parse format. It could be one line of comma separated values per GC for example that you could import to other tools.
>
>
>
> But I agree with Fredrik, we should look at exactly what problems you try to solve, and see if it instead can be solved in JFR. You could make a recording that only gathers GC data, and you could run it for days and still get a pretty small recording (at least smaller than what a corresponding gc log would be). If you then still feel the need to import the data to some other tool, maybe we should add that tool?s functionality to Mission Control?
>
>
>
> Kind Regards
>
> /Mattis
>
>
>
> From: Fredrik Arvidsson
> Sent: den 17 april 2015 14:36
> To: Martijn Verburg
> Cc: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Source Developers
> Subject: Re: Updates to JEP-158: JVM Unified Logging are coming...
>
>
>
> Hi Martijn, and the others :)
>
> I'm glad you like what we do. We also think the tag based logging is something good, and that it will make the logging in the JVM easier to implement, configure and consume.
>
> Regarding 'binary / compressed' log format. We are not planning to add any structured log format to the unified logging framework. It is outside the scope of this JEP. The log data format is a simple string with some well defined decorations. The logs are primarily meant to be read by humans.
>
> There will be log output extension points in the framework, but they will not be accessible publicly and they will not support 3rd party extensions in runtime. Even if the output extension API would be made fully accessible, the data fed in to it would still only be a string, since thats what the developers are adding in the code where the logging framework is called. I guess one could add compression of log data as an extension, but I don't think that is really what you are asking for.
>
> As you might know, Oracle offers low latency low intrusive structured logging in its Java Flight Recorder product. We are not aiming in this JEP to overlap that functionality more than absolutely needed.
>
> Cheers
> /Fredrik
>
> On 2015-04-17 12:12, Martijn Verburg wrote:
>
> Hi Fredrik,
>
>
>
> Thanks from us (jClarity and some other orgs) for considering the tag based system, we're really glad you've gone in this direction. One quick bit of feedback.
>
>
>
> Is it possible to add a binary / compressed logging format or an interface/ API to plug one in for high performance Logging? Human readable is nice for looking at logs immediately, but for some of our customers they'd be looking to offload that concern to another process/host.
>
>
>
>
> Cheers,
> Martijn
>
>
>
> On 17 April 2015 at 09:32, Fredrik Arvidsson wrote:
>
> Hi
>
> We are planning to release an updated version of JEP-158 very soon. The work to update this JEP has been going on for some time and we now feel we are ready to present it to a wider audience.
>
> The JEP for JVM Unified Logging was created back in February 2012. The requirements for the API and implementation were heavily influenced by the logging functionality in JRockit JVM. The JEP was updated and refined in mid 2014 and eventually targeted for JDK 9 in late 2014:
> https://bugs.openjdk.java.net/browse/JDK-8046148
>
> During the review process of the JEP some concerns were voiced about the chosen API and functionality but the conclusion was that the proposal would work, and the JEP was targeted for JDK 9 and the implementation work was started.
>
> Early 2015 during pre-reviews and presentations of the API and implementation concerns were again raised about the formulation of the JEP, this time with greater force. At this point we decided to take a time-out and investigate our options going forward.
>
> The time-out led to a modified proposal that can be found here:
> HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158.html" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
> and with some illustrations here:
> HYPERLINK "http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158_Illustration.png" \nhttp://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>
> So what have we changed, and why?
> In short we have switched from using an hierarchical log subject layout to something that could be best described as a tag based solution.
>
> The main reason for the change of the logging API is that we have found that some logging can't easily be ordered under a single hierarchical subject but can belong to multiple subjects/areas. One example of this is logging in the 'metaspace' code. The functionality in the 'metaspace area' can be called from both GC and Runtime code. Another example is class-unloading. There are more examples on this of course, but these two we think are very clear and easy to understand.
>
> The core functionality of the logging framework is not changed that much from the earlier proposal. We have tried to make it leaner and not as verbose (functionality wise) as before. The scope of the implementation has been narrowed down some to enable us to deliver good value as soon as possible.
>
> Our plan is as follows:
> After getting initial feedback from the community about the new proposal we will update the JEP description. We aim to do this early next week.
> We are planning to use the JDK9 sandbox repository during development. This enables us who are implementing it to work in an efficient way and at the same time it allows any interested party to try out and follow the work during the implementation phase.
>
> More information about the sandbox repository name and other practicalities will follow shortly.
>
> Cheers
> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From kirk at kodewerk.com Fri Apr 17 20:40:15 2015
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 17 Apr 2015 22:40:15 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <5530D296.9000408@oracle.com>
References: <5530B711.2070009@oracle.com>
<132d6a7d-26a7-466a-b567-0cf662a87d0c@default>
<5530C0B8.5020701@oracle.com>
<26421508-9c07-45e5-a109-1b148272c862@default>
<5530D296.9000408@oracle.com>
Message-ID:
On Apr 17, 2015, at 11:29 AM, Fredrik Arvidsson wrote:
> Hi
> Ill try to reply in-line below.
>
> On 2015-04-17 10:27, Mattis Castegren wrote:
>> Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1, it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining, that could lead to us having to use long verbose lines in order to get everything. This is something we had in older versions of JRockit, where you had your "favorite" verbose line that included tons of modules, like gc, yc, pausetime, compaction etc.
> Of course there is a risk that people would forget to add a tag. But I can't see that this risk is very high. Logging code has to be put through code review just like any other change and we just have to pay extra attention to this in the beginning i guess. Using the hierarchical scheme there is also a risk that the logging topic is set to the wrong one.
Indeed!
>
> There are no recommendations right now on what tags to create or use in the logging code. We will work with all groups trying to establish some guidelines I guess to have tag names consistent.
My recommendation to teams has always been to give architectural guidelines or use requirements from operations to define logging. If you leave logging to dev it?s generally useful for dev and no one else.
>
> If we see a real need to have 'meta-tags' consisting of several other tags we could introduce something like that I'm sure, but this is just something we have discussed briefly.
JMS has a spec for managing this type of behavior.
>
> There will also be a way to list all existing 'tag combinations' used in the code in runtime. This could maybe be used to spot the ones that are potentially wrong?
>> If the recommendation is to ALWAYS include "gc" if you log something to "g1", wouldn't it make sense to make "g1" a subset of "gc"? Otherwise you would have to copy boilerplate code to include all the tags in your current area, like
>>
>> log ("gc,g1,g1_init", ...)
>>
>> If you forget it in one place, and we want to gather full information from a run, we would have to ask customers to run with "Xverbose:gc,g1,g1_init,g1_other_module,..."
> Yes, this would be the way to handle missed tags in the code. I can't see that there is another way really :(
Make them manageable so if you forget on the command line you can change them on the fly.
Regards,
Kirk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From thomas.stuefe at gmail.com Sat Apr 18 18:02:45 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 18 Apr 2015 20:02:45 +0200
Subject: Updates to JEP-158: JVM Unified Logging are coming...
In-Reply-To: <5530B711.2070009@oracle.com>
References: <5530B711.2070009@oracle.com>
Message-ID:
Hi Frederik,
I like this proposal a lot, especially the abandonment of a hierarchical
structure in favor of tags. In the SAPJVM we have a tracing system in many
details similar to the one proposed here. We will be probably abandon it
and switch to the official logging system once it is implemented in the
OpenJDK.
Some questions/remarks:
1 Will logging be available from native JDK code too, not only from within
the hotspot?
2 Will there a way to cover early logging? One common problem is logging
during initialization time of the VM, and there is always the problem
whether logging system is already initialized ("I don't see my trace - did
I just not hit it or was logging not up yet?"). Would be very nice if this
problem were covered, e.g. by capturing output in-memory and writing it out
delayed once logging subsystem is up.
3 A similar problem is that logging should use as little VM infrastructure
as possible, to make it possible to use it from all VM code.
If you agree with (2) and (3), it may make sense to add some explicit
requirements to the JEP.
4 "Stretch Goal: Ability to configure in which order decorations should be
printed"
In our tracing system we also have decorations, and we even added a feature
to give the user the ability to format it itself, by adding a format-string
like feature (-XtraceFormat="blabla @PID @TID @USER"). This looked like a
neat idea, but we found in practice over the years that this feature was
very rarely used. So maybe this stretch goal is not needed.
5 Would be nice to have short alternative names for the decorators, maybe
even single letters
6 "The different log levels should have guidelines that define the expected
performance overhead for the level. " It also may make sense to add guide
lines for the expected verbosity of log levels, either in terms of
datasize/time or messages/time.
I look forward to this logging system in practice!
Kind Regards, Thomas
On Fri, Apr 17, 2015 at 9:32 AM, Fredrik Arvidsson <
fredrik.arvidsson at oracle.com> wrote:
> Hi
>
> We are planning to release an updated version of JEP-158 very soon. The
> work to update this JEP has been going on for some time and we now feel we
> are ready to present it to a wider audience.
>
> The JEP for JVM Unified Logging was created back in February 2012. The
> requirements for the API and implementation were heavily influenced by the
> logging functionality in JRockit JVM. The JEP was updated and refined in
> mid 2014 and eventually targeted for JDK 9 in late 2014:
> https://bugs.openjdk.java.net/browse/JDK-8046148
>
> During the review process of the JEP some concerns were voiced about the
> chosen API and functionality but the conclusion was that the proposal would
> work, and the JEP was targeted for JDK 9 and the implementation work was
> started.
>
> Early 2015 during pre-reviews and presentations of the API and
> implementation concerns were again raised about the formulation of the JEP,
> this time with greater force. At this point we decided to take a time-out
> and investigate our options going forward.
>
> The time-out led to a modified proposal that can be found here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
> and with some illustrations here:
> http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
>
> So what have we changed, and why?
> In short we have switched from using an hierarchical log subject layout to
> something that could be best described as a tag based solution.
>
> The main reason for the change of the logging API is that we have found
> that some logging can't easily be ordered under a single hierarchical
> subject but can belong to multiple subjects/areas. One example of this is
> logging in the 'metaspace' code. The functionality in the 'metaspace area'
> can be called from both GC and Runtime code. Another example is
> class-unloading. There are more examples on this of course, but these two
> we think are very clear and easy to understand.
>
> The core functionality of the logging framework is not changed that much
> from the earlier proposal. We have tried to make it leaner and not as
> verbose (functionality wise) as before. The scope of the implementation has
> been narrowed down some to enable us to deliver good value as soon as
> possible.
>
> Our plan is as follows:
> After getting initial feedback from the community about the new proposal
> we will update the JEP description. We aim to do this early next week.
> We are planning to use the JDK9 sandbox repository during development.
> This enables us who are implementing it to work in an efficient way and at
> the same time it allows any interested party to try out and follow the work
> during the implementation phase.
>
> More information about the sandbox repository name and other
> practicalities will follow shortly.
>
> Cheers
> Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From yasuenag at gmail.com Mon Apr 20 13:53:19 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 20 Apr 2015 22:53:19 +0900
Subject: PING: RFR: JDK-8072913: [REDO] GCCause should distinguish jcmd GC.run
from System.gc()
In-Reply-To: <55003F77.80606@gmail.com>
References: <54DB6113.4080104@gmail.com> <54DDEF20.6010501@oracle.com>
<54DF4956.7030709@gmail.com> <55003F77.80606@gmail.com>
Message-ID: <553504CF.8080904@gmail.com>
Hi all,
I've uploaded webrev for this enhancement.
Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/
Thanks,
Yasumasa
On 2015/03/11 22:13, Yasumasa Suenaga wrote:
> Hi all,
>
>> So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run
>> to it.
>
> I've uploaded new webrev, and I've applied it to new patch.
> Could you review it?
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.01/
>
> I also updated jtreg testcase.
> It works fine in my environment.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2015/02/14 22:10, Yasumasa Suenaga wrote:
>> Hi Mikael,
>>
>>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run
>>
>> Can I add _dcmd_gc_run to GCCause::is_user_requested_gc() ?
>> This function is used with GCCause::is_serviceability_requested_gc() .
>> CMSCollector::is_external_interruption() and AdaptiveSizePolicy::check_gc_overhead_limit()
>>
>> is_user_requested_gc() and is_serviceability_requested_gc() checkes _jvmti_force_gc
>> is selected.
>> So I think we can remove _jvmti_force_gc from is_user_requested_gc() and add _dcmd_gc_run
>> to it.
>>
>>> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary.
>>
>> We can use GCCause::is_user_requested_gc() if the proposal in above is accepted.
>>
>>
>> Thanks
>>
>> Yasumasa
>>
>>
>>
>> On 2015/02/13 21:33, Mikael Gerdin wrote:
>>> Hi Yasumasa,
>>>
>>> On 2015-02-11 15:02, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> I've committed JDK-8068589 to add new GCCause - Diagnostic Command.
>>>> However, it has been backouted because test is failed [1] and it is not considered
>>>> about concurrent GC: -XX:+ExplicitGCInvokesConcurrent [2].
>>>>
>>>> I've created patch for this enhancement.
>>>> Could you review it?
>>>>
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8072913/webrev.00/
>>>
>>> I'd prefer if you could add a GCCause::is_system_gc_equivalent() which returns true for some set of GCCause enum values, such as _java_lang_system_gc and _dcmd_gc_run
>>>
>>> Given that the documentation of the GC.run command is:
>>> "GC.run
>>> Call java.lang.System.gc().
>>>
>>> Impact: Medium: Depends on Java heap size and content.
>>>
>>> Syntax: GC.run"
>>>
>>> I interpret the documentation that the GC is supposed to be (for all intents and purposes) equivalent to the application invoking System.gc().
>>>
>>> This would also require updates to other places where we refer to the _java_lang_system_gc GCCause, such as UseAdaptiveSizePolicyWithSystemGC
>>>
>>> A "grep" for _java_lang_system_gc should yield more places where updates may be necessary.
>>>
>>> /Mikael
>>>
>>>>
>>>>
>>>> I'm jdk9 committer, but I'm not employee at Oracle.
>>>> So I need a Sponsor.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011957.html
>>>> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-February/011962.html
>>>>
From joe.darcy at oracle.com Mon Apr 20 16:49:33 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 20 Apr 2015 09:49:33 -0700
Subject: JDK 9 RFR of JDK-8077952:
sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
should be quarantined
Message-ID: <55352E1D.8050608@oracle.com>
Hello,
As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
has been failing for several days across platforms, I think the time has
come to mark the test as ignored until the full fix for related bug
JDK-8077924:
sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start failing
after JDK-8076221
can be developed.
Patch below.
Thanks,
-Joe
diff -r 9b63a16654d5
test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
--- a/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Thu
Apr 16 11:33:59 2015 -0700
+++ b/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Mon
Apr 20 09:47:52 2015 -0700
@@ -29,6 +29,7 @@
# @library /lib/testlibrary
# @build jdk.testlibrary.* TestLogger Utils RmiBootstrapTest
# @run shell/timeout=300 RmiSslBootstrapTest.sh
+# @ignore 8077924
# Define the Java class test name
TESTCLASS="RmiBootstrapTest"
From jaroslav.bachorik at oracle.com Mon Apr 20 17:25:32 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 20 Apr 2015 19:25:32 +0200
Subject: JDK 9 RFR of JDK-8077952:
sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
should be quarantined
In-Reply-To: <55352E1D.8050608@oracle.com>
References: <55352E1D.8050608@oracle.com>
Message-ID: <5535368C.9060106@oracle.com>
Looks good!
-JB-
On 20.4.2015 18:49, joe darcy wrote:
> Hello,
>
> As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
> has been failing for several days across platforms, I think the time has
> come to mark the test as ignored until the full fix for related bug
>
> JDK-8077924:
> sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start failing
> after JDK-8076221
>
> can be developed.
>
> Patch below.
>
> Thanks,
>
> -Joe
>
> diff -r 9b63a16654d5
> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
> --- a/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Thu
> Apr 16 11:33:59 2015 -0700
> +++ b/test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh Mon
> Apr 20 09:47:52 2015 -0700
> @@ -29,6 +29,7 @@
> # @library /lib/testlibrary
> # @build jdk.testlibrary.* TestLogger Utils RmiBootstrapTest
> # @run shell/timeout=300 RmiSslBootstrapTest.sh
> +# @ignore 8077924
>
> # Define the Java class test name
> TESTCLASS="RmiBootstrapTest"
>
From Alan.Bateman at oracle.com Mon Apr 20 17:44:21 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 20 Apr 2015 18:44:21 +0100
Subject: JDK 9 RFR of JDK-8077952:
sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
should be quarantined
In-Reply-To: <55352E1D.8050608@oracle.com>
References: <55352E1D.8050608@oracle.com>
Message-ID: <55353AF5.7020801@oracle.com>
On 20/04/2015 17:49, joe darcy wrote:
> Hello,
>
> As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
> has been failing for several days across platforms, I think the time
> has come to mark the test as ignored until the full fix for related bug
>
> JDK-8077924:
> sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start
> failing after JDK-8076221
>
> can be developed.
This looks okay but we mostly use the exclude list
(jdk/test/ProblemList.txt) these days in the jdk repo (I realize @ignore
is still used in the hotspot repo).
-Alan.
From shanliang.jiang at oracle.com Tue Apr 21 07:01:29 2015
From: shanliang.jiang at oracle.com (Shanliang Jiang)
Date: Tue, 21 Apr 2015 09:01:29 +0200
Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError:
sun.management.ManagementFactoryHelper.getDiagnosticMXBean
Message-ID: <5535F5C9.5060408@oracle.com>
Hi,
Please review this test fix:
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8078144
The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean
was removed because HotSpotDiagnosticMXBean is not in java.management
module but in jdk.management module, to get the HotSpotDiagnosticMXBean
we should call:
ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
I passed all failed tests with the fix.
Thanks,
Shanliang
From Alan.Bateman at oracle.com Tue Apr 21 07:05:56 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 08:05:56 +0100
Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError:
sun.management.ManagementFactoryHelper.getDiagnosticMXBean
In-Reply-To: <5535F5C9.5060408@oracle.com>
References: <5535F5C9.5060408@oracle.com>
Message-ID: <5535F6D4.8080300@oracle.com>
On 21/04/2015 08:01, Shanliang Jiang wrote:
> Hi,
>
> Please review this test fix:
>
> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8078144
>
> The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean
> was removed because HotSpotDiagnosticMXBean is not in java.management
> module but in jdk.management module, to get the
> HotSpotDiagnosticMXBean we should call:
> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
>
> I passed all failed tests with the fix.
>
I see JInfoRunningProcessFlagTest still imports
sun.management.ManagementFactoryHelper. Best to remove that now as
otherwise this issue will come back again once javac has support for
modules. Otherwise looks okay to me.
-Alan.
From staffan.larsen at oracle.com Tue Apr 21 07:19:14 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 21 Apr 2015 09:19:14 +0200
Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError:
sun.management.ManagementFactoryHelper.getDiagnosticMXBean
In-Reply-To: <5535F5C9.5060408@oracle.com>
References: <5535F5C9.5060408@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 21 apr 2015, at 09:01, Shanliang Jiang wrote:
>
> Hi,
>
> Please review this test fix:
>
> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8078144
>
> The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean was removed because HotSpotDiagnosticMXBean is not in java.management module but in jdk.management module, to get the HotSpotDiagnosticMXBean we should call:
> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
>
> I passed all failed tests with the fix.
>
> Thanks,
> Shanliang
>
>
>
From shanliang.jiang at oracle.com Tue Apr 21 07:47:25 2015
From: shanliang.jiang at oracle.com (Shanliang Jiang)
Date: Tue, 21 Apr 2015 09:47:25 +0200
Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError:
sun.management.ManagementFactoryHelper.getDiagnosticMXBean
In-Reply-To: <5535F6D4.8080300@oracle.com>
References: <5535F5C9.5060408@oracle.com> <5535F6D4.8080300@oracle.com>
Message-ID: <5536008D.9020406@oracle.com>
Alan Bateman wrote:
> On 21/04/2015 08:01, Shanliang Jiang wrote:
>> Hi,
>>
>> Please review this test fix:
>>
>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8078144
>>
>> The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean
>> was removed because HotSpotDiagnosticMXBean is not in java.management
>> module but in jdk.management module, to get the
>> HotSpotDiagnosticMXBean we should call:
>> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
>>
>> I passed all failed tests with the fix.
>>
> I see JInfoRunningProcessFlagTest still imports
> sun.management.ManagementFactoryHelper. Best to remove that now as
> otherwise this issue will come back again once javac has support for
> modules. Otherwise looks okay to me.
OK I have removed that useless import, here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8078144/01/
by the way the test JInfoRunningProcessFlagTest is in
jdk/test/ProblemList.txt and I found the issue by "find ./ -name
"*.java" |xargs grep ManagementFactoryHelper.getDiagnosticMXBean ". So
my fix just makes it compilable but it still fails
Thanks,
Shanliang
From Alan.Bateman at oracle.com Tue Apr 21 08:02:47 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Apr 2015 09:02:47 +0100
Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError:
sun.management.ManagementFactoryHelper.getDiagnosticMXBean
In-Reply-To: <5536008D.9020406@oracle.com>
References: <5535F5C9.5060408@oracle.com> <5535F6D4.8080300@oracle.com>
<5536008D.9020406@oracle.com>
Message-ID: <55360427.4000908@oracle.com>
On 21/04/2015 08:47, Shanliang Jiang wrote:
> OK I have removed that useless import, here is the new version:
> http://cr.openjdk.java.net/~sjiang/JDK-8078144/01/
Looks fine.
-Alan.
From yekaterina.kantserova at oracle.com Tue Apr 21 08:08:11 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Tue, 21 Apr 2015 01:08:11 -0700 (PDT)
Subject: JDK 9 RFR of JDK-8077952:
sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be
quarantined
Message-ID:
Hi Joe,
I would also suggest to put the test on the ProblemList, which is the current practice for jdk repo.
Best regards,
Katja
----- Original Message -----
From: Alan.Bateman at oracle.com
To: joe.darcy at oracle.com, serviceability-dev at openjdk.java.net
Sent: Monday, April 20, 2015 7:44:30 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: JDK 9 RFR of JDK-8077952: sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be quarantined
On 20/04/2015 17:49, joe darcy wrote:
> Hello,
>
> As the test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh
> has been failing for several days across platforms, I think the time
> has come to mark the test as ignored until the full fix for related bug
>
> JDK-8077924:
> sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh start
> failing after JDK-8076221
>
> can be developed.
This looks okay but we mostly use the exclude list
(jdk/test/ProblemList.txt) these days in the jdk repo (I realize @ignore
is still used in the hotspot repo).
-Alan.
From mandy.chung at oracle.com Tue Apr 21 15:34:59 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 21 Apr 2015 08:34:59 -0700
Subject: RFR: 8078144 many nightly tests failed due to NoSuchMethodError:
sun.management.ManagementFactoryHelper.getDiagnosticMXBean
In-Reply-To: <5535F5C9.5060408@oracle.com>
References: <5535F5C9.5060408@oracle.com>
Message-ID: <55366E23.9020105@oracle.com>
On 4/21/2015 12:01 AM, Shanliang Jiang wrote:
> Hi,
>
> Please review this test fix:
>
> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8078144/00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8078144
>
> The method sun.management.ManagementFactoryHelper.getDiagnosticMXBean
> was removed because HotSpotDiagnosticMXBean is not in java.management
> module but in jdk.management module, to get the
> HotSpotDiagnosticMXBean we should call:
> ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
The webrev.01 version looks good to me. JDK-8042901 fixed several
tests to eliminate the dependency on sun.management internal APIs and
missed these few tests. You probably may have done this - grep and see
if there are any remaining tests to be updated.
Mandy
From joe.darcy at oracle.com Wed Apr 22 02:13:16 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 21 Apr 2015 19:13:16 -0700
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
Message-ID: <553703BC.1070504@oracle.com>
Hello,
As the next step of implementing "Proposed new policies for JDK 9
regression tests: tiered testing, intermittent failures, and randomness"
[1], please review this changeset which adds a "randomness" jtreg
keyword and tags 240 regression tests in the jdk repository with the
keyword:
JDK-8078334: Mark regression tests using randomness
http://cr.openjdk.java.net/~darcy/8078334.0/
The update to test/TEST.ROOT is
-# The list of keywords supported in the entire test suite
-keys=2d dnd i18n intermittent
+# The list of keywords supported in the entire test suite. The
+# "intermittent" keyword marks tests known to fail intermittently.
+# The "randomness" keyword marks tests using randomness with test
+# cases differing from run to run. (A test using a fixed random seed
+# would not count as "randomness" by this definition.) Extra care
+# should be taken to handle test failures of intermittent or
+# randomness tests.
+
+keys=2d dnd i18n intermittent randomness
To find the affected files for this fix, I grepped over the regression
tests looking for "random" and verified if a random number generated was
used in a way where its values would differ from run to run. In
particular, as noted above, a java.util.Random random number generator
with a fixed seed did *not* qualify a test for the "randomness" keyword.
The usual update to the files in this changeset is just
+ * @key randomness
The updated tests are mostly in the core libs and security libs areas
with a few serviceability tests too. The list in this bug is not quite
exhaustive; I did not include rmi tests or client libraries tests.
I verified that running
jtreg ... -l -k:randomness .
returns the expected number of tests and that the tests continue to pass
(or be ignored) when run.
One goal of marking the tests using randomness is to help root out some
remaining intermittent test failures. If one of the randomness tests is
observed to fail intermittently, if it has not already been updated to
print out the random seed and be able to accept a particular seed when
run, the test should be so modified so that future failures can log the
seed value in hopes of reproducing the failure.
Brian Burkhalter has proactively made these sorts of changes to the
java.math tests earlier in JDK 9. [2] Since most of the randomness tests
don't have a history of instability (and due to the unexpected large
number of them!), I don't think it is necessary to proactively update
all the other tests without evidence of a history of failure. However,
when an otherwise unexplained failure is seen, I recommend applying the
sort of updates Brian has done in java.math to the failing test(s).
Thanks,
-Joe
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
[2] JDK-8074460, Always print seeds used in [Splittable]Random instances
in java.math tests,
https://bugs.openjdk.java.net/browse/JDK-8074460
From daniel.fuchs at oracle.com Wed Apr 22 08:31:47 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 22 Apr 2015 10:31:47 +0200
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <553703BC.1070504@oracle.com>
References: <553703BC.1070504@oracle.com>
Message-ID: <55375C73.7060001@oracle.com>
On 22/04/15 04:13, Joseph D. Darcy wrote:
> One goal of marking the tests using randomness is to help root out some
> remaining intermittent test failures. If one of the randomness tests is
> observed to fail intermittently, if it has not already been updated to
> print out the random seed and be able to accept a particular seed when
> run, the test should be so modified so that future failures can log the
> seed value in hopes of reproducing the failure.
Hi Joe,
The following logging tests use UUID.randomUUID() to generate
a 'unique' file name in order to avoid possible collision if
these tests are run concurrently or if some files have been
left over from a previous run (some of these use %t - the temporary
directory - which has been known to cause intermittent
failure in those cases).
So I believe that removing randomness, or attempting to
make it predictable, would in those specific cases make
those tests more prone to intermittent failures.
In this light - should these tests still be tagged with
the @randomness keyword?
test/java/util/logging/CheckZombieLockTest.java
test/java/util/logging/FileHandlerLongLimit.java
test/java/util/logging/FileHandlerPath.java
test/java/util/logging/FileHandlerPatternExceptions.java
test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java
best regards,
-- daniel
From yekaterina.kantserova at oracle.com Wed Apr 22 09:17:10 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 22 Apr 2015 11:17:10 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in tests
Message-ID: <55376716.10806@oracle.com>
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8059047
webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
This fix is a part of JEP 241: Remove the jhat Tool
(https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put
parser/validator into common test library since the functionality can be
useful not only for SVC tools tests but even for some future GC tests.
The old jhat packages have been moved as follows:
com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
The source has not been changed except Copyrights year.
Thanks,
Katja
From yekaterina.kantserova at oracle.com Wed Apr 22 10:56:28 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 22 Apr 2015 12:56:28 +0200
Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK
Message-ID: <55377E5C.3090404@oracle.com>
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8076524
webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00
This fix is a part of JEP 241: Remove the jhat Tool
(https://bugs.openjdk.java.net/browse/JDK-8059039).
Thanks,
Katja
From Alan.Bateman at oracle.com Wed Apr 22 11:09:30 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 22 Apr 2015 12:09:30 +0100
Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK
In-Reply-To: <55377E5C.3090404@oracle.com>
References: <55377E5C.3090404@oracle.com>
Message-ID: <5537816A.4020103@oracle.com>
On 22/04/2015 11:56, Yekaterina Kantserova wrote:
> Hi,
>
> Could I please have a review of this fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8076524
> webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00
>
> This fix is a part of JEP 241: Remove the jhat Tool
> (https://bugs.openjdk.java.net/browse/JDK-8059039).
This looks okay to me although I would have expected these tests to be
removed as part of the change to remove jhat (no issue with it being
split into multiple changes, just wondering why it is being done this way).
-Alan
From staffan.larsen at oracle.com Wed Apr 22 11:17:53 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Apr 2015 13:17:53 +0200
Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK
In-Reply-To: <55377E5C.3090404@oracle.com>
References: <55377E5C.3090404@oracle.com>
Message-ID: <98BB76C4-35EF-48C3-AFE5-D34735C15933@oracle.com>
Looks good!
Thanks,
/Staffan
> On 22 apr 2015, at 12:56, Yekaterina Kantserova wrote:
>
> Hi,
>
> Could I please have a review of this fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8076524
> webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00
>
> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039).
>
> Thanks,
> Katja
From yekaterina.kantserova at oracle.com Wed Apr 22 11:18:45 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 22 Apr 2015 13:18:45 +0200
Subject: RFR(S): 8076524: Remove jhat tests and help library from JDK
In-Reply-To: <5537816A.4020103@oracle.com>
References: <55377E5C.3090404@oracle.com> <5537816A.4020103@oracle.com>
Message-ID: <55378395.4000004@oracle.com>
Hi Alan,
Thank you for looking at it! When JEP was created the work has been
divided in product and test parts according to the JEP guidelines.
That's the reason I can come up with.
To test part belongs even
https://bugs.openjdk.java.net/browse/JDK-8059047. That's would be great
if you can take a look at it as well.
// Katja
On 04/22/2015 01:09 PM, Alan Bateman wrote:
> On 22/04/2015 11:56, Yekaterina Kantserova wrote:
>> Hi,
>>
>> Could I please have a review of this fix.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8076524
>> webrev: http://cr.openjdk.java.net/~ykantser/8076524/webrev.00
>>
>> This fix is a part of JEP 241: Remove the jhat Tool
>> (https://bugs.openjdk.java.net/browse/JDK-8059039).
> This looks okay to me although I would have expected these tests to be
> removed as part of the change to remove jhat (no issue with it being
> split into multiple changes, just wondering why it is being done this
> way).
>
> -Alan
From staffan.larsen at oracle.com Wed Apr 22 11:20:15 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Apr 2015 13:20:15 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To: <55376716.10806@oracle.com>
References: <55376716.10806@oracle.com>
Message-ID: <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
Looks good!
Thanks,
/Staffan
> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
>
> Hi,
>
> Could I please have a review of this fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>
> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>
> The old jhat packages have been moved as follows:
> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>
> The source has not been changed except Copyrights year.
>
> Thanks,
> Katja
From yekaterina.kantserova at oracle.com Wed Apr 22 12:25:05 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 22 Apr 2015 14:25:05 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To: <68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
Message-ID: <55379321.1090403@oracle.com>
Staffan, thank you for the review!
This issue needs a change in jdk as well.
http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 -
BasicJMapTest.java will use HprofParser to verify hprof dumps created by
the test.
// Katja
On 04/22/2015 01:20 PM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
>>
>> Hi,
>>
>> Could I please have a review of this fix.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>
>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>>
>> The old jhat packages have been moved as follows:
>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>
>> The source has not been changed except Copyrights year.
>>
>> Thanks,
>> Katja
From staffan.larsen at oracle.com Wed Apr 22 13:05:03 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Apr 2015 15:05:03 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To: <55379321.1090403@oracle.com>
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
Message-ID: <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
I think you are missing a "@build jdk.test.lib.hprof..*?.
/Staffan
> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote:
>
> Staffan, thank you for the review!
>
> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test.
>
> // Katja
>
>
>
> On 04/22/2015 01:20 PM, Staffan Larsen wrote:
>> Looks good!
>>
>> Thanks,
>> /Staffan
>>
>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
>>>
>>> Hi,
>>>
>>> Could I please have a review of this fix.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>>
>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>>>
>>> The old jhat packages have been moved as follows:
>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>>
>>> The source has not been changed except Copyrights year.
>>>
>>> Thanks,
>>> Katja
>
From staffan.larsen at oracle.com Wed Apr 22 13:06:53 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Apr 2015 15:06:53 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To: <1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
<1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
Message-ID:
I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh
/Staffan
> On 22 apr 2015, at 15:05, Staffan Larsen wrote:
>
> I think you are missing a "@build jdk.test.lib.hprof..*?.
>
> /Staffan
>
>> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote:
>>
>> Staffan, thank you for the review!
>>
>> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test.
>>
>> // Katja
>>
>>
>>
>> On 04/22/2015 01:20 PM, Staffan Larsen wrote:
>>> Looks good!
>>>
>>> Thanks,
>>> /Staffan
>>>
>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
>>>>
>>>> Hi,
>>>>
>>>> Could I please have a review of this fix.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>>>
>>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>>>>
>>>> The old jhat packages have been moved as follows:
>>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>>>
>>>> The source has not been changed except Copyrights year.
>>>>
>>>> Thanks,
>>>> Katja
>>
>
From staffan.larsen at oracle.com Wed Apr 22 13:09:30 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 22 Apr 2015 15:09:30 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To:
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
<1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
Message-ID: <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com>
Oh, and: serviceability/dcmd/gc/HeapDumpTest.java
> On 22 apr 2015, at 15:06, Staffan Larsen wrote:
>
> I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh
>
> /Staffan
>
>> On 22 apr 2015, at 15:05, Staffan Larsen wrote:
>>
>> I think you are missing a "@build jdk.test.lib.hprof..*?.
>>
>> /Staffan
>>
>>> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote:
>>>
>>> Staffan, thank you for the review!
>>>
>>> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test.
>>>
>>> // Katja
>>>
>>>
>>>
>>> On 04/22/2015 01:20 PM, Staffan Larsen wrote:
>>>> Looks good!
>>>>
>>>> Thanks,
>>>> /Staffan
>>>>
>>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Could I please have a review of this fix.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>>>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>>>>
>>>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>>>>>
>>>>> The old jhat packages have been moved as follows:
>>>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>>>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>>>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>>>>
>>>>> The source has not been changed except Copyrights year.
>>>>>
>>>>> Thanks,
>>>>> Katja
>>>
>>
>
From amy.lu at oracle.com Wed Apr 22 11:19:39 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 22 Apr 2015 19:19:39 +0800
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <55375C73.7060001@oracle.com>
References: <553703BC.1070504@oracle.com> <55375C73.7060001@oracle.com>
Message-ID: <553783CB.7050902@oracle.com>
On 4/22/15 4:31 PM, Daniel Fuchs wrote:
> On 22/04/15 04:13, Joseph D. Darcy wrote:
>> One goal of marking the tests using randomness is to help root out some
>> remaining intermittent test failures. If one of the randomness tests is
>> observed to fail intermittently, if it has not already been updated to
>> print out the random seed and be able to accept a particular seed when
>> run, the test should be so modified so that future failures can log the
>> seed value in hopes of reproducing the failure.
>
> Hi Joe,
>
> The following logging tests use UUID.randomUUID() to generate
> a 'unique' file name in order to avoid possible collision if
> these tests are run concurrently or if some files have been
> left over from a previous run (some of these use %t - the temporary
> directory - which has been known to cause intermittent
> failure in those cases).
>
> So I believe that removing randomness, or attempting to
> make it predictable, would in those specific cases make
> those tests more prone to intermittent failures.
>
> In this light - should these tests still be tagged with
> the @randomness keyword?
>
> test/java/util/logging/CheckZombieLockTest.java
> test/java/util/logging/FileHandlerLongLimit.java
> test/java/util/logging/FileHandlerPath.java
> test/java/util/logging/FileHandlerPatternExceptions.java
> test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java
>
>
>
> best regards,
>
> -- daniel
I notice similar case in below tests:
test/java/util/zip/ZipFile/FinalizeZipFile.java
Test need some zip file to test on. Random is used to generate the
zip file name.
test/java/util/zip/ZipFile/ReadZip.java
Random is used to generate a non-existing file name for negative test
@randomness might not needed for following tests where test need a zip
file to test on, and Random is used to fill some content to the file in
createZipFile().
test/java/util/zip/ZipFile/MultiThreadedReadTest.java
test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java
Thanks,
Amy
From yekaterina.kantserova at oracle.com Wed Apr 22 17:02:13 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 22 Apr 2015 10:02:13 -0700 (PDT)
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
Message-ID: <02db0e73-b01d-4b1a-a963-89e4c956f0bc@default>
Thanks for the catch Staffan! I'll go through all of them and send out a new webrev.
// Katja
----- Original Message -----
From: staffan.larsen at oracle.com
To: staffan.larsen at oracle.com
Cc: yekaterina.kantserova at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
Sent: Wednesday, April 22, 2015 3:09:35 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: RFR(M): 8059047: Extract parser/validator from jhat for use in tests
Oh, and: serviceability/dcmd/gc/HeapDumpTest.java
> On 22 apr 2015, at 15:06, Staffan Larsen wrote:
>
> I also found this test that uses jhat and needs an update: com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh
>
> /Staffan
>
>> On 22 apr 2015, at 15:05, Staffan Larsen wrote:
>>
>> I think you are missing a "@build jdk.test.lib.hprof..*?.
>>
>> /Staffan
>>
>>> On 22 apr 2015, at 14:25, Yekaterina Kantserova wrote:
>>>
>>> Staffan, thank you for the review!
>>>
>>> This issue needs a change in jdk as well. http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.00 - BasicJMapTest.java will use HprofParser to verify hprof dumps created by the test.
>>>
>>> // Katja
>>>
>>>
>>>
>>> On 04/22/2015 01:20 PM, Staffan Larsen wrote:
>>>> Looks good!
>>>>
>>>> Thanks,
>>>> /Staffan
>>>>
>>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Could I please have a review of this fix.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>>>>> webrev: http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>>>>
>>>>> This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>>>>>
>>>>> The old jhat packages have been moved as follows:
>>>>> com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>>>>> com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>>>>> com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>>>>
>>>>> The source has not been changed except Copyrights year.
>>>>>
>>>>> Thanks,
>>>>> Katja
>>>
>>
>
From joe.darcy at oracle.com Wed Apr 22 17:02:57 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 22 Apr 2015 10:02:57 -0700
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <55375C73.7060001@oracle.com>
References: <553703BC.1070504@oracle.com> <55375C73.7060001@oracle.com>
Message-ID: <5537D441.1070204@oracle.com>
Hi Daniel,
On 4/22/2015 1:31 AM, Daniel Fuchs wrote:
> On 22/04/15 04:13, Joseph D. Darcy wrote:
>> One goal of marking the tests using randomness is to help root out some
>> remaining intermittent test failures. If one of the randomness tests is
>> observed to fail intermittently, if it has not already been updated to
>> print out the random seed and be able to accept a particular seed when
>> run, the test should be so modified so that future failures can log the
>> seed value in hopes of reproducing the failure.
>
> Hi Joe,
>
> The following logging tests use UUID.randomUUID() to generate
> a 'unique' file name in order to avoid possible collision if
> these tests are run concurrently or if some files have been
> left over from a previous run (some of these use %t - the temporary
> directory - which has been known to cause intermittent
> failure in those cases).
>
> So I believe that removing randomness, or attempting to
> make it predictable, would in those specific cases make
> those tests more prone to intermittent failures.
>
> In this light - should these tests still be tagged with
> the @randomness keyword?
>
> test/java/util/logging/CheckZombieLockTest.java
> test/java/util/logging/FileHandlerLongLimit.java
> test/java/util/logging/FileHandlerPath.java
> test/java/util/logging/FileHandlerPatternExceptions.java
> test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java
>
>
The randomness label is just meant to be documentation and not
pejorative. Its uses in the tests you identify it is more likely to
increase rather than decrease stability. However, I still think it is
appropriate to mark these tests for their behavior.
Thanks,
-Joe
From staffan.larsen at oracle.com Thu Apr 23 12:06:27 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 23 Apr 2015 14:06:27 +0200
Subject: RFR: 8076473 Remove the jhat code and update makefiles
Message-ID: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
Please review this change to remove the jhat tool. I will not push this change until the tests have been removed (see a different review thread).
JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
bug: https://bugs.openjdk.java.net/browse/JDK-8076473
webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/
webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/
Thanks,
/Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Alan.Bateman at oracle.com Thu Apr 23 12:15:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Apr 2015 13:15:14 +0100
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
Message-ID: <5538E252.9040006@oracle.com>
On 23/04/2015 13:06, Staffan Larsen wrote:
> Please review this change to remove the jhat tool. I will not push
> this change until the tests have been removed (see a different review
> thread).
>
> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>
> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/
>
> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/
>
>
This looks good to me, and I assume Katja's patch from yesterday got all
the tests.
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jaroslav.bachorik at oracle.com Thu Apr 23 12:38:48 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 23 Apr 2015 14:38:48 +0200
Subject: RFR 8077953: [TEST_BUG]
com/sun/management/OperatingSystemMXBean/TestTotalSwap.java
Compilation failed after JDK-8077387
Message-ID: <5538E7D8.3020303@oracle.com>
Please, review this JDK8 only test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8077953
Webrev: http://cr.openjdk.java.net/~jbachorik/8077953/webrev.00
Backport of https://bugs.openjdk.java.net/browse/JDK-8077387 requires
testlibrary functionality not yet backported to JDK8. This patch takes
care of bringing that functionality there.
Thanks,
-JB-
From staffan.larsen at oracle.com Thu Apr 23 13:22:50 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 23 Apr 2015 15:22:50 +0200
Subject: RFR 8077953: [TEST_BUG]
com/sun/management/OperatingSystemMXBean/TestTotalSwap.java
Compilation failed after JDK-8077387
In-Reply-To: <5538E7D8.3020303@oracle.com>
References: <5538E7D8.3020303@oracle.com>
Message-ID: <9DD9F27E-6F05-4AA1-998E-CB97357078DF@oracle.com>
Looks good! (assuming you ran through the tests successfully)
Thanks,
/Staffan
> On 23 apr 2015, at 14:38, Jaroslav Bachorik wrote:
>
> Please, review this JDK8 only test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8077953
> Webrev: http://cr.openjdk.java.net/~jbachorik/8077953/webrev.00
>
> Backport of https://bugs.openjdk.java.net/browse/JDK-8077387 requires testlibrary functionality not yet backported to JDK8. This patch takes care of bringing that functionality there.
>
> Thanks,
>
> -JB-
From staffan.larsen at oracle.com Thu Apr 23 14:13:23 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 23 Apr 2015 16:13:23 +0200
Subject: RFR: 8078519 Can't run SA tools from a non-images build
Message-ID: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com>
Please see description of the problem in the bug report: https://bugs.openjdk.java.net/browse/JDK-8078519
The simple fix is included below.
Thanks,
/Staffan
diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
--- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
+++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
@@ -259,7 +259,12 @@
saProps = new Properties();
URL url = null;
try {
- url = VM.class.getClassLoader().getResource("sa.properties");
+ if (VM.class.getClassLoader() == null) {
+ url = ClassLoader.getSystemResource("sa.properties");
+ }
+ else {
+ url = VM.class.getClassLoader().getResource("sa.properties");
+ }
saProps.load(new BufferedInputStream(url.openStream()));
} catch (Exception e) {
System.err.println("Unable to load properties " +
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From staffan.larsen at oracle.com Thu Apr 23 14:51:11 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 23 Apr 2015 16:51:11 +0200
Subject: RFR: 8078519 Can't run SA tools from a non-images build
In-Reply-To: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com>
References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com>
Message-ID: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com>
Here is an improved and simplified patch:
diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
--- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
+++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
@@ -259,8 +259,7 @@
saProps = new Properties();
URL url = null;
try {
- url = VM.class.getClassLoader().getResource("sa.properties");
- saProps.load(new BufferedInputStream(url.openStream()));
+ saProps.load(VM.class.getResourceAsStream("/sa.properties"));
} catch (Exception e) {
System.err.println("Unable to load properties " +
(url == null ? "null" : url.toString()) +
> On 23 apr 2015, at 16:13, Staffan Larsen wrote:
>
> Please see description of the problem in the bug report: https://bugs.openjdk.java.net/browse/JDK-8078519
>
> The simple fix is included below.
>
> Thanks,
> /Staffan
>
>
> diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> @@ -259,7 +259,12 @@
> saProps = new Properties();
> URL url = null;
> try {
> - url = VM.class.getClassLoader().getResource("sa.properties");
> + if (VM.class.getClassLoader() == null) {
> + url = ClassLoader.getSystemResource("sa.properties");
> + }
> + else {
> + url = VM.class.getClassLoader().getResource("sa.properties");
> + }
> saProps.load(new BufferedInputStream(url.openStream()));
> } catch (Exception e) {
> System.err.println("Unable to load properties " +
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Alan.Bateman at oracle.com Thu Apr 23 15:12:05 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Apr 2015 16:12:05 +0100
Subject: RFR: 8078519 Can't run SA tools from a non-images build
In-Reply-To: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com>
References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com>
<45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com>
Message-ID: <55390BC5.7050300@oracle.com>
On 23/04/2015 15:51, Staffan Larsen wrote:
> Here is an improved and simplified patch:
>
> diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> @@ -259,8 +259,7 @@
> saProps = new Properties();
> URL url = null;
> try {
> - url = VM.class.getClassLoader().getResource("sa.properties");
> - saProps.load(new BufferedInputStream(url.openStream()));
> + saProps.load(VM.class.getResourceAsStream("/sa.properties"));
> } catch (Exception e) {
> System.err.println("Unable to load properties " +
> (url == null ? "null" :
> url.toString()) +
>
>
This looks good to me.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From erik.joelsson at oracle.com Thu Apr 23 15:22:56 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Apr 2015 08:22:56 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <5538E252.9040006@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
<5538E252.9040006@oracle.com>
Message-ID: <55390E50.1050209@oracle.com>
Looks good to me.
/Erik
On 2015-04-23 05:15, Alan Bateman wrote:
>
>
> On 23/04/2015 13:06, Staffan Larsen wrote:
>> Please review this change to remove the jhat tool. I will not push
>> this change until the tests have been removed (see a different review
>> thread).
>>
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
>> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>>
>> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/
>>
>> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/
>>
>>
> This looks good to me, and I assume Katja's patch from yesterday got
> all the tests.
>
> -Alan.
From mandy.chung at oracle.com Thu Apr 23 16:41:37 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 23 Apr 2015 09:41:37 -0700
Subject: RFR: 8078519 Can't run SA tools from a non-images build
In-Reply-To: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com>
References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com>
<45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com>
Message-ID: <553920C1.7020705@oracle.com>
On 04/23/2015 07:51 AM, Staffan Larsen wrote:
> Here is an improved and simplified patch:
>
> diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> @@ -259,8 +259,7 @@
> saProps = new Properties();
> URL url = null;
> try {
> - url = VM.class.getClassLoader().getResource("sa.properties");
> - saProps.load(new BufferedInputStream(url.openStream()));
> + saProps.load(VM.class.getResourceAsStream("/sa.properties"));
> } catch (Exception e) {
> System.err.println("Unable to load properties " +
> (url == null ? "null" :
> url.toString()) +
This is a better version. Looks good.
Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dmitry.samersoff at oracle.com Thu Apr 23 16:44:06 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 23 Apr 2015 19:44:06 +0300
Subject: RFR: 8078519 Can't run SA tools from a non-images build
In-Reply-To: <45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com>
References: <0194C2C3-2AF8-4F4E-9267-2474EBCF9CA9@oracle.com>
<45FE0063-1817-42AF-83FF-6DF0A7E4716B@oracle.com>
Message-ID: <55392156.9070505@oracle.com>
Staffan,
Looks good for me.
-Dmitry
On 2015-04-23 17:51, Staffan Larsen wrote:
> Here is an improved and simplified patch:
>
> diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
> @@ -259,8 +259,7 @@
> saProps = new Properties();
> URL url = null;
> try {
> - url = VM.class.getClassLoader().getResource("sa.properties");
> - saProps.load(new BufferedInputStream(url.openStream()));
> + saProps.load(VM.class.getResourceAsStream("/sa.properties"));
> } catch (Exception e) {
> System.err.println("Unable to load properties " +
> (url == null ? "null" : url.toString()) +
>
>
>> On 23 apr 2015, at 16:13, Staffan Larsen > > wrote:
>>
>> Please see description of the problem in the bug
>> report: https://bugs.openjdk.java.net/browse/JDK-8078519
>>
>> The simple fix is included below.
>>
>> Thanks,
>> /Staffan
>>
>>
>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
>> b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
>> --- a/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
>> +++ b/agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
>> @@ -259,7 +259,12 @@
>> saProps = new Properties();
>> URL url = null;
>> try {
>> - url = VM.class.getClassLoader().getResource("sa.properties");
>> + if (VM.class.getClassLoader() == null) {
>> + url = ClassLoader.getSystemResource("sa.properties");
>> + }
>> + else {
>> + url = VM.class.getClassLoader().getResource("sa.properties");
>> + }
>> saProps.load(new BufferedInputStream(url.openStream()));
>> } catch (Exception e) {
>> System.err.println("Unable to load properties " +
>
--
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 Thu Apr 23 19:52:42 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 23 Apr 2015 12:52:42 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
Message-ID: <55394D8A.4080101@oracle.com>
It looks good.
A question:
Do we want to get rid of the jhat in the
jdk/closed/old-build/common/Release.gmk ?
jhat.1 \
com/sun/tools/hat \
jhat$(EXE_SUFFIX)
Thanks,
Serguei
On 4/23/15 5:06 AM, Staffan Larsen wrote:
> Please review this change to remove the jhat tool. I will not push
> this change until the tests have been removed (see a different review
> thread).
>
> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>
> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/
>
> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/
>
>
> Thanks,
> /Staffan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From erik.joelsson at oracle.com Thu Apr 23 21:50:04 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Apr 2015 14:50:04 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <55394D8A.4080101@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
<55394D8A.4080101@oracle.com>
Message-ID: <5539690C.4090007@oracle.com>
No, that file is old legacy and not used anymore. It will hopefully soon
go away.
/Erik
On 2015-04-23 12:52, serguei.spitsyn at oracle.com wrote:
> It looks good.
> A question:
> Do we want to get rid of the jhat in the
> jdk/closed/old-build/common/Release.gmk ?
> jhat.1 \
> com/sun/tools/hat \
> jhat$(EXE_SUFFIX)
>
> Thanks,
> Serguei
>
>
>
> On 4/23/15 5:06 AM, Staffan Larsen wrote:
>> Please review this change to remove the jhat tool. I will not push
>> this change until the tests have been removed (see a different review
>> thread).
>>
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
>> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>>
>> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/
>>
>> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/
>>
>>
>> Thanks,
>> /Staffan
>>
>
From serguei.spitsyn at oracle.com Thu Apr 23 23:41:35 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 23 Apr 2015 16:41:35 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <5539690C.4090007@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
<55394D8A.4080101@oracle.com> <5539690C.4090007@oracle.com>
Message-ID: <5539832F.2070900@oracle.com>
On 4/23/15 2:50 PM, Erik Joelsson wrote:
> No, that file is old legacy and not used anymore. It will hopefully
> soon go away.
Ok then.
Thanks, Erik!
Serguei
>
> /Erik
>
> On 2015-04-23 12:52, serguei.spitsyn at oracle.com wrote:
>> It looks good.
>> A question:
>> Do we want to get rid of the jhat in the
>> jdk/closed/old-build/common/Release.gmk ?
>> jhat.1 \
>> com/sun/tools/hat \
>> jhat$(EXE_SUFFIX)
>>
>> Thanks,
>> Serguei
>>
>>
>>
>> On 4/23/15 5:06 AM, Staffan Larsen wrote:
>>> Please review this change to remove the jhat tool. I will not push
>>> this change until the tests have been removed (see a different
>>> review thread).
>>>
>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>>>
>>> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/
>>>
>>> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/
>>>
>>>
>>> Thanks,
>>> /Staffan
>>>
>>
>
From joe.darcy at oracle.com Fri Apr 24 01:54:17 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 23 Apr 2015 18:54:17 -0700
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <553703BC.1070504@oracle.com>
References: <553703BC.1070504@oracle.com>
Message-ID: <5539A249.7050105@oracle.com>
Hello,
Any additional comments on marking with tests in question with a
"randomness" keyword?
Thanks,
-Joe
On 4/21/2015 7:13 PM, Joseph D. Darcy wrote:
> Hello,
>
> As the next step of implementing "Proposed new policies for JDK 9
> regression tests: tiered testing, intermittent failures, and
> randomness" [1], please review this changeset which adds a
> "randomness" jtreg keyword and tags 240 regression tests in the jdk
> repository with the keyword:
>
> JDK-8078334: Mark regression tests using randomness
> http://cr.openjdk.java.net/~darcy/8078334.0/
>
> The update to test/TEST.ROOT is
>
> -# The list of keywords supported in the entire test suite
> -keys=2d dnd i18n intermittent
> +# The list of keywords supported in the entire test suite. The
> +# "intermittent" keyword marks tests known to fail intermittently.
> +# The "randomness" keyword marks tests using randomness with test
> +# cases differing from run to run. (A test using a fixed random seed
> +# would not count as "randomness" by this definition.) Extra care
> +# should be taken to handle test failures of intermittent or
> +# randomness tests.
> +
> +keys=2d dnd i18n intermittent randomness
>
> To find the affected files for this fix, I grepped over the regression
> tests looking for "random" and verified if a random number generated
> was used in a way where its values would differ from run to run. In
> particular, as noted above, a java.util.Random random number generator
> with a fixed seed did *not* qualify a test for the "randomness" keyword.
>
> The usual update to the files in this changeset is just
>
> + * @key randomness
>
> The updated tests are mostly in the core libs and security libs areas
> with a few serviceability tests too. The list in this bug is not quite
> exhaustive; I did not include rmi tests or client libraries tests.
>
> I verified that running
>
> jtreg ... -l -k:randomness .
>
> returns the expected number of tests and that the tests continue to
> pass (or be ignored) when run.
>
> One goal of marking the tests using randomness is to help root out
> some remaining intermittent test failures. If one of the randomness
> tests is observed to fail intermittently, if it has not already been
> updated to print out the random seed and be able to accept a
> particular seed when run, the test should be so modified so that
> future failures can log the seed value in hopes of reproducing the
> failure.
>
> Brian Burkhalter has proactively made these sorts of changes to the
> java.math tests earlier in JDK 9. [2] Since most of the randomness
> tests don't have a history of instability (and due to the unexpected
> large number of them!), I don't think it is necessary to proactively
> update all the other tests without evidence of a history of failure.
> However, when an otherwise unexplained failure is seen, I recommend
> applying the sort of updates Brian has done in java.math to the
> failing test(s).
>
> Thanks,
>
> -Joe
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
>
> [2] JDK-8074460, Always print seeds used in [Splittable]Random
> instances in java.math tests,
> https://bugs.openjdk.java.net/browse/JDK-8074460
From Alan.Bateman at oracle.com Fri Apr 24 05:58:09 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 24 Apr 2015 06:58:09 +0100
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <5539A249.7050105@oracle.com>
References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com>
Message-ID: <5539DB71.2070605@oracle.com>
On 24/04/2015 02:54, Joseph D. Darcy wrote:
> Hello,
>
> Any additional comments on marking with tests in question with a
> "randomness" keyword?
>
> Thanks,
>
> -Joe
>
I don't object to this keyword although I should say that most of the
(apparent) randomness that I've seen hasn't been because of tests using
Random but rather because of non-deterministic sequence of tests running
in the same VM. The switch from othervm to agentvm a few years ago took
a long time to weed out issues, same thing (even more) with
-concurrency. Another source of apparent randomness is just having a
large pool of machines and where machines are randomly selected to
execute the tests.
I agree with your comments that tests using Random should have report
the seed and a have a way to re-run with the same value. It could help
with some cases.
One thing that isn't clear to me is how this keyword will be maintained.
If I modify a test and replace the use of Random then I guess I need to
remember to also remove this label. When I add a test that uses Random
... Just wondering if there is a tool to do the tests analysis,
identify the use of specific APIs ,and help identify where the keyword
might be missing or not needed.
-Alan.
From yekaterina.kantserova at oracle.com Fri Apr 24 09:34:38 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Fri, 24 Apr 2015 11:34:38 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To: <85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com>
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
<1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
<85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com>
Message-ID: <553A0E2E.4090805@oracle.com>
Hi,
Here comes the updated version.
bug: https://bugs.openjdk.java.net/browse/JDK-8059047
webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/
webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/
webrev hotspot:
http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/
One comment about changes in hotspot part. The refactored version of
serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check:
70 /*
71 * Some hprof dumps of all objects contain
constantPoolOop references that cannot be resolved, so we ignore
72 * failures about resolving constantPoolOop fields
using a negative lookahead
73 */
74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve
object.*constantPoolOop.*).*");
It depends on that the current version of jdk.test.lib.hprof parser
simply write down warnings to stdout. As a result the test needs to
invent own logic to parse it.
I suggest instead to improve jdk.test.lib.hprof parser as a separate
RFE. The parser will collect such information and provide a new method
for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings().
The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly
when RFE is implemented.
Thanks,
Katja
On 04/22/2015 03:09 PM, Staffan Larsen wrote:
> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
> >>>>>
> >>>>>Hi,
> >>>>>
> >>>>>Could I please have a review of this fix.
> >>>>>
> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047
> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
> >>>>>
> >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
> >>>>>
> >>>>>The old jhat packages have been moved as follows:
> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
> >>>>>
> >>>>>The source has not been changed except Copyrights year.
> >>>>>
> >>>>>Thanks,
> >>>>>Katja
From staffan.larsen at oracle.com Fri Apr 24 10:10:45 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 24 Apr 2015 12:10:45 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To: <553A0E2E.4090805@oracle.com>
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
<1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
<85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com>
<553A0E2E.4090805@oracle.com>
Message-ID:
> On 24 apr 2015, at 11:34, Yekaterina Kantserova wrote:
>
> Hi,
>
> Here comes the updated version.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>
> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/
> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/
test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java:
In main() I think you should change the deleteOnExit() to just delete(). There is no reason to wait with it.
Perhaps we should also verify that the file does not already exists before we try to write to it. If it exists, we can delete it.
> webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/
test/serviceability/dcmd/gc/HeapDumpTest.java:
Same thing: call delete() instead of deleteOnExit().
>
>
> One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check:
>
> 70 /*
> 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore
> 72 * failures about resolving constantPoolOop fields using a negative lookahead
> 73 */
> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*");
>
> It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it.
>
> I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented.
Sounds right. A quick, hacky solution is to redirect System.out to a stream or file while running the parser?
/Staffan
>
>
> Thanks,
> Katja
>
>
>
> On 04/22/2015 03:09 PM, Staffan Larsen wrote:
>> On 22 apr 2015, at 11:17, Yekaterina Kantserova wrote:
>> >>>>>
>> >>>>>Hi,
>> >>>>>
>> >>>>>Could I please have a review of this fix.
>> >>>>>
>> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047
>> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>> >>>>>
>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>> >>>>>
>> >>>>>The old jhat packages have been moved as follows:
>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>> >>>>>
>> >>>>>The source has not been changed except Copyrights year.
>> >>>>>
>> >>>>>Thanks,
>> >>>>>Katja
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jaroslav.bachorik at oracle.com Fri Apr 24 10:23:05 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 24 Apr 2015 12:23:05 +0200
Subject: RFR 8076971: sun/management/jmxremote/startstop/JMXStatusTest.java
failed with AssertionError
Message-ID: <553A1989.9010909@oracle.com>
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8076971
Webrev: http://cr.openjdk.java.net/~jbachorik/8076971/webrev.00
The tests trying to access target JVMs via eg. 'jcmd' will fail on
embedded configurations if the flag '-XX:+UsePerfData' is not specified.
This patch adds this flag to the test application test builders thus
making the target JVMs visible to 'jcmd'.
Thanks,
-JB-
From staffan.larsen at oracle.com Fri Apr 24 10:44:11 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 24 Apr 2015 12:44:11 +0200
Subject: RFR 8076971:
sun/management/jmxremote/startstop/JMXStatusTest.java failed
with AssertionError
In-Reply-To: <553A1989.9010909@oracle.com>
References: <553A1989.9010909@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 24 apr 2015, at 12:23, Jaroslav Bachorik wrote:
>
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8076971
> Webrev: http://cr.openjdk.java.net/~jbachorik/8076971/webrev.00
>
> The tests trying to access target JVMs via eg. 'jcmd' will fail on embedded configurations if the flag '-XX:+UsePerfData' is not specified.
>
> This patch adds this flag to the test application test builders thus making the target JVMs visible to 'jcmd'.
>
> Thanks,
>
> -JB-
From jaroslav.bachorik at oracle.com Fri Apr 24 11:28:05 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 24 Apr 2015 13:28:05 +0200
Subject: RFR 8077402: JMXStartStopTest fails intermittently on slow hosts
Message-ID: <553A28C5.70409@oracle.com>
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8077402
Webrev: http://cr.openjdk.java.net/~jbachorik/8077402/webrev.00
Currently, the test waits for 5*{timeout.factor} seconds for the target
application to start up before timing out. On extremely slow machines
even the timeout.factor will not assure a successful target application
startup and the test will fail sporadically.
The proposed solution is to defer timing-out to the test harness. The
test library will still take care of collecting the thread dump and
terminating any left-over processes (ProcessTools.startProcess()
methods). While this will not remedy the failures on extremely slow
machines it is better not to introduce any additional arbitrary time-out
limits.
As a part of this patch there is a small clarification in the javadoc of
ProcessTools.startProcess() method and a null check in
JMXStartStopTest$TestAppRun to prevent NPE hiding the timeout message.
Thanks,
-JB-
From staffan.larsen at oracle.com Fri Apr 24 11:38:19 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 24 Apr 2015 13:38:19 +0200
Subject: RFR 8077402: JMXStartStopTest fails intermittently on slow hosts
In-Reply-To: <553A28C5.70409@oracle.com>
References: <553A28C5.70409@oracle.com>
Message-ID: <08C16F8F-92E5-4C9C-8AB6-D1DA1B03FF94@oracle.com>
I think this looks good.
jtreg is not very good at cleaning up processes that are launched by a test since there are no APIs in Java to find these processes. However, such APIs are being added as part of JEP 102 and once present, jtreg will make use of them to try to clean up better.
/Staffan
> On 24 apr 2015, at 13:28, Jaroslav Bachorik wrote:
>
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8077402
> Webrev: http://cr.openjdk.java.net/~jbachorik/8077402/webrev.00
>
> Currently, the test waits for 5*{timeout.factor} seconds for the target application to start up before timing out. On extremely slow machines even the timeout.factor will not assure a successful target application startup and the test will fail sporadically.
>
> The proposed solution is to defer timing-out to the test harness. The test library will still take care of collecting the thread dump and terminating any left-over processes (ProcessTools.startProcess() methods). While this will not remedy the failures on extremely slow machines it is better not to introduce any additional arbitrary time-out limits.
>
> As a part of this patch there is a small clarification in the javadoc of ProcessTools.startProcess() method and a null check in JMXStartStopTest$TestAppRun to prevent NPE hiding the timeout message.
>
> Thanks,
>
> -JB-
From yekaterina.kantserova at oracle.com Fri Apr 24 14:17:41 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Fri, 24 Apr 2015 16:17:41 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To:
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
<1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
<85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com>
<553A0E2E.4090805@oracle.com>
Message-ID: <553A5085.10805@oracle.com>
All suggestions have been implemented. Please find new webrevs here:
webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02
webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02
webrev hotspot:
http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01
// Katja
On 04/24/2015 12:10 PM, Staffan Larsen wrote:
>
>> On 24 apr 2015, at 11:34, Yekaterina Kantserova
>> > > wrote:
>>
>> Hi,
>>
>> Here comes the updated version.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>>
>> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/
>>
>> webrev jdk:
>> http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/
>>
>
> test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java:
>
> In main() I think you should change the deleteOnExit() to just
> delete(). There is no reason to wait with it.
>
> Perhaps we should also verify that the file does not already exists
> before we try to write to it. If it exists, we can delete it.
>
>
>
>> webrev hotspot:
>> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/
>>
>
> test/serviceability/dcmd/gc/HeapDumpTest.java:
>
> Same thing: call delete() instead of deleteOnExit().
>
>
>>
>>
>> One comment about changes in hotspot part. The refactored version of
>> serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check:
>>
>> 70 /*
>> 71 * Some hprof dumps of all objects contain
>> constantPoolOop references that cannot be resolved, so we ignore
>> 72 * failures about resolving constantPoolOop fields
>> using a negative lookahead
>> 73 */
>> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to
>> resolve object.*constantPoolOop.*).*");
>>
>> It depends on that the current version of jdk.test.lib.hprof parser
>> simply write down warnings to stdout. As a result the test needs to
>> invent own logic to parse it.
>>
>> I suggest instead to improve jdk.test.lib.hprof parser as a separate
>> RFE. The parser will collect such information and provide a new
>> method for getting it, e.g.
>> jdk.test.lib.hprof.model.Snapshot.getWarnings(). The
>> serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly
>> when RFE is implemented.
>
> Sounds right. A quick, hacky solution is to redirect System.out to a
> stream or file while running the parser?
>
> /Staffan
>
>>
>>
>> Thanks,
>> Katja
>>
>>
>>
>> On 04/22/2015 03:09 PM, Staffan Larsen wrote:
>>> On 22 apr 2015, at 11:17, Yekaterina
>>> Kantserova>> > wrote:
>>> >>>>>
>>> >>>>>Hi,
>>> >>>>>
>>> >>>>>Could I please have a review of this fix.
>>> >>>>>
>>> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047
>>>
>>> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>>
>>> >>>>>
>>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool
>>> (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to put
>>> parser/validator into common test library since the functionality
>>> can be useful not only for SVC tools tests but even for some future
>>> GC tests.
>>> >>>>>
>>> >>>>>The old jhat packages have been moved as follows:
>>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>> >>>>>
>>> >>>>>The source has not been changed except Copyrights year.
>>> >>>>>
>>> >>>>>Thanks,
>>> >>>>>Katja
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From alexander.kulyakhtin at oracle.com Fri Apr 24 14:33:59 2015
From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin)
Date: Fri, 24 Apr 2015 07:33:59 -0700 (PDT)
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Message-ID:
Hi,
Could I, please, have a review of this tests-only change:
https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
Everywhere in the hotspot/test files import statements have been changed as needed.
Best regards,
Alex
From stefan.karlsson at oracle.com Fri Apr 24 14:41:38 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 24 Apr 2015 16:41:38 +0200
Subject: RFR: 8078601: print_concurrent_locks should be guarded with
INCLUDE_SERVICES
Message-ID: <553A5622.7040709@oracle.com>
Hi,
Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS.
http://cr.openjdk.java.net/~stefank/8078601/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8078601
This code in thread.cpp is guarded by INCLUDE_ALL_GCS:
#if INCLUDE_ALL_GCS
// Dump concurrent locks
ConcurrentLocksDump concurrent_locks;
if (print_concurrent_locks) {
concurrent_locks.dump_at_safepoint();
}
#endif // INCLUDE_ALL_GCS
but the code is not specific to any of our non-Serial GCs. The code
should be guarded by INCLUDE_SERVICES.
ConcurrentLocksDump::dump_at_safepoint() uses
HeapInspection::find_instances_at_safepoint, which is declared in
heapInspection.hpp:
static void find_instances_at_safepoint(Klass* k, GrowableArray*
result) NOT_SERVICES_RETURN;
and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See:
make/excludeSrc.make:
ifeq ($(INCLUDE_SERVICES), false)
CXXFLAGS += -DINCLUDE_SERVICES=0
CFLAGS += -DINCLUDE_SERVICES=0
Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \
attachListener_linux.cpp attachListener.cpp
endif
I've verified that this change builds with minimal1 and full HotSpot
slowdebug build.
Thanks,
Stefank
From staffan.larsen at oracle.com Fri Apr 24 15:08:31 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 24 Apr 2015 17:08:31 +0200
Subject: RFR: 8078601: print_concurrent_locks should be guarded with
INCLUDE_SERVICES
In-Reply-To: <553A5622.7040709@oracle.com>
References: <553A5622.7040709@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 24 apr 2015, at 16:41, Stefan Karlsson wrote:
>
> Hi,
>
> Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS.
>
> http://cr.openjdk.java.net/~stefank/8078601/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8078601
>
> This code in thread.cpp is guarded by INCLUDE_ALL_GCS:
> #if INCLUDE_ALL_GCS
> // Dump concurrent locks
> ConcurrentLocksDump concurrent_locks;
> if (print_concurrent_locks) {
> concurrent_locks.dump_at_safepoint();
> }
> #endif // INCLUDE_ALL_GCS
>
> but the code is not specific to any of our non-Serial GCs. The code should be guarded by INCLUDE_SERVICES.
>
> ConcurrentLocksDump::dump_at_safepoint() uses HeapInspection::find_instances_at_safepoint, which is declared in heapInspection.hpp:
> static void find_instances_at_safepoint(Klass* k, GrowableArray* result) NOT_SERVICES_RETURN;
>
> and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See: make/excludeSrc.make:
>
> ifeq ($(INCLUDE_SERVICES), false)
> CXXFLAGS += -DINCLUDE_SERVICES=0
> CFLAGS += -DINCLUDE_SERVICES=0
>
> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \
> attachListener_linux.cpp attachListener.cpp
> endif
>
> I've verified that this change builds with minimal1 and full HotSpot slowdebug build.
>
> Thanks,
> Stefank
From markus.gronlund at oracle.com Fri Apr 24 18:00:14 2015
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Fri, 24 Apr 2015 11:00:14 -0700 (PDT)
Subject: RFR: 8078601: print_concurrent_locks should be guarded with
INCLUDE_SERVICES
In-Reply-To:
References: <553A5622.7040709@oracle.com>
Message-ID:
Looks good!
Thanks
Markus
-----Original Message-----
From: Staffan Larsen
Sent: den 24 april 2015 11:09
To: Stefan Karlsson
Cc: Serviceability Dev
Subject: Re: RFR: 8078601: print_concurrent_locks should be guarded with INCLUDE_SERVICES
Looks good!
Thanks,
/Staffan
> On 24 apr 2015, at 16:41, Stefan Karlsson wrote:
>
> Hi,
>
> Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS.
>
> http://cr.openjdk.java.net/~stefank/8078601/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8078601
>
> This code in thread.cpp is guarded by INCLUDE_ALL_GCS:
> #if INCLUDE_ALL_GCS
> // Dump concurrent locks
> ConcurrentLocksDump concurrent_locks; if (print_concurrent_locks) {
> concurrent_locks.dump_at_safepoint();
> }
> #endif // INCLUDE_ALL_GCS
>
> but the code is not specific to any of our non-Serial GCs. The code should be guarded by INCLUDE_SERVICES.
>
> ConcurrentLocksDump::dump_at_safepoint() uses HeapInspection::find_instances_at_safepoint, which is declared in heapInspection.hpp:
> static void find_instances_at_safepoint(Klass* k, GrowableArray*
> result) NOT_SERVICES_RETURN;
>
> and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See: make/excludeSrc.make:
>
> ifeq ($(INCLUDE_SERVICES), false)
> CXXFLAGS += -DINCLUDE_SERVICES=0
> CFLAGS += -DINCLUDE_SERVICES=0
>
> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \
> attachListener_linux.cpp attachListener.cpp endif
>
> I've verified that this change builds with minimal1 and full HotSpot slowdebug build.
>
> Thanks,
> Stefank
From joe.darcy at oracle.com Fri Apr 24 18:04:24 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 24 Apr 2015 11:04:24 -0700
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <5539DB71.2070605@oracle.com>
References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com>
<5539DB71.2070605@oracle.com>
Message-ID: <553A85A8.7080207@oracle.com>
On 4/23/2015 10:58 PM, Alan Bateman wrote:
> On 24/04/2015 02:54, Joseph D. Darcy wrote:
>> Hello,
>>
>> Any additional comments on marking with tests in question with a
>> "randomness" keyword?
>>
>> Thanks,
>>
>> -Joe
>>
> I don't object to this keyword although I should say that most of the
> (apparent) randomness that I've seen hasn't been because of tests
> using Random but rather because of non-deterministic sequence of tests
> running in the same VM. The switch from othervm to agentvm a few years
> ago took a long time to weed out issues, same thing (even more) with
> -concurrency. Another source of apparent randomness is just having a
> large pool of machines and where machines are randomly selected to
> execute the tests.
>
> I agree with your comments that tests using Random should have report
> the seed and a have a way to re-run with the same value. It could help
> with some cases.
>
> One thing that isn't clear to me is how this keyword will be
> maintained. If I modify a test and replace the use of Random then I
> guess I need to remember to also remove this label. When I add a test
> that uses Random ... Just wondering if there is a tool to do the
> tests analysis, identify the use of specific APIs ,and help identify
> where the keyword might be missing or not needed.
>
The goal of the keyword is to enable better analysis of bug failures. We
(still) have some intermittent test failures in the platform, some
probably remaining from -concurrency issues and some due to inconsistent
machine config issues on the test farms. However, there is reason to
believe some of the tests also fail because of the use of randomness in
the generation of test cases. For example, the test
java/lang/invoke/MethodHandles/CatchExceptionTest.java
fails about once every three hundred runs when the random cases it
generates trigger an error condition. Setting the seed to known-bad
value causes the test to fail consistently (JDK-8055269). I have
suspicions some of our other intermittently failing tests are in a
similar but undiagnosed situation.
If a test uses randomness, I think the default assumed cause for a test
failure should switch from environmental causes (bad machine config,
etc.) to the random behavior. Therefore, when a random-using test fails,
I think the failure analysis needs to include recording of the bad seed
to see if the failure is reproducible / deterministic with a fixed seed
value.
I was very surprised by the large number of random-using tests in the
JDK regression tests. Nearly all of these have been stably passing for
many years. After the one-time cost of this large update to add the
keywords, there would be a small amount of incremental test maintenance
as new random-using tests were added or the randomness value of a test
changed. However, I would expect whether or not a test used randomness
to be a property of a test that very rarely changed.
Thanks,
-Joe
From david.holmes at oracle.com Fri Apr 24 21:49:04 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 25 Apr 2015 07:49:04 +1000
Subject: RFR: 8078601: print_concurrent_locks should be guarded with
INCLUDE_SERVICES
In-Reply-To: <553A5622.7040709@oracle.com>
References: <553A5622.7040709@oracle.com>
Message-ID: <553ABA50.4020409@oracle.com>
Looks good. Thanks Stefan.
David
On 25/04/2015 12:41 AM, Stefan Karlsson wrote:
> Hi,
>
> Please review this patch to fix an incorrect usage of #if INCLUDE_ALL_GCS.
>
> http://cr.openjdk.java.net/~stefank/8078601/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8078601
>
> This code in thread.cpp is guarded by INCLUDE_ALL_GCS:
> #if INCLUDE_ALL_GCS
> // Dump concurrent locks
> ConcurrentLocksDump concurrent_locks;
> if (print_concurrent_locks) {
> concurrent_locks.dump_at_safepoint();
> }
> #endif // INCLUDE_ALL_GCS
>
> but the code is not specific to any of our non-Serial GCs. The code
> should be guarded by INCLUDE_SERVICES.
>
> ConcurrentLocksDump::dump_at_safepoint() uses
> HeapInspection::find_instances_at_safepoint, which is declared in
> heapInspection.hpp:
> static void find_instances_at_safepoint(Klass* k, GrowableArray*
> result) NOT_SERVICES_RETURN;
>
> and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See:
> make/excludeSrc.make:
>
> ifeq ($(INCLUDE_SERVICES), false)
> CXXFLAGS += -DINCLUDE_SERVICES=0
> CFLAGS += -DINCLUDE_SERVICES=0
>
> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \
> attachListener_linux.cpp attachListener.cpp
> endif
>
> I've verified that this change builds with minimal1 and full HotSpot
> slowdebug build.
>
> Thanks,
> Stefank
From david.holmes at oracle.com Mon Apr 27 00:17:14 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 27 Apr 2015 10:17:14 +1000
Subject: RFR 8076971: sun/management/jmxremote/startstop/JMXStatusTest.java
failed with AssertionError
In-Reply-To: <553A1989.9010909@oracle.com>
References: <553A1989.9010909@oracle.com>
Message-ID: <553D800A.3060702@oracle.com>
Looks okay.
Thanks,
David
On 24/04/2015 8:23 PM, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8076971
> Webrev: http://cr.openjdk.java.net/~jbachorik/8076971/webrev.00
>
> The tests trying to access target JVMs via eg. 'jcmd' will fail on
> embedded configurations if the flag '-XX:+UsePerfData' is not specified.
>
> This patch adds this flag to the test application test builders thus
> making the target JVMs visible to 'jcmd'.
>
> Thanks,
>
> -JB-
From david.holmes at oracle.com Mon Apr 27 00:26:18 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 27 Apr 2015 10:26:18 +1000
Subject: RFR 8077402: JMXStartStopTest fails intermittently on slow hosts
In-Reply-To: <553A28C5.70409@oracle.com>
References: <553A28C5.70409@oracle.com>
Message-ID: <553D822A.6090303@oracle.com>
Looks okay.
Thanks,
David
On 24/04/2015 9:28 PM, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8077402
> Webrev: http://cr.openjdk.java.net/~jbachorik/8077402/webrev.00
>
> Currently, the test waits for 5*{timeout.factor} seconds for the target
> application to start up before timing out. On extremely slow machines
> even the timeout.factor will not assure a successful target application
> startup and the test will fail sporadically.
>
> The proposed solution is to defer timing-out to the test harness. The
> test library will still take care of collecting the thread dump and
> terminating any left-over processes (ProcessTools.startProcess()
> methods). While this will not remedy the failures on extremely slow
> machines it is better not to introduce any additional arbitrary time-out
> limits.
>
> As a part of this patch there is a small clarification in the javadoc of
> ProcessTools.startProcess() method and a null check in
> JMXStartStopTest$TestAppRun to prevent NPE hiding the timeout message.
>
> Thanks,
>
> -JB-
From david.holmes at oracle.com Mon Apr 27 01:39:28 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 27 Apr 2015 11:39:28 +1000
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
In-Reply-To:
References:
Message-ID: <553D9350.3060206@oracle.com>
Hi Alex,
On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
> Hi,
>
> Could I, please, have a review of this tests-only change:
>
> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
>
> The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
I presume this is a first step towards fixing:
https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test
libraries) ?
> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
Did you use "hg rename" for that? The webrev suggests not as it shows
deleted and added files rather than moved ones.
> Everywhere in the hotspot/test files import statements have been changed as needed.
Seems okay based on scanning through the patch.
Copyright dates will need updating in many cases.
Thanks,
David
> Best regards,
> Alex
>
>
>
From stefan.karlsson at oracle.com Mon Apr 27 07:10:10 2015
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 27 Apr 2015 09:10:10 +0200
Subject: RFR: 8078601: print_concurrent_locks should be guarded with
INCLUDE_SERVICES
In-Reply-To: <553ABA50.4020409@oracle.com>
References: <553A5622.7040709@oracle.com> <553ABA50.4020409@oracle.com>
Message-ID: <553DE0D2.6010600@oracle.com>
On 2015-04-24 23:49, David Holmes wrote:
> Looks good. Thanks Stefan.
Thanks, David.
StefanK
>
> David
>
> On 25/04/2015 12:41 AM, Stefan Karlsson wrote:
>> Hi,
>>
>> Please review this patch to fix an incorrect usage of #if
>> INCLUDE_ALL_GCS.
>>
>> http://cr.openjdk.java.net/~stefank/8078601/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8078601
>>
>> This code in thread.cpp is guarded by INCLUDE_ALL_GCS:
>> #if INCLUDE_ALL_GCS
>> // Dump concurrent locks
>> ConcurrentLocksDump concurrent_locks;
>> if (print_concurrent_locks) {
>> concurrent_locks.dump_at_safepoint();
>> }
>> #endif // INCLUDE_ALL_GCS
>>
>> but the code is not specific to any of our non-Serial GCs. The code
>> should be guarded by INCLUDE_SERVICES.
>>
>> ConcurrentLocksDump::dump_at_safepoint() uses
>> HeapInspection::find_instances_at_safepoint, which is declared in
>> heapInspection.hpp:
>> static void find_instances_at_safepoint(Klass* k, GrowableArray*
>> result) NOT_SERVICES_RETURN;
>>
>> and heapInspection.cpp is excluded when INCLUDE_SERVICES is false. See:
>> make/excludeSrc.make:
>>
>> ifeq ($(INCLUDE_SERVICES), false)
>> CXXFLAGS += -DINCLUDE_SERVICES=0
>> CFLAGS += -DINCLUDE_SERVICES=0
>>
>> Src_Files_EXCLUDE += heapDumper.cpp heapInspection.cpp \
>> attachListener_linux.cpp attachListener.cpp
>> endif
>>
>> I've verified that this change builds with minimal1 and full HotSpot
>> slowdebug build.
>>
>> Thanks,
>> Stefank
From cheleswer.sahu at oracle.com Mon Apr 27 13:43:25 2015
From: cheleswer.sahu at oracle.com (cheleswer sahu)
Date: Mon, 27 Apr 2015 19:13:25 +0530
Subject: [8u60] request for approval: 8072863: Replace fatal() with
vm_exit_during_initialization()
when an incorrect class is found on the bootclasspath
In-Reply-To: <553E1708.9090301@oracle.com>
References: <553E1708.9090301@oracle.com>
Message-ID: <553E3CFD.7070408@oracle.com>
Hi!
May I please have approval to backport this fix from JDK9 to JDK8. I have built the JDK-8 hotspot and tested already. JDK9 fix applies cleanly to JDK8. As I do not have an account for OPENJDK, David Buck will push the fix into jdk8u/hs-dev/hotspot.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072863
JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f47b463a95b8
Review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-April/014392.html
Regards,
Cheleswer
From coleen.phillimore at oracle.com Mon Apr 27 17:49:56 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 27 Apr 2015 13:49:56 -0400
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <552832AF.8080204@oracle.com>
References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com>
Message-ID: <553E76C4.6090401@oracle.com>
Serguei,
This looks nice. I thought this change was going to delay calling
AdjustCpoolCacheAndVtable until the end of the redefinition, rather than
for each class, so was a bit confused by the change.
Your change is a nice cleanup and improves MethodHandle method
replacement performance.
Your backport may not be simple for jdk8 because PreviousVersionNode is
another type and not an InstanceKlass. Maybe you've convinced me that
it's worth backporting those changes too. Let me know.
Thanks,
Coleen
On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen and Dan,
>
> This is the second class redefinition scalability/optimization fix
> that is in my queue to push into 9 and 8u60.
>
> The approach is similar to the first one but much smaller.
> For convenience, these are the links to the first scalability fix:
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>
> Please, let me know if you have any chance to review this.
> This is the last one that is waiting for your attention! :)
>
> Thanks,
> Serguei
>
> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8073705
>>
>>
>> Open hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>>
>>
>>
>> Summary:
>>
>> This is the 2-nd round of performance/calability fixes in class
>> redefinition.
>> This time, the two remaining issues that were left alone in the
>> first round fix:
>> - optimized ConstantPoolCache::adjust_method_entries() is used
>> for previous versions
>> - the MemberNameTable::adjust_method_entries() has been
>> optimized too
>> - some cleanup
>>
>>
>> Testing:
>> In progress: nsk redefine classes tests, JTREG
>> java/lang/instrument, com/sun/jdi
>>
>>
>> Thanks,
>> Serguei
>>
>
From serguei.spitsyn at oracle.com Mon Apr 27 20:05:54 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 27 Apr 2015 13:05:54 -0700
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <553E76C4.6090401@oracle.com>
References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com>
<553E76C4.6090401@oracle.com>
Message-ID: <553E96A2.3050000@oracle.com>
Hi Coleen,
Thank you for the review!
On 4/27/15 10:49 AM, Coleen Phillimore wrote:
>
> Serguei,
>
> This looks nice. I thought this change was going to delay calling
> AdjustCpoolCacheAndVtable until the end of the redefinition, rather
> than for each class, so was a bit confused by the change.
I consider this for as a next round of optimizations which is more risky.
We need to decide when we are Ok to take this risk.
My guess is that it is better to do it together with the constant pool
merge elimination.
>
> Your change is a nice cleanup and improves MethodHandle method
> replacement performance.
Thanks!
>
> Your backport may not be simple for jdk8 because PreviousVersionNode
> is another type and not an InstanceKlass. Maybe you've convinced me
> that it's worth backporting those changes too. Let me know.
I've already backported the first chunk where this problem was hit.
It seems, this one should not be harder to backport.
Thanks!
Serguei
>
> Thanks,
> Coleen
>
> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Coleen and Dan,
>>
>> This is the second class redefinition scalability/optimization fix
>> that is in my queue to push into 9 and 8u60.
>>
>> The approach is similar to the first one but much smaller.
>> For convenience, these are the links to the first scalability fix:
>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>>
>> Please, let me know if you have any chance to review this.
>> This is the last one that is waiting for your attention! :)
>>
>> Thanks,
>> Serguei
>>
>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8073705
>>>
>>>
>>> Open hotspot webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>>>
>>>
>>>
>>> Summary:
>>>
>>> This is the 2-nd round of performance/calability fixes in class
>>> redefinition.
>>> This time, the two remaining issues that were left alone in the
>>> first round fix:
>>> - optimized ConstantPoolCache::adjust_method_entries() is used
>>> for previous versions
>>> - the MemberNameTable::adjust_method_entries() has been
>>> optimized too
>>> - some cleanup
>>>
>>>
>>> Testing:
>>> In progress: nsk redefine classes tests, JTREG
>>> java/lang/instrument, com/sun/jdi
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>
>
From serguei.spitsyn at oracle.com Mon Apr 27 20:25:08 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 27 Apr 2015 13:25:08 -0700
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <553E96A2.3050000@oracle.com>
References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com>
<553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com>
Message-ID: <553E9B24.3080809@oracle.com>
On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
> Thank you for the review!
>
> On 4/27/15 10:49 AM, Coleen Phillimore wrote:
>>
>> Serguei,
>>
>> This looks nice. I thought this change was going to delay calling
>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather
>> than for each class, so was a bit confused by the change.
>
> I consider this for as a next round of optimizations which is more risky.
> We need to decide when we are Ok to take this risk.
> My guess is that it is better to do it together with the constant pool
> merge elimination.
Sorry, I forgot to tell that my plan is to open another bug that should
cover moving all this adjustments to the end of redefinition.
This was a source of the confusion!
Thanks,
Serguei
>
>>
>> Your change is a nice cleanup and improves MethodHandle method
>> replacement performance.
>
> Thanks!
>
>>
>> Your backport may not be simple for jdk8 because PreviousVersionNode
>> is another type and not an InstanceKlass. Maybe you've convinced me
>> that it's worth backporting those changes too. Let me know.
>
> I've already backported the first chunk where this problem was hit.
> It seems, this one should not be harder to backport.
>
> Thanks!
> Serguei
>
>>
>> Thanks,
>> Coleen
>>
>> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Coleen and Dan,
>>>
>>> This is the second class redefinition scalability/optimization fix
>>> that is in my queue to push into 9 and 8u60.
>>>
>>> The approach is similar to the first one but much smaller.
>>> For convenience, these are the links to the first scalability fix:
>>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>>>
>>> Please, let me know if you have any chance to review this.
>>> This is the last one that is waiting for your attention! :)
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the fix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8073705
>>>>
>>>>
>>>> Open hotspot webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>>>>
>>>>
>>>>
>>>> Summary:
>>>>
>>>> This is the 2-nd round of performance/calability fixes in class
>>>> redefinition.
>>>> This time, the two remaining issues that were left alone in the
>>>> first round fix:
>>>> - optimized ConstantPoolCache::adjust_method_entries() is used
>>>> for previous versions
>>>> - the MemberNameTable::adjust_method_entries() has been
>>>> optimized too
>>>> - some cleanup
>>>>
>>>>
>>>> Testing:
>>>> In progress: nsk redefine classes tests, JTREG
>>>> java/lang/instrument, com/sun/jdi
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>
>>
>
From serguei.spitsyn at oracle.com Mon Apr 27 21:12:59 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 27 Apr 2015 14:12:59 -0700
Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint
sets last method param to exception
Message-ID: <553EA65B.6080805@oracle.com>
Please, review the jdk 9 fix for:
https://bugs.openjdk.java.net/browse/JDK-8076579
9 hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1
Summary:
This bug is a regression that was introduced but the fix of:
https://bugs.openjdk.java.net/browse/JDK-7187554
The bug is in the InterpreterRuntime::member_name_arg_or_null()
function that
does not return NULL if there is no invokestatic appendix argument
(MemberName).
It is why the _remove_activation_preserving_args is trying to to
restore unexisting
appendix argument when a pop instruction is executed by a debugger in
the debuggee VM.
The fix is to correctly set NULL in the thread vm_result when it is
necessary:
thread->set_vm_result(NULL);
Testing in progress:
In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests,
JTREG com/sun/jdi tests,
ad-hog ExceptionBug.java test from the bug report
Thanks,
Serguei
From serguei.spitsyn at oracle.com Tue Apr 28 04:27:46 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 27 Apr 2015 21:27:46 -0700
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <553E9B24.3080809@oracle.com>
References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com>
<553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com>
<553E9B24.3080809@oracle.com>
Message-ID: <553F0C42.4060000@oracle.com>
On 4/27/15 1:25 PM, serguei.spitsyn at oracle.com wrote:
> On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Coleen,
>>
>> Thank you for the review!
>>
>> On 4/27/15 10:49 AM, Coleen Phillimore wrote:
>>>
>>> Serguei,
>>>
>>> This looks nice. I thought this change was going to delay calling
>>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather
>>> than for each class, so was a bit confused by the change.
>>
>> I consider this for as a next round of optimizations which is more
>> risky.
>> We need to decide when we are Ok to take this risk.
>> My guess is that it is better to do it together with the constant
>> pool merge elimination.
>
> Sorry, I forgot to tell that my plan is to open another bug that should
> cover moving all this adjustments to the end of redefinition.
> This was a source of the confusion!
I've filed a separate bug report for the above:
https://bugs.openjdk.java.net/browse/JDK-8078725
Thanks,
Serguei
>
> Thanks,
> Serguei
>
>>
>>>
>>> Your change is a nice cleanup and improves MethodHandle method
>>> replacement performance.
>>
>> Thanks!
>>
>>>
>>> Your backport may not be simple for jdk8 because PreviousVersionNode
>>> is another type and not an InstanceKlass. Maybe you've convinced me
>>> that it's worth backporting those changes too. Let me know.
>>
>> I've already backported the first chunk where this problem was hit.
>> It seems, this one should not be harder to backport.
>>
>> Thanks!
>> Serguei
>>
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Coleen and Dan,
>>>>
>>>> This is the second class redefinition scalability/optimization fix
>>>> that is in my queue to push into 9 and 8u60.
>>>>
>>>> The approach is similar to the first one but much smaller.
>>>> For convenience, these are the links to the first scalability fix:
>>>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>>>>
>>>> Please, let me know if you have any chance to review this.
>>>> This is the last one that is waiting for your attention! :)
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the fix for:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8073705
>>>>>
>>>>>
>>>>> Open hotspot webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>>
>>>>> This is the 2-nd round of performance/calability fixes in class
>>>>> redefinition.
>>>>> This time, the two remaining issues that were left alone in the
>>>>> first round fix:
>>>>> - optimized ConstantPoolCache::adjust_method_entries() is
>>>>> used for previous versions
>>>>> - the MemberNameTable::adjust_method_entries() has been
>>>>> optimized too
>>>>> - some cleanup
>>>>>
>>>>>
>>>>> Testing:
>>>>> In progress: nsk redefine classes tests, JTREG
>>>>> java/lang/instrument, com/sun/jdi
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>
>>>
>>
>
From david.holmes at oracle.com Tue Apr 28 06:17:15 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Apr 2015 16:17:15 +1000
Subject: [8u60] request for approval: 8072863: Replace fatal() with
vm_exit_during_initialization()
when an incorrect class is found on the bootclasspath
In-Reply-To: <553E3CFD.7070408@oracle.com>
References: <553E1708.9090301@oracle.com> <553E3CFD.7070408@oracle.com>
Message-ID: <553F25EB.6060807@oracle.com>
Approved.
Thanks,
David
On 27/04/2015 11:43 PM, cheleswer sahu wrote:
> Hi!
>
> May I please have approval to backport this fix from JDK9 to JDK8. I
> have built the JDK-8 hotspot and tested already. JDK9 fix applies
> cleanly to JDK8. As I do not have an account for OPENJDK, David Buck
> will push the fix into jdk8u/hs-dev/hotspot.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072863
>
> JDK9 changeset:
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/f47b463a95b8
>
> Review thread:
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-April/014392.html
>
>
> Regards,
> Cheleswer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
From alexander.kulyakhtin at oracle.com Tue Apr 28 08:55:42 2015
From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin)
Date: Tue, 28 Apr 2015 01:55:42 -0700 (PDT)
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Message-ID:
Hi,
Could someone, please, comment on the proposed renaming from com.oracle.java.testlibrary to jdk.test.lib in the hotspot repo?
The changes have been verified by running all the hotspot tests and making sure there are no compilation or other errors related to the change.
Best regards,
Alexander
----- Original Message -----
From: alexander.kulyakhtin at oracle.com
To: serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
Sent: Friday, April 24, 2015 5:34:22 PM GMT +03:00 Iraq
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Hi,
Could I, please, have a review of this tests-only change:
https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
Everywhere in the hotspot/test files import statements have been changed as needed.
Best regards,
Alex
From alexander.kulyakhtin at oracle.com Tue Apr 28 11:08:54 2015
From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin)
Date: Tue, 28 Apr 2015 04:08:54 -0700 (PDT)
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Message-ID:
Hi David,
Thank you very much for your comments.
> I presume this is a first step towards fixing:
> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ?
Yes, this is correct
> Did you use "hg rename" for that? The webrev suggests not as it shows
No, I used hg add and hg delete.
I'm going to fix this now by doing hg rename
> Copyright dates will need updating in many cases.
I'm going to update the copyrights
I'll send out the updated webrev as soon as I'm done.
Best regards,
Alex
----- Original Message -----
From: david.holmes at oracle.com
To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Hi Alex,
On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
> Hi,
>
> Could I, please, have a review of this tests-only change:
>
> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
>
> The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
deleted and added files rather than moved ones.
> Everywhere in the hotspot/test files import statements have been changed as needed.
Seems okay based on scanning through the patch.
Copyright dates will need updating in many cases.
Thanks,
David
> Best regards,
> Alex
>
>
>
From staffan.larsen at oracle.com Tue Apr 28 12:05:43 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 28 Apr 2015 14:05:43 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To: <553A5085.10805@oracle.com>
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
<1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
<85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com>
<553A0E2E.4090805@oracle.com>
<553A5085.10805@oracle.com>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 24 apr 2015, at 16:17, Yekaterina Kantserova wrote:
>
> All suggestions have been implemented. Please find new webrevs here:
>
> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02
> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02
> webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01
>
> // Katja
>
>
>
> On 04/24/2015 12:10 PM, Staffan Larsen wrote:
>>
>>> On 24 apr 2015, at 11:34, Yekaterina Kantserova > wrote:
>>>
>>> Hi,
>>>
>>> Here comes the updated version.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>>>
>>> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/
>>> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/
>>
>> test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java:
>>
>> In main() I think you should change the deleteOnExit() to just delete(). There is no reason to wait with it.
>>
>> Perhaps we should also verify that the file does not already exists before we try to write to it. If it exists, we can delete it.
>>
>>
>>
>>> webrev hotspot: http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/
>>
>> test/serviceability/dcmd/gc/HeapDumpTest.java:
>>
>> Same thing: call delete() instead of deleteOnExit().
>>
>>
>>>
>>>
>>> One comment about changes in hotspot part. The refactored version of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check:
>>>
>>> 70 /*
>>> 71 * Some hprof dumps of all objects contain constantPoolOop references that cannot be resolved, so we ignore
>>> 72 * failures about resolving constantPoolOop fields using a negative lookahead
>>> 73 */
>>> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to resolve object.*constantPoolOop.*).*");
>>>
>>> It depends on that the current version of jdk.test.lib.hprof parser simply write down warnings to stdout. As a result the test needs to invent own logic to parse it.
>>>
>>> I suggest instead to improve jdk.test.lib.hprof parser as a separate RFE. The parser will collect such information and provide a new method for getting it, e.g. jdk.test.lib.hprof.model.Snapshot.getWarnings(). The serviceability/dcmd/gc/HeapDumpTest.java will be changed accordingly when RFE is implemented.
>>
>> Sounds right. A quick, hacky solution is to redirect System.out to a stream or file while running the parser?
>>
>> /Staffan
>>
>>>
>>>
>>> Thanks,
>>> Katja
>>>
>>>
>>>
>>> On 04/22/2015 03:09 PM, Staffan Larsen wrote:
>>>> On 22 apr 2015, at 11:17, Yekaterina Kantserova> wrote:
>>>> >>>>>
>>>> >>>>>Hi,
>>>> >>>>>
>>>> >>>>>Could I please have a review of this fix.
>>>> >>>>>
>>>> >>>>>bug:https:// bugs.openjdk.java.net/browse/JDK-8059047
>>>> >>>>>webrev:http:// cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>>> >>>>>
>>>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool (https://bugs.openjdk.java.net/browse/JDK-8059039 ). I suggest to put parser/validator into common test library since the functionality can be useful not only for SVC tools tests but even for some future GC tests.
>>>> >>>>>
>>>> >>>>>The old jhat packages have been moved as follows:
>>>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>>>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>>>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>>> >>>>>
>>>> >>>>>The source has not been changed except Copyrights year.
>>>> >>>>>
>>>> >>>>>Thanks,
>>>> >>>>>Katja
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From yekaterina.kantserova at oracle.com Tue Apr 28 12:11:38 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Tue, 28 Apr 2015 14:11:38 +0200
Subject: RFR(M): 8059047: Extract parser/validator from jhat for use in
tests
In-Reply-To:
References: <55376716.10806@oracle.com>
<68C1884F-92C7-4224-BD54-2CA03F36F441@oracle.com>
<55379321.1090403@oracle.com>
<1F11945C-A588-4348-90D0-D1D56757E2D2@oracle.com>
<85215D92-AA71-4A77-8361-EDCC1AB546A9@oracle.com>
<553A0E2E.4090805@oracle.com>
<553A5085.10805@oracle.com>
Message-ID: <553F78FA.3090202@oracle.com>
Staffan,
Thanks for the review!
// Katja
On 04/28/2015 02:05 PM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
>> On 24 apr 2015, at 16:17, Yekaterina Kantserova
>> > > wrote:
>>
>> All suggestions have been implemented. Please find new webrevs here:
>>
>> webrev root: http://cr.openjdk.java.net/~ykantser/8059047/webrev.02
>> webrev jdk: http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.02
>> webrev hotspot:
>> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.01
>>
>> // Katja
>>
>>
>>
>> On 04/24/2015 12:10 PM, Staffan Larsen wrote:
>>>
>>>> On 24 apr 2015, at 11:34, Yekaterina Kantserova
>>>> >>> > wrote:
>>>>
>>>> Hi,
>>>>
>>>> Here comes the updated version.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8059047
>>>>
>>>> webrev root:
>>>> http://cr.openjdk.java.net/~ykantser/8059047/webrev.01/
>>>>
>>>> webrev jdk:
>>>> http://cr.openjdk.java.net/~ykantser/8059047.jdk/webrev.01/
>>>>
>>>
>>> test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java:
>>>
>>> In main() I think you should change the deleteOnExit() to just
>>> delete(). There is no reason to wait with it.
>>>
>>> Perhaps we should also verify that the file does not already exists
>>> before we try to write to it. If it exists, we can delete it.
>>>
>>>
>>>
>>>> webrev hotspot:
>>>> http://cr.openjdk.java.net/~ykantser/8059047.hotspot/webrev.00/
>>>>
>>>
>>> test/serviceability/dcmd/gc/HeapDumpTest.java:
>>>
>>> Same thing: call delete() instead of deleteOnExit().
>>>
>>>
>>>>
>>>>
>>>> One comment about changes in hotspot part. The refactored version
>>>> of serviceability/dcmd/gc/HeapDumpTest.java doesn't contain check:
>>>>
>>>> 70 /*
>>>> 71 * Some hprof dumps of all objects contain
>>>> constantPoolOop references that cannot be resolved, so we ignore
>>>> 72 * failures about resolving constantPoolOop fields
>>>> using a negative lookahead
>>>> 73 */
>>>> 74 output.shouldNotMatch(".*WARNING(?!.*Failed to
>>>> resolve object.*constantPoolOop.*).*");
>>>>
>>>> It depends on that the current version of jdk.test.lib.hprof parser
>>>> simply write down warnings to stdout. As a result the test needs to
>>>> invent own logic to parse it.
>>>>
>>>> I suggest instead to improve jdk.test.lib.hprof parser as a
>>>> separate RFE. The parser will collect such information and provide
>>>> a new method for getting it, e.g.
>>>> jdk.test.lib.hprof.model.Snapshot.getWarnings(). The
>>>> serviceability/dcmd/gc/HeapDumpTest.java will be changed
>>>> accordingly when RFE is implemented.
>>>
>>> Sounds right. A quick, hacky solution is to redirect System.out to a
>>> stream or file while running the parser?
>>>
>>> /Staffan
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Katja
>>>>
>>>>
>>>>
>>>> On 04/22/2015 03:09 PM, Staffan Larsen wrote:
>>>>> On 22 apr 2015, at 11:17, Yekaterina
>>>>> Kantserova>>>> > wrote:
>>>>> >>>>>
>>>>> >>>>>Hi,
>>>>> >>>>>
>>>>> >>>>>Could I please have a review of this fix.
>>>>> >>>>>
>>>>> >>>>>bug:https://bugs.openjdk.java.net/browse/JDK-8059047
>>>>>
>>>>> >>>>>webrev:http://cr.openjdk.java.net/~ykantser/8059047/webrev.00/
>>>>> >>>>>
>>>>> >>>>>This fix is a part of JEP 241: Remove the jhat Tool
>>>>> (https://bugs.openjdk.java.net/browse/JDK-8059039). I suggest to
>>>>> put parser/validator into common test library since the
>>>>> functionality can be useful not only for SVC tools tests but even
>>>>> for some future GC tests.
>>>>> >>>>>
>>>>> >>>>>The old jhat packages have been moved as follows:
>>>>> >>>>>com.sun.tools.hat.internal.model -> jdk.test.lib.hprof.model
>>>>> >>>>>com.sun.tools.hat.internal.parser -> jdk.test.lib.hprof.parser
>>>>> >>>>>com.sun.tools.hat.internal.util -> jdk.test.lib.hprof.util
>>>>> >>>>>
>>>>> >>>>>The source has not been changed except Copyrights year.
>>>>> >>>>>
>>>>> >>>>>Thanks,
>>>>> >>>>>Katja
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From alexander.kulyakhtin at oracle.com Tue Apr 28 13:09:43 2015
From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin)
Date: Tue, 28 Apr 2015 06:09:43 -0700 (PDT)
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Message-ID: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default>
Hi,
I've updated the webrev in accordance with David's comments.
Could you, please, review the changes:
> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html
Best regards,
Alex
----- Original Message -----
From: alexander.kulyakhtin at oracle.com
To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net
Cc: serviceability-dev at openjdk.java.net
Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Hi David,
Thank you very much for your comments.
> I presume this is a first step towards fixing:
> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ?
Yes, this is correct
> Did you use "hg rename" for that? The webrev suggests not as it shows
No, I used hg add and hg delete.
I'm going to fix this now by doing hg rename
> Copyright dates will need updating in many cases.
I'm going to update the copyrights
I'll send out the updated webrev as soon as I'm done.
Best regards,
Alex
----- Original Message -----
From: david.holmes at oracle.com
To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Hi Alex,
On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
> Hi,
>
> Could I, please, have a review of this tests-only change:
>
> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
>
> The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
deleted and added files rather than moved ones.
> Everywhere in the hotspot/test files import statements have been changed as needed.
Seems okay based on scanning through the patch.
Copyright dates will need updating in many cases.
Thanks,
David
> Best regards,
> Alex
>
>
>
From coleen.phillimore at oracle.com Tue Apr 28 13:58:46 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 28 Apr 2015 09:58:46 -0400
Subject: RFR (S) 8073705: more performance issues in class redefinition
In-Reply-To: <553F0C42.4060000@oracle.com>
References: <5514C2C1.9040302@oracle.com> <552832AF.8080204@oracle.com>
<553E76C4.6090401@oracle.com> <553E96A2.3050000@oracle.com>
<553E9B24.3080809@oracle.com> <553F0C42.4060000@oracle.com>
Message-ID: <553F9216.6080106@oracle.com>
On 4/28/15, 12:27 AM, serguei.spitsyn at oracle.com wrote:
> On 4/27/15 1:25 PM, serguei.spitsyn at oracle.com wrote:
>> On 4/27/15 1:05 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Coleen,
>>>
>>> Thank you for the review!
>>>
>>> On 4/27/15 10:49 AM, Coleen Phillimore wrote:
>>>>
>>>> Serguei,
>>>>
>>>> This looks nice. I thought this change was going to delay calling
>>>> AdjustCpoolCacheAndVtable until the end of the redefinition, rather
>>>> than for each class, so was a bit confused by the change.
>>>
>>> I consider this for as a next round of optimizations which is more
>>> risky.
>>> We need to decide when we are Ok to take this risk.
>>> My guess is that it is better to do it together with the constant
>>> pool merge elimination.
>>
>> Sorry, I forgot to tell that my plan is to open another bug that should
>> cover moving all this adjustments to the end of redefinition.
>> This was a source of the confusion!
>
> I've filed a separate bug report for the above:
> https://bugs.openjdk.java.net/browse/JDK-8078725
This is good. I'll watch this next bug. Yes, the optimizations are
more risky here but I think they would still use the same code. But it
definitely needs more testing.
Coleen
>
>
> Thanks,
> Serguei
>
>>
>> Thanks,
>> Serguei
>>
>>>
>>>>
>>>> Your change is a nice cleanup and improves MethodHandle method
>>>> replacement performance.
>>>
>>> Thanks!
>>>
>>>>
>>>> Your backport may not be simple for jdk8 because
>>>> PreviousVersionNode is another type and not an InstanceKlass. Maybe
>>>> you've convinced me that it's worth backporting those changes too.
>>>> Let me know.
>>>
>>> I've already backported the first chunk where this problem was hit.
>>> It seems, this one should not be harder to backport.
>>>
>>> Thanks!
>>> Serguei
>>>
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 4/10/15, 4:29 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Hi Coleen and Dan,
>>>>>
>>>>> This is the second class redefinition scalability/optimization fix
>>>>> that is in my queue to push into 9 and 8u60.
>>>>>
>>>>> The approach is similar to the first one but much smaller.
>>>>> For convenience, these are the links to the first scalability fix:
>>>>> Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
>>>>>
>>>>> Please, let me know if you have any chance to review this.
>>>>> This is the last one that is waiting for your attention! :)
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>> On 3/26/15 7:38 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> Please, review the fix for:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8073705
>>>>>>
>>>>>>
>>>>>> Open hotspot webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
>>>>>>
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> This is the 2-nd round of performance/calability fixes in
>>>>>> class redefinition.
>>>>>> This time, the two remaining issues that were left alone in
>>>>>> the first round fix:
>>>>>> - optimized ConstantPoolCache::adjust_method_entries() is
>>>>>> used for previous versions
>>>>>> - the MemberNameTable::adjust_method_entries() has been
>>>>>> optimized too
>>>>>> - some cleanup
>>>>>>
>>>>>>
>>>>>> Testing:
>>>>>> In progress: nsk redefine classes tests, JTREG
>>>>>> java/lang/instrument, com/sun/jdi
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>
>>>>
>>>
>>
>
From staffan.larsen at oracle.com Tue Apr 28 15:09:53 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 28 Apr 2015 17:09:53 +0200
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
In-Reply-To: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default>
References: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default>
Message-ID:
Looks good!
Thanks,
/Staffan
> On 28 apr 2015, at 15:09, Alexander Kulyakhtin wrote:
>
> Hi,
>
> I've updated the webrev in accordance with David's comments.
>
> Could you, please, review the changes:
>
>> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
>> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html
>
> Best regards,
> Alex
>
>
> ----- Original Message -----
> From: alexander.kulyakhtin at oracle.com
> To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net
> Cc: serviceability-dev at openjdk.java.net
> Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq
> Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
>
> Hi David,
>
> Thank you very much for your comments.
>
>> I presume this is a first step towards fixing:
>> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ?
> Yes, this is correct
>
>> Did you use "hg rename" for that? The webrev suggests not as it shows
> No, I used hg add and hg delete.
> I'm going to fix this now by doing hg rename
>
>> Copyright dates will need updating in many cases.
> I'm going to update the copyrights
>
> I'll send out the updated webrev as soon as I'm done.
>
> Best regards,
> Alex
>
> ----- Original Message -----
> From: david.holmes at oracle.com
> To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
> Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq
> Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
>
> Hi Alex,
>
> On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
>> Hi,
>>
>> Could I, please, have a review of this tests-only change:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
>> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
>>
>> The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
>
>
>
>> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
>
> deleted and added files rather than moved ones.
>
>> Everywhere in the hotspot/test files import statements have been changed as needed.
>
> Seems okay based on scanning through the patch.
>
> Copyright dates will need updating in many cases.
>
> Thanks,
> David
>
>> Best regards,
>> Alex
>>
>>
>>
From alexander.kulyakhtin at oracle.com Tue Apr 28 15:39:26 2015
From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin)
Date: Tue, 28 Apr 2015 08:39:26 -0700 (PDT)
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Message-ID:
Hi Staffan,
Thank you very much for the reviewing.
Best regards,
Alex
----- Original Message -----
From: staffan.larsen at oracle.com
To: alexander.kulyakhtin at oracle.com
Cc: david.holmes at oracle.com, hotspot-dev at openjdk.java.net, serviceability-dev at openjdk.java.net
Sent: Tuesday, April 28, 2015 6:09:55 PM GMT +03:00 Iraq
Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
Looks good!
Thanks,
/Staffan
> On 28 apr 2015, at 15:09, Alexander Kulyakhtin wrote:
>
> Hi,
>
> I've updated the webrev in accordance with David's comments.
>
> Could you, please, review the changes:
>
>> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
>> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html
>
> Best regards,
> Alex
>
>
> ----- Original Message -----
> From: alexander.kulyakhtin at oracle.com
> To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net
> Cc: serviceability-dev at openjdk.java.net
> Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq
> Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
>
> Hi David,
>
> Thank you very much for your comments.
>
>> I presume this is a first step towards fixing:
>> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ?
> Yes, this is correct
>
>> Did you use "hg rename" for that? The webrev suggests not as it shows
> No, I used hg add and hg delete.
> I'm going to fix this now by doing hg rename
>
>> Copyright dates will need updating in many cases.
> I'm going to update the copyrights
>
> I'll send out the updated webrev as soon as I'm done.
>
> Best regards,
> Alex
>
> ----- Original Message -----
> From: david.holmes at oracle.com
> To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
> Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq
> Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
>
> Hi Alex,
>
> On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
>> Hi,
>>
>> Could I, please, have a review of this tests-only change:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
>> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
>>
>> The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
>
>
>
>> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
>
> deleted and added files rather than moved ones.
>
>> Everywhere in the hotspot/test files import statements have been changed as needed.
>
> Seems okay based on scanning through the patch.
>
> Copyright dates will need updating in many cases.
>
> Thanks,
> David
>
>> Best regards,
>> Alex
>>
>>
>>
From aph at redhat.com Tue Apr 28 18:27:22 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 28 Apr 2015 19:27:22 +0100
Subject: sun/jvm/hotspot/oops/Symbol.java
Message-ID: <553FD10A.7020006@redhat.com>
I've been testing serviceability support for AArch64, and I keep getting
bad pointers and NullPointerExceptions.
I thought it was a bug in my back-end, but it's not. The problem is
that we read a Symbol pointer out of the constant pool and then try to
use it. Unfortunately, the bottom two bits of a symbol pointer in the
constant pool have special meanings and we must mask them before use.
This is my fix:
diff -r 11b7f6b12521 agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java
--- a/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Fri Apr 24 16:28:29 2015 +0100
+++ b/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Tue Apr 28 19:23:18 2015 +0100
@@ -43,6 +43,8 @@
});
}
+ static class TagBits { final static int _resolved_value = 0, _symbol_bit = 1, _pseudo_bit = 2, _symbol_mask = 3; }
+
private static synchronized void initialize(TypeDataBase db) throws WrongTypeException {
Type type = db.lookupType("Symbol");
length = type.getCIntegerField("_length");
@@ -60,7 +62,8 @@
if (addr == null) {
return null;
}
- return new Symbol(addr);
+ return new Symbol(addr.andWithMask(~ TagBits._symbol_mask));
}
I'm not at all sure this is the right place to fix it, but it works.
I'm just really surprised no-one noticed this before.
Andrew.
From dmitry.samersoff at oracle.com Tue Apr 28 20:00:36 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 28 Apr 2015 23:00:36 +0300
Subject: sun/jvm/hotspot/oops/Symbol.java
In-Reply-To: <553FD10A.7020006@redhat.com>
References: <553FD10A.7020006@redhat.com>
Message-ID: <553FE6E4.5010502@oracle.com>
Andrew,
Thank you for the fix, I'll take a look at it
-Dmitry (current SA owner)
On 2015-04-28 21:27, Andrew Haley wrote:
> I've been testing serviceability support for AArch64, and I keep getting
> bad pointers and NullPointerExceptions.
>
> I thought it was a bug in my back-end, but it's not. The problem is
> that we read a Symbol pointer out of the constant pool and then try to
> use it. Unfortunately, the bottom two bits of a symbol pointer in the
> constant pool have special meanings and we must mask them before use.
>
> This is my fix:
>
> diff -r 11b7f6b12521 agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java
> --- a/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Fri Apr 24 16:28:29 2015 +0100
> +++ b/agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java Tue Apr 28 19:23:18 2015 +0100
> @@ -43,6 +43,8 @@
> });
> }
>
> + static class TagBits { final static int _resolved_value = 0, _symbol_bit = 1, _pseudo_bit = 2, _symbol_mask = 3; }
> +
> private static synchronized void initialize(TypeDataBase db) throws WrongTypeException {
> Type type = db.lookupType("Symbol");
> length = type.getCIntegerField("_length");
> @@ -60,7 +62,8 @@
> if (addr == null) {
> return null;
> }
> - return new Symbol(addr);
> + return new Symbol(addr.andWithMask(~ TagBits._symbol_mask));
> }
>
> I'm not at all sure this is the right place to fix it, but it works.
>
> I'm just really surprised no-one noticed this before.
>
> Andrew.
>
--
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 joe.darcy at oracle.com Tue Apr 28 23:53:41 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 28 Apr 2015 16:53:41 -0700
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <553A85A8.7080207@oracle.com>
References: <553703BC.1070504@oracle.com>
<5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com>
<553A85A8.7080207@oracle.com>
Message-ID: <55401D85.1090306@oracle.com>
Hello,
I'd like to get this changeset, or something close to it, pushed soon so
we can start taking advantage of better failure triaging.
Any further concerns?
Thanks,
-Joe
On 4/24/2015 11:04 AM, joe darcy wrote:
> On 4/23/2015 10:58 PM, Alan Bateman wrote:
>> On 24/04/2015 02:54, Joseph D. Darcy wrote:
>>> Hello,
>>>
>>> Any additional comments on marking with tests in question with a
>>> "randomness" keyword?
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>> I don't object to this keyword although I should say that most of the
>> (apparent) randomness that I've seen hasn't been because of tests
>> using Random but rather because of non-deterministic sequence of
>> tests running in the same VM. The switch from othervm to agentvm a
>> few years ago took a long time to weed out issues, same thing (even
>> more) with -concurrency. Another source of apparent randomness is
>> just having a large pool of machines and where machines are randomly
>> selected to execute the tests.
>>
>> I agree with your comments that tests using Random should have report
>> the seed and a have a way to re-run with the same value. It could
>> help with some cases.
>>
>> One thing that isn't clear to me is how this keyword will be
>> maintained. If I modify a test and replace the use of Random then I
>> guess I need to remember to also remove this label. When I add a test
>> that uses Random ... Just wondering if there is a tool to do the
>> tests analysis, identify the use of specific APIs ,and help identify
>> where the keyword might be missing or not needed.
>>
>
> The goal of the keyword is to enable better analysis of bug failures.
> We (still) have some intermittent test failures in the platform, some
> probably remaining from -concurrency issues and some due to
> inconsistent machine config issues on the test farms. However, there
> is reason to believe some of the tests also fail because of the use of
> randomness in the generation of test cases. For example, the test
>
> java/lang/invoke/MethodHandles/CatchExceptionTest.java
>
> fails about once every three hundred runs when the random cases it
> generates trigger an error condition. Setting the seed to known-bad
> value causes the test to fail consistently (JDK-8055269). I have
> suspicions some of our other intermittently failing tests are in a
> similar but undiagnosed situation.
>
> If a test uses randomness, I think the default assumed cause for a
> test failure should switch from environmental causes (bad machine
> config, etc.) to the random behavior. Therefore, when a random-using
> test fails, I think the failure analysis needs to include recording of
> the bad seed to see if the failure is reproducible / deterministic
> with a fixed seed value.
>
> I was very surprised by the large number of random-using tests in the
> JDK regression tests. Nearly all of these have been stably passing for
> many years. After the one-time cost of this large update to add the
> keywords, there would be a small amount of incremental test
> maintenance as new random-using tests were added or the randomness
> value of a test changed. However, I would expect whether or not a test
> used randomness to be a property of a test that very rarely changed.
>
> Thanks,
>
> -Joe
From Alan.Bateman at oracle.com Wed Apr 29 06:51:18 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 29 Apr 2015 07:51:18 +0100
Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness
In-Reply-To: <55401D85.1090306@oracle.com>
References: <553703BC.1070504@oracle.com>
<5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com>
<553A85A8.7080207@oracle.com> <55401D85.1090306@oracle.com>
Message-ID: <55407F66.1030905@oracle.com>
On 29/04/2015 00:53, Joseph D. Darcy wrote:
> Hello,
>
> I'd like to get this changeset, or something close to it, pushed soon
> so we can start taking advantage of better failure triaging.
>
> Any further concerns?
I should have been clearer, I don't have any issues with the proposed
patch. I was mostly probing to see how the keyword would be used as it
looks to be more for triage rather than test selection.
-Alan
From aph at redhat.com Wed Apr 29 07:42:33 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 29 Apr 2015 08:42:33 +0100
Subject: RFR: 8078521: AARCH64: Add AArch64 SA support
In-Reply-To: <553A8B20.9050109@oracle.com>
References: <55391C34.3070502@redhat.com> <553954D8.2070506@oracle.com>
<553A012C.1070008@redhat.com> <553A8B20.9050109@oracle.com>
Message-ID: <55408B69.8050108@redhat.com>
On 04/24/2015 07:27 PM, Dean Long wrote:
> Not a review, but a couple things I noticed:
>
> agent/src/os/linux/ps_proc.c:
>
> I don't think you need to change this file. There is already
> PTRACE_GETREGSET support there.
>
>
>
> agent/src/os/linux/Makefile:
>
> + echo FECK
>
> The conflict will be handled in a separate bug (8078632).
http://cr.openjdk.java.net/~aph/8078521-2/
Andrew.
From serguei.spitsyn at oracle.com Wed Apr 29 09:48:43 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 29 Apr 2015 02:48:43 -0700
Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint
sets last method param to exception
In-Reply-To: <553EA65B.6080805@oracle.com>
References: <553EA65B.6080805@oracle.com>
Message-ID: <5540A8FB.4010101@oracle.com>
Ping...
Just wanted to tell that it is a very safe and simple one-liner so that
I assumed it to be reviewed in a couple of days, not weeks! :)
Thanks!
Serguei
On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the jdk 9 fix for:
> https://bugs.openjdk.java.net/browse/JDK-8076579
>
>
> 9 hotspot webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1
>
>
>
> Summary:
>
> This bug is a regression that was introduced but the fix of:
> https://bugs.openjdk.java.net/browse/JDK-7187554
>
> The bug is in the InterpreterRuntime::member_name_arg_or_null()
> function that
> does not return NULL if there is no invokestatic appendix argument
> (MemberName).
> It is why the _remove_activation_preserving_args is trying to to
> restore unexisting
> appendix argument when a pop instruction is executed by a debugger
> in the debuggee VM.
> The fix is to correctly set NULL in the thread vm_result when it is
> necessary:
> thread->set_vm_result(NULL);
>
>
> Testing in progress:
> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests,
> JTREG com/sun/jdi tests,
> ad-hog ExceptionBug.java test from the bug report
>
>
> Thanks,
> Serguei
From jaroslav.bachorik at oracle.com Wed Apr 29 10:02:33 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 29 Apr 2015 12:02:33 +0200
Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint
sets last method param to exception
In-Reply-To: <5540A8FB.4010101@oracle.com>
References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com>
Message-ID: <5540AC39.9030900@oracle.com>
The fix looks ok as far as the change goes.
I'm relying on your analysis for the correctness.
-JB-
On 29.4.2015 11:48, serguei.spitsyn at oracle.com wrote:
> Ping...
> Just wanted to tell that it is a very safe and simple one-liner so that
> I assumed it to be reviewed in a couple of days, not weeks! :)
>
> Thanks!
> Serguei
>
> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the jdk 9 fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8076579
>>
>>
>> 9 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1
>>
>>
>>
>> Summary:
>>
>> This bug is a regression that was introduced but the fix of:
>> https://bugs.openjdk.java.net/browse/JDK-7187554
>>
>> The bug is in the InterpreterRuntime::member_name_arg_or_null()
>> function that
>> does not return NULL if there is no invokestatic appendix argument
>> (MemberName).
>> It is why the _remove_activation_preserving_args is trying to to
>> restore unexisting
>> appendix argument when a pop instruction is executed by a debugger
>> in the debuggee VM.
>> The fix is to correctly set NULL in the thread vm_result when it is
>> necessary:
>> thread->set_vm_result(NULL);
>>
>>
>> Testing in progress:
>> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests,
>> JTREG com/sun/jdi tests,
>> ad-hog ExceptionBug.java test from the bug report
>>
>>
>> Thanks,
>> Serguei
>
From david.holmes at oracle.com Wed Apr 29 11:23:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 Apr 2015 21:23:00 +1000
Subject: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
In-Reply-To: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default>
References: <2b465404-a78c-4914-a81d-6e9a2a97bbe1@default>
Message-ID: <5540BF14.1070606@oracle.com>
On 28/04/2015 11:09 PM, Alexander Kulyakhtin wrote:
> Hi,
>
> I've updated the webrev in accordance with David's comments.
>
> Could you, please, review the changes:
>
>> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
>> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.01/index.html
Looks good.
Aside: test/compiler/c2/8005956/PolynomialRoot.java doesn't have an
OpenJDK copyright header. (Added by JDK-8017510)
Thanks,
David
> Best regards,
> Alex
>
>
> ----- Original Message -----
> From: alexander.kulyakhtin at oracle.com
> To: david.holmes at oracle.com, hotspot-dev at openjdk.java.net
> Cc: serviceability-dev at openjdk.java.net
> Sent: Tuesday, April 28, 2015 2:08:54 PM GMT +03:00 Iraq
> Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
>
> Hi David,
>
> Thank you very much for your comments.
>
>> I presume this is a first step towards fixing:
>> https://bugs.openjdk.java.net/browse/JDK-8075327 (merging the two test libraries) ?
> Yes, this is correct
>
>> Did you use "hg rename" for that? The webrev suggests not as it shows
> No, I used hg add and hg delete.
> I'm going to fix this now by doing hg rename
>
>> Copyright dates will need updating in many cases.
> I'm going to update the copyrights
>
> I'll send out the updated webrev as soon as I'm done.
>
> Best regards,
> Alex
>
> ----- Original Message -----
> From: david.holmes at oracle.com
> To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
> Sent: Monday, April 27, 2015 4:39:31 AM GMT +03:00 Iraq
> Subject: Re: RFR: JDK-8067013: Rename the com.oracle.java.testlibary package
>
> Hi Alex,
>
> On 25/04/2015 12:33 AM, Alexander Kulyakhtin wrote:
>> Hi,
>>
>> Could I, please, have a review of this tests-only change:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8067013: Rename the com.oracle.java.testlibary package
>> Webrev: http://cr.openjdk.java.net/~akulyakh/8067013/webrev.00/index.html
>>
>> The change renames com.oracle.java.testlibrary package to jdk.test.lib package:
>
>
>
>> The directory structure have been changed under the hotspot/test/testlibrary/ to provide for the package renaming,
>
> deleted and added files rather than moved ones.
>
>> Everywhere in the hotspot/test files import statements have been changed as needed.
>
> Seems okay based on scanning through the patch.
>
> Copyright dates will need updating in many cases.
>
> Thanks,
> David
>
>> Best regards,
>> Alex
>>
>>
>>
From serguei.spitsyn at oracle.com Wed Apr 29 11:49:00 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 29 Apr 2015 04:49:00 -0700
Subject: RFR (XM) 8076579: Popping a stack frame after exception breakpoint
sets last method param to exception
In-Reply-To: <5540AC39.9030900@oracle.com>
References: <553EA65B.6080805@oracle.com> <5540A8FB.4010101@oracle.com>
<5540AC39.9030900@oracle.com>
Message-ID: <5540C52C.1080003@oracle.com>
Thank you a lot, Jaroslav!
Serguei
On 4/29/15 3:02 AM, Jaroslav Bachorik wrote:
> The fix looks ok as far as the change goes.
>
> I'm relying on your analysis for the correctness.
>
> -JB-
>
> On 29.4.2015 11:48, serguei.spitsyn at oracle.com wrote:
>> Ping...
>> Just wanted to tell that it is a very safe and simple one-liner so that
>> I assumed it to be reviewed in a couple of days, not weeks! :)
>>
>> Thanks!
>> Serguei
>>
>> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the jdk 9 fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8076579
>>>
>>>
>>> 9 hotspot webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1
>>>
>>>
>>>
>>>
>>> Summary:
>>>
>>> This bug is a regression that was introduced but the fix of:
>>> https://bugs.openjdk.java.net/browse/JDK-7187554
>>>
>>> The bug is in the InterpreterRuntime::member_name_arg_or_null()
>>> function that
>>> does not return NULL if there is no invokestatic appendix argument
>>> (MemberName).
>>> It is why the _remove_activation_preserving_args is trying to to
>>> restore unexisting
>>> appendix argument when a pop instruction is executed by a debugger
>>> in the debuggee VM.
>>> The fix is to correctly set NULL in the thread vm_result when it is
>>> necessary:
>>> thread->set_vm_result(NULL);
>>>
>>>
>>> Testing in progress:
>>> In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests,
>>> JTREG com/sun/jdi tests,
>>> ad-hog ExceptionBug.java test from the bug report
>>>
>>>
>>> Thanks,
>>> Serguei
>>
>
From alexander.kulyakhtin at oracle.com Wed Apr 29 14:33:41 2015
From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin)
Date: Wed, 29 Apr 2015 07:33:41 -0700 (PDT)
Subject: RFR: JDK-8078962: Add Open JDK copyright to PolynomialRoot.java test
Message-ID: <5f0d4a2d-a9f7-4e59-86bd-d04ab2b54108@default>
Hi,
Could you, please, review the copyright change in the file below?
There's no code changes, only the copyright has been changed.
CR: https://bugs.openjdk.java.net/browse/JDK-8078962 Add Open JDK copyright to PolynomialRoot.java test
Webrev: http://cr.openjdk.java.net/~akulyakh/8078962/webrev00/
Best regards,
Alexander
From jaroslav.bachorik at oracle.com Wed Apr 29 17:47:16 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 29 Apr 2015 19:47:16 +0200
Subject: RFR: JDK-8078962: Add Open JDK copyright to PolynomialRoot.java
test
In-Reply-To: <5f0d4a2d-a9f7-4e59-86bd-d04ab2b54108@default>
References: <5f0d4a2d-a9f7-4e59-86bd-d04ab2b54108@default>
Message-ID: <55411924.9090703@oracle.com>
Looks good!
-JB-
On 29.4.2015 16:33, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review the copyright change in the file below?
> There's no code changes, only the copyright has been changed.
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8078962 Add Open JDK copyright to PolynomialRoot.java test
> Webrev: http://cr.openjdk.java.net/~akulyakh/8078962/webrev00/
>
> Best regards,
> Alexander
>
From yekaterina.kantserova at oracle.com Thu Apr 30 07:39:10 2015
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Thu, 30 Apr 2015 09:39:10 +0200
Subject: RFR(XXS): 8079120: serviceability/dcmd/gc/HeapDumpAllTest.java:
compilation failed
Message-ID: <5541DC1E.8000509@oracle.com>
Hi,
Could I please have a review of this very small fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8079120
webrev: http://cr.openjdk.java.net/~ykantser/8079120/webrev.00/
Thanks,
Katja
From staffan.larsen at oracle.com Thu Apr 30 07:49:18 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 30 Apr 2015 09:49:18 +0200
Subject: RFR(XXS): 8079120: serviceability/dcmd/gc/HeapDumpAllTest.java:
compilation failed
In-Reply-To: <5541DC1E.8000509@oracle.com>
References: <5541DC1E.8000509@oracle.com>
Message-ID: <4DB0D766-D54B-4D5B-B330-F626068F57AF@oracle.com>
Looks good!
Thanks,
/Staffan
> On 30 apr 2015, at 09:39, Yekaterina Kantserova wrote:
>
> Hi,
>
> Could I please have a review of this very small fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8079120
> webrev: http://cr.openjdk.java.net/~ykantser/8079120/webrev.00/
>
> Thanks,
> Katja
>
>
>
From jaroslav.bachorik at oracle.com Thu Apr 30 14:25:57 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 30 Apr 2015 16:25:57 +0200
Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java
fails intermittently
Message-ID: <55423B75.6000703@oracle.com>
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8078143
Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00
The test fails intermittently due to inconsistent reporting of the live
threads number.It is related to
https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said,
caused by) - certain performance counters used for the thread accounting
are being updated under a mutex but are read without it - and it can
lead to stale data being reported. More details are available in the
linked issue and discussion.
Because of this it is not enough to join() a terminating thread to make
sure the numbers would be correct. Luckily enough, it seems to be
sufficient to wait for a short time before actually accessing the
counters to be able to get a consistent view. In this fix I opted for a
ridiculously huge interval of 500ms just to be sure.
Thanks,
-JB-
From jaroslav.bachorik at oracle.com Thu Apr 30 14:48:06 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 30 Apr 2015 16:48:06 +0200
Subject: RFR 8072906:
sun/management/jmxremote/bootstrap/CustomLauncherTest.java
failing on embedded platform
Message-ID: <554240A6.7070309@oracle.com>
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-8072906
Webrev: http://cr.openjdk.java.net/~jbachorik/8072906/webrev.00
The test tries to exercise a custom launcher on embedded platforms and
fails because the corresponding binary is not available. The test should
not require the presence of the binary and skip the execution gracefully
if it can't find one - this was broken while addressing JDK-8029809.
The fix brings back the ability just skip the test if the launcher
binary does not exist.
Thanks,
-JB-
From martinrb at google.com Thu Apr 30 17:18:36 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 30 Apr 2015 10:18:36 -0700
Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java
fails intermittently
In-Reply-To: <55423B75.6000703@oracle.com>
References: <55423B75.6000703@oracle.com>
Message-ID:
Tests that sleep can almost always be better written some other way.
In this case, I would prefer busy-waiting with timeout until the expected
condition becomes true.
Here's some code from jsr166 tck tests:
/**
* Spin-waits until sync.isQueued(t) becomes true.
*/
void waitForQueuedThread(AbstractQueuedSynchronizer sync, Thread t) {
long startTime = System.nanoTime();
while (!sync.isQueued(t)) {
if (millisElapsedSince(startTime) > LONG_DELAY_MS)
throw new AssertionFailedError("timed out");
Thread.yield();
}
assertTrue(t.isAlive());
}
On Thu, Apr 30, 2015 at 7:25 AM, Jaroslav Bachorik <
jaroslav.bachorik at oracle.com> wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8078143
> Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00
>
> The test fails intermittently due to inconsistent reporting of the live
> threads number.It is related to
> https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said, caused
> by) - certain performance counters used for the thread accounting are being
> updated under a mutex but are read without it - and it can lead to stale
> data being reported. More details are available in the linked issue and
> discussion.
>
> Because of this it is not enough to join() a terminating thread to make
> sure the numbers would be correct. Luckily enough, it seems to be
> sufficient to wait for a short time before actually accessing the counters
> to be able to get a consistent view. In this fix I opted for a ridiculously
> huge interval of 500ms just to be sure.
>
> Thanks,
>
> -JB-
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jaroslav.bachorik at oracle.com Thu Apr 30 18:27:23 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 30 Apr 2015 20:27:23 +0200
Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java
fails intermittently
In-Reply-To:
References: <55423B75.6000703@oracle.com>
Message-ID: <5542740B.6080507@oracle.com>
On 30.4.2015 19:18, Martin Buchholz wrote:
> Tests that sleep can almost always be better written some other way.
> In this case, I would prefer busy-waiting with timeout until the
> expected condition becomes true.
The thing is that in case of a real issue with the thread counters we
a/ would be busy-waiting till the test times out (using an arbitrary
delay is also problematic due to different performance of different
machines running with different configurations)
b/ would get a rather confusing message about the test timing out at the end
-JB-
>
> Here's some code from jsr166 tck tests:
>
> /**
> * Spin-waits until sync.isQueued(t) becomes true.
> */
> void waitForQueuedThread(AbstractQueuedSynchronizer sync, Thread t) {
> long startTime = System.nanoTime();
> while (!sync.isQueued(t)) {
> if (millisElapsedSince(startTime) > LONG_DELAY_MS)
> throw new AssertionFailedError("timed out");
> Thread.yield();
> }
> assertTrue(t.isAlive());
> }
>
>
> On Thu, Apr 30, 2015 at 7:25 AM, Jaroslav Bachorik
> > wrote:
>
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8078143
> Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00
>
> The test fails intermittently due to inconsistent reporting of the
> live threads number.It is related to
> https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said,
> caused by) - certain performance counters used for the thread
> accounting are being updated under a mutex but are read without it -
> and it can lead to stale data being reported. More details are
> available in the linked issue and discussion.
>
> Because of this it is not enough to join() a terminating thread to
> make sure the numbers would be correct. Luckily enough, it seems to
> be sufficient to wait for a short time before actually accessing the
> counters to be able to get a consistent view. In this fix I opted
> for a ridiculously huge interval of 500ms just to be sure.
>
> Thanks,
>
> -JB-
>
>
From david.holmes at oracle.com Thu Apr 30 21:08:18 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 01 May 2015 07:08:18 +1000
Subject: RFR 8072906:
sun/management/jmxremote/bootstrap/CustomLauncherTest.java
failing on embedded platform
In-Reply-To: <554240A6.7070309@oracle.com>
References: <554240A6.7070309@oracle.com>
Message-ID: <554299C2.6040301@oracle.com>
On 1/05/2015 12:48 AM, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8072906
> Webrev: http://cr.openjdk.java.net/~jbachorik/8072906/webrev.00
>
> The test tries to exercise a custom launcher on embedded platforms and
> fails because the corresponding binary is not available. The test should
> not require the presence of the binary and skip the execution gracefully
> if it can't find one - this was broken while addressing JDK-8029809.
>
> The fix brings back the ability just skip the test if the launcher
> binary does not exist.
A message to that effect would be useful.
Thanks,
David
> Thanks,
>
> -JB-
From serguei.spitsyn at oracle.com Thu Apr 30 22:20:53 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 30 Apr 2015 15:20:53 -0700
Subject: RFR 8072906:
sun/management/jmxremote/bootstrap/CustomLauncherTest.java
failing on embedded platform
In-Reply-To: <554299C2.6040301@oracle.com>
References: <554240A6.7070309@oracle.com> <554299C2.6040301@oracle.com>
Message-ID: <5542AAC5.1040906@oracle.com>
+1 for the suggestion from David.
Otherwise, the fix looks Ok.
No need to re-review after printing a message is added.
Thanks,
Serguei
On 4/30/15 2:08 PM, David Holmes wrote:
> On 1/05/2015 12:48 AM, Jaroslav Bachorik wrote:
>> Please, review the following test change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8072906
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8072906/webrev.00
>>
>> The test tries to exercise a custom launcher on embedded platforms and
>> fails because the corresponding binary is not available. The test should
>> not require the presence of the binary and skip the execution gracefully
>> if it can't find one - this was broken while addressing JDK-8029809.
>>
>> The fix brings back the ability just skip the test if the launcher
>> binary does not exist.
>
> A message to that effect would be useful.
>
> Thanks,
> David
>
>> Thanks,
>>
>> -JB-
From david.holmes at oracle.com Thu Apr 30 23:56:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 01 May 2015 09:56:25 +1000
Subject: RFR 8078143: java/lang/management/ThreadMXBean/AllThreadIds.java
fails intermittently
In-Reply-To: <55423B75.6000703@oracle.com>
References: <55423B75.6000703@oracle.com>
Message-ID: <5542C129.1070600@oracle.com>
Hi Jaroslav,
On 1/05/2015 12:25 AM, Jaroslav Bachorik wrote:
> Please, review the following test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8078143
> Webrev: http://cr.openjdk.java.net/~jbachorik/8078143/webrev.00
>
> The test fails intermittently due to inconsistent reporting of the live
> threads number.It is related to
> https://bugs.openjdk.java.net/browse/JDK-8021335 (or, better said,
> caused by) - certain performance counters used for the thread accounting
> are being updated under a mutex but are read without it - and it can
> lead to stale data being reported. More details are available in the
> linked issue and discussion.
Okay I just refreshed my memory on that - the fix is non-trivial
unfortunately.
> Because of this it is not enough to join() a terminating thread to make
> sure the numbers would be correct.
Right.
> Luckily enough, it seems to be
> sufficient to wait for a short time before actually accessing the
> counters to be able to get a consistent view. In this fix I opted for a
> ridiculously huge interval of 500ms just to be sure.
It is a kludge but there's little else to be done without fixing 8021335.
So grudgingly Reviewed.
Thanks,
David
> Thanks,
>
> -JB-