serviceability-dev Digest, Vol 71, Issue 7
Burtus, Christer
Christer.Burtus at delaval.com
Wed Oct 2 02:35:42 PDT 2013
----- Original Message -----
From: serviceability-dev-request at openjdk.java.net [mailto:serviceability-dev-request at openjdk.java.net]
Sent: Wednesday, October 02, 2013 11:27 AM W. Europe Standard Time
To: serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
Subject: serviceability-dev Digest, Vol 71, Issue 7
Send serviceability-dev mailing list submissions to
serviceability-dev at openjdk.java.net
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/serviceability-dev
or, via email, send a message with subject or body 'help' to
serviceability-dev-request at openjdk.java.net
You can reach the person managing the list at
serviceability-dev-owner at openjdk.java.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of serviceability-dev digest..."
Today's Topics:
1. hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher
suites (xuelei.fan at oracle.com)
2. hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll
WEEK_OF_YEAR is broken for January 1 2010
(masayoshi.okutsu at oracle.com)
3. Re: RFR (S): 8016845: SA is unable to use hsdis on windows
(Staffan Larsen)
4. hg: jdk8/tl/jdk: 8024952: ClassCastException in
PlainSocketImpl.accept() when using custom socketImpl
(sean.coffey at oracle.com)
5. RFR 6523160: RuntimeMXBean.getUptime() returns negative
values (Jaroslav Bachorik)
6. Re: RFR (S): 6313383: SA: Update jmap to support HPROF binary
format "JAVA PROFILE 1.0.2" (Peter Allwin)
7. Re: RFR (S): 8016845: SA is unable to use hsdis on windows
(Mikael Gerdin)
8. Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative
values (Staffan Larsen)
9. Re: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't
enumerate anonymous classes (Fredrik Arvidsson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 02 Oct 2013 03:26:43 +0000
From: xuelei.fan at oracle.com
Subject: hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher
suites
To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net,
core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net,
security-dev at openjdk.java.net, net-dev at openjdk.java.net
Message-ID: <20131002032658.A714B62C88 at hg.openjdk.java.net>
Changeset: 3fca37c636be
Author: xuelei
Date: 2013-10-01 20:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fca37c636be
8025123: SNI support in Kerberos cipher suites
Reviewed-by: weijun, xuelei
Contributed-by: Artem Smotrakov <artem.smotrakov at oracle.com>
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java
! test/sun/security/krb5/auto/SSL.java
------------------------------
Message: 2
Date: Wed, 02 Oct 2013 06:32:25 +0000
From: masayoshi.okutsu at oracle.com
Subject: hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll
WEEK_OF_YEAR is broken for January 1 2010
To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net,
core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net,
security-dev at openjdk.java.net, net-dev at openjdk.java.net
Message-ID: <20131002063239.AC93662C8C at hg.openjdk.java.net>
Changeset: 914c29c10bce
Author: okutsu
Date: 2013-10-02 15:31 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914c29c10bce
6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010
Reviewed-by: peytoia
! src/share/classes/java/util/GregorianCalendar.java
+ test/java/util/Calendar/Bug6902861.java
------------------------------
Message: 3
Date: Wed, 2 Oct 2013 09:22:28 +0200
From: Staffan Larsen <staffan.larsen at oracle.com>
Subject: Re: RFR (S): 8016845: SA is unable to use hsdis on windows
To: Fredrik Arvidsson <fredrik.arvidsson at oracle.com>
Cc: serviceability-dev at openjdk.java.net,
hotspot-runtime-dev at openjdk.java.net
Message-ID: <06A81151-E94D-4E81-99A9-8413FA509456 at oracle.com>
Content-Type: text/plain; charset=iso-8859-1
Looks good!
Thanks,
/Staffan
On 20 sep 2013, at 16:29, Fredrik Arvidsson <fredrik.arvidsson at oracle.com> wrote:
> Please help me review this:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8016845
> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8016845/webrev.00/ <http://cr.openjdk.java.net/%7Eallwin/farvidss/8016845/webrev.00/>
>
> Small change was made in the sa.make file for windows to compile and link sadis.c in to sawindbg.dll providing JNI entrypoints needed to call the hsdis disassembler from SADB on windows. A small change in agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java to have the correct library name when loading library depending if running on 32 or 64 bit platform.
>
> To test this you have to build the hsdis library yourself, since it cant be bundled due to license issues. Instructions can be found here: http://dropzone.nfshost.com/hsdis.htm (hint, I have pre-built binaries). When running disassembling in HSDB (using the 'dis' command in the console) the hsdis-amd64.dll/hsdis-i386.dll must be in the /bin directory of the JRE/JDK used.
>
> Cheers
> /Fredrik
------------------------------
Message: 4
Date: Wed, 02 Oct 2013 08:22:34 +0000
From: sean.coffey at oracle.com
Subject: hg: jdk8/tl/jdk: 8024952: ClassCastException in
PlainSocketImpl.accept() when using custom socketImpl
To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net,
core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net,
security-dev at openjdk.java.net, net-dev at openjdk.java.net
Message-ID: <20131002082305.2A14B62C96 at hg.openjdk.java.net>
Changeset: 368172cb6dc5
Author: coffeys
Date: 2013-10-02 09:21 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368172cb6dc5
8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
Reviewed-by: chegar
! src/windows/classes/java/net/PlainSocketImpl.java
+ test/java/net/PlainSocketImpl/CustomSocketImplFactory.java
------------------------------
Message: 5
Date: Wed, 02 Oct 2013 10:47:26 +0200
From: Jaroslav Bachorik <jaroslav.bachorik at oracle.com>
Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative
values
To: "serviceability-dev at openjdk.java.net
serviceability-dev at openjdk.java.net"
<serviceability-dev at openjdk.java.net>, jmx-dev at openjdk.java.net
Message-ID: <524BDD9E.1050100 at oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
currently the JVM uptime reported by the RuntimeMXBean is based on
System.currentTimeMillis() which makes it susceptible to changes of the
OS time (eg. changing timezone, NTP synchronization etc.). The uptime
should not depend on the system time and should be calculated using a
monotonic clock source.
There is already the way to get the actual JVM uptime in ticks. It is
accessible as Management::timestamp() and the ticks are convertible to
milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very
easy to switch to the monotonic clock based uptime.
The patch consists of the hotspot and jdk parts.
For the hotspot a new constant needs to be introduced in
src/share/vm/services/jmm.h and the actual logic to obtain the uptime in
milliseconds is added in src/share/vm/services/management.cpp.
For the jdk the changes comprise of adding the necessary JNI bridging
methods in order to get the new uptime, introducing the same constant
that is used in hotspot and changes to mapfile-vers files in order to
properly build the native library.
Issue: https://bugs.openjdk.java.net/browse/JDK-6523160
Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00
Thanks,
-JB-
------------------------------
Message: 6
Date: Wed, 2 Oct 2013 10:49:04 +0200
From: Peter Allwin <peter.allwin at oracle.com>
Subject: Re: RFR (S): 6313383: SA: Update jmap to support HPROF binary
format "JAVA PROFILE 1.0.2"
To: Fredrik Arvidsson <fredrik.arvidsson at oracle.com>
Cc: serviceability-dev at openjdk.java.net,
hotspot-runtime-dev at openjdk.java.net
Message-ID: <4F092E8F-8002-4E02-9F75-519A3083AB96 at oracle.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Fredrik,
Looks great!
Thanks for fixing this,
/peter
On Sep 20, 2013, at 2:35 PM, Fredrik Arvidsson <fredrik.arvidsson at oracle.com> wrote:
> Hi
>
> Please help me and review the changes below:
>
> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/6313383/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-6313383
>
> This change adds support for dumping large heaps (> 4G) using jmap by implementing the "JAVA PROFILE 1.0.2" file format with segmented heap dump records.
> The HPROF binary format specification can be found here: https://java.net/downloads/heap-snapshot/hprof-binary-format.html.
>
> I added a simple test to verify that heaps smaller than 2G are dumped using the "JAVA PROFILE 1.0.1" format. The last section in the test, aiming to test the format used when dumping heaps larger than 2G, is commented out since the test system didn't like that kind of heap sizes and ultimately failed (OOM and sometimes timeout). The test should be reintroduced once we can reliably support such tests in the test system.
>
> Thanks 'allwin' for hosting my review :)
>
> Cheers
> /Fredrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131002/6d76ccd9/attachment-0001.html
------------------------------
Message: 7
Date: Wed, 02 Oct 2013 10:51:53 +0200
From: Mikael Gerdin <mikael.gerdin at oracle.com>
Subject: Re: RFR (S): 8016845: SA is unable to use hsdis on windows
To: Fredrik Arvidsson <fredrik.arvidsson at oracle.com>,
serviceability-dev at openjdk.java.net,
hotspot-runtime-dev at openjdk.java.net
Message-ID: <524BDEA9.5020800 at oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Fredrik,
On 09/20/2013 04:29 PM, Fredrik Arvidsson wrote:
> Please help me review this:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8016845
> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8016845/webrev.00/
> <http://cr.openjdk.java.net/%7Eallwin/farvidss/8016845/webrev.00/>
the change looks good to me.
>
> Small change was made in the sa.make file for windows to compile and
> link sadis.c in to sawindbg.dll providing JNI entrypoints needed to call
> the hsdis disassembler from SADB on windows. A small change in
> agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java to have
> the correct library name when loading library depending if running on 32
> or 64 bit platform.
Thanks for fixing this!
/Mikael
>
> To test this you have to build the hsdis library yourself, since it cant
> be bundled due to license issues. Instructions can be found here:
> http://dropzone.nfshost.com/hsdis.htm (hint, I have pre-built binaries).
> When running disassembling in HSDB (using the 'dis' command in the
> console) the hsdis-amd64.dll/hsdis-i386.dll must be in the /bin
> directory of the JRE/JDK used.
>
> Cheers
> /Fredrik
------------------------------
Message: 8
Date: Wed, 2 Oct 2013 11:23:34 +0200
From: Staffan Larsen <staffan.larsen at oracle.com>
Subject: Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative
values
To: Jaroslav Bachorik <jaroslav.bachorik at oracle.com>
Cc: "serviceability-dev at openjdk.java.net
serviceability-dev at openjdk.java.net"
<serviceability-dev at openjdk.java.net>, jmx-dev at openjdk.java.net
Message-ID: <4088022F-6550-4C95-86D5-640F2E737839 at oracle.com>
Content-Type: text/plain; charset=iso-8859-1
Looks good!
Thanks,
/Staffan
On 2 okt 2013, at 10:47, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
> Hello,
>
> currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS time (eg. changing timezone, NTP synchronization etc.). The uptime should not depend on the system time and should be calculated using a monotonic clock source.
>
> There is already the way to get the actual JVM uptime in ticks. It is accessible as Management::timestamp() and the ticks are convertible to milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very easy to switch to the monotonic clock based uptime.
>
> The patch consists of the hotspot and jdk parts.
>
> For the hotspot a new constant needs to be introduced in src/share/vm/services/jmm.h and the actual logic to obtain the uptime in milliseconds is added in src/share/vm/services/management.cpp.
>
> For the jdk the changes comprise of adding the necessary JNI bridging methods in order to get the new uptime, introducing the same constant that is used in hotspot and changes to mapfile-vers files in order to properly build the native library.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160
> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00
>
> Thanks,
>
> -JB-
------------------------------
Message: 9
Date: Wed, 02 Oct 2013 11:28:19 +0200
From: Fredrik Arvidsson <fredrik.arvidsson at oracle.com>
Subject: Re: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't
enumerate anonymous classes
To: "serguei.spitsyn at oracle.com" <serguei.spitsyn at oracle.com>
Cc: serviceability-dev at openjdk.java.net,
hotspot-gc-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net
Message-ID: <524BE733.2070205 at oracle.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi and thanks for all your comments.
I have simplified the code in *instanceKlass.cpp* like suggested and
here is a new webrev:
http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/
<http://cr.openjdk.java.net/%7Eallwin/farvidss/8024423/webrev.01/>
Regarding the need to synchronize the access to ClassLoaderDataGraph I
have come to the conclusion that it should be safe to call this without
any additional synchronization since newly loaded and added classes are
appended to the end of its 'list' of classes. This would mean that the
call could 'miss' the classes added during the collection phase, but
this is not a big issue. I hope that my conclusion is correct.
I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...)
method is to be left alone this time since I got the impression that
only SystemDictionary 'knows' about initiating class loaders.
There is plenty of room for improvement and simplification of much of
the code in this area, but I feel that it must wait until another time.
The task to re-factor and simplify would quickly grow out of hands I'm
afraid :)
Cheers
/Fredrik
On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote:
> Hi Frederik,
>
>
> Thank you for jumping on this issue!
>
>
> *src/share/vm/oops/instanceKlass.cpp*
> 2333 int src_index = 0;
> 2334 while (src_index < src_length) {
> 2335 dest[dest_index++] = src[src_index++];
> 2336 }
> 2337
> 2338 // If we have a hash, append it
> 2339 if(hash_len > 0) {
> 2340 int hash_index = 0;
> 2341 while (hash_index < hash_len) {
> 2342 dest[dest_index++] = hash_buf[hash_index++];
> 2343 }
> 2344 }
>
> The above can be simplified a little bit:
> // Add the actual class name
> for (int src_index = 0; src_index < src_length; ) {
> dest[dest_index++] = src[src_index++];
> }
> // If we have a hash, append it
> for (int hash_index = 0; hash_index < hash_len; ) {
> dest[dest_index++] = hash_buf[hash_index++];
> }
>
> The conditionif(hash_len > 0) is covered by the loop itself.
>
> Style-related comments:
> -wrong indent at the lines: 2316-2319
> - need a space after the 'if' at the lines: 2315, 2339
>
>
> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp
>
> *The copyright comment must be up-to-date.
> The comments at the lines 35-38, 258-260 are not valid anymore.
>
>
> > In this review I still have an outstanding unanswered question about
> > the need to synchronize the access to the:
>
> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment);
> > and
> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add);
>
> This kind of walking is usually done at safepoint in a VM_Operation.
> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces.
> The suggestion from Mikael is good too.
>
> Should this fix include the getClassLoaderClasses() as well?
> I'm still trying to realize the impact and consistency of this fix. :(
>
> What tests are you going to run for verification?
>
> Thanks,
> Serguei
> *
> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote:
>> Hi
>>
>> Please help me to review the changes below:
>>
>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423
>> Webrev:
>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/
>> <http://cr.openjdk.java.net/%7Eallwin/farvidss/8024423/webrev.00/>
>>
>> In this review I still have an outstanding unanswered question about
>> the need to synchronize the access to the:
>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment);
>> and
>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add);
>>
>> calls in
>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html <http://cr.openjdk.java.net/%7Eallwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html>
>>
>> Please give me advise on this.
>>
>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see:
>> https://bugs.openjdk.java.net/browse/JDK-8025576
>>
>> Cheers
>> /Fredrik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131002/49255ad9/attachment.html
End of serviceability-dev Digest, Vol 71, Issue 7
*************************************************
"This is an e-mail from a DeLaval company. This e-mail is confidential
and may also be privileged. Please delete the email and notify us
immediately if you are not the intended recipient. DeLaval does not
enter into contracts or contractual obligations via electronic mail,
unless otherwise agreed in writing between parties concerned.
Thank you."
More information about the serviceability-dev
mailing list