----- Original Message -----
From: serviceability-dev-requ...@openjdk.java.net
[mailto:serviceability-dev-requ...@openjdk.java.net]
Sent: Wednesday, October 02, 2013 11:27 AM W. Europe Standard Time
To: serviceability-dev@openjdk.java.net <serviceability-dev@openjdk.java.net>
Subject: serviceability-dev Digest, Vol 71, Issue 7
Send serviceability-dev mailing list submissions to
serviceability-dev@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-requ...@openjdk.java.net
You can reach the person managing the list at
serviceability-dev-ow...@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....@oracle.com)
2. hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll
WEEK_OF_YEAR is broken for January 1 2010
(masayoshi.oku...@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.cof...@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....@oracle.com
Subject: hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher
suites
To: jdk8-chan...@openjdk.java.net, compiler-...@openjdk.java.net,
core-libs-...@openjdk.java.net, serviceability-dev@openjdk.java.net,
security-...@openjdk.java.net, net-...@openjdk.java.net
Message-ID: <20131002032658.a714b62...@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.smotra...@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.oku...@oracle.com
Subject: hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll
WEEK_OF_YEAR is broken for January 1 2010
To: jdk8-chan...@openjdk.java.net, compiler-...@openjdk.java.net,
core-libs-...@openjdk.java.net, serviceability-dev@openjdk.java.net,
security-...@openjdk.java.net, net-...@openjdk.java.net
Message-ID: <20131002063239.ac93662...@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.lar...@oracle.com>
Subject: Re: RFR (S): 8016845: SA is unable to use hsdis on windows
To: Fredrik Arvidsson <fredrik.arvids...@oracle.com>
Cc: serviceability-dev@openjdk.java.net,
hotspot-runtime-...@openjdk.java.net
Message-ID: <06a81151-e94d-4e81-99a9-8413fa509...@oracle.com>
Content-Type: text/plain; charset=iso-8859-1
Looks good!
Thanks,
/Staffan
On 20 sep 2013, at 16:29, Fredrik Arvidsson <fredrik.arvids...@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.cof...@oracle.com
Subject: hg: jdk8/tl/jdk: 8024952: ClassCastException in
PlainSocketImpl.accept() when using custom socketImpl
To: jdk8-chan...@openjdk.java.net, compiler-...@openjdk.java.net,
core-libs-...@openjdk.java.net, serviceability-dev@openjdk.java.net,
security-...@openjdk.java.net, net-...@openjdk.java.net
Message-ID: <20131002082305.2a14b62...@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.bacho...@oracle.com>
Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative
values
To: "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net"
<serviceability-dev@openjdk.java.net>, jmx-...@openjdk.java.net
Message-ID: <524bdd9e.1050...@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.all...@oracle.com>
Subject: Re: RFR (S): 6313383: SA: Update jmap to support HPROF binary
format "JAVA PROFILE 1.0.2"
To: Fredrik Arvidsson <fredrik.arvids...@oracle.com>
Cc: serviceability-dev@openjdk.java.net,
hotspot-runtime-...@openjdk.java.net
Message-ID: <4f092e8f-8002-4e02-9f75-519a3083a...@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.arvids...@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.ger...@oracle.com>
Subject: Re: RFR (S): 8016845: SA is unable to use hsdis on windows
To: Fredrik Arvidsson <fredrik.arvids...@oracle.com>,
serviceability-dev@openjdk.java.net,
hotspot-runtime-...@openjdk.java.net
Message-ID: <524bdea9.5020...@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.lar...@oracle.com>
Subject: Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative
values
To: Jaroslav Bachorik <jaroslav.bacho...@oracle.com>
Cc: "serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net"
<serviceability-dev@openjdk.java.net>, jmx-...@openjdk.java.net
Message-ID: <4088022f-6550-4c95-86d5-640f2e737...@oracle.com>
Content-Type: text/plain; charset=iso-8859-1
Looks good!
Thanks,
/Staffan
On 2 okt 2013, at 10:47, Jaroslav Bachorik <jaroslav.bacho...@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.arvids...@oracle.com>
Subject: Re: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't
enumerate anonymous classes
To: "serguei.spit...@oracle.com" <serguei.spit...@oracle.com>
Cc: serviceability-dev@openjdk.java.net,
hotspot-gc-...@openjdk.java.net,
hotspot-runtime-...@openjdk.java.net
Message-ID: <524be733.2070...@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.spit...@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."
