hg: jdk8/tl/nashorn: 7 new changesets

[sundararajan . athijegannathan]

Changeset: 6cb4f20d971f
Author:jlaskey
Date:  2013-10-11 14:54 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6cb4f20d971f

8026309: latest runsunspider.js tests contains several bugs
Reviewed-by: sundar, lagergren
Contributed-by: james.las...@oracle.com

! test/script/basic/runsunspider.js

Changeset: 8c617a092d68
Author:hannesw
Date:  2013-10-14 11:45 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c617a092d68

8026016: too many relinks dominate avatar.js http benchmark
Reviewed-by: sundar, jlaskey, attila

! src/jdk/nashorn/internal/runtime/ScriptObject.java
+ test/script/basic/JDK-8026016.js
+ test/script/basic/JDK-8026016.js.EXPECTED

Changeset: d155c4a7703c
Author:attila
Date:  2013-10-14 12:41 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d155c4a7703c

8026113: Nashorn arrays should automatically convert to Java arrays
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
+ test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java

Changeset: 64e841576c68
Author:attila
Date:  2013-10-15 15:57 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/64e841576c68

8026397: Fix ambiguity with array conversion, including passing JS NativeArrays 
in Java variable arity methods' vararg array position
Reviewed-by: jlaskey, sundar

! src/jdk/internal/dynalink/beans/SingleDynamicMethod.java
! src/jdk/internal/dynalink/support/Guards.java
! src/jdk/internal/dynalink/support/messages.properties
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java

Changeset: aa452eb4a5d0
Author:hannesw
Date:  2013-10-15 17:37 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa452eb4a5d0

8026367: Add a sync keyword to mozilla_compat
Reviewed-by: sundar, attila, lagergren

! src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8026367.js
! test/script/sandbox/loadcompat.js

Changeset: b3ee112a328e
Author:jlaskey
Date:  2013-10-15 13:14 -0300
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b3ee112a328e

8026498: Revert: latest runsunspider.js tests contains several bugs
Reviewed-by: sundar, hannesw
Contributed-by: james.las...@oracle.com

! test/script/basic/runsunspider.js

Changeset: 9a13e95cc40f
Author:sundar
Date:  2013-10-15 22:13 +0530
URL:   http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9a13e95cc40f

Merge

Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd

[Yekaterina Kantserova]

Hi David,

Thank you for your comments!

You have right, it's worth to check testlibrary changes twice. For 
example Erik Helin has pointed out to me there already is Asserts.java 
in hotspot/testlibrary. I don't mind to merge hotspot testlibrary into jdk.


Thanks,
Katja



On 10/16/2013 06:06 AM, David Holmes wrote:

Hi Katja,

Not a review just a couple of meta comments.

First I've added hotspto-dev as all these changes to the test library 
need a wider review audience. I'm a little concerned about its current 
rate of expansion.


Second all the new files have the wrong copyright notice - they should 
have the OpenJDK copyright.


Thanks,
David

On 15/10/2013 11:35 PM, Yekaterina Kantserova wrote:

Hi,

Could I please have a review of this fix.

The purpose of this fix is to get rid of intermittent failures in
sun/tools/jstatd tests and make the tests more stable, legible and
maintainable.

Thanks,
Katja

Webrev:
http://cr.openjdk.java.net/~ykantser/809/webrev.00/

Primal bug:
https://bugs.openjdk.java.net/browse/JDK-809

Similar bugs:
https://bugs.openjdk.java.net/browse/JDK-8019630
https://bugs.openjdk.java.net/browse/JDK-6636094
https://bugs.openjdk.java.net/browse/JDK-6543979

Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd

[Jaroslav Bachorik]

On 16.10.2013 10:06, Yekaterina Kantserova wrote:

Hi David,

Thank you for your comments!

You have right, it's worth to check testlibrary changes twice. For
example Erik Helin has pointed out to me there already is Asserts.java
in hotspot/testlibrary. I don't mind to merge hotspot testlibrary into jdk.


This is already tracked by JDK-8015497. It would be nice to have one 
shared testlibrary, though.


-JB-



Thanks,
Katja



On 10/16/2013 06:06 AM, David Holmes wrote:

Hi Katja,

Not a review just a couple of meta comments.

First I've added hotspto-dev as all these changes to the test library
need a wider review audience. I'm a little concerned about its current
rate of expansion.

Second all the new files have the wrong copyright notice - they should
have the OpenJDK copyright.

Thanks,
David

On 15/10/2013 11:35 PM, Yekaterina Kantserova wrote:

Hi,

Could I please have a review of this fix.

The purpose of this fix is to get rid of intermittent failures in
sun/tools/jstatd tests and make the tests more stable, legible and
maintainable.

Thanks,
Katja

Webrev:
http://cr.openjdk.java.net/~ykantser/809/webrev.00/

Primal bug:
https://bugs.openjdk.java.net/browse/JDK-809

Similar bugs:
https://bugs.openjdk.java.net/browse/JDK-8019630
https://bugs.openjdk.java.net/browse/JDK-6636094
https://bugs.openjdk.java.net/browse/JDK-6543979

Re: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq"

[Staffan Larsen]

Looks good!

Thanks,
/Staffan

On 15 okt 2013, at 12:53, Thomas Schatzl  wrote:

> Hi all,
> 
>  can I have reviews for the following change? It updates the SA agent
> that got out of date after the changes for JDK-7163191 where the
> HeapRegionSeq class has been refactored.
> 
> The changes mirror the changes in the C++ code of that revision, adding
> a G1HeapRegionTable java class, and the associated modifications in the
> HeapRegionSeq class.
> 
> There have been no interface changes to the HeapRegionSeq class to avoid
> breakage of any tools depending on it.
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8025925/webrev/
> 
> Testing:
> Connecting an SA-agent with the change on a running java program; test
> case in bug report
> 
> (I added the serviceability-dev mailing list as additional recipients as
> the change also concerns this part of the VM)
> 
> Thanks,
>  Thomas
> 
> 

Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd

[Jaroslav Bachorik]

On 15.10.2013 15:35, Yekaterina Kantserova wrote:

Hi,

Could I please have a review of this fix.

The purpose of this fix is to get rid of intermittent failures in
sun/tools/jstatd tests and make the tests more stable, legible and
maintainable.

Thanks,
Katja

Webrev:
http://cr.openjdk.java.net/~ykantser/809/webrev.00/

Primal bug:
https://bugs.openjdk.java.net/browse/JDK-809

Similar bugs:
https://bugs.openjdk.java.net/browse/JDK-8019630
https://bugs.openjdk.java.net/browse/JDK-6636094
https://bugs.openjdk.java.net/browse/JDK-6543979



Hi Katja,

these are my comments:

test/sun/tools/jstatd/JstatdHelper.java
===
* 82-84 Should be moved to 91 since the check is only valid for 
Tool.RMIREGISTRY
* Started processes are not cleaned up in case they get stuck for some 
reason. The original test tried to explicitely kill the target processes.



test/lib/testlibrary/jdk/testlibrary/Asserts.java
=
* Missing javadoc for the public library methods


test/lib/testlibrary/jdk/testlibrary/ProcessThread.java
===
* Missing javadoc for the public library methods


test/lib/testlibrary/jdk/testlibrary/TestThread.java

* Missing javadoc for the public library methods


test/lib/testlibrary/jdk/testlibrary/Utils.java
===
* Missing javadoc for the public library methods

* 57 serverSocket.close() should be called in "finally" block to make 
sure the resources are released even in case of an exception being thrown



test/sun/tools/jstatd/JstatGcutilParser.java

* The comments from the original test explaining the tested format are 
missing



Cheers,

-JB-

Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd

[Yekaterina Kantserova]

Thanks a lot for comments! Will check and change.

// Katja

On 10/16/2013 10:50 AM, Jaroslav Bachorik wrote:

On 15.10.2013 15:35, Yekaterina Kantserova wrote:

Hi,

Could I please have a review of this fix.

The purpose of this fix is to get rid of intermittent failures in
sun/tools/jstatd tests and make the tests more stable, legible and
maintainable.

Thanks,
Katja

Webrev:
http://cr.openjdk.java.net/~ykantser/809/webrev.00/

Primal bug:
https://bugs.openjdk.java.net/browse/JDK-809

Similar bugs:
https://bugs.openjdk.java.net/browse/JDK-8019630
https://bugs.openjdk.java.net/browse/JDK-6636094
https://bugs.openjdk.java.net/browse/JDK-6543979



Hi Katja,

these are my comments:

test/sun/tools/jstatd/JstatdHelper.java
===
* 82-84 Should be moved to 91 since the check is only valid for 
Tool.RMIREGISTRY
* Started processes are not cleaned up in case they get stuck for some 
reason. The original test tried to explicitely kill the target processes.



test/lib/testlibrary/jdk/testlibrary/Asserts.java
=
* Missing javadoc for the public library methods


test/lib/testlibrary/jdk/testlibrary/ProcessThread.java
===
* Missing javadoc for the public library methods


test/lib/testlibrary/jdk/testlibrary/TestThread.java

* Missing javadoc for the public library methods


test/lib/testlibrary/jdk/testlibrary/Utils.java
===
* Missing javadoc for the public library methods

* 57 serverSocket.close() should be called in "finally" block to make 
sure the resources are released even in case of an exception being thrown



test/sun/tools/jstatd/JstatGcutilParser.java

* The comments from the original test explaining the tested format are 
missing



Cheers,

-JB-

Re: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq"

[Thomas Schatzl]

Hi,

On Wed, 2013-10-16 at 10:48 +0200, Staffan Larsen wrote:
> Looks good!
> 

  Thanks Staffan and Mikael for the reviews!

Thomas

hg: hsx/hotspot-rt/hotspot: 8025638: jmap returns 0 instead of 1 when it fails.

[staffan . larsen]

Changeset: 7fe6ef09d242
Author:farvidsson
Date:  2013-10-16 09:20 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7fe6ef09d242

8025638: jmap returns 0 instead of 1 when it fails.
Summary: Re-factored some code handling return values and fails/errors during 
tool execution.
Reviewed-by: sla, kevinw
Contributed-by: fredrik.arvids...@oracle.com

! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java
! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java
! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java
! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java
! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java
! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java
! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java
! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java

hg: jdk8/tl/jdk: 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed

[dmitry . degrave]

Changeset: 9ea6a464c147
Author:igerasim
Date:  2013-10-15 21:15 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ea6a464c147

8023431: Test java/util/zip/GZIP/GZIPInZip.java failed
Summary: Properly close PipedStreams. Additional testing for malformed input
Reviewed-by: darcy, sherman

! test/java/util/zip/GZIP/GZIPInZip.java

Re: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads

[Mikael Auno]

This bug got a bit lost from my radar after vacation, but I've picked it
again now. I've moved Arrays.asList() as suggested. In further testing 
of the fix though, I found that the include list is not enough, as one 
of the expected method exit events is from String.intern(), which might 
also be called from background threads. To counter this, I added a 
thread filter to the events. This also has the added benefit of speeding 
up the test significantly (from 90 seconds to about 5 seconds) in the 
cases where there are background threads interfering.


Also added to this webrev is a fix for MethodEntryExitEvents.java which 
had exactly the same problem and a similar test design as 
MethodExitReturnValuesTest.java.


The updated webrev is at 
http://cr.openjdk.java.net/~allwin/auno/8009681/webrev.00/.


Thanks,
Mikael

On 2013-05-28 08:46, Staffan Larsen wrote:

Looks good.

You could optimize it a bit by not doing the Arrays.asList() on every
methodExit event.

/Staffan

On 17 apr 2013, at 15:03, Mikael Auno 
wrote:


Hi, I'd like some reviews on
http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for
JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681).

The issue here is that when MethodExitReturnValuesTest hooks into
MethodExit events through JDI it uses an exclude list to filter out
classes from which it is not interested in these events. This is
bound to break over and over again as new features are added to the
JDK. I've changed the test to use an include list instead,
containing only the handful of classes the test is actually
interested in.

Thanks,

>> Mikael

hg: jdk8/tl: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

[erik . joelsson]

Changeset: af81988013b5
Author:erikj
Date:  2013-10-16 13:50 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/af81988013b5

6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar
Reviewed-by: dholmes, chegar

! common/makefiles/JavaCompilation.gmk
! common/makefiles/RMICompilation.gmk

hg: jdk8/tl/corba: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

[erik . joelsson]

Changeset: 438c54c148a6
Author:erikj
Date:  2013-10-16 13:49 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/438c54c148a6

6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar
Reviewed-by: dholmes, chegar

! makefiles/BuildCorba.gmk

hg: jdk8/tl/jdk: 2 new changesets

[erik . joelsson]

Changeset: 76a7c0bc74fd
Author:erikj
Date:  2013-10-16 13:50 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76a7c0bc74fd

6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar
Reviewed-by: dholmes, chegar

! makefiles/GendataBreakIterator.gmk
! makefiles/GenerateClasses.gmk
! makefiles/Setup.gmk
! src/share/classes/sun/tools/tree/Node.java

Changeset: e078fd8a78f6
Author:erikj
Date:  2013-10-16 15:53 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e078fd8a78f6

Merge

Codereview request: 8026028 [findbugs] findbugs report some issue in com.sun.jmx.snmp package

[shanliang]

Hi,

Please review the following fix, main issue here is that we should clone 
an internal variable before returning.


webrev:
http://cr.openjdk.java.net/~sjiang/JDK-8026028/00/

bug
https://bugs.openjdk.java.net/browse/JDK-8026028

Thanks,
Shanliang

hg: jdk8/tl/jdk: 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx)

[rob . mckenna]

Changeset: d8eec0e3a023
Author:robm
Date:  2013-10-16 15:06 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8eec0e3a023

8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx)
Reviewed-by: chegar, alanb

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! test/java/net/InetAddress/GetLocalHostWithSM.java
! test/java/net/Socket/GetLocalAddress.java

RFR 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues

[Jaroslav Bachorik]

Please, review this simple test change.

The test tries to get the number of times a certain thread was blocked 
during the test run and intermittently fails with the difference of 1 - 
the expected number is 4 but the reported number is 3.


When updating the thread statistics (the blocked count in this case) no 
lock is used so there might be stale data when the ThreadMXBean 
retrieves the stats. The patch tries to workaround this problem by 
retrying a few times with the added delay. The test will try to obtain 
the correct result for at most 10 seconds - after that it will fail if 
the retrieved blocked count does not equal the expected blocked count.


Issue : https://bugs.openjdk.java.net/browse/JDK-7197919
Webrev: http://cr.openjdk.java.net/~jbachorik/7197919/webrev.00

Thanks,

-JB-

[PING] Re: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently

[Jaroslav Bachorik]

On 2.10.2013 12:55, Jaroslav Bachorik wrote:

On 20.9.2013 14:54, shanliang wrote:

Jaroslav,

It is a good idea to use the RMI Testlibrary.

Better to call:
agent.close();

at Line 55,  close the RMIRegistry (rmid.shutdown(rmidPort) Line 55)
does not ensure the JMX connector doing full clean, it is always better
to do clean within a test.


Thanks. Implemented.

http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01

-JB-



Shanliang


Jaroslav Bachorik wrote:

Please, review the following change for JDK-8024613

Issue: https://bugs.openjdk.java.net/browse/JDK-8024613
Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/


The patch takes care of intermittent test failures caused by timing
issues when starting the RMID process. It could happen that the RMID
process hasn't been properly initialized in the timeframe of 5 seconds
and the test would fail.

The patch replaces the home-brewed RMID process management with the
one available in the RMI Testlibrary which is used by more tests and
therefore should be more stable.

Thanks,

-JB-

Re: [PING] Re: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently

[Daniel Fuchs]

Hi Jaroslav,

Looks fine to me (not a reviewer).

-- daniel

On 10/16/13 4:44 PM, Jaroslav Bachorik wrote:

On 2.10.2013 12:55, Jaroslav Bachorik wrote:

On 20.9.2013 14:54, shanliang wrote:

Jaroslav,

It is a good idea to use the RMI Testlibrary.

Better to call:
agent.close();

at Line 55,  close the RMIRegistry (rmid.shutdown(rmidPort) Line 55)
does not ensure the JMX connector doing full clean, it is always better
to do clean within a test.


Thanks. Implemented.

http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01

-JB-



Shanliang


Jaroslav Bachorik wrote:

Please, review the following change for JDK-8024613

Issue: https://bugs.openjdk.java.net/browse/JDK-8024613
Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/


The patch takes care of intermittent test failures caused by timing
issues when starting the RMID process. It could happen that the RMID
process hasn't been properly initialized in the timeframe of 5 seconds
and the test would fail.

The patch replaces the home-brewed RMID process management with the
one available in the RMI Testlibrary which is used by more tests and
therefore should be more stable.

Thanks,

-JB-

Re: [PING] Re: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently

[shanliang]

Looks fine to me.

Shanliang

Jaroslav Bachorik wrote:

On 2.10.2013 12:55, Jaroslav Bachorik wrote:

On 20.9.2013 14:54, shanliang wrote:

Jaroslav,

It is a good idea to use the RMI Testlibrary.

Better to call:
agent.close();

at Line 55,  close the RMIRegistry (rmid.shutdown(rmidPort) Line 55)
does not ensure the JMX connector doing full clean, it is always better
to do clean within a test.


Thanks. Implemented.

http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01

-JB-



Shanliang


Jaroslav Bachorik wrote:

Please, review the following change for JDK-8024613

Issue: https://bugs.openjdk.java.net/browse/JDK-8024613
Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/


The patch takes care of intermittent test failures caused by timing
issues when starting the RMID process. It could happen that the RMID
process hasn't been properly initialized in the timeframe of 5 seconds
and the test would fail.

The patch replaces the home-brewed RMID process management with the
one available in the RMI Testlibrary which is used by more tests and
therefore should be more stable.

Thanks,

-JB-

hg: jdk8/tl/jdk: 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger

[daniel . fuchs]

Changeset: 445667b19e32
Author:dfuchs
Date:  2013-10-16 17:19 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445667b19e32

8011638: Remove deprecated methods in sun.util.logging.PlatformLogger
Reviewed-by: psandoz, mchung, alanb, chegar

! src/share/classes/sun/font/FontUtilities.java
! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java

RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops

[Erik Helin]

Hi all,

this patch fixes an issue where an oop in JvmtiBreakpoint,
JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector.

Instead of registering the oop as an unhandled oop, which would have
worked, I decided to wrap the oop in a handle as long as it is on the
stack.

A JvmtiBreakpoint is created on the stack by the two methods
JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This
JvmtiBreakpoint is only created to carry the Method*, jlocation and oop
to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when
at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy
the values from the stack allocated JvmtiBreakpoint and then place/clear the
newly alloacted JvmtiBreakpoint in
JvmtiCurrentBreakpoints::_jvmti_breakpoints.

I have updated to the code to check that the public constructor is only
used to allocate JvmtiBreakpoints on the stack (to warn a future
programmer if he/she decides to allocate one on the heap). The
class_loader oop is now wrapped in a Handle for stack allocated
JvmtiBreakpoints.

Due to the stack allocated JvmtiBreakpoint having the oop in a handle,
the oops_do method of VM_ChangeBreakpoints can be removed. This also
makes the oop in the handle safe for use after the VM_ChangeBreakpoint
operation is finished.

The unhandled oop in the JvmtiBreakpoint allocated on the heap will be
visited by the GC via jvmtiExport::oops_do ->
JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do ->
GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being
added to.

I've also removed some dead code to simplify the change:
- GrowableCache::insert
- JvmtiBreakpoint::copy
- JvmtiBreakpoint::lessThan
- GrowableElement::lessThan

Finally, I also formatted JvmtiEnv::ClearBreakpoint and
Jvmti::SetBreakpoint exactly the same to highlight that they share all
code except one line. Unfortunately, I was not able to remove this code
duplication in a good way.

Webrev:
http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/

Testing:
- JPRT
- The four tests that were failing are now passing

Thanks,
Erik

Re: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values

[Jaroslav Bachorik]

On 15.10.2013 08:49, David Holmes wrote:

Hi Jaroslav,

os_bsd.cpp / os_linux.cpp:

If you don't have a monotonic clock you leave timer_frequency set to 0!
(So you need to test on a system without a monotonic clock, or else
force it to act as-if not present.)

That aside I don't trust clock_getres to give values that actually allow
the timer frequency to be determined. As per the comments in os_linux.cpp:

// It's fixed in newer kernels, however clock_getres() still returns
// 1/HZ. We check if clock_getres() works, but will ignore its reported
// resolution for now. Hopefully as people move to new kernels, this
// won't be a problem.

we don't know what kernels provide real values here and which provide
dummy ones.

On BSD you haven't modified os::elapsed_counter.

Looking at the linux changes I don't think the logic is correct even if
clock_getres is accurate. In the existing code we have:

elapsed_counter -> elapsed time in microseconds
elapsed_frequency -> 1000 * 1000 (ie micros per second)
elapsed_time -> elapsed_counter*0.01 -> time in seconds

Now we have:

elapsed_counter -> elapsed time in nanoseconds
elapsed_frequency -> 1x10^9 / whatever clock_getres says
elapsed_time -> counter/frequency -> ???

So elapsed_time not, in general, going to give the elapsed time in
seconds. And elapsed_time is not dependent on the "frequency" at all
because elapsed_counter is not reporting ticks but an actual elapsed
"time" in nanoseconds.


Also note that we constants for:

NANOSECS_PER_SEC
NANOSECS_PER_MILLISEC

to aid with time conversions.

The linux webrev contains unrelated UseLargePages changes!


Sorry for the mess with UseLargePages changes :/

I've fixed the problems with the frequency (using a fixed number as 
before) and I kept the changes to minimum.


I was hesitating about changing the elapsed_counter precision from 
microseconds to nanoseconds but since solaris and windows versions 
already use nanosecond ticks for elapsed_counter I think the change is safe.


The update webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03




David
-


On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote:

On 10.10.2013 13:15, Staffan Larsen wrote:


On 10 okt 2013, at 13:02, Jaroslav Bachorik
 wrote:


On 10.10.2013 05:44, David Holmes wrote:

On 10/10/2013 4:12 AM, Staffan Larsen wrote:


On 9 okt 2013, at 16:19, Jaroslav Bachorik
 wrote:


On 9.10.2013 16:10, Staffan Larsen wrote:

There is now an awful amount of different timestamps in the
Management class. Can they be consolidated somehow? At least
_begin_vm_creation_time and the new _begin_vm_creation_ns.

This discussion also implies that the "elapsed time" we print in
the
hs_err file is also wrong. It uses os::elapsedTime() which uses
os::elapsed_counter().

And I guess the same thing for the VM.uptime Diagnostic Command
(class VMUptimeDCmd) which also relies on os::elapsed_counter().


Also the reported GC pauses duration might be wrong since it uses
Management::timestamp().

On the first sight the change looks rather trivial. But, honestly,
I'm not sure which other parts could for whatever reason break once
the time-of-day timestamp is replaced with a monotonic equivalent.
One would think that it shouldn't matter but one never knows ...

Staffan, do you think this kind of change is suitable for the
current
phase of JDK release cycle? I think I could improve the patch in few
days and then it should probably be able to pass the review before
ZBB. But, it's only P3  ...


I think it is a bit late in the release cycle to clean this up in the
way it should be cleaned up. I think we should wait until the first 8
update release and do a more thorough job than we have time for right
now.


I second that. The elapsed_counter/elpased_timer APIs and
implementations are a tangled mess. But part of the problem has been
that people want/expect monotonic time-of-day based timestamps (yes a
contradiction - though some people make sure TOD does not get modified
on their production systems). The use of timestamps in logging has
to be
examined carefully - mainly GC logging. I recall a "simple" attempted
change in the past that resulted in trying to compare a nanoTime based
timestamp with the TOD. :(


Actually, if I'm reading the sources right for Solaris and Win the
monotonic clock source is used to provide elapsed_counter() value. It
falls back to TOD when the monotonic clock source is not available.
For Linux/BSD the TOD is used directly.

This makes me wonder if changing the linux/bsd implementation to
follow the same logic would be really that disruptive.


Good point. I would like a world where elapsed_counter is monotonic
(where possible). Still a bit scary this late in the release, but an
interesting experiment.


The change is rather simple and tests ok. All the means to get a
monotonic timestamp are already there and proved to work. The core tests
in JPRT went fine.

The updated webrev is at
http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02

-

Re: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops

[Coleen Phillimore]

Erik,
Thank you for doing the extra cleanup for this.  Did you run the 
nsk.jvmti.testlist tests too though?   These things have a nasty way of 
interacting.   The code looks good though.


thanks,
Coleen

On 10/16/2013 12:09 PM, Erik Helin wrote:

Hi all,

this patch fixes an issue where an oop in JvmtiBreakpoint,
JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector.

Instead of registering the oop as an unhandled oop, which would have
worked, I decided to wrap the oop in a handle as long as it is on the
stack.

A JvmtiBreakpoint is created on the stack by the two methods
JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This
JvmtiBreakpoint is only created to carry the Method*, jlocation and oop
to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when
at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy
the values from the stack allocated JvmtiBreakpoint and then place/clear the
newly alloacted JvmtiBreakpoint in
JvmtiCurrentBreakpoints::_jvmti_breakpoints.

I have updated to the code to check that the public constructor is only
used to allocate JvmtiBreakpoints on the stack (to warn a future
programmer if he/she decides to allocate one on the heap). The
class_loader oop is now wrapped in a Handle for stack allocated
JvmtiBreakpoints.

Due to the stack allocated JvmtiBreakpoint having the oop in a handle,
the oops_do method of VM_ChangeBreakpoints can be removed. This also
makes the oop in the handle safe for use after the VM_ChangeBreakpoint
operation is finished.

The unhandled oop in the JvmtiBreakpoint allocated on the heap will be
visited by the GC via jvmtiExport::oops_do ->
JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do ->
GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being
added to.

I've also removed some dead code to simplify the change:
- GrowableCache::insert
- JvmtiBreakpoint::copy
- JvmtiBreakpoint::lessThan
- GrowableElement::lessThan

Finally, I also formatted JvmtiEnv::ClearBreakpoint and
Jvmti::SetBreakpoint exactly the same to highlight that they share all
code except one line. Unfortunately, I was not able to remove this code
duplication in a good way.

Webrev:
http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/

Testing:
- JPRT
- The four tests that were failing are now passing

Thanks,
Erik

Re: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops

[Mikael Gerdin]

Erik,

(it's not necessary to cross-post between hotspot-dev and 
hotspot-gc-dev, so I removed hotspot-gc from the CC list)


On 2013-10-16 18:09, Erik Helin wrote:

Hi all,

this patch fixes an issue where an oop in JvmtiBreakpoint,
JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector.

Instead of registering the oop as an unhandled oop, which would have
worked, I decided to wrap the oop in a handle as long as it is on the
stack.

A JvmtiBreakpoint is created on the stack by the two methods
JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This
JvmtiBreakpoint is only created to carry the Method*, jlocation and oop
to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when
at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy
the values from the stack allocated JvmtiBreakpoint and then place/clear the
newly alloacted JvmtiBreakpoint in
JvmtiCurrentBreakpoints::_jvmti_breakpoints.

I have updated to the code to check that the public constructor is only
used to allocate JvmtiBreakpoints on the stack (to warn a future
programmer if he/she decides to allocate one on the heap). The
class_loader oop is now wrapped in a Handle for stack allocated
JvmtiBreakpoints.

Due to the stack allocated JvmtiBreakpoint having the oop in a handle,
the oops_do method of VM_ChangeBreakpoints can be removed. This also
makes the oop in the handle safe for use after the VM_ChangeBreakpoint
operation is finished.

The unhandled oop in the JvmtiBreakpoint allocated on the heap will be
visited by the GC via jvmtiExport::oops_do ->
JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do ->
GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being
added to.

I've also removed some dead code to simplify the change:
- GrowableCache::insert
- JvmtiBreakpoint::copy
- JvmtiBreakpoint::lessThan
- GrowableElement::lessThan

Finally, I also formatted JvmtiEnv::ClearBreakpoint and
Jvmti::SetBreakpoint exactly the same to highlight that they share all
code except one line. Unfortunately, I was not able to remove this code
duplication in a good way.

Webrev:
http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/


jvmtiImpl.hpp:
Since clone() uses unhandled oops, and is only supposed to be used by 
the VM operation, would it make sense to 
assert(SafepointSynchronize::is_at_safepoint())?


196   GrowableElement *clone(){
 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle);

jvmtiImpl.cpp:
No comments.

jvmtiEnv.cpp:
Have you verified that the generated JVMTI entry point contains a 
ResourceMark or is it just not needed?

-  ResourceMark rm;
+  HandleMark hm;

Otherwise the code change looks good.


One thing that you didn't describe here, but which was related to the 
bug (which we discussed) was the fact that the old code tried to "do the 
right thing" WRT CheckUnhandledOops, but it incorrectly added a Method*:


thread->allow_unhandled_oop((oop*)&_method);

We should take care to find other such places where we try to put a 
non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in the 
unhandled oops code.


/Mikael



Testing:
- JPRT
- The four tests that were failing are now passing

Thanks,
Erik

hg: jdk8/tl/langtools: 8026704: Build failure with --enable-debug

[jonathan . gibbons]

Changeset: d7e155f874a7
Author:jjg
Date:  2013-10-16 10:47 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d7e155f874a7

8026704: Build failure with --enable-debug
Reviewed-by: ksrini

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
- test/tools/javac/lambda/LocalVariableTable.java

hg: jdk8/tl/jdk: 8013839: Enhance Logger API for handling of resource bundles; ...

[daniel . fuchs]

Changeset: 2ef43f3a901c
Author:dfuchs
Date:  2013-10-16 20:47 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ef43f3a901c

8013839: Enhance Logger API for handling of resource bundles
4814565: (rb) add method to get basename from a ResourceBundle
Summary: adds Logger.setResourceBundle(ResourceBundle) and 
ResourceBundle.getBaseBundleName()
Reviewed-by: mchung, naoto

! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
+ test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle.java
+ test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle_fr.java
+ 
test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle.properties
+ 
test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle_fr.properties
+ test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java
+ test/java/util/logging/Logger/logrb/resources/ListBundle.java
+ test/java/util/logging/Logger/logrb/resources/ListBundle_fr.java
+ test/java/util/logging/Logger/logrb/resources/PropertyBundle.properties
+ test/java/util/logging/Logger/logrb/resources/PropertyBundle_fr.properties
+ test/java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java
+ test/java/util/logging/Logger/setResourceBundle/resources/ListBundle.java
+ test/java/util/logging/Logger/setResourceBundle/resources/ListBundle_fr.java
+ 
test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle.properties
+ 
test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle_fr.properties

hg: hsx/hotspot-rt/hotspot: 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files

[staffan . larsen]

Changeset: 042cf42c72bd
Author:simonis
Date:  2013-10-16 15:06 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/042cf42c72bd

8026703: Wrongly placed  element in Event-Based JVM Tracing .xsl 
files
Reviewed-by: sla, kamg

! src/share/vm/trace/traceEventClasses.xsl
! src/share/vm/trace/traceEventIds.xsl
! src/share/vm/trace/traceTypes.xsl

hg: jdk8/tl/jdk: 8025910: rename substream(long) -> skip and remove substream(long, long)

[mike . duigou]

Changeset: cf9cb3d241a3
Author:mduigou
Date:  2013-10-16 13:03 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf9cb3d241a3

8025910: rename substream(long) -> skip and remove substream(long,long)
Reviewed-by: psandoz, henryjen

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java

hg: jdk8/tl/langtools: 8026286: Improper locking of annotation queues causes assertion failures.; ...

[eric . mccorkle]

Changeset: 7f6481e5fe3a
Author:emc
Date:  2013-10-16 16:33 -0400
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7f6481e5fe3a

8026286: Improper locking of annotation queues causes assertion failures.
8026063: Calls to annotate.flush() cause incorrect type annotations to be 
generated.
Summary: Fix locking in ClassReader.java
Reviewed-by: jfranck

! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+ test/tools/javac/annotations/typeAnnotations/TestAnonInnerInstance1.java
! test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java

hg: jdk8/tl/jdk: 8025255: (tz) Support tzdata2013g

[sean . coffey]

Changeset: 60e3cdbe8cdf
Author:aefimov
Date:  2013-10-13 14:19 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf

8025255: (tz) Support tzdata2013g
Reviewed-by: okutsu, mfang

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/antarctica
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/etcetera
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/iso3166.tab
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/southamerica
! make/sun/javazic/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/etcetera
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/iso3166.tab
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/zone.tab

URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file'

[Dmitry Samersoff]

On 2013-10-14 11:49, Staffan Larsen wrote:
> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. First, 
> I don't like having macros defined in the middle of a method. Second, the 
> definition of the macro includes the value of a local variable which is a bit 
> hairy. Can't you just ROUNDUP directly in the four places it's needed? I 
> think it would make for more readable code.
> 
> nit on line 743: filed -> field
> 
> Thanks,
> /Staffan
> 
> On 12 okt 2013, at 13:25, Dmitry Samersoff  
> wrote:
> 
>> Hi Everybody,
>>
>> Please review the fix
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/
>>
>> The value of p_memsz filed of elf header of LOAD section inside coredump
>> is rounded up to page size. So round up corresponding value read from
>> the header of library it self.
>>
>> -- 
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the sources.
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file'

[Dmitry Samersoff]

Staffan,

Just realized that my letter remain unsent.

Fixed in-place, press shift-reload.

http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/

-Dmitry


On 2013-10-14 11:49, Staffan Larsen wrote:
> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. First, 
> I don't like having macros defined in the middle of a method. Second, the 
> definition of the macro includes the value of a local variable which is a bit 
> hairy. Can't you just ROUNDUP directly in the four places it's needed? I 
> think it would make for more readable code.
> 
> nit on line 743: filed -> field
> 
> Thanks,
> /Staffan
> 
> On 12 okt 2013, at 13:25, Dmitry Samersoff  
> wrote:
> 
>> Hi Everybody,
>>
>> Please review the fix
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/
>>
>> The value of p_memsz filed of elf header of LOAD section inside coredump
>> is rounded up to page size. So round up corresponding value read from
>> the header of library it self.
>>
>> -- 
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the sources.
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

hg: hsx/hotspot-rt/hotspot: 2 new changesets

[harold . seigel]

Changeset: d248425bcfe8
Author:hseigel
Date:  2013-10-16 14:32 -0400
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d248425bcfe8

8024804: Crash when InterfaceMethodref resolves to Object.registerNatives
Summary: Added check for NULL prior to continuation of method look up to avoid 
runtime crash during look up of Object's superclass' methods.
Reviewed-by: coleenp, hseigel
Contributed-by: lois.fol...@oracle.com

! src/share/vm/interpreter/linkResolver.cpp
+ test/runtime/8024804/RegisterNatives.java

Changeset: 9e0ef3f02648
Author:hseigel
Date:  2013-10-16 15:26 -0400
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9e0ef3f02648

Merge

Re: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values

[David Holmes]

Hi Jaroslav,

Minor nit: os::elapsed_time should really be defined in terms of the 
other functions ie:


return ((double) os::elapsed_counter()) / os::elapsed_frequency();

I also prefer the cast above as it is very clear that we will be doing a 
floating-point division.


Aside: AFAICS os::elapsed_time() is never actually used ??

I agree that it appears that changing the frequency should be okay.

Thanks,
David

On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote:

On 15.10.2013 08:49, David Holmes wrote:

Hi Jaroslav,

os_bsd.cpp / os_linux.cpp:

If you don't have a monotonic clock you leave timer_frequency set to 0!
(So you need to test on a system without a monotonic clock, or else
force it to act as-if not present.)

That aside I don't trust clock_getres to give values that actually allow
the timer frequency to be determined. As per the comments in
os_linux.cpp:

// It's fixed in newer kernels, however clock_getres() still returns
// 1/HZ. We check if clock_getres() works, but will ignore its reported
// resolution for now. Hopefully as people move to new kernels, this
// won't be a problem.

we don't know what kernels provide real values here and which provide
dummy ones.

On BSD you haven't modified os::elapsed_counter.

Looking at the linux changes I don't think the logic is correct even if
clock_getres is accurate. In the existing code we have:

elapsed_counter -> elapsed time in microseconds
elapsed_frequency -> 1000 * 1000 (ie micros per second)
elapsed_time -> elapsed_counter*0.01 -> time in seconds

Now we have:

elapsed_counter -> elapsed time in nanoseconds
elapsed_frequency -> 1x10^9 / whatever clock_getres says
elapsed_time -> counter/frequency -> ???

So elapsed_time not, in general, going to give the elapsed time in
seconds. And elapsed_time is not dependent on the "frequency" at all
because elapsed_counter is not reporting ticks but an actual elapsed
"time" in nanoseconds.


Also note that we constants for:

NANOSECS_PER_SEC
NANOSECS_PER_MILLISEC

to aid with time conversions.

The linux webrev contains unrelated UseLargePages changes!


Sorry for the mess with UseLargePages changes :/

I've fixed the problems with the frequency (using a fixed number as
before) and I kept the changes to minimum.

I was hesitating about changing the elapsed_counter precision from
microseconds to nanoseconds but since solaris and windows versions
already use nanosecond ticks for elapsed_counter I think the change is
safe.

The update webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03




David
-


On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote:

On 10.10.2013 13:15, Staffan Larsen wrote:


On 10 okt 2013, at 13:02, Jaroslav Bachorik
 wrote:


On 10.10.2013 05:44, David Holmes wrote:

On 10/10/2013 4:12 AM, Staffan Larsen wrote:


On 9 okt 2013, at 16:19, Jaroslav Bachorik
 wrote:


On 9.10.2013 16:10, Staffan Larsen wrote:

There is now an awful amount of different timestamps in the
Management class. Can they be consolidated somehow? At least
_begin_vm_creation_time and the new _begin_vm_creation_ns.

This discussion also implies that the "elapsed time" we print in
the
hs_err file is also wrong. It uses os::elapsedTime() which uses
os::elapsed_counter().

And I guess the same thing for the VM.uptime Diagnostic Command
(class VMUptimeDCmd) which also relies on os::elapsed_counter().


Also the reported GC pauses duration might be wrong since it uses
Management::timestamp().

On the first sight the change looks rather trivial. But, honestly,
I'm not sure which other parts could for whatever reason break once
the time-of-day timestamp is replaced with a monotonic equivalent.
One would think that it shouldn't matter but one never knows ...

Staffan, do you think this kind of change is suitable for the
current
phase of JDK release cycle? I think I could improve the patch in
few
days and then it should probably be able to pass the review before
ZBB. But, it's only P3  ...


I think it is a bit late in the release cycle to clean this up in
the
way it should be cleaned up. I think we should wait until the
first 8
update release and do a more thorough job than we have time for
right
now.


I second that. The elapsed_counter/elpased_timer APIs and
implementations are a tangled mess. But part of the problem has been
that people want/expect monotonic time-of-day based timestamps (yes a
contradiction - though some people make sure TOD does not get
modified
on their production systems). The use of timestamps in logging has
to be
examined carefully - mainly GC logging. I recall a "simple" attempted
change in the past that resulted in trying to compare a nanoTime
based
timestamp with the TOD. :(


Actually, if I'm reading the sources right for Solaris and Win the
monotonic clock source is used to provide elapsed_counter() value. It
falls back to TOD when the monotonic clock source is not available.
For Linux/BSD the TOD is used directly.

This makes me wonder if changing the linux/bsd implementation t

Re: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file'

[David Holmes]

Hi Dmitry,

In

 716 static inline size_t round_page(int x){
 717   static int page_size;
 718
 719   page_size = sysconf(_SC_PAGE_SIZE);
 720   return ROUNDUP(x,page_size);
 721 }

Does page_size being static mean that line 719 will only be executed 
once? Otherwise it serves no purpose.


Typo: exisiting

Otherwise seems okay.

Thanks,
David

On 17/10/2013 7:11 AM, Dmitry Samersoff wrote:

On 2013-10-14 11:49, Staffan Larsen wrote:

The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. First, I 
don't like having macros defined in the middle of a method. Second, the 
definition of the macro includes the value of a local variable which is a bit 
hairy. Can't you just ROUNDUP directly in the four places it's needed? I think 
it would make for more readable code.

nit on line 743: filed -> field

Thanks,
/Staffan

On 12 okt 2013, at 13:25, Dmitry Samersoff  wrote:


Hi Everybody,

Please review the fix

http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/

The value of p_memsz filed of elf header of LOAD section inside coredump
is rounded up to page size. So round up corresponding value read from
the header of library it self.

--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

hg: jdk8/tl/jdk: 8026768: java.util.Map.Entry comparingBy methods missing @since 1.8

[henry . jen]

Changeset: e2e3c2c249e2
Author:henryjen
Date:  2013-10-16 21:34 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2e3c2c249e2

8026768: java.util.Map.Entry comparingBy methods missing @since 1.8
Reviewed-by: dholmes

! src/share/classes/java/util/Map.java

hg: jdk8/tl/jdk: 8025703: Update LSR datafile for BCP 47

[yuka . kamiya]

Changeset: ce266885222d
Author:peytoia
Date:  2013-10-17 13:57 +0900
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce266885222d

8025703: Update LSR datafile for BCP 47
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/LocaleEquivalentMaps.java
+ test/java/util/Locale/Bug8025703.java
! test/java/util/Locale/tools/language-subtag-registry.txt

hg: jdk8/tl/jdk: 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files

[bradford . wetmore]

Changeset: a45acc8de0f3
Author:wetmore
Date:  2013-10-16 23:32 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a45acc8de0f3

8026762: jdk8-tl builds windows builds failing in corba - javac: no source files
Reviewed-by: katleman, dholmes

! makefiles/GenerateClasses.gmk