From harold.seigel at oracle.com Sun Sep 1 09:37:30 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Sun, 01 Sep 2013 16:37:30 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8023381: VM fails to initialize in
runtime/CDSCompressedKPtrs/XShareAuto.java
runtime/SharedArchiveFile/CdsSameObjectAlignment.java
Message-ID: <20130901163744.0C1EA62478@hg.openjdk.java.net>
Changeset: 35b99e7e0af2
Author: hseigel
Date: 2013-09-01 10:37 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/35b99e7e0af2
8023381: VM fails to initialize in runtime/CDSCompressedKPtrs/XShareAuto.java runtime/SharedArchiveFile/CdsSameObjectAlignment.java
Summary: Improve handling when CDS archive cannot be mapped
Reviewed-by: kvn, dholmes, mseledtsov
! src/share/vm/memory/filemap.cpp
! test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java
! test/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java
From xuelei.fan at oracle.com Sun Sep 1 20:01:03 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Mon, 02 Sep 2013 03:01:03 +0000
Subject: hg: jdk8/tl/jdk: 8024068:
sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails
Message-ID: <20130902030200.A5CDA6248B@hg.openjdk.java.net>
Changeset: ead6babac5a9
Author: xuelei
Date: 2013-09-01 20:00 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ead6babac5a9
8024068: sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails
Reviewed-by: weijun
! test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java
From alex.schenkman at oracle.com Mon Sep 2 00:56:07 2013
From: alex.schenkman at oracle.com (Alex Schenkman)
Date: Mon, 02 Sep 2013 09:56:07 +0200
Subject: RFR 8014506: Test for Jdp (Java Discovery Protocol) feature
In-Reply-To: <3B20B5DC-9E92-4EB6-97FF-0F2D2B4E1E10@oracle.com>
References: <51A31867.9080602@oracle.com> <51CAC09B.7070706@oracle.com>
<7E2E50A8-1FB1-429B-8AAB-94863C215623@oracle.com>
<51D56A11.5030600@oracle.com> <5214AC0A.4010603@oracle.com>
<70F043F0-9F19-4761-B175-1D6652B5A146@oracle.com>
<3B20B5DC-9E92-4EB6-97FF-0F2D2B4E1E10@oracle.com>
Message-ID: <52244497.8010902@oracle.com>
I've added a README file and moved Dmitry's tests into its own folder,
to address the comments below.
http://cr.openjdk.java.net/~dsamersoff/sponsorship/aschenkman/8014506/webrev.03/
On 2013-08-21 20:10, Staffan Larsen wrote:
> A couple of more comments:
>
> - It was a little too hard to figure out exactly how the tests worked:
> who is sending JDP packets? who is listening for them? who is
> launching the tests? Perhaps it would make sense to add a small readme
> which explains how it all fits together?
>
> - There are already some JDP tests in that directory which are also
> made up of a couple of files. Mixing them together makes it hard to
> see which files belong to which set of tests. Maybe we should have
> distinct subfolders for the sets?
>
> - There is also the question of how much overlap there are between
> your tests and the already existing tests. It would be preferable to
> have no overlap. Perhaps some of the existing shell-based tests can be
> subsumed by your java-based tests?
>
> Thanks,
> /Staffan
>
> On 21 aug 2013, at 18:15, Staffan Larsen > wrote:
>
>> Alex,
>>
>> This looks a lot better than the previous version. Thanks for
>> cleaning things up. Below are a couple of comments:
>>
>> - Use of "package" is discouraged for jtreg test:
>> http://openjdk.java.net/jtreg/faq.html#question4.9
>>
>> - Maybe change name of SpecificLauncher.java to
>> SpecificJdpAddressLauncher.java?
>>
>> - The constructor and onSocketTimeOut() in JdpOffTest.java has wrong
>> indentation.
>>
>> - The comment for JdpOffTest.shouldContinue() has weird indentation.
>>
>> - How does one run PacketTest.java? It looks like a TestNG test, but
>> I couldn't get jtreg to run it.
>>
>> - Why the mix of standard jtreg tests and TestNG tests?
>>
>> - nit: somewhat non-standard formatting with spaces inside
>> parens: socket.receive( datagram );
>>
>> - nit: statements should be on a new line:
>> if ( hasTestLivedLongEnough() ) { shutdown(); }
>>
>>
>> Thanks,
>> /Staffan
>>
>> On 21 aug 2013, at 14:01, Alex Schenkman > > wrote:
>>
>>> Staffan, do you think you can take another look this?
>>> Thanks!
>>>
>>> On 2013-07-04 14:26, Alex Schenkman wrote:
>>>> Thanks Staffan for your comments.
>>>>
>>>> The indentation is corrected in all files, sorry about that.
>>>>
>>>> About the racing condition in PortFinder.java, you are absolutely
>>>> right, there is no warranty that this port will be free.
>>>> I do not know a better way to do this. Any suggestions?
>>>> On the other hand, even if this fails every now and then, it will
>>>> work most of the times and it is better than what we have today.
>>>> I have added better comments in PortFinder to reflect the problem.
>>>>
>>>> The new webrev is here [1], at the same address than before.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://cr.openjdk.java.net/~dsamersoff/8014506/webrev.01/
>>>>
>>>>
>>>> PS:
>>>> PortFinder.java, line 37:
>>>> There is an extra tag that should be removed.
>>>>
>>>>
>>>>
>>>> On 2013-06-26 13:54, Staffan Larsen wrote:
>>>>> test/lib/testlibrary/jdk/testlibrary/PortFinder.java:
>>>>>
>>>>> - This looks racy to me. There is no guarantee that the port will still be available after the call to close().
>>>>> - Missing copyright notice.
>>>>> - In comment "on of them" -> "one of them"
>>>>>
>>>>> test/sun/management/jdp/ClientConnection.java:
>>>>>
>>>>> - broken indentation
>>>>> - inconsistent spacing in method calls. Sometime "joinGroup(address);" and sometimes "setSoTimeout( msTimeOut );". Should be without spaces.
>>>>>
>>>>> test/sun/management/jdp/DynamicLauncher.java:
>>>>>
>>>>> - type: binded -> bound
>>>>> - inconsistent spacing in method calls
>>>>>
>>>>> test/sun/management/jdp/JdpOffTest.java
>>>>>
>>>>> - broken indentation
>>>>>
>>>>> test/sun/management/jdp/JdpTestUtil.java
>>>>>
>>>>> - broken indentation
>>>>>
>>>>>
>>>>> I stopped reading here. Can we get these basic things fixed before the next review round, please?
>>>>>
>>>>> /Staffan
>>>>>
>>>>>
>>>>> On 26 jun 2013, at 12:21, Dmitry Samersoff wrote:
>>>>>
>>>>>> Nils,
>>>>>>
>>>>>> I'm sponsoring this push but don't see any review replies in this thread.
>>>>>>
>>>>>> Webrev refreshed against latest tl is here:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8014506/webrev.01/
>>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>>
>>>>>> On 2013-05-27 12:25, Alex Schenkman wrote:
>>>>>>> Please review these tests for the Jdp protocol.
>>>>>>>
>>>>>>> There are three cases:
>>>>>>> 1) Jdp is off.
>>>>>>> 2) Jdp is on and using default address and port.
>>>>>>> 3) Jdp is on using custom address and port.
>>>>>>>
>>>>>>> Tests:http://cr.openjdk.java.net/~nloodin/8014506/webrev.00/
>>>>>>>
>>>>>>> Jdp feature enhancement:https://jbs.oracle.com/bugs/browse/JDK-8002048
>>>>>>> JDK CCC:http://ccc.us.oracle.com/8002048
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>>
>>>>>>> --
>>>>>>> Alex Schenkman
>>>>>>> Java VM SQE Stockholm
>>>>>>>
>>>>>> --
>>>>>> Dmitry Samersoff
>>>>>> Oracle Java development team, Saint Petersburg, Russia
>>>>>> * I would love to change the world, but they won't give me the sources.
>>>>
>>>> --
>>>> Alex Schenkman
>>>> Java VM SQE Stockholm
>>>
>>> --
>>> Alex Schenkman
>>> Java VM SQE Stockholm
>>
>
--
Alex Schenkman
Java VM SQE Stockholm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130902/67e079e7/attachment.html
From jaroslav.bachorik at oracle.com Mon Sep 2 02:13:58 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 02 Sep 2013 11:13:58 +0200
Subject: Codereview request for JDK-8023669: MBean*Info.hashCode : NPE
In-Reply-To: <521F5DFC.5050600@oracle.com>
References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com>
<521F5697.3040108@oracle.com> <521F5DFC.5050600@oracle.com>
Message-ID: <522456D6.6040102@oracle.com>
Hi,
On 08/29/2013 04:43 PM, Daniel Fuchs wrote:
> On 8/29/13 4:11 PM, shanliang wrote:
>> Here is the new version:
>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
>>
>> Indeed, calling Objects.hash(Object ...) is a good idea, which
>> simplifies the code.
>>
>> I used also Arrays.hashCode() to simplify the code, now the fix likes
>> really simple.
>>
>> I have passed JCK tests, unit tests of management are passed too in my
>> desk.
>>
>> toString() worked perfectly in the test, nothing to fix.
>>
>> Shanliang
>
> Hi Shanliang,
>
> This looks good! Thumbs up!
Looks good.
One minor nit is that
test/javax/management/MBeanInfo/MBeanInfoHashCodeNPETest.java:36 should
probably read "Tests that hashCode() does not throw NullPointerException"
-JB-
>
> -- daniel
>
>>
>> Daniel Fuchs wrote:
>>> On 8/29/13 9:34 AM, shanliang wrote:
>>>> Hi,
>>>>
>>>> Please review following fix, it addresses the issue only in the method
>>>> "hashCode":
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669
>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
>>>>
>>>> Thanks,
>>>> Shanliang
>>>>
>>>
>>> Hi Shanliang,
>>>
>>>
>>>
>>>
>>>
>>> I suggest to simplify this by calling:
>>>
>>> public int hashCode() {
>>> return Objects.hash(getName(), getType());
>>> }
>>>
>>> (see
>>> )
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> int hash = getName() == null ? 10 : getName().hashCode();
>>>
>>> could be replaced by:
>>>
>>> int hash = Objects.hashCode(getName());
>>>
>>> Generally - and that stands for the other files you modified, you can
>>> simplify things by replacing x.hashCode() with Objects.hashCode(x)
>>> whenever there's the possibility that x can be null.
>>>
>>> Note however that Objects is an API @since JDK 7 - so if you intend
>>> to backport this fix to 6 & 5 you will need to alter your changeset
>>> when backporting it.
>>>
>>>
>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest
>>> to use Objects.hash(...);
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> BTW: one more question: you're also testing toString() in the test
>>> and that's good - but are there any toString() that will require
>>> fixing?
>>>
>>>
>>
>
From jaroslav.bachorik at oracle.com Mon Sep 2 03:36:43 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 02 Sep 2013 12:36:43 +0200
Subject: VisualVM issue when starting JMX agent with jcmd
In-Reply-To:
References:
Message-ID: <52246A3B.9080201@oracle.com>
Hi Martin,
On 08/30/2013 08:36 AM, Martin Traverso wrote:
> I'm running into an issue when connecting to a process from VisualVM.
> First, let me describe the setup:
> - A Linux machine running jstatd configured with a "grant all permissions"
> policy file and a test java program that sleeps forever. The Java version
> is:
>
> java version "1.7.0_10"
> Java(TM) SE Runtime Environment (build 1.7.0_10-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)
>
> - VisualVM 1.3.6 (Java 1.7.0_25-b15) running on a Mac, with a "jstatd
> connection" entry for the first machine
>
> If I start the test program with the following -D options and connect to it
> in VisualVM, everything works fine. I can see the Overview, Monitor,
> Threads, MBeans tabs, browse the mbeans, etc.
>
> -Dcom.sun.management.jmxremote=true
> -Dcom.sun.management.jmxremote.port=9600
> -Dcom.sun.management.jmxremote.rmi.port=9601
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dcom.sun.management.jmxremote.ssl=false
>
> If, instead, I run it without any command line options and start the jmx
> agent via jcmd, some tabs are missing when I connect to the process in
> VisualVM. Also half of the things don't work (e.g., the mbeans tab shows
> "Data not available because JMX connection to the JMX agent could not be
> established", CPU information in the monitor tab is disabled, etc).
>
> jcmd ManagementAgent.start jmxremote.port=9600
> jmxremote.rmi.port=9601 jmxremote.ssl=false jmxremote.authenticate=false
> jcmd ManagementAgent.start_local
>
> Is this expected behavior? Is there any way around it? Maybe I'm missing
> some configuration options?
Well, it is expected. VisualVM performs the capability checks only on
the first access to the application. You can add a new JMX application
manually after you have enabled the management agent.
Cheers,
-JB-
>
> Thanks!
>
> Martin
>
From chris.hegarty at oracle.com Mon Sep 2 06:03:13 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 02 Sep 2013 13:03:13 +0000
Subject: hg: jdk8/tl/jdk: 8024103: AtomicLongArray
getAndAccumulate/accumulateAndGet have int type for new value arg
Message-ID: <20130902130401.1BB7E624A1@hg.openjdk.java.net>
Changeset: 441da45931fa
Author: chegar
Date: 2013-09-02 14:02 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/441da45931fa
8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg
Reviewed-by: alanb, psandoz
! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
From daniel.fuchs at oracle.com Mon Sep 2 09:40:14 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Mon, 02 Sep 2013 16:40:14 +0000
Subject: hg: jdk8/tl/jdk: 8016127: NLS: logging.properties translatability
recommendation; ...
Message-ID: <20130902164042.DF39A624A9@hg.openjdk.java.net>
Changeset: 92d594a938ff
Author: dfuchs
Date: 2013-09-02 18:28 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d594a938ff
8016127: NLS: logging.properties translatability recommendation
8024131: Issues with cached localizedLevelName in java.util.logging.Level
Summary: This fix updates logging.properties resource bundles to follow internationalization guidelines. It also fixes a caching issue with localizedLevelName. The regression test that was added needs both fixes to pass.
Reviewed-by: mchung, alanb
! src/share/classes/java/util/logging/Level.java
! src/share/classes/sun/util/logging/resources/logging.properties
! src/share/classes/sun/util/logging/resources/logging_de.properties
! src/share/classes/sun/util/logging/resources/logging_es.properties
! src/share/classes/sun/util/logging/resources/logging_fr.properties
! src/share/classes/sun/util/logging/resources/logging_it.properties
! src/share/classes/sun/util/logging/resources/logging_ja.properties
! src/share/classes/sun/util/logging/resources/logging_ko.properties
! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties
! src/share/classes/sun/util/logging/resources/logging_sv.properties
! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties
! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties
+ test/java/util/logging/LocalizedLevelName.java
From staffan.larsen at oracle.com Mon Sep 2 11:11:04 2013
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Mon, 02 Sep 2013 18:11:04 +0000
Subject: hg: jdk8/tl/jdk: 7172176: java/jconsole
test/sun/tools/jconsole/ImmutableResourceTest.sh failing
Message-ID: <20130902181123.8FC20624AC@hg.openjdk.java.net>
Changeset: a7d463f5a5b9
Author: egahlin
Date: 2013-09-02 16:03 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7d463f5a5b9
7172176: java/jconsole test/sun/tools/jconsole/ImmutableResourceTest.sh failing
Reviewed-by: mchung, mfang
! src/share/classes/sun/tools/jconsole/Resources.java
! test/ProblemList.txt
- test/sun/tools/jconsole/ImmutableResourceTest.java
- test/sun/tools/jconsole/ImmutableResourceTest.sh
! test/sun/tools/jconsole/ResourceCheckTest.java
! test/sun/tools/jconsole/ResourceCheckTest.sh
From vicente.romero at oracle.com Mon Sep 2 14:45:09 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Mon, 02 Sep 2013 21:45:09 +0000
Subject: hg: jdk8/tl/langtools: 8022162: Incorrect signature determination for
certain inner class generics
Message-ID: <20130902214512.172BA624B1@hg.openjdk.java.net>
Changeset: 2bf4c132bf90
Author: vromero
Date: 2013-09-02 22:44 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2bf4c132bf90
8022162: Incorrect signature determination for certain inner class generics
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+ test/tools/javac/T8022162/IncorrectSignatureDeterminationForInnerClassesTest.java
From vicente.romero at oracle.com Mon Sep 2 14:39:43 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Mon, 02 Sep 2013 21:39:43 +0000
Subject: hg: jdk8/tl/langtools: 8016177: structural most specific and stuckness
Message-ID: <20130902213946.1D225624AF@hg.openjdk.java.net>
Changeset: 4a6acc42c3a1
Author: vromero
Date: 2013-09-02 22:38 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a6acc42c3a1
8016177: structural most specific and stuckness
Reviewed-by: jjg, vromero
Contributed-by: maurizio.cimadamore at oracle.com
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Lint.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/util/GraphUtils.java
! src/share/classes/com/sun/tools/javac/util/List.java
! test/tools/javac/Diagnostics/compressed/T8012003c.out
! test/tools/javac/diags/examples/BadArgTypesInLambda.java
- test/tools/javac/diags/examples/CyclicInference.java
! test/tools/javac/diags/examples/IncompatibleArgTypesInMethodRef.java
+ test/tools/javac/diags/examples/PotentiallyAmbiguousOverload.java
+ test/tools/javac/lambda/8016177/T8016177a.java
+ test/tools/javac/lambda/8016177/T8016177a.out
+ test/tools/javac/lambda/8016177/T8016177b.java
+ test/tools/javac/lambda/8016177/T8016177b.out
+ test/tools/javac/lambda/8016177/T8016177c.java
+ test/tools/javac/lambda/8016177/T8016177c.out
+ test/tools/javac/lambda/8016177/T8016177d.java
+ test/tools/javac/lambda/8016177/T8016177e.java
+ test/tools/javac/lambda/8016177/T8016177f.java
+ test/tools/javac/lambda/8016177/T8016177g.java
+ test/tools/javac/lambda/8016177/T8016177g.out
! test/tools/javac/lambda/BadRecovery.out
! test/tools/javac/lambda/ErroneousLambdaExpr.java
+ test/tools/javac/lambda/ErroneousLambdaExpr.out
! test/tools/javac/lambda/MethodReference22.out
! test/tools/javac/lambda/MethodReference23.out
! test/tools/javac/lambda/MethodReference41.java
+ test/tools/javac/lambda/MethodReference41.out
! test/tools/javac/lambda/MethodReference42.java
+ test/tools/javac/lambda/MethodReference42.out
! test/tools/javac/lambda/MethodReference43.java
+ test/tools/javac/lambda/MethodReference43.out
! test/tools/javac/lambda/MethodReference44.java
+ test/tools/javac/lambda/MethodReference44.out
! test/tools/javac/lambda/MethodReference46.java
+ test/tools/javac/lambda/MethodReference46.out
! test/tools/javac/lambda/MethodReference47.java
! test/tools/javac/lambda/MethodReference47.out
! test/tools/javac/lambda/MethodReference48.java
+ test/tools/javac/lambda/MethodReference48.out
! test/tools/javac/lambda/MethodReference70.out
! test/tools/javac/lambda/MethodReference71.out
! test/tools/javac/lambda/MostSpecific04.java
+ test/tools/javac/lambda/MostSpecific04.out
! test/tools/javac/lambda/MostSpecific05.java
+ test/tools/javac/lambda/MostSpecific05.out
! test/tools/javac/lambda/MostSpecific08.java
+ test/tools/javac/lambda/MostSpecific08.out
! test/tools/javac/lambda/TargetType01.java
+ test/tools/javac/lambda/TargetType01.out
! test/tools/javac/lambda/TargetType02.java
+ test/tools/javac/lambda/TargetType02.out
! test/tools/javac/lambda/TargetType10.java
- test/tools/javac/lambda/TargetType10.out
! test/tools/javac/lambda/TargetType21.java
! test/tools/javac/lambda/TargetType21.out
! test/tools/javac/lambda/TargetType24.java
! test/tools/javac/lambda/TargetType24.out
! test/tools/javac/lambda/TargetType26.out
! test/tools/javac/lambda/TargetType27.out
! test/tools/javac/lambda/TargetType39.out
! test/tools/javac/lambda/TargetType43.out
! test/tools/javac/lambda/TargetType66.java
! test/tools/javac/lambda/TargetType66.out
! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java
- test/tools/javac/lambda/typeInference/InferenceTest5.java
+ test/tools/javac/lambda/typeInference/InferenceTest6.java
! test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out
- test/tools/javac/lambda/typeInference/InferenceTest_neg5.java
- test/tools/javac/lambda/typeInference/InferenceTest_neg5.out
! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java
From jaroslav.bachorik at oracle.com Tue Sep 3 01:02:09 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 03 Sep 2013 10:02:09 +0200
Subject: RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
Message-ID: <52259781.1070405@oracle.com>
Please, review the following patch:
http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
It addresses the problem of the test not properly cleaning up the
created threads at exit. It does so by running the test in "othervm"
mode. Although it is possible to modify the test to cleanup the threads
at exit it would add more complexity to the test while achieving the
same result as running the test in "othervm" mode.
Thanks,
-JB -
From chris.hegarty at oracle.com Tue Sep 3 01:21:43 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 03 Sep 2013 09:21:43 +0100
Subject: RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <52259781.1070405@oracle.com>
References: <52259781.1070405@oracle.com>
Message-ID: <52259C17.2080606@oracle.com>
On 09/03/2013 09:02 AM, Jaroslav Bachorik wrote:
> Please, review the following patch:
> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
>
> It addresses the problem of the test not properly cleaning up the
> created threads at exit. It does so by running the test in "othervm"
> mode. Although it is possible to modify the test to cleanup the threads
> at exit it would add more complexity to the test while achieving the
> same result as running the test in "othervm" mode.
Seems reasonable.
-Chris.
>
> Thanks,
>
> -JB -
>
From shanliang.jiang at oracle.com Tue Sep 3 01:32:46 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Tue, 03 Sep 2013 10:32:46 +0200
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <52259781.1070405@oracle.com>
References: <52259781.1070405@oracle.com>
Message-ID: <52259EAE.70007@oracle.com>
Looks good, simple but workable solution!
Shanliang
Jaroslav Bachorik wrote:
> Please, review the following patch:
> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
>
> It addresses the problem of the test not properly cleaning up the
> created threads at exit. It does so by running the test in "othervm"
> mode. Although it is possible to modify the test to cleanup the threads
> at exit it would add more complexity to the test while achieving the
> same result as running the test in "othervm" mode.
>
> Thanks,
>
> -JB -
>
From daniel.fuchs at oracle.com Tue Sep 3 02:17:05 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 03 Sep 2013 11:17:05 +0200
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <52259781.1070405@oracle.com>
References: <52259781.1070405@oracle.com>
Message-ID: <5225A911.7050507@oracle.com>
On 9/3/13 10:02 AM, Jaroslav Bachorik wrote:
> It addresses the problem of the test not properly cleaning up the
> created threads at exit. It does so by running the test in "othervm"
> mode. Although it is possible to modify the test to cleanup the threads
> at exit it would add more complexity to the test while achieving the
> same result as running the test in "othervm" mode.
+1
-- daniel
From Alan.Bateman at oracle.com Tue Sep 3 03:57:01 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Sep 2013 11:57:01 +0100
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <52259781.1070405@oracle.com>
References: <52259781.1070405@oracle.com>
Message-ID: <5225C07D.9050007@oracle.com>
On 03/09/2013 09:02, Jaroslav Bachorik wrote:
> Please, review the following patch:
> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
>
> It addresses the problem of the test not properly cleaning up the
> created threads at exit. It does so by running the test in "othervm"
> mode. Although it is possible to modify the test to cleanup the threads
> at exit it would add more complexity to the test while achieving the
> same result as running the test in "othervm" mode.
>
> Thanks,
>
> -JB -
This looks okay. There is a second test that I noted in the bug that has
a similar issue, maybe that needs its own bug.
-Alan
From jaroslav.bachorik at oracle.com Tue Sep 3 04:15:33 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 03 Sep 2013 13:15:33 +0200
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
Message-ID: <5225C4D5.6040805@oracle.com>
Please, review the following patch of the intermittently failing test:
http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
Sometimes the ThreadExecutionSynchronizer class failes to achieve the
desired synchronization (due to possible data races when evaluating and
setting the "waiting" variable) leading to test failures.
The patch fixes the possibility of data race. Also the Locks class is
tidied up a bit.
Thanks,
-JB-
From jaroslav.bachorik at oracle.com Tue Sep 3 04:26:32 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 03 Sep 2013 13:26:32 +0200
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <5225C07D.9050007@oracle.com>
References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com>
Message-ID: <5225C768.5050207@oracle.com>
On 09/03/2013 12:57 PM, Alan Bateman wrote:
> On 03/09/2013 09:02, Jaroslav Bachorik wrote:
>> Please, review the following patch:
>> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
>>
>> It addresses the problem of the test not properly cleaning up the
>> created threads at exit. It does so by running the test in "othervm"
>> mode. Although it is possible to modify the test to cleanup the threads
>> at exit it would add more complexity to the test while achieving the
>> same result as running the test in "othervm" mode.
>>
>> Thanks,
>>
>> -JB -
> This looks okay. There is a second test that I noted in the bug that has
> a similar issue, maybe that needs its own bug.
Hm, actually there are 6 other tests using the LockingThread class which
leaves the threads running. So all those tests should be made running in
"othervm" mode.
Does increasing the number of tests running in "othervm" mode have any
negative consequences?
-JB-
>
> -Alan
From jaroslav.bachorik at oracle.com Tue Sep 3 04:53:59 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 03 Sep 2013 13:53:59 +0200
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <5225C768.5050207@oracle.com>
References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com>
<5225C768.5050207@oracle.com>
Message-ID: <5225CDD7.4050405@oracle.com>
On 09/03/2013 01:26 PM, Jaroslav Bachorik wrote:
> On 09/03/2013 12:57 PM, Alan Bateman wrote:
>> On 03/09/2013 09:02, Jaroslav Bachorik wrote:
>>> Please, review the following patch:
>>> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.01
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8004179
>>>
>>> It addresses the problem of the test not properly cleaning up the
>>> created threads at exit. It does so by running the test in "othervm"
>>> mode. Although it is possible to modify the test to cleanup the threads
>>> at exit it would add more complexity to the test while achieving the
>>> same result as running the test in "othervm" mode.
>>>
>>> Thanks,
>>>
>>> -JB -
>> This looks okay. There is a second test that I noted in the bug that has
>> a similar issue, maybe that needs its own bug.
>
> Hm, actually there are 6 other tests using the LockingThread class which
> leaves the threads running. So all those tests should be made running in
> "othervm" mode.
I was too hasty, it seems. The number of tests not being run in
"othervm" mode and leaving live threads is 4 (in addition to
SynchronizerLockingThread). They are:
java/lang/management/ThreadMXBean/MyOwnSynchronizer
java/lang/management/ThreadMXBean/SharedSynchronizer
java/lang/management/ThreadMXBean/SynchronizationStatistics
java/lang/management/ThreadMXBean/LockedMonitors
-JB-
>
> Does increasing the number of tests running in "othervm" mode have any
> negative consequences?
>
> -JB-
>
>>
>> -Alan
>
From Alan.Bateman at oracle.com Tue Sep 3 04:54:50 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Sep 2013 12:54:50 +0100
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <5225C768.5050207@oracle.com>
References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com>
<5225C768.5050207@oracle.com>
Message-ID: <5225CE0A.9020305@oracle.com>
On 03/09/2013 12:26, Jaroslav Bachorik wrote:
> :
> Hm, actually there are 6 other tests using the LockingThread class which
> leaves the threads running. So all those tests should be made running in
> "othervm" mode.
>
> Does increasing the number of tests running in "othervm" mode have any
> negative consequences?
The big advantage of agentvm mode is that it doesn't need to start a new
VM for each test so you save on the startup. The advantage is very
apparent with short running tests, barely noticeable with long running
tests. It's okay to have tests running in othervm mode (reliability
trumps performance), we just need to be careful not to use it to fix
every issue, otherwise the overall test execution time will creep up.
-Alan.
From daniel.fuchs at oracle.com Tue Sep 3 05:10:57 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 03 Sep 2013 14:10:57 +0200
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5225C4D5.6040805@oracle.com>
References: <5225C4D5.6040805@oracle.com>
Message-ID: <5225D1D1.4080706@oracle.com>
Hi Jaroslav,
Have you considered replacing the ThreadExecutionSynchronizer with
a plain (and more reliable) CyclicBarrier or Phaser object?
best regards
-- daniel
On 9/3/13 1:15 PM, Jaroslav Bachorik wrote:
> Please, review the following patch of the intermittently failing test:
> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>
>
> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
> desired synchronization (due to possible data races when evaluating and
> setting the "waiting" variable) leading to test failures.
>
> The patch fixes the possibility of data race. Also the Locks class is
> tidied up a bit.
>
> Thanks,
>
> -JB-
>
From erik.gahlin at oracle.com Tue Sep 3 05:50:22 2013
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 03 Sep 2013 14:50:22 +0200
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5225C4D5.6040805@oracle.com>
References: <5225C4D5.6040805@oracle.com>
Message-ID: <5225DB0E.2000409@oracle.com>
Looks good,
but I think it's better for tests to spin forever if they can't reach a
state and let the test harness deal with it, but I'm fine with it, since
it was that way before.
Erik
Jaroslav Bachorik skrev 2013-09-03 13:15:
> Please, review the following patch of the intermittently failing test:
> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>
>
> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
> desired synchronization (due to possible data races when evaluating and
> setting the "waiting" variable) leading to test failures.
>
> The patch fixes the possibility of data race. Also the Locks class is
> tidied up a bit.
>
> Thanks,
>
> -JB-
From jaroslav.bachorik at oracle.com Tue Sep 3 06:02:39 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 03 Sep 2013 15:02:39 +0200
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5225D1D1.4080706@oracle.com>
References: <5225C4D5.6040805@oracle.com> <5225D1D1.4080706@oracle.com>
Message-ID: <5225DDEF.2010402@oracle.com>
On 09/03/2013 02:10 PM, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> Have you considered replacing the ThreadExecutionSynchronizer with
> a plain (and more reliable) CyclicBarrier or Phaser object?
>
>
>
>
Yes, I've played with the idea of using more advanced concurrency
constructs. But I couldn't fit the CyclicBarrier to the usecase and when
I used Phaser the solution complexity was considerably higher. It might
be due to my lack of experience with the Phaser, specifically, but the
plain old 'synchronized' yielded the best results for me :(
-JB-
>
> best regards
>
> -- daniel
>
> On 9/3/13 1:15 PM, Jaroslav Bachorik wrote:
>> Please, review the following patch of the intermittently failing test:
>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>
>>
>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>> desired synchronization (due to possible data races when evaluating and
>> setting the "waiting" variable) leading to test failures.
>>
>> The patch fixes the possibility of data race. Also the Locks class is
>> tidied up a bit.
>>
>> Thanks,
>>
>> -JB-
>>
>
From jaroslav.bachorik at oracle.com Tue Sep 3 06:36:39 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 03 Sep 2013 15:36:39 +0200
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <5225CE0A.9020305@oracle.com>
References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com>
<5225C768.5050207@oracle.com> <5225CE0A.9020305@oracle.com>
Message-ID: <5225E5E7.7000308@oracle.com>
On 09/03/2013 01:54 PM, Alan Bateman wrote:
> On 03/09/2013 12:26, Jaroslav Bachorik wrote:
>> :
>> Hm, actually there are 6 other tests using the LockingThread class which
>> leaves the threads running. So all those tests should be made running in
>> "othervm" mode.
>>
>> Does increasing the number of tests running in "othervm" mode have any
>> negative consequences?
> The big advantage of agentvm mode is that it doesn't need to start a new
> VM for each test so you save on the startup. The advantage is very
> apparent with short running tests, barely noticeable with long running
> tests. It's okay to have tests running in othervm mode (reliability
> trumps performance), we just need to be careful not to use it to fix
> every issue, otherwise the overall test execution time will creep up.
Ok, I've rounded up all the tests in java/lang/management/ThreadMXBean
not cleaning up the threads and not running in "othervm" mode and made
them running in "othervm" mode. There are 5 such tests.
IMO, for 5 tests it is worth to go for the simple solution and just run
them in "othervm" mode. If the number goes significantly higher, though,
we should consider putting more effort into fixing the cleanup logic in
those tests.
The updated patch is at
http://cr.openjdk.java.net/~jbachorik/8004179/webrev.02
-JB-
>
> -Alan.
From Alan.Bateman at oracle.com Tue Sep 3 06:52:36 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Sep 2013 14:52:36 +0100
Subject: jmx-dev RFR: 8004179:
test/java/lang/management/ThreadMXBean/SynchronizerLockingThread.java
doesn't clean up
In-Reply-To: <5225E5E7.7000308@oracle.com>
References: <52259781.1070405@oracle.com> <5225C07D.9050007@oracle.com>
<5225C768.5050207@oracle.com> <5225CE0A.9020305@oracle.com>
<5225E5E7.7000308@oracle.com>
Message-ID: <5225E9A4.4000805@oracle.com>
On 03/09/2013 14:36, Jaroslav Bachorik wrote:
> :
> Ok, I've rounded up all the tests in java/lang/management/ThreadMXBean
> not cleaning up the threads and not running in "othervm" mode and made
> them running in "othervm" mode. There are 5 such tests.
>
> IMO, for 5 tests it is worth to go for the simple solution and just run
> them in "othervm" mode. If the number goes significantly higher, though,
> we should consider putting more effort into fixing the cleanup logic in
> those tests.
>
> The updated patch is at
> http://cr.openjdk.java.net/~jbachorik/8004179/webrev.02
>
Okay, this seems okay for me for now.
-Alan.
From mike.duigou at oracle.com Tue Sep 3 11:29:51 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 03 Sep 2013 18:29:51 +0000
Subject: hg: jdk8/tl/jdk: 8024015: TEST.groups: move jdk/lambda tests from
jdk_other to jdk_lang
Message-ID: <20130903183016.83E8F624D5@hg.openjdk.java.net>
Changeset: 4bdbe25b1e04
Author: mduigou
Date: 2013-09-03 11:29 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbe25b1e04
8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang
Reviewed-by: alanb, mchung
! test/TEST.groups
From henry.jen at oracle.com Tue Sep 3 11:42:39 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 03 Sep 2013 18:42:39 +0000
Subject: hg: jdk8/tl/jdk: 8022176: Weaken contract of java.lang.AutoCloseable
Message-ID: <20130903184253.92577624D9@hg.openjdk.java.net>
Changeset: 77a8c4ad516c
Author: henryjen
Date: 2013-08-28 14:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a8c4ad516c
8022176: Weaken contract of java.lang.AutoCloseable
Reviewed-by: alanb, martin, mduigou, psandoz
Contributed-by: brian.goetz at oracle.com
! src/share/classes/java/lang/AutoCloseable.java
From henry.jen at oracle.com Tue Sep 3 11:45:02 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 03 Sep 2013 18:45:02 +0000
Subject: hg: jdk8/tl/jdk: 8024178: Difference in Stream.collect(Collector)
methods located in jdk8 and jdk8-lambda repos
Message-ID: <20130903184516.0465F624DA@hg.openjdk.java.net>
Changeset: 3db3ae4e0853
Author: henryjen
Date: 2013-09-03 11:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3db3ae4e0853
8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos
Reviewed-by: mduigou
! src/share/classes/java/util/stream/DelegatingStream.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
From henry.jen at oracle.com Tue Sep 3 12:20:56 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 03 Sep 2013 19:20:56 +0000
Subject: hg: jdk8/tl/jdk: 8017513: Support for closeable streams; ...
Message-ID: <20130903192122.7985F624DB@hg.openjdk.java.net>
Changeset: 2e8d51a5596b
Author: henryjen
Date: 2013-09-03 12:16 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e8d51a5596b
8017513: Support for closeable streams
8022237: j.u.s.BaseStream.onClose() has an issue in implementation or requires spec clarification
8022572: Same exception instances thrown from j.u.stream.Stream.onClose() handlers are not listed as suppressed
Summary: BaseStream implements AutoCloseable; Remove CloseableStream and DelegatingStream
Reviewed-by: alanb, mduigou, psandoz
Contributed-by: brian.goetz at oracle.com
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/BaseStream.java
- src/share/classes/java/util/stream/CloseableStream.java
- src/share/classes/java/util/stream/DelegatingStream.java
! 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
! src/share/classes/java/util/stream/Streams.java
! test/java/nio/file/Files/StreamTest.java
! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamCloseTest.java
From sean.coffey at oracle.com Tue Sep 3 14:38:37 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Tue, 03 Sep 2013 21:38:37 +0000
Subject: hg: jdk8/tl/jdk: 8017195: Introduce option to setKeepAlive parameter
on CORBA sockets
Message-ID: <20130903213858.AB7C2624EB@hg.openjdk.java.net>
Changeset: 5920155dd080
Author: coffeys
Date: 2013-09-03 22:37 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5920155dd080
8017195: Introduce option to setKeepAlive parameter on CORBA sockets
Reviewed-by: chegar, msheppar
+ test/com/sun/corba/transport/KeepAliveSockets.java
From sean.coffey at oracle.com Tue Sep 3 14:38:13 2013
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Tue, 03 Sep 2013 21:38:13 +0000
Subject: hg: jdk8/tl/corba: 8017195: Introduce option to setKeepAlive
parameter on CORBA sockets
Message-ID: <20130903213814.6AB1C624E9@hg.openjdk.java.net>
Changeset: af8e5bc3a150
Author: coffeys
Date: 2013-09-03 22:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/af8e5bc3a150
8017195: Introduce option to setKeepAlive parameter on CORBA sockets
Reviewed-by: chegar, msheppar
! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java
From vicente.romero at oracle.com Tue Sep 3 15:32:39 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 03 Sep 2013 22:32:39 +0000
Subject: hg: jdk8/tl/langtools: 8023389: Javac fails to infer type for lambda
used with intersection type and wildcards
Message-ID: <20130903223245.6CEFF624F9@hg.openjdk.java.net>
Changeset: fb5a846c4a49
Author: vromero
Date: 2013-09-03 23:31 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fb5a846c4a49
8023389: Javac fails to infer type for lambda used with intersection type and wildcards
Reviewed-by: jjg, vromero
Contributed-by: maurizio.cimadamore at oracle.com
! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/8023389/T8023389.java
From mike.duigou at oracle.com Tue Sep 3 15:27:52 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Tue, 03 Sep 2013 22:27:52 +0000
Subject: hg: jdk8/tl: 8024200: handle hg wrapper with space after #!
Message-ID: <20130903222753.16AF5624F7@hg.openjdk.java.net>
Changeset: 6d7f27953da6
Author: mduigou
Date: 2013-09-03 15:23 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/6d7f27953da6
8024200: handle hg wrapper with space after #!
Reviewed-by: tbell
! common/bin/hgforest.sh
From vicente.romero at oracle.com Tue Sep 3 15:48:35 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 03 Sep 2013 22:48:35 +0000
Subject: hg: jdk8/tl/langtools: 8023545: Misleading error message when using
diamond operator with private constructor
Message-ID: <20130903224838.B0601624FC@hg.openjdk.java.net>
Changeset: 9be0afbdf244
Author: vromero
Date: 2013-09-03 23:41 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9be0afbdf244
8023545: Misleading error message when using diamond operator with private constructor
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/T8023545/MisleadingErrorMsgDiamondPlusPrivateCtorTest.java
+ test/tools/javac/T8023545/MisleadingErrorMsgDiamondPlusPrivateCtorTest.out
From vicente.romero at oracle.com Tue Sep 3 16:02:41 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 03 Sep 2013 23:02:41 +0000
Subject: hg: jdk8/tl/langtools: 8023549: Compiler emitting spurious errors
when constructor reference type is inferred and explicit type
arguments are supplied
Message-ID: <20130903230245.08C30624FD@hg.openjdk.java.net>
Changeset: 438547d895dc
Author: vromero
Date: 2013-09-04 00:01 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/438547d895dc
8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied
Reviewed-by: jjg, vromero
Contributed-by: maurizio.cimadamore at oracle.com
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/MrefInferAndExplicitParams.java
+ test/tools/javac/lambda/8023549/T8023549.java
+ test/tools/javac/lambda/8023549/T8023549.out
From henry.jen at oracle.com Tue Sep 3 16:06:21 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Tue, 03 Sep 2013 23:06:21 +0000
Subject: hg: jdk8/tl/jdk: 8023997: j.l.String.join(java.lang.CharSequence,
java.lang.Iterable) sample doesn't compile and is incorrect
Message-ID: <20130903230634.D79CA624FE@hg.openjdk.java.net>
Changeset: 06b01083ebd7
Author: henryjen
Date: 2013-09-03 16:05 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06b01083ebd7
8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect
Reviewed-by: alanb
! src/share/classes/java/lang/String.java
From david.holmes at oracle.com Tue Sep 3 18:34:22 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 04 Sep 2013 11:34:22 +1000
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5225DDEF.2010402@oracle.com>
References: <5225C4D5.6040805@oracle.com> <5225D1D1.4080706@oracle.com>
<5225DDEF.2010402@oracle.com>
Message-ID: <52268E1E.2060306@oracle.com>
Hi Jaroslav,
On 3/09/2013 11:02 PM, Jaroslav Bachorik wrote:
> On 09/03/2013 02:10 PM, Daniel Fuchs wrote:
>> Hi Jaroslav,
>>
>> Have you considered replacing the ThreadExecutionSynchronizer with
>> a plain (and more reliable) CyclicBarrier or Phaser object?
>>
>>
>>
>>
>
> Yes, I've played with the idea of using more advanced concurrency
> constructs. But I couldn't fit the CyclicBarrier to the usecase and when
> I used Phaser the solution complexity was considerably higher. It might
> be due to my lack of experience with the Phaser, specifically, but the
> plain old 'synchronized' yielded the best results for me :(
Unfortunately your use of wait() does not account for spurious wakeups -
which the existing Semaphore masks from you.
A CyclicBarrier would seem to be a better fit, but the logic in this
test is convoluted enough that it is hard to tell exactly what the
synchronization protocol is.
Also your gratuitous style changes made it very hard to see actual
functional changes in the test. There's really no need to change for
loops into for-each loops. ;-)
David
----
> -JB-
>
>>
>> best regards
>>
>> -- daniel
>>
>> On 9/3/13 1:15 PM, Jaroslav Bachorik wrote:
>>> Please, review the following patch of the intermittently failing test:
>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>>
>>>
>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>>> desired synchronization (due to possible data races when evaluating and
>>> setting the "waiting" variable) leading to test failures.
>>>
>>> The patch fixes the possibility of data race. Also the Locks class is
>>> tidied up a bit.
>>>
>>> Thanks,
>>>
>>> -JB-
>>>
>>
>
From mandy.chung at oracle.com Tue Sep 3 19:24:51 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 03 Sep 2013 19:24:51 -0700
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5225C4D5.6040805@oracle.com>
References: <5225C4D5.6040805@oracle.com>
Message-ID: <522699F3.5000904@oracle.com>
Hi Jaroslav,
Like Daniel and David said, CyclicBarrier and other j.u.concurrent
utility seem a good replacement with the ThreadExecutionSynchronizer
class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
added to the platform (both java.util.concurrent and
java.lang.management were added in JDK 5). Later
ThreadExecutionSynchronizer was added to fix some intermittent issue.
I think it's worth the investigation to replace the existing logic with
j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
by a few other tests).
Mandy
On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
> Please, review the following patch of the intermittently failing test:
> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>
>
> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
> desired synchronization (due to possible data races when evaluating and
> setting the "waiting" variable) leading to test failures.
>
> The patch fixes the possibility of data race. Also the Locks class is
> tidied up a bit.
>
> Thanks,
>
> -JB-
From david.holmes at oracle.com Tue Sep 3 20:52:51 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Wed, 04 Sep 2013 03:52:51 +0000
Subject: hg: jdk8/tl/jdk: 8024140: [TESTBUG] Profile based regression test
groups for jdk repo
Message-ID: <20130904035308.EA4B662504@hg.openjdk.java.net>
Changeset: 2cdd1078f45b
Author: dholmes
Date: 2013-09-03 23:47 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cdd1078f45b
8024140: [TESTBUG] Profile based regression test groups for jdk repo
Reviewed-by: alanb, chegar
! test/TEST.groups
From robert.field at oracle.com Tue Sep 3 21:44:02 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Wed, 04 Sep 2013 04:44:02 +0000
Subject: hg: jdk8/tl/jdk: 8008688: Make MethodHandleInfo public
Message-ID: <20130904044413.E99EF62509@hg.openjdk.java.net>
Changeset: 4bdbd1fabea4
Author: rfield
Date: 2013-09-03 21:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbd1fabea4
8008688: Make MethodHandleInfo public
Summary: A major overhaul to MethodHandleInfo and method handles in general.
Reviewed-by: vlivanov, twisti
Contributed-by: john.r.rose at oracle.com
! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
+ src/share/classes/java/lang/invoke/InfoFromMemberName.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleInfo.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/invoke/SerializedLambda.java
! test/java/lang/invoke/7087570/Test7087570.java
+ test/java/lang/invoke/RevealDirectTest.java
+ test/java/lang/invoke/jtreg.security.policy
From jaroslav.bachorik at oracle.com Tue Sep 3 23:56:56 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 04 Sep 2013 08:56:56 +0200
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <522699F3.5000904@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
Message-ID: <5226D9B8.1040402@oracle.com>
On 09/04/2013 04:24 AM, Mandy Chung wrote:
> Hi Jaroslav,
>
> Like Daniel and David said, CyclicBarrier and other j.u.concurrent
> utility seem a good replacement with the ThreadExecutionSynchronizer
> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
> added to the platform (both java.util.concurrent and
> java.lang.management were added in JDK 5). Later
> ThreadExecutionSynchronizer was added to fix some intermittent issue.
>
> I think it's worth the investigation to replace the existing logic with
> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
> by a few other tests).
Ok, let's go back to the basics :)
The reason for the test to fail intermittently are stale reads from the
"waiting" variable. In order to minimize the changes it seems sufficient
to make the "waiting" variable volatile to prevent the stale reads. The
code modifying the "waiting" variable is already guarded by the
semaphore so we are good there.
The changes in Locks.java are about more consistent approach to waiting
for a thread to enter a desired state. I took Erik's recommendation to
just wait indefinitely for the desired thread state and let the harness
deal with timeouts.
The very simplified patch is at
http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
simplify java.lang.management tests using it.
-JB-
>
> Mandy
>
> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
>> Please, review the following patch of the intermittently failing test:
>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>
>>
>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>> desired synchronization (due to possible data races when evaluating and
>> setting the "waiting" variable) leading to test failures.
>>
>> The patch fixes the possibility of data race. Also the Locks class is
>> tidied up a bit.
>>
>> Thanks,
>>
>> -JB-
>
From jaroslav.bachorik at oracle.com Wed Sep 4 00:16:03 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 04 Sep 2013 09:16:03 +0200
Subject: jmx-dev RFR: 8002307
javax.management.modelmbean.ModelMBeanInfoSupport
may expose internal representation by storing an externally mutable
object
In-Reply-To: <51E7BB6C.6030704@oracle.com>
References: <51A4AB45.4070100@oracle.com> <51A4DC90.7050809@oracle.com>
<51E7BB6C.6030704@oracle.com>
Message-ID: <5226DE33.9000801@oracle.com>
[ping]
Thanks for the reviews. I still need a reviewer to take a look at this.
This issue blocks a P2 targeted for JDK8 (JDK-7148504).
Thanks,
-JB-
On 07/18/2013 11:54 AM, Jaroslav Bachorik wrote:
> Hi,
>
> thanks for the comments.
>
> Here (http://cr.openjdk.java.net/~jbachorik/8002307/webrev.03/) is the
> updated webrev implementing suggestions from Daniel and Shanliang.
>
> -JB-
>
>
From daniel.fuchs at oracle.com Wed Sep 4 00:19:24 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 04 Sep 2013 09:19:24 +0200
Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5226D9B8.1040402@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
<5226D9B8.1040402@oracle.com>
Message-ID: <5226DEFC.5000905@oracle.com>
Hi Jaroslav,
That looks like a reasonable small change if you are anxious to get that
fix out of your plate fast. I'll trust that your analysis is right and that
declaring waiting volatile is enough to fix the issue. It was certainly an
error to access 'waiting' from multiple threads without any kind of
synchronization.
I'll be happy to see ThreadExecutionSynchronizer go away in JDK 9 :-)
best regards,
-- daniel
On 9/4/13 8:56 AM, Jaroslav Bachorik wrote:
> On 09/04/2013 04:24 AM, Mandy Chung wrote:
>> Hi Jaroslav,
>>
>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent
>> utility seem a good replacement with the ThreadExecutionSynchronizer
>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
>> added to the platform (both java.util.concurrent and
>> java.lang.management were added in JDK 5). Later
>> ThreadExecutionSynchronizer was added to fix some intermittent issue.
>>
>> I think it's worth the investigation to replace the existing logic with
>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
>> by a few other tests).
>
> Ok, let's go back to the basics :)
>
> The reason for the test to fail intermittently are stale reads from the
> "waiting" variable. In order to minimize the changes it seems sufficient
> to make the "waiting" variable volatile to prevent the stale reads. The
> code modifying the "waiting" variable is already guarded by the
> semaphore so we are good there.
>
> The changes in Locks.java are about more consistent approach to waiting
> for a thread to enter a desired state. I took Erik's recommendation to
> just wait indefinitely for the desired thread state and let the harness
> deal with timeouts.
>
> The very simplified patch is at
> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
>
> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
> simplify java.lang.management tests using it.
>
> -JB-
>
>> Mandy
>>
>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
>>> Please, review the following patch of the intermittently failing test:
>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>>
>>>
>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>>> desired synchronization (due to possible data races when evaluating and
>>> setting the "waiting" variable) leading to test failures.
>>>
>>> The patch fixes the possibility of data race. Also the Locks class is
>>> tidied up a bit.
>>>
>>> Thanks,
>>>
>>> -JB-
From john.coomes at oracle.com Wed Sep 4 00:23:06 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 04 Sep 2013 07:23:06 +0000
Subject: hg: hsx/hotspot-rt: 5 new changesets
Message-ID: <20130904072306.B588D62526@hg.openjdk.java.net>
Changeset: c8da1b6a9762
Author: mduigou
Date: 2013-08-20 17:44 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/c8da1b6a9762
8023433: Improve 'make help'
Reviewed-by: tbell
! NewMakefile.gmk
Changeset: f643fee2b40f
Author: mduigou
Date: 2013-08-26 10:09 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/f643fee2b40f
8023491: Remove target names from test/Makefile and defer to sub-repo makefiles.
Reviewed-by: erikj
! common/makefiles/Main.gmk
! test/Makefile
Changeset: 163091288aeb
Author: lana
Date: 2013-08-26 14:49 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/163091288aeb
Merge
! common/makefiles/Main.gmk
Changeset: 51a61778a99d
Author: mduigou
Date: 2013-08-29 16:04 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/51a61778a99d
8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to put output.
Reviewed-by: erikj, vromero, henryjen
! test/Makefile
Changeset: 4ac867c44467
Author: lana
Date: 2013-08-29 16:18 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/4ac867c44467
Merge
From john.coomes at oracle.com Wed Sep 4 00:23:30 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 04 Sep 2013 07:23:30 +0000
Subject: hg: hsx/hotspot-rt/jaxws: 4 new changesets
Message-ID: <20130904072342.0440062527@hg.openjdk.java.net>
Changeset: b99d7e355d4b
Author: mkos
Date: 2013-08-23 09:57 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/b99d7e355d4b
8022885: Update JAX-WS RI integration to 2.2.9-b14140
8013016: Rebase 8009009 against the latest jdk8/jaxws
Reviewed-by: alanb, chegar
! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java
! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java
! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java
! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeRef.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/package-info.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java
! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/package-info.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/EditDistance.java
! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDEventListener.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDHandlerBase.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDParser.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EndOfInputException.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EntityDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/ExternalEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InputEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InternalEntity.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/MessageCatalog.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/Resolver.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/SimpleHashtable.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlChars.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlNames.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlReader.java
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/package.html
! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/resources/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreatorProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AttributesHolder.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/FragmentedArray.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBuffer.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferException.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferMark.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferResult.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferSource.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/DefaultWithLexicalHandler.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Features.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Properties.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java
! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java
! src/share/jaxws_classes/com/sun/xml/internal/txw2/output/XMLWriter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties
! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java
! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/ersSet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/group.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/JAXPParser.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/XSOMParser.java
! src/share/jaxws_classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java
! src/share/jaxws_classes/javax/xml/bind/Binder.java
! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java
! src/share/jaxws_classes/javax/xml/bind/DataBindingException.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverter.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java
! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterInterface.java
! src/share/jaxws_classes/javax/xml/bind/Element.java
! src/share/jaxws_classes/javax/xml/bind/GetPropertyAction.java
! src/share/jaxws_classes/javax/xml/bind/JAXB.java
! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java
! src/share/jaxws_classes/javax/xml/bind/JAXBElement.java
! src/share/jaxws_classes/javax/xml/bind/JAXBException.java
! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java
! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java
! src/share/jaxws_classes/javax/xml/bind/MarshalException.java
! src/share/jaxws_classes/javax/xml/bind/Messages.java
! src/share/jaxws_classes/javax/xml/bind/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/NotIdentifiableEvent.java
! src/share/jaxws_classes/javax/xml/bind/ParseConversionEvent.java
! src/share/jaxws_classes/javax/xml/bind/PrintConversionEvent.java
! src/share/jaxws_classes/javax/xml/bind/PropertyException.java
! src/share/jaxws_classes/javax/xml/bind/SchemaOutputResolver.java
! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java
! src/share/jaxws_classes/javax/xml/bind/UnmarshalException.java
! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java
! src/share/jaxws_classes/javax/xml/bind/UnmarshallerHandler.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEvent.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEventHandler.java
! src/share/jaxws_classes/javax/xml/bind/ValidationEventLocator.java
! src/share/jaxws_classes/javax/xml/bind/ValidationException.java
! src/share/jaxws_classes/javax/xml/bind/Validator.java
! src/share/jaxws_classes/javax/xml/bind/WhiteSpaceProcessor.java
! src/share/jaxws_classes/javax/xml/bind/annotation/DomHandler.java
! src/share/jaxws_classes/javax/xml/bind/annotation/W3CDomHandler.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessOrder.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorOrder.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyAttribute.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttachmentRef.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttribute.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementDecl.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRef.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRefs.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementWrapper.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElements.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnum.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnumValue.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlID.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlIDREF.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlList.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMixed.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNs.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNsForm.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRegistry.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRootElement.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchema.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaTypes.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSeeAlso.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlTransient.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlType.java
! src/share/jaxws_classes/javax/xml/bind/annotation/XmlValue.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java
! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html
! src/share/jaxws_classes/javax/xml/bind/annotation/package.html
! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentMarshaller.java
! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java
! src/share/jaxws_classes/javax/xml/bind/attachment/package.html
! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java
! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.java
! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ParseConversionEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/PrintConversionEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java
! src/share/jaxws_classes/javax/xml/bind/helpers/package.html
! src/share/jaxws_classes/javax/xml/bind/package.html
! src/share/jaxws_classes/javax/xml/bind/util/JAXBResult.java
! src/share/jaxws_classes/javax/xml/bind/util/JAXBSource.java
! src/share/jaxws_classes/javax/xml/bind/util/Messages.java
! src/share/jaxws_classes/javax/xml/bind/util/Messages.properties
! src/share/jaxws_classes/javax/xml/bind/util/ValidationEventCollector.java
! src/share/jaxws_classes/javax/xml/bind/util/package.html
Changeset: d8593d8581df
Author: mkos
Date: 2013-08-23 11:10 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/d8593d8581df
8023636: Missing files from 8022885
Reviewed-by: alanb, chegar
+ src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/StreamingSOAP.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamespaceContextExAdaper.java
+ src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLReaderComposite.java
Changeset: 533c1032337c
Author: lana
Date: 2013-08-26 14:50 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/533c1032337c
Merge
Changeset: 6908370afe83
Author: lana
Date: 2013-08-29 16:18 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/6908370afe83
Merge
From paul.sandoz at oracle.com Wed Sep 4 00:32:57 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 04 Sep 2013 07:32:57 +0000
Subject: hg: jdk8/tl/jdk: 8024182: test/java/util/Arrays/SetAllTest.java fails
to compile due to recent compiler changes
Message-ID: <20130904073331.52F5B6252A@hg.openjdk.java.net>
Changeset: 462c5589bc1a
Author: psandoz
Date: 2013-08-12 12:22 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/462c5589bc1a
8024182: test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes
Summary: Use explicit lambda due to javac simplfying rules for overload resolution with implicit lambdas
Reviewed-by: alanb, mduigou
! test/java/util/Arrays/SetAllTest.java
From john.coomes at oracle.com Wed Sep 4 00:24:58 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 04 Sep 2013 07:24:58 +0000
Subject: hg: hsx/hotspot-rt/jdk: 48 new changesets
Message-ID: <20130904073532.52CDD6252B@hg.openjdk.java.net>
Changeset: eb18a483e772
Author: alanb
Date: 2013-08-21 09:59 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eb18a483e772
8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile
Reviewed-by: lancea, mduigou
! test/TEST.ROOT
+ test/TEST.groups
Changeset: 68be998c2596
Author: egahlin
Date: 2013-08-19 12:57 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/68be998c2596
6358357: Division by zero in Threads tab when shrinking jconsole window
Reviewed-by: mchung, leifs, jbachorik
! src/share/classes/sun/tools/jconsole/Plotter.java
Changeset: bddf55211ed8
Author: egahlin
Date: 2013-08-19 16:21 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bddf55211ed8
6417721: Thread list should not allow multiple selection
Reviewed-by: alanb, jbachorik, sjiang
! src/share/classes/sun/tools/jconsole/ThreadTab.java
Changeset: 2636d337a1ed
Author: egahlin
Date: 2013-08-19 16:41 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2636d337a1ed
6800801: NPE in JConsole when using Nimbus L&F
Reviewed-by: alanb, sjiang
! src/share/classes/sun/tools/jconsole/ConnectDialog.java
! src/share/classes/sun/tools/jconsole/VMPanel.java
Changeset: ba943fc47fc8
Author: egahlin
Date: 2013-08-19 13:11 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ba943fc47fc8
7042707: Un-needed mnemonic in JConsole resource file
Reviewed-by: mfang, jbachorik
! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties
! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties
! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
Changeset: 3b8fed46b2a8
Author: dholmes
Date: 2013-08-21 05:56 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3b8fed46b2a8
8023460: OPENJDK build fails due to missing jfr.jar
Reviewed-by: alanb
! makefiles/Profiles.gmk
Changeset: 8996f47f738d
Author: sla
Date: 2013-08-21 17:19 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8996f47f738d
8023485: Remove com/sun/jdi/DoubleAgentTest.java and com/sun/jdi/FieldWatchpoints.java from ProblemList.txt
Reviewed-by: chegar, mgronlun
! test/ProblemList.txt
Changeset: fad3b6673159
Author: mduigou
Date: 2013-08-21 12:03 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fad3b6673159
8023306: Add replace() implementations to TreeMap
Reviewed-by: psandoz, alanb, chegar, bpb
! src/share/classes/java/util/TreeMap.java
Changeset: 91a31c77be5b
Author: mduigou
Date: 2013-08-21 12:03 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/91a31c77be5b
8023395: Remove sun.misc.Sort and sun.misc.Compare
Reviewed-by: alanb, smarks, darcy, mr
- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java
Changeset: 60891d90327f
Author: henryjen
Date: 2013-08-20 14:23 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/60891d90327f
8016846: Pattern.splitAsStream tests required
Reviewed-by: alanb, psandoz
Contributed-by: Ben Evans
+ test/java/util/regex/PatternTest.java
Changeset: ec827a62070a
Author: xuelei
Date: 2013-08-21 19:44 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ec827a62070a
8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs
Reviewed-by: weijun
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java
! test/sun/security/ssl/templates/SSLSocketTemplate.java
Changeset: a0896634ab46
Author: sla
Date: 2013-08-22 08:28 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a0896634ab46
8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails
Reviewed-by: ysr
! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
Changeset: b7c4094be729
Author: darcy
Date: 2013-08-22 09:40 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b7c4094be729
8023587: Fix lone remaining doclint issue in java.util.regex
Reviewed-by: jjg
! src/share/classes/java/util/regex/Pattern.java
Changeset: 8a7d9cc2f41c
Author: dxu
Date: 2013-08-22 11:43 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8a7d9cc2f41c
8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details
Reviewed-by: alanb
! test/ProblemList.txt
! test/java/io/File/MaxPathLength.java
Changeset: 2281a7f79738
Author: plevart
Date: 2013-08-20 14:13 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2281a7f79738
8022721: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition
Reviewed-by: alanb, jfranck
! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java
Changeset: 7496ec8bab76
Author: smarks
Date: 2013-08-22 15:54 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7496ec8bab76
8022445: fix RMISocketFactory example to avoid using localhost
Reviewed-by: chegar, alanb
! src/share/classes/java/rmi/server/RMISocketFactory.java
Changeset: 7b6211cd8d76
Author: egahlin
Date: 2013-08-21 17:15 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7b6211cd8d76
6417649: -interval=0 is accepted and jconsole doesn't update window content at all
Reviewed-by: alanb, jbachorik
! src/share/classes/sun/tools/jconsole/JConsole.java
Changeset: 77a32e5df365
Author: egahlin
Date: 2013-08-21 17:17 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/77a32e5df365
6359971: Threads tab: Simple text to explain that one can click on a thread to get stack trace
Reviewed-by: alanb, jbachorik
! src/share/classes/sun/tools/jconsole/Messages.java
! src/share/classes/sun/tools/jconsole/ThreadTab.java
! src/share/classes/sun/tools/jconsole/resources/messages.properties
Changeset: 223be1d3494f
Author: bpb
Date: 2013-08-22 13:32 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/223be1d3494f
6470700: Math.random() / Math.initRNG() uses "double checked locking"
Summary: Replace class Random variable with a static final holder class
Reviewed-by: alanb, mduigou, chegar
Contributed-by: Brian Burkhalter
! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java
Changeset: 4ef82445ea20
Author: dfuchs
Date: 2013-08-23 20:59 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4ef82445ea20
8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle
Reviewed-by: mchung, lancea
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/Logger/getLogger/TestLogger.java
+ test/java/util/logging/Logger/getLogger/testlogger/MyResource.java
Changeset: 216a4b93cee8
Author: bpb
Date: 2013-08-23 14:15 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/216a4b93cee8
6378503: In java.math.BigDecimal, division by one returns zero
6446965: Using BigDecimal.divideToIntegralValue with extreme scales can lead to an incorrect result
Summary: Fix overflow of ints and ensure appropriate values passed to checkScaleNonZero()
Reviewed-by: darcy, martin
Contributed-by: Brian Burkhalter
! src/share/classes/java/math/BigDecimal.java
! src/share/classes/java/math/BigInteger.java
! test/java/math/BigDecimal/IntegralDivisionTests.java
Changeset: 0ee3b995d63b
Author: alanb
Date: 2013-08-26 10:01 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0ee3b995d63b
8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8)
Reviewed-by: alanb
Contributed-by: yiming.wang at oracle.com
! test/java/nio/file/WatchService/SensitivityModifier.java
Changeset: 67a1a031876a
Author: igerasim
Date: 2013-08-25 23:20 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/67a1a031876a
7129312: BufferedInputStream calculates negative array size with large streams and mark
Reviewed-by: alanb
! src/share/classes/java/io/BufferedInputStream.java
+ test/java/io/BufferedInputStream/LargeCopyWithMark.java
Changeset: 6917c114b197
Author: jfranck
Date: 2013-08-26 13:38 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6917c114b197
8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases
Reviewed-by: darcy, vromero, psandoz
! src/share/classes/java/lang/Class.java
! test/java/lang/annotation/TypeAnnotationReflection.java
+ test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
Changeset: 8a36fc7f494c
Author: shade
Date: 2013-08-26 17:50 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8a36fc7f494c
8023234: StampedLock serializes readers on writer unlock
Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock
Reviewed-by: martin, shade
Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java
Changeset: 07585a2483fa
Author: rriggs
Date: 2013-08-26 11:46 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/07585a2483fa
8011944: Sort fails with ArrayIndexOutOfBoundsException
Summary: Increase the size of pending stack and add test cases
Reviewed-by: alanb
! src/share/classes/java/util/ComparableTimSort.java
! src/share/classes/java/util/TimSort.java
+ test/java/util/Arrays/TimSortStackSize.java
Changeset: 92a66af7f834
Author: igerasim
Date: 2013-08-26 18:26 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/92a66af7f834
8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions
Reviewed-by: alanb, chegar
! src/share/classes/java/lang/AbstractStringBuilder.java
Changeset: 5ce9025c9e1a
Author: psandoz
Date: 2013-08-26 22:55 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5ce9025c9e1a
8020292: j.u.SplittableRandom
Reviewed-by: mduigou
Contributed-by: Guy Steele , Doug Lea , Brian Goetz , Paul Sandoz
+ src/share/classes/java/util/SplittableRandom.java
+ test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java
Changeset: 35c1609d9488
Author: henryjen
Date: 2013-08-09 09:05 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/35c1609d9488
8023681: Fix raw type warning caused by Sink
Reviewed-by: mduigou, briangoetz
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/DistinctOps.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Sink.java
! src/share/classes/java/util/stream/SliceOps.java
! src/share/classes/java/util/stream/SortedOps.java
Changeset: 9586ca82bd8b
Author: bpittore
Date: 2013-08-26 11:27 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9586ca82bd8b
8014135: The JVMTI specification does not conform to recent changes in JNI specification
Summary: Added support for statically linked agents
Reviewed-by: alanb, sspitsyn, bobv, coleenp
! src/share/classes/com/sun/tools/attach/VirtualMachine.java
Changeset: c58e39bb5d62
Author: lana
Date: 2013-08-26 14:53 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c58e39bb5d62
Merge
Changeset: 6cdc679e3412
Author: lana
Date: 2013-08-26 22:18 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6cdc679e3412
Merge
Changeset: ca53110f1c74
Author: weijun
Date: 2013-08-27 17:50 +0800
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ca53110f1c74
8015669: KerberosPrincipal::equals should ignore name-type
Reviewed-by: mullan
! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
+ test/sun/security/krb5/auto/KPEquals.java
Changeset: 4bddc344848e
Author: weijun
Date: 2013-08-27 17:50 +0800
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4bddc344848e
8022761: regression: SecurityException is NOT thrown while trying to pack a wrongly signed Indexed Jar file
Reviewed-by: sherman
! src/share/classes/java/util/jar/JarVerifier.java
+ test/sun/security/tools/jarsigner/jvindex.sh
Changeset: 134283a88499
Author: mullan
Date: 2013-08-27 10:46 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/134283a88499
8023769: JDK-8016850 broke the old build
Summary: remove files that were moved/removed from com/sun/security/auth/FILES_java.gmk
Reviewed-by: chegar, xuelei
! make/com/sun/security/auth/FILES_java.gmk
Changeset: 6a1bfcde4d4d
Author: mullan
Date: 2013-08-27 12:04 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6a1bfcde4d4d
8019830: Add com.sun.media.sound to the list of restricted package
Reviewed-by: vinnie
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/java/lang/SecurityManager/CheckPackageAccess.java
Changeset: 3575263eefab
Author: mullan
Date: 2013-08-27 12:27 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3575263eefab
Merge
- src/share/classes/com/sun/security/auth/PolicyParser.java
- src/share/classes/com/sun/security/auth/SubjectCodeSource.java
- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java
Changeset: 51151b440e95
Author: darcy
Date: 2013-08-27 11:46 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/51151b440e95
8023827: Fix doclint issues in javax.net.ssl
Reviewed-by: wetmore, xuelei
! src/share/classes/javax/net/ssl/SNIHostName.java
! src/share/classes/javax/net/ssl/X509KeyManager.java
Changeset: ade440668f94
Author: henryjen
Date: 2013-08-26 22:32 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ade440668f94
8023275: Wrapping collections should override default methods
Reviewed-by: mduigou, psandoz
! src/share/classes/java/util/Collections.java
+ test/java/util/Collections/Wrappers.java
Changeset: 3f6777cbfe69
Author: sherman
Date: 2013-08-27 12:54 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3f6777cbfe69
8023647: "abc1c".matches("(\\w)+1\\1")) returns false
Summary: to correct the wrong GroupCurly group index backoff code
Reviewed-by: alanb
! src/share/classes/java/util/regex/Pattern.java
! test/java/util/regex/RegExTest.java
Changeset: be2d25a277a7
Author: henryjen
Date: 2013-08-21 20:41 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/be2d25a277a7
8023528: Rename Comparator combinators to disambiguate overloading methods
Reviewed-by: mduigou, smarks
! src/share/classes/java/util/Comparator.java
! test/java/util/Comparator/BasicTest.java
! test/java/util/Map/EntryComparators.java
! test/java/util/function/BinaryOperator/BasicTest.java
Changeset: 2efa310226f7
Author: alanb
Date: 2013-08-28 14:07 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2efa310226f7
8023717: (process) ProcessBuilder should catch SecurityException rather than AccessControlException
Reviewed-by: wetmore, alanb
Contributed-by: martinrb at google.com
! src/share/classes/java/lang/ProcessBuilder.java
Changeset: 378acd4d03c8
Author: alanb
Date: 2013-08-28 15:50 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/378acd4d03c8
8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil
Reviewed-by: chegar
! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java
! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java
! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java
! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java
! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/EPoll.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollPort.java
! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/InheritedChannel.java
! src/solaris/classes/sun/nio/ch/KQueue.java
! src/solaris/classes/sun/nio/ch/KQueuePort.java
! src/solaris/classes/sun/nio/ch/NativeThread.java
! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SolarisEventPort.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java
! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java
! src/windows/classes/sun/nio/ch/DatagramDispatcher.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
! src/windows/classes/sun/nio/ch/FileKey.java
! src/windows/classes/sun/nio/ch/Iocp.java
! src/windows/classes/sun/nio/ch/PipeImpl.java
! src/windows/classes/sun/nio/ch/SocketDispatcher.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
Changeset: 690b2931baef
Author: sherman
Date: 2013-08-28 09:46 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/690b2931baef
8023713: ZipFileSystem crashes on old zip file
Summary: to handle extra data field copy correctly even the extra data does not follow the spec
Reviewed-by: alanb, martin, chegar
! src/share/classes/java/util/zip/ZipOutputStream.java
! test/java/util/zip/TestExtraTime.java
Changeset: b1f41565b806
Author: psandoz
Date: 2013-08-28 22:11 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b1f41565b806
8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom
Reviewed-by: mduigou
Contributed-by: Doug Lea , Paul Sandoz
! src/share/classes/java/util/Random.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/Random/RandomStreamTest.java
+ test/java/util/Random/RandomTest.java
! test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java
Changeset: 779ff9f3b2e3
Author: sla
Date: 2013-08-29 11:22 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/779ff9f3b2e3
8023786: (jdk) setjmp/longjmp changes the process signal mask on OS X
Reviewed-by: dholmes
! src/share/back/SDE.c
! src/share/native/common/check_code.c
Changeset: 5bf4f2eeee85
Author: dxu
Date: 2013-08-29 10:43 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5bf4f2eeee85
4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links
Summary: Exclude the possible usage of linked files or directories in the test
Reviewed-by: alanb
! test/java/io/pathNames/General.java
Changeset: c817276bd870
Author: lana
Date: 2013-08-29 16:26 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c817276bd870
Merge
- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java
From john.coomes at oracle.com Wed Sep 4 00:38:58 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 04 Sep 2013 07:38:58 +0000
Subject: hg: hsx/hotspot-rt/nashorn: 24 new changesets
Message-ID: <20130904073920.796D46252E@hg.openjdk.java.net>
Changeset: dbb0a20a6f27
Author: attila
Date: 2013-08-21 13:39 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/dbb0a20a6f27
8023373: allow super invocation for adapters
Reviewed-by: lagergren, sundar
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
+ test/script/basic/JDK-8023373.js
+ test/script/basic/JDK-8023373.js.EXPECTED
Changeset: dc322503ce36
Author: attila
Date: 2013-08-21 13:39 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/dc322503ce36
8022903: Enhance for-in and for-each for Lists and Maps
Reviewed-by: lagergren, sundar
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
+ test/script/basic/JDK-8022903.js
+ test/script/basic/JDK-8022903.js.EXPECTED
Changeset: b7c04b3b01a7
Author: sundar
Date: 2013-08-21 17:28 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/b7c04b3b01a7
8023368: Instance __proto__ property should exist and be writable.
Reviewed-by: attila, hannesw
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/NativeObject.java
! src/jdk/nashorn/internal/runtime/PropertyListener.java
! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
! src/jdk/nashorn/internal/runtime/resources/Options.properties
! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8023368.js
+ test/script/basic/JDK-8023368.js.EXPECTED
+ test/script/basic/JDK-8023368_2.js
+ test/script/basic/JDK-8023368_2.js.EXPECTED
+ test/script/basic/circular_proto.js
+ test/script/basic/circular_proto.js.EXPECTED
+ test/script/basic/mirror_proto_assign.js
+ test/script/basic/mirror_proto_assign.js.EXPECTED
+ test/script/basic/nonextensible_proto_assign.js
+ test/script/basic/nonextensible_proto_assign.js.EXPECTED
Changeset: 54f60d91024c
Author: sundar
Date: 2013-08-22 18:46 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/54f60d91024c
8023551: Mirror functions can not be invoked using invokeMethod, invokeFunction
Reviewed-by: attila, jlaskey, lagergren
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
+ test/script/basic/JDK-8023551.js
+ test/script/basic/JDK-8023551.js.EXPECTED
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
Changeset: 8ad9bcb04e6d
Author: hannesw
Date: 2013-08-22 17:23 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/8ad9bcb04e6d
8023531: new RegExp('').toString() should return '/(?:)/'
Reviewed-by: sundar, jlaskey
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/regexp/RegExp.java
+ test/script/basic/JDK-8023531.js
Changeset: c5c5ab3f420a
Author: jlaskey
Date: 2013-08-22 13:51 -0300
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/c5c5ab3f420a
8023228: Debugger information gather is too slow.
Reviewed-by: sundar, lagergren
Contributed-by: james.laskey at oracle.com
! src/jdk/nashorn/internal/runtime/Context.java
+ src/jdk/nashorn/internal/runtime/DebuggerSupport.java
Changeset: 5a1e07b9a3cd
Author: sundar
Date: 2013-08-22 22:32 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/5a1e07b9a3cd
8023560: Arbitrary javax.script.Bindings objects as ENGINE_SCOPE objects are not handled as expected.
Reviewed-by: jlaskey, lagergren, hannesw
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java
Changeset: d82ac93aa55c
Author: sundar
Date: 2013-08-23 16:10 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/d82ac93aa55c
8023631: engine.js init script should be loaded into every global instance created by engines
Reviewed-by: attila, hannesw
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/resources/engine.js
+ test/src/jdk/nashorn/api/scripting/InvocableTest.java
+ test/src/jdk/nashorn/api/scripting/ScopeTest.java
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
+ test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java
Changeset: 6b6a8fc714a9
Author: lagergren
Date: 2013-08-23 12:43 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/6b6a8fc714a9
8023453: --log=attr did not unindent identNodes
Reviewed-by: attila, jlaskey
! src/jdk/nashorn/internal/codegen/Attr.java
Changeset: 4dcd5a22fdd3
Author: lagergren
Date: 2013-08-23 12:44 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/4dcd5a22fdd3
Merge
Changeset: f18f2ce1b2dc
Author: attila
Date: 2013-08-23 13:10 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f18f2ce1b2dc
8023630: Implement Java.super() as the preferred way to call super methods
Reviewed-by: jlaskey, lagergren, sundar
! src/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
+ src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapter.java
+ src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
+ test/script/basic/JDK-8023630.js
+ test/script/basic/JDK-8023630.js.EXPECTED
! test/script/basic/NASHORN-397.js
Changeset: 2ce55025a37d
Author: sundar
Date: 2013-08-23 16:44 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/2ce55025a37d
Merge
Changeset: a18f92a0a910
Author: lana
Date: 2013-08-26 14:54 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/a18f92a0a910
Merge
Changeset: badc919cd621
Author: lagergren
Date: 2013-08-23 14:16 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/badc919cd621
8023550: -d option was broken for any dir but '.'. Fixed Java warnings.
Reviewed-by: jlaskey, sundar
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java
! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java
! src/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk/internal/dynalink/DefaultBootstrapper.java
! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java
! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeRegExp.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/DebuggerSupport.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java
! src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Region.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java
! src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java
! src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java
! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java
! tools/fxshell/jdk/nashorn/tools/FXShell.java
Changeset: e2d94d032760
Author: jlaskey
Date: 2013-08-23 09:56 -0300
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/e2d94d032760
8020946: TokenType#toString returned null
Reviewed-by: hannesw, lagergren
Contributed-by: james.laskey at oracle.com
! src/jdk/nashorn/internal/parser/TokenType.java
Changeset: eb7b8340ce3a
Author: lagergren
Date: 2013-08-23 15:46 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/eb7b8340ce3a
8023454: Updated DEVELOPER_README and command line flags, ensuring that undocumented flags that aren't guaranteed to work (disabled by default) and that are work in progress show up with an EXPERIMENTAL tag.
Reviewed-by: attila, jlaskey
! docs/DEVELOPER_README
! src/jdk/nashorn/internal/runtime/resources/Options.properties
Changeset: 12820c8d0a5d
Author: jlaskey
Date: 2013-08-23 12:20 -0300
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/12820c8d0a5d
8019987: String trimRight and trimLeft could be defined
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com
! src/jdk/nashorn/internal/objects/NativeString.java
+ test/script/basic/JDK-8019987.js
Changeset: c19c66e661a9
Author: hannesw
Date: 2013-08-26 15:59 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/c19c66e661a9
8023650: Regexp m flag does not recognize CRNL or CR
Reviewed-by: jlaskey, lagergren
! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Config.java
! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java
! src/jdk/nashorn/tools/Shell.java
+ test/script/basic/JDK-8023650.js
Changeset: 99e48c76d11f
Author: jlaskey
Date: 2013-08-26 15:33 -0300
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/99e48c76d11f
8023721: Simplify eval in DebuggerSupport.
Reviewed-by: sundar, lagergren, hannesw
Contributed-by: james.laskey at oracle.com
! src/jdk/nashorn/internal/runtime/DebuggerSupport.java
Changeset: 3bd077423a08
Author: sundar
Date: 2013-08-27 15:54 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/3bd077423a08
8022773: ScriptEngineTest.printManyTest fails
Reviewed-by: lagergren, attila
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
Changeset: 47f0a4c4b729
Author: attila
Date: 2013-08-27 13:17 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/47f0a4c4b729
8023780: Gracefully handle @CS methods while binding bean properties
Reviewed-by: jlaskey, lagergren, sundar
! src/jdk/nashorn/internal/objects/NativeObject.java
+ test/script/basic/JDK-8023780.js
+ test/script/basic/JDK-8023780.js.EXPECTED
Changeset: bda0e89f88ae
Author: sundar
Date: 2013-08-27 18:57 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/bda0e89f88ae
8023784: Object.prototype.toString should contain the class name for all instances
Reviewed-by: lagergren, jlaskey
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java
! src/jdk/nashorn/internal/objects/NativeFloat32Array.java
! src/jdk/nashorn/internal/objects/NativeFloat64Array.java
! src/jdk/nashorn/internal/objects/NativeInt16Array.java
! src/jdk/nashorn/internal/objects/NativeInt32Array.java
! src/jdk/nashorn/internal/objects/NativeInt8Array.java
! src/jdk/nashorn/internal/objects/NativeUint16Array.java
! src/jdk/nashorn/internal/objects/NativeUint32Array.java
! src/jdk/nashorn/internal/objects/NativeUint8Array.java
! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
+ test/script/basic/JDK-8023784.js
+ test/script/basic/JDK-8023784.js.EXPECTED
! test/script/basic/NASHORN-377.js.EXPECTED
Changeset: 101606d3eb84
Author: sundar
Date: 2013-08-27 19:26 +0530
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/101606d3eb84
Merge
Changeset: bf70cbd2c836
Author: lana
Date: 2013-08-29 16:34 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/bf70cbd2c836
Merge
From john.coomes at oracle.com Wed Sep 4 00:37:34 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Wed, 04 Sep 2013 07:37:34 +0000
Subject: hg: hsx/hotspot-rt/langtools: 21 new changesets
Message-ID: <20130904073843.335606252C@hg.openjdk.java.net>
Changeset: 7de231613e4a
Author: jjg
Date: 2013-08-21 16:13 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7de231613e4a
8023515: import type-annotations updates
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com
! src/share/classes/com/sun/source/tree/MethodTree.java
! src/share/classes/com/sun/source/tree/TypeParameterTree.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java
+ test/tools/javac/annotations/typeAnnotations/failures/DummyProcessor.java
+ test/tools/javac/annotations/typeAnnotations/failures/T8020715.java
! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java
+ test/tools/javac/tree/TypeAnnotationsPretty.java
Changeset: 2068190f8ac2
Author: emc
Date: 2013-08-21 20:23 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2068190f8ac2
7118412: Shadowing of type-variables vs. member types
4987840: What is the scope of an annotation?
Summary: Fixed issue with shadowing of type names.
Reviewed-by: jjg, abuckley, mcimadamore
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
Changeset: 57e1266527dd
Author: jjg
Date: 2013-08-21 17:26 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/57e1266527dd
8022287: javac.sym.Profiles uses a static Map when it should not
Reviewed-by: ksrini
! src/share/classes/com/sun/tools/javac/sym/Profiles.java
+ test/tools/javac/profiles/ProfileTest.java
Changeset: eebb29618f50
Author: emc
Date: 2013-08-21 20:41 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/eebb29618f50
8023520: Add missing test for JDK-7118412
Summary: The test for JDK-7118412 was dropped from the changeset in a merging accident.
Reviewed-by: jjg
+ test/tools/javac/7118412/ShadowingTest.java
Changeset: 7a4717f3ea7b
Author: vromero
Date: 2013-08-22 10:22 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7a4717f3ea7b
8022316: Generic throws, overriding and method reference
Reviewed-by: jjg, mcimadamore
! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.java
+ test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.out
Changeset: 25aaff78d754
Author: vromero
Date: 2013-08-22 13:12 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/25aaff78d754
8023112: javac should not use lazy constant evaluation approach for method references
Reviewed-by: jjg, mcimadamore
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/T8023112/SkipLazyConstantCreationForMethodRefTest.java
Changeset: 1ab22e60a738
Author: emc
Date: 2013-08-22 12:47 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1ab22e60a738
8020745: Suspicious MethodParameters attribute generated for local classes capturing local variables
Summary: Corrected an error in a previous patch that caused captured locals to be added to the beginning, not the end of a parameter list.
Reviewed-by: jjg, mcimadamore, ksrini, abuckley
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
- test/tools/javac/8015701/AnonymousParameters.java
+ test/tools/javac/MethodParameters/CaptureTest.java
Changeset: b77381d99056
Author: jjg
Date: 2013-08-22 12:41 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b77381d99056
8022173: Relax some warnings in doclint
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclint/HtmlTag.java
! test/tools/doclint/html/ListTagsTest.java
! test/tools/doclint/html/OtherTagsTest.java
! test/tools/doclint/html/OtherTagsTest.out
! test/tools/doclint/html/TableTagsTest.java
Changeset: 60f156c653d3
Author: jjg
Date: 2013-08-26 11:48 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/60f156c653d3
8023701: Fix badly named test
Reviewed-by: bpatel
- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
+ test/com/sun/javadoc/testNavigation/TestNavigation.java
+ test/com/sun/javadoc/testNavigation/pkg/A.java
+ test/com/sun/javadoc/testNavigation/pkg/C.java
+ test/com/sun/javadoc/testNavigation/pkg/E.java
+ test/com/sun/javadoc/testNavigation/pkg/I.java
Changeset: 7bf6313e1ced
Author: jjg
Date: 2013-08-26 15:55 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7bf6313e1ced
8023768: Use the unannotatedType in cyclicity checks.
Reviewed-by: jjg
Contributed-by: wdietl at gmail.com
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java
Changeset: 00ca54ceca1b
Author: lana
Date: 2013-08-26 14:54 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/00ca54ceca1b
Merge
Changeset: cc3fb73f5e08
Author: lana
Date: 2013-08-26 22:18 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/cc3fb73f5e08
Merge
Changeset: 7fb27bc201cc
Author: bpatel
Date: 2013-08-27 11:41 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7fb27bc201cc
7052170: javadoc -charset option generates wrong meta tag
Reviewed-by: jjg
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
+ test/com/sun/javadoc/testCharset/TestCharset.java
+ test/com/sun/javadoc/testCharset/pkg/Foo.java
Changeset: 662a5188bded
Author: darcy
Date: 2013-08-27 11:58 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/662a5188bded
8023826: Typo in warning about obsolete source / target values
Reviewed-by: jjg, wmdietl
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
Changeset: 7de7100c30ce
Author: henryjen
Date: 2013-08-28 10:17 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7de7100c30ce
8014566: Remove @ignore tags from MethodReference66 and InInterface when 8013875 is fixed
Reviewed-by: briangoetz, jjg
! test/tools/javac/lambda/MethodReference66.java
! test/tools/javac/lambda/lambdaExecution/InInterface.java
Changeset: 189942cdf585
Author: jjg
Date: 2013-08-28 15:40 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/189942cdf585
8010310: [javadoc] Error processing sources with -private
Reviewed-by: vromero, mcimadamore
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
+ test/tools/javadoc/nonConstExprs/Test.java
Changeset: 0e6577980181
Author: jjg
Date: 2013-08-29 11:41 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0e6577980181
8001669: javadoc internal DocletAbortException should set cause when appropriate
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
Changeset: b0b25c1f6cbd
Author: jjg
Date: 2013-08-29 11:57 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b0b25c1f6cbd
8023522: tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA newline fail on windows only
Reviewed-by: darcy
! test/tools/javac/tree/TypeAnnotationsPretty.java
Changeset: 9c0e192c0926
Author: jjg
Date: 2013-08-29 12:03 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9c0e192c0926
8013384: Potential infinite loop in javadoc
Reviewed-by: darcy
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
Changeset: 96b6865eda94
Author: jjg
Date: 2013-08-29 12:11 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/96b6865eda94
8022744: javac -Xpkginfo command's documentation is sparse
Reviewed-by: darcy
! src/share/classes/com/sun/tools/javac/main/Option.java
Changeset: fcd768844b99
Author: lana
Date: 2013-08-29 16:34 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/fcd768844b99
Merge
- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
- test/tools/javac/8015701/AnonymousParameters.java
From paul.sandoz at oracle.com Wed Sep 4 00:54:04 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Wed, 04 Sep 2013 07:54:04 +0000
Subject: hg: jdk8/tl/jdk: 8023463: Improvements to HashMap/LinkedHashMap use
of bins/buckets and trees (red/black); ...
Message-ID: <20130904075421.EE3746252F@hg.openjdk.java.net>
Changeset: d62c911aebbb
Author: psandoz
Date: 2013-09-04 09:34 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d62c911aebbb
8023463: Improvements to HashMap/LinkedHashMap use of bins/buckets and trees (red/black)
8012913: LinkedHashMap key/value/entry spliterators should report ORDERED
Reviewed-by: mduigou, forax, bchristi, alanb
Contributed-by: Doug Lea , Paul Sandoz
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/LinkedHashMap.java
! test/java/lang/reflect/Generics/Probe.java
! test/java/util/Map/CheckRandomHashSeed.java
! test/java/util/Map/InPlaceOpsCollisions.java
+ test/java/util/Map/MapBinToFromTreeTest.java
- test/java/util/Map/TreeBinSplitBackToEntries.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
From david.holmes at oracle.com Wed Sep 4 01:29:05 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 04 Sep 2013 18:29:05 +1000
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5226D9B8.1040402@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
<5226D9B8.1040402@oracle.com>
Message-ID: <5226EF51.8010402@oracle.com>
On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote:
> On 09/04/2013 04:24 AM, Mandy Chung wrote:
>> Hi Jaroslav,
>>
>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent
>> utility seem a good replacement with the ThreadExecutionSynchronizer
>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
>> added to the platform (both java.util.concurrent and
>> java.lang.management were added in JDK 5). Later
>> ThreadExecutionSynchronizer was added to fix some intermittent issue.
>>
>> I think it's worth the investigation to replace the existing logic with
>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
>> by a few other tests).
>
>
> Ok, let's go back to the basics :)
>
> The reason for the test to fail intermittently are stale reads from the
> "waiting" variable. In order to minimize the changes it seems sufficient
> to make the "waiting" variable volatile to prevent the stale reads. The
> code modifying the "waiting" variable is already guarded by the
> semaphore so we are good there.
Yes that seems valid.
> The changes in Locks.java are about more consistent approach to waiting
> for a thread to enter a desired state. I took Erik's recommendation to
> just wait indefinitely for the desired thread state and let the harness
> deal with timeouts.
Yes that seems good too.
> The very simplified patch is at
> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
One thing you "fixed" in the original version but is no longer "fixed"
is findOwnerInfo where you made the break exit both loops. I'm unclear
if that is a correctness issue or just an optimization? I suspect an
optimization and that once you have found what you need,
lock.equals(blockedLock) will not be true for any other ThreadInfo objects.
Thanks,
David
> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
> simplify java.lang.management tests using it.
>
> -JB-
>
>>
>> Mandy
>>
>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
>>> Please, review the following patch of the intermittently failing test:
>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>>
>>>
>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>>> desired synchronization (due to possible data races when evaluating and
>>> setting the "waiting" variable) leading to test failures.
>>>
>>> The patch fixes the possibility of data race. Also the Locks class is
>>> tidied up a bit.
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>
From jaroslav.bachorik at oracle.com Wed Sep 4 01:33:13 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 04 Sep 2013 10:33:13 +0200
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5226EF51.8010402@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
<5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com>
Message-ID: <5226F049.9090108@oracle.com>
On 09/04/2013 10:29 AM, David Holmes wrote:
> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote:
>> On 09/04/2013 04:24 AM, Mandy Chung wrote:
>>> Hi Jaroslav,
>>>
>>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent
>>> utility seem a good replacement with the ThreadExecutionSynchronizer
>>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
>>> added to the platform (both java.util.concurrent and
>>> java.lang.management were added in JDK 5). Later
>>> ThreadExecutionSynchronizer was added to fix some intermittent issue.
>>>
>>> I think it's worth the investigation to replace the existing logic with
>>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
>>> by a few other tests).
>>
>>
>> Ok, let's go back to the basics :)
>>
>> The reason for the test to fail intermittently are stale reads from the
>> "waiting" variable. In order to minimize the changes it seems sufficient
>> to make the "waiting" variable volatile to prevent the stale reads. The
>> code modifying the "waiting" variable is already guarded by the
>> semaphore so we are good there.
>
> Yes that seems valid.
>
>> The changes in Locks.java are about more consistent approach to waiting
>> for a thread to enter a desired state. I took Erik's recommendation to
>> just wait indefinitely for the desired thread state and let the harness
>> deal with timeouts.
>
> Yes that seems good too.
>
>> The very simplified patch is at
>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
>
> One thing you "fixed" in the original version but is no longer "fixed"
> is findOwnerInfo where you made the break exit both loops. I'm unclear
> if that is a correctness issue or just an optimization? I suspect an
> optimization and that once you have found what you need,
> lock.equals(blockedLock) will not be true for any other ThreadInfo objects.
Exactly. It was an optimization and I excluded the change to keep the
fix very simple - given that the whole test would very likely be
rewritten for JDK9.
-JB-
>
> Thanks,
> David
>
>> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
>> simplify java.lang.management tests using it.
>>
>> -JB-
>>
>>>
>>> Mandy
>>>
>>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
>>>> Please, review the following patch of the intermittently failing test:
>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>>>
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>>>
>>>>
>>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>>>> desired synchronization (due to possible data races when evaluating and
>>>> setting the "waiting" variable) leading to test failures.
>>>>
>>>> The patch fixes the possibility of data race. Also the Locks class is
>>>> tidied up a bit.
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>
>>
From alan.bateman at oracle.com Wed Sep 4 03:43:16 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 04 Sep 2013 10:43:16 +0000
Subject: hg: jdk8/tl/jdk: 8008981: Deprecate SecurityManager
checkTopLevelWindow, checkSystemClipboardAccess,
checkAwtEventQueueAccess
Message-ID: <20130904104408.A440B62545@hg.openjdk.java.net>
Changeset: 336784cd60c3
Author: alanb
Date: 2013-09-04 11:40 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336784cd60c3
8008981: Deprecate SecurityManager checkTopLevelWindow, checkSystemClipboardAccess, checkAwtEventQueueAccess
Reviewed-by: anthony, art, mchung
! src/macosx/classes/sun/lwawt/LWToolkit.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/Toolkit.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/event/InputEvent.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/sun/applet/AppletSecurity.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java
! src/share/classes/sun/swing/SwingUtilities2.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/windows/classes/sun/awt/windows/WToolkit.java
+ test/java/awt/security/Permissions.java
From vicente.romero at oracle.com Wed Sep 4 03:54:15 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Wed, 04 Sep 2013 10:54:15 +0000
Subject: hg: jdk8/tl/langtools: 8008275: javac.Main should be @Supported
Message-ID: <20130904105427.AFBD862546@hg.openjdk.java.net>
Changeset: b94824ddcbb6
Author: vromero
Date: 2013-09-04 11:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b94824ddcbb6
8008275: javac.Main should be @Supported
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/Main.java
From daniel.fuchs at oracle.com Wed Sep 4 06:34:23 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Wed, 04 Sep 2013 13:34:23 +0000
Subject: hg: jdk8/tl/jdk: 6823527: java.util.logging.Handler has thread safety
issues
Message-ID: <20130904133455.3B2146254E@hg.openjdk.java.net>
Changeset: ac6e99af2056
Author: dfuchs
Date: 2013-09-04 15:32 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac6e99af2056
6823527: java.util.logging.Handler has thread safety issues
Reviewed-by: dholmes, mchung
! src/share/classes/java/util/logging/ConsoleHandler.java
! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/Handler.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/SocketHandler.java
! src/share/classes/java/util/logging/StreamHandler.java
From zhengyu.gu at oracle.com Wed Sep 4 08:18:50 2013
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Wed, 04 Sep 2013 15:18:50 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022798: "assert(seq > 0) failed: counter
overflow" in Kitchensink
Message-ID: <20130904151852.9A6A56255B@hg.openjdk.java.net>
Changeset: baa7927dfbd2
Author: zgu
Date: 2013-09-04 08:55 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/baa7927dfbd2
8022798: "assert(seq > 0) failed: counter overflow" in Kitchensink
Summary: Removed incorrect assertion, sequence number can overflow
Reviewed-by: dholmes, kamg
! src/share/vm/services/memPtr.cpp
From sundararajan.athijegannathan at oracle.com Wed Sep 4 08:45:14 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 04 Sep 2013 15:45:14 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130904154517.75E7F6255F@hg.openjdk.java.net>
Changeset: b5ff11e00050
Author: sundar
Date: 2013-09-04 14:29 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b5ff11e00050
8024120: Setting __proto__ to null removes the __proto__ property
Reviewed-by: lagergren, attila
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
! test/script/basic/JDK-8023368.js
! test/script/basic/JDK-8023368.js.EXPECTED
+ test/script/basic/JDK-8024120.js
! test/script/basic/circular_proto.js
! test/script/basic/nonextensible_proto_assign.js
Changeset: e43ab4062636
Author: sundar
Date: 2013-09-04 19:58 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e43ab4062636
8024174: Setting __proto__ property in Object literal should be supported
Reviewed-by: jlaskey, lagergren
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
+ test/script/basic/JDK-8024174.js
From daniel.fuchs at oracle.com Wed Sep 4 07:54:52 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Wed, 04 Sep 2013 14:54:52 +0000
Subject: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency
Message-ID: <20130904145522.D672D62558@hg.openjdk.java.net>
Changeset: b3d6953b9829
Author: dfuchs
Date: 2013-09-04 16:22 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829
8019853: Break logging and AWT circular dependency
Summary: Break logging and AWT circular dependency, which was at the root cause for 8023258 - Logger.getLogger() after ImageIO.read() returns different logger instance
Reviewed-by: mchung, art
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/sun/awt/AppContext.java
! src/share/classes/sun/misc/JavaAWTAccess.java
! src/share/classes/sun/misc/SharedSecrets.java
! test/java/util/logging/TestAppletLoggerContext.java
+ test/java/util/logging/TestLoggingWithMainAppContext.java
From john.r.rose at oracle.com Wed Sep 4 12:01:59 2013
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 4 Sep 2013 12:01:59 -0700
Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to
handle appendix arguments
In-Reply-To: <5213C0AA.5030706@oracle.com>
References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com>
<51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com>
<51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com>
<51F7F13E.8040104@oracle.com>
<5213C0AA.5030706@oracle.com>
Message-ID:
Yes, please file this bug. I'm working on MH-related optimizations, and I am finding that preserving the required code pattern is blocking some optimizations, notably making customized variations of direct MHs.
(The required code pattern is that the DMH in Local#0 has a member field which supplies the missing argument to the outgoing linker call. Making a variant DMH with a customized calling sequence is possible, but then it has wrong interactions with the MethodHandleInfo API. It would be easier to make a customized non-DMH, with no member field.)
? John
On Aug 20, 2013, at 12:16 PM, serguei.spitsyn at oracle.com wrote:
> John,
>
> Thank you for the comments!
> In fact, I was very reluctant to implement it the way as it is in the webrev.
> I'm in favor of the choice #3, and think, it is much better from the stability point of view.
> Restoring the MemberName slot at deoptimization is not going to cause a performance degradation.
>
> If you and Christian are Ok with it I can file a new compiler bug to cover this issue.
>
> Thanks,
> Serguei
>
>
> On 8/12/13 3:30 PM, John Rose wrote:
>> This fix will be delicate and may have regressions if the exact code shape (of the PopFrame-ed invokestatic call) changes.
>>
>> Note that member_name_arg_or_null assumes that the value in Local#0 is a DMH; there will be asserts thrown if this fails. It also assumes that the member name held by the DMH in fact corresponds to the linker call (linkToStatic, linkToVirtual, etc.) being PopFrame-ed.
>>
>> In fact, the linker call might in some cases be run from another source than "aload0; getfield member". Requiring that this correspondence exist always is a new internal interface that is hard to document and verify; it may also inhibit present or future optimizations.
>>
>> There are other approaches that might be more robust:
>> 1. Do not allow PopFrame to linker calls, since they (by definition) throw away their trailing MemberName argument.
>> 2. Do not make such frames visible to the user.
>> 3. Modify the linker primitives to store a copy of their trailing MemberName argument to a new slot in the interpreter frame and compiled frame. Be sure to populate this new slot on deoptimization.
>>
>> ? John
>>
>> P.S. Sorry about the delay in commenting; I am just digging out from under JVMLS business!
>>
>> On Jul 30, 2013, at 10:00 AM, serguei.spitsyn at oracle.com wrote:
>>
>>> The updated webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 7/29/13 10:11 PM, David Holmes wrote:
>>>> Hi Serguei,
>>>>
>>>> I'm fine with restoring to what was in the first webrev.
>>>>
>>>> Further trimming of the JVMTI code is something the embedded folk could look at. It may not be worthwhile.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote:
>>>>> On 7/29/13 8:22 PM, David Holmes wrote:
>>>>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Christian and David,
>>>>>>>
>>>>>>> Thank you for the quick review and comments!
>>>>>>>
>>>>>>> This is a new version of webrev:
>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2
>>>>>>>
>>>>>> Sorry. You need that guard after all - at least you do if you continue
>>>>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null
>>>>>> will not exist:
>>>>>>
>>>>>> __ call_VM(rax, CAST_FROM_FN_PTR(address,
>>>>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi);
>>>>>>
>>>>> You are right, nice catch again.
>>>>> Probably, it was the reason, I did not remove the #if/#endif in the
>>>>> first place. :)
>>>>>
>>>>>> I'm a little surprised that the assembly code does not have that whole
>>>>>> section guarded with INCLUDE_JVMTI - perhaps it should?
>>>>> It should.
>>>>> But it can be non-trivial because of other dependencies like the above.
>>>>> To make it right, both _remove_activation_preserving_args_entry and
>>>>> generate_earlyret_entry_for
>>>>> must be isolated with #if INCLUDE_JVMTI.
>>>>> Then more files have to be involved in this chain of changes:
>>>>> interpreter/templateInterpreter.hpp
>>>>> interpreter/templateInterpreter.hpp
>>>>> memory/universe.hpp
>>>>> memory/universe.cpp
>>>>> code/codeCache.hpp
>>>>> code/codeCache.cpp
>>>>> . . . etc ..
>>>>>
>>>>> Please, note, that the HOTSWAP macro is used in many places as well.
>>>>> I'm not sure we still need it, so that another decision is needed for it.
>>>>>
>>>>> So, it seems that this kind of clean up is going far beyond my fix.
>>>>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3
>>>>> platform-dependent files as it was in the webrev v1.
>>>>> I'm a little bit reluctant to open another clean-up bug for this issue
>>>>> but maybe it is needed.
>>>>> Please, let me know if you are comfortable with this solution.
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>> Run this through a JPRT test build for productEmb to check that the
>>>>>> minimal VM builds ok.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>>
>>>>>>>
>>>>>>> On 7/28/13 9:11 PM, David Holmes wrote:
>>>>>>>> Hi Serguei,
>>>>>>>>
>>>>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Please, review the fix for:
>>>>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554
>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554
>>>>>>>>>
>>>>>>>>> Open webrev:
>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1
>>>>>>>>>
>>>>>>>>>
>>>>>>>> In the templateInterpreter code why did you put this guard on your new
>>>>>>>> code (from x86_32 version):
>>>>>>>>
>>>>>>>> 1923 #if INCLUDE_JVMTI
>>>>>>>>
>>>>>>>> when the whole chunk of code this is situated in is specifically for
>>>>>>>> JVMTI support
>>>>>>>>
>>>>>>>> 1824 //
>>>>>>>> 1825 // JVMTI PopFrame support
>>>>>>>> 1826 //
>>>>>>>>
>>>>>>>> ???
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> Summary:
>>>>>>>>> Restore the appendix argument of a polymorphic intrinsic call
>>>>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame().
>>>>>>>>>
>>>>>>>>> Description
>>>>>>>>> When JVMTI's PopFrame removes a frame that was called via a call
>>>>>>>>> site
>>>>>>>>> that
>>>>>>>>> takes an appendix and that call site is reexecuted the appendix is
>>>>>>>>> not on
>>>>>>>>> the stack anymore because it got removed by the adapter.
>>>>>>>>> This fix is to detect such a case and push the appendix on the
>>>>>>>>> stack
>>>>>>>>> again before reexecution.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist,
>>>>>>>>> nsk.jdi.testlist
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>
From xueming.shen at oracle.com Wed Sep 4 12:31:47 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 04 Sep 2013 19:31:47 +0000
Subject: hg: jdk8/tl/jdk: 6341345: (spec) Console.reader() should make it
clear that the reader requires line termination
Message-ID: <20130904193159.060FA6256A@hg.openjdk.java.net>
Changeset: 478afc30679b
Author: sherman
Date: 2013-09-04 12:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/478afc30679b
6341345: (spec) Console.reader() should make it clear that the reader requires line termination
Summary: to clarify the spec
Reviewed-by: alanb
! src/share/classes/java/io/Console.java
From xueming.shen at oracle.com Wed Sep 4 12:33:50 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 04 Sep 2013 19:33:50 +0000
Subject: hg: jdk8/tl/jdk: 7186632: NLS t13y issue on jar.properties file
Message-ID: <20130904193402.691896256B@hg.openjdk.java.net>
Changeset: c6a4df06d57e
Author: sherman
Date: 2013-09-04 12:37 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6a4df06d57e
7186632: NLS t13y issue on jar.properties file
Summary: to remove the redundant backslash
Reviewed-by: naoto
! src/share/classes/sun/tools/jar/resources/jar.properties
From dmitry.samersoff at oracle.com Wed Sep 4 13:35:20 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 05 Sep 2013 00:35:20 +0400
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation for
invokedynamic
Message-ID: <52279988.6070809@oracle.com>
Please, review the changes.
http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/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 jonathan.gibbons at oracle.com Wed Sep 4 14:45:25 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 04 Sep 2013 21:45:25 +0000
Subject: hg: jdk8/tl/langtools: 8024288: javadoc generated-by comment should
always be present
Message-ID: <20130904214528.81C7F6257C@hg.openjdk.java.net>
Changeset: 044721d4d359
Author: jjg
Date: 2013-09-04 14:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/044721d4d359
8024288: javadoc generated-by comment should always be present
Reviewed-by: bpatel
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java
From christian.thalinger at oracle.com Wed Sep 4 15:30:14 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 4 Sep 2013 15:30:14 -0700
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation for
invokedynamic
In-Reply-To: <52279988.6070809@oracle.com>
References: <52279988.6070809@oracle.com>
Message-ID: <48AEBE20-A4D6-43A5-8BA4-572B94C949D0@oracle.com>
On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff wrote:
> Please, review the changes.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/webrev.01/
With this change you can dump the boot class path classes again?
-- Chris
>
> -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 robert.field at oracle.com Wed Sep 4 19:48:00 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 05 Sep 2013 02:48:00 +0000
Subject: hg: jdk8/tl/jdk: 8020816: Metafactory crashes on code with method
reference; ...
Message-ID: <20130905024824.0967D62583@hg.openjdk.java.net>
Changeset: bd6fcc5eebb8
Author: rfield
Date: 2013-09-04 19:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6fcc5eebb8
8020816: Metafactory crashes on code with method reference
8021050: MethodHandleInfo throws exception when method handle is to a method with @CallerSensitive
Summary: Fixed by 8008688 - this is a test to confirm the above fixed
Reviewed-by: vlivanov
+ test/jdk/lambda/MethodReferenceTestCallerSensitive.java
From dmitry.samersoff at oracle.com Thu Sep 5 00:31:47 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 05 Sep 2013 11:31:47 +0400
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation
for invokedynamic
In-Reply-To: <48AEBE20-A4D6-43A5-8BA4-572B94C949D0@oracle.com>
References: <52279988.6070809@oracle.com>
<48AEBE20-A4D6-43A5-8BA4-572B94C949D0@oracle.com>
Message-ID: <52283363.8030504@oracle.com>
On 2013-09-05 02:30, Christian Thalinger wrote:
>
> On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff wrote:
>
>> Please, review the changes.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/webrev.01/
>
> With this change you can dump the boot class path classes again?
>
Yes. Also I manually checked generated classes with javap.
But I'll much appreciate you if you can apply the patch and confirm that
output is OK from compiler team point of view.
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
From shanliang.jiang at oracle.com Thu Sep 5 01:37:46 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Thu, 05 Sep 2013 10:37:46 +0200
Subject: Codereview request: 8023529 OpenMBeanInfoSupport.equals/hashCode
throw NPE
Message-ID: <522842DA.6010908@oracle.com>
I have added 2 tasts to make sure that call
OpenMBean*InfoSupport.equals/hashCode do not throw NPE
The unit tests and JCK tests are passed.
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8023529
Thanks,
Shanliang
From joel.franck at oracle.com Thu Sep 5 02:37:19 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Thu, 05 Sep 2013 09:37:19 +0000
Subject: hg: jdk8/tl/langtools: 8023974: Drop 'implements Completer' and
'implements SourceCompleter' from ClassReader resp. JavaCompiler.
Message-ID: <20130905093732.0493E62590@hg.openjdk.java.net>
Changeset: a76c663a9cac
Author: jfranck
Date: 2013-09-05 11:27 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76c663a9cac
8023974: Drop 'implements Completer' and 'implements SourceCompleter' from ClassReader resp. JavaCompiler.
Reviewed-by: jjg, jfranck
Contributed-by: Andreas Lundblad
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
From jaroslav.bachorik at oracle.com Thu Sep 5 04:15:55 2013
From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com)
Date: Thu, 05 Sep 2013 11:15:55 +0000
Subject: hg: jdk8/tl/jdk: 8023464:
test/closed/sun/tracing/ProviderProxyTest.java failing
Message-ID: <20130905111656.CB3466259A@hg.openjdk.java.net>
Changeset: af1b08ff48ae
Author: jbachorik
Date: 2013-09-05 13:04 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af1b08ff48ae
8023464: test/closed/sun/tracing/ProviderProxyTest.java failing
Summary: Don't rely on assertions when an Exception suits better
Reviewed-by: alanb, dfuchs, sjiang
! src/share/classes/sun/tracing/ProviderSkeleton.java
From jaroslav.bachorik at oracle.com Thu Sep 5 05:35:01 2013
From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com)
Date: Thu, 05 Sep 2013 12:35:01 +0000
Subject: hg: jdk8/tl/jdk: 8004179: Few of
test/java/lang/management/ThreadMXBean/* tests don't clean up
the created threads
Message-ID: <20130905123532.492126259C@hg.openjdk.java.net>
Changeset: 9522b5e836d3
Author: jbachorik
Date: 2013-09-05 14:34 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9522b5e836d3
8004179: Few of test/java/lang/management/ThreadMXBean/* tests don't clean up the created threads
Summary: Just run those tests in "othervm" mode.
Reviewed-by: alanb, dfuchs, sjiang
! test/java/lang/management/ThreadMXBean/LockedMonitors.java
! test/java/lang/management/ThreadMXBean/LockedSynchronizers.java
! test/java/lang/management/ThreadMXBean/MyOwnSynchronizer.java
! test/java/lang/management/ThreadMXBean/SharedSynchronizer.java
! test/java/lang/management/ThreadMXBean/SynchronizationStatistics.java
From jaroslav.bachorik at oracle.com Thu Sep 5 05:52:12 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 05 Sep 2013 14:52:12 +0200
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5226F049.9090108@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
<5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com>
<5226F049.9090108@oracle.com>
Message-ID: <52287E7C.3050107@oracle.com>
On 09/04/2013 10:33 AM, Jaroslav Bachorik wrote:
> On 09/04/2013 10:29 AM, David Holmes wrote:
>> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote:
>>> On 09/04/2013 04:24 AM, Mandy Chung wrote:
>>>> Hi Jaroslav,
>>>>
>>>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent
>>>> utility seem a good replacement with the ThreadExecutionSynchronizer
>>>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
>>>> added to the platform (both java.util.concurrent and
>>>> java.lang.management were added in JDK 5). Later
>>>> ThreadExecutionSynchronizer was added to fix some intermittent issue.
>>>>
>>>> I think it's worth the investigation to replace the existing logic with
>>>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
>>>> by a few other tests).
>>>
>>>
>>> Ok, let's go back to the basics :)
>>>
>>> The reason for the test to fail intermittently are stale reads from the
>>> "waiting" variable. In order to minimize the changes it seems sufficient
>>> to make the "waiting" variable volatile to prevent the stale reads. The
>>> code modifying the "waiting" variable is already guarded by the
>>> semaphore so we are good there.
>>
>> Yes that seems valid.
>>
>>> The changes in Locks.java are about more consistent approach to waiting
>>> for a thread to enter a desired state. I took Erik's recommendation to
>>> just wait indefinitely for the desired thread state and let the harness
>>> deal with timeouts.
>>
>> Yes that seems good too.
>>
>>> The very simplified patch is at
>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
>>
>> One thing you "fixed" in the original version but is no longer "fixed"
>> is findOwnerInfo where you made the break exit both loops. I'm unclear
>> if that is a correctness issue or just an optimization? I suspect an
>> optimization and that once you have found what you need,
>> lock.equals(blockedLock) will not be true for any other ThreadInfo objects.
>
> Exactly. It was an optimization and I excluded the change to keep the
> fix very simple - given that the whole test would very likely be
> rewritten for JDK9.
Task for removal of
java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer filed -
JDK-8024326
So, is this change good to go?
Thanks,
-JB-
>
> -JB-
>
>>
>> Thanks,
>> David
>>
>>> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
>>> simplify java.lang.management tests using it.
>>>
>>> -JB-
>>>
>>>>
>>>> Mandy
>>>>
>>>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
>>>>> Please, review the following patch of the intermittently failing test:
>>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>>>>
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>>>>
>>>>>
>>>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>>>>> desired synchronization (due to possible data races when evaluating and
>>>>> setting the "waiting" variable) leading to test failures.
>>>>>
>>>>> The patch fixes the possibility of data race. Also the Locks class is
>>>>> tidied up a bit.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -JB-
>>>>
>>>
>
From daniel.fuchs at oracle.com Thu Sep 5 05:59:50 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 05 Sep 2013 14:59:50 +0200
Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <52287E7C.3050107@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
<5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com>
<5226F049.9090108@oracle.com> <52287E7C.3050107@oracle.com>
Message-ID: <52288046.9020100@oracle.com>
On 9/5/13 2:52 PM, Jaroslav Bachorik wrote:
> On 09/04/2013 10:33 AM, Jaroslav Bachorik wrote:
>> On 09/04/2013 10:29 AM, David Holmes wrote:
>>> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote:
>>>> On 09/04/2013 04:24 AM, Mandy Chung wrote:
>>>>> Hi Jaroslav,
>>>>>
>>>>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent
>>>>> utility seem a good replacement with the ThreadExecutionSynchronizer
>>>>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
>>>>> added to the platform (both java.util.concurrent and
>>>>> java.lang.management were added in JDK 5). Later
>>>>> ThreadExecutionSynchronizer was added to fix some intermittent issue.
>>>>>
>>>>> I think it's worth the investigation to replace the existing logic with
>>>>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
>>>>> by a few other tests).
>>>>
>>>>
>>>> Ok, let's go back to the basics :)
>>>>
>>>> The reason for the test to fail intermittently are stale reads from the
>>>> "waiting" variable. In order to minimize the changes it seems sufficient
>>>> to make the "waiting" variable volatile to prevent the stale reads. The
>>>> code modifying the "waiting" variable is already guarded by the
>>>> semaphore so we are good there.
>>>
>>> Yes that seems valid.
>>>
>>>> The changes in Locks.java are about more consistent approach to waiting
>>>> for a thread to enter a desired state. I took Erik's recommendation to
>>>> just wait indefinitely for the desired thread state and let the harness
>>>> deal with timeouts.
>>>
>>> Yes that seems good too.
>>>
>>>> The very simplified patch is at
>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
>>>
>>> One thing you "fixed" in the original version but is no longer "fixed"
>>> is findOwnerInfo where you made the break exit both loops. I'm unclear
>>> if that is a correctness issue or just an optimization? I suspect an
>>> optimization and that once you have found what you need,
>>> lock.equals(blockedLock) will not be true for any other ThreadInfo objects.
>>
>> Exactly. It was an optimization and I excluded the change to keep the
>> fix very simple - given that the whole test would very likely be
>> rewritten for JDK9.
>
> Task for removal of
> java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer filed -
> JDK-8024326
>
> So, is this change good to go?
In what I'm concerned yes - but I'm not a reviewer...
cheers,
-- daniel
>
> Thanks,
>
> -JB-
>
>>
>> -JB-
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
>>>> simplify java.lang.management tests using it.
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>> Mandy
>>>>>
>>>>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
>>>>>> Please, review the following patch of the intermittently failing test:
>>>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>>>>>
>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>>>>>
>>>>>>
>>>>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>>>>>> desired synchronization (due to possible data races when evaluating and
>>>>>> setting the "waiting" variable) leading to test failures.
>>>>>>
>>>>>> The patch fixes the possibility of data race. Also the Locks class is
>>>>>> tidied up a bit.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -JB-
>>>>>
>>>>
>>
>
From kevin.walls at oracle.com Thu Sep 5 06:12:07 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 05 Sep 2013 14:12:07 +0100
Subject: RR(XXS) 8023478: Test fails with HS crash in GCNotifier.
Message-ID: <52288327.5080809@oracle.com>
Hi,
If I have my CHECK and THREAD thinking straight, I have a small review
request in gcNotifier, to avoid a crash that came up in testing recently.
The report is a hotspot crash in a test, where there's an exception
pending when calling java_lang_String::create_from_str, which allocates.
We are in GCNotifier::sendNotificationInternal and before the call that
crashes, we called createGcInfo which have several allocations can
return a null handle if an exception occurs.
If we have returned from createGcInfo, which returns null for an exception,
we need to return rather than continue in sendNotificationInternal,
which will try to allocate again.
sendNotificationInternal has a caller that clears any exception.
So that should be a very small change:
$ hg diff src/share/vm/services/gcNotifier.cpp
diff --git a/src/share/vm/services/gcNotifier.cpp
b/src/share/vm/services/gcNotifier.cpp
--- a/src/share/vm/services/gcNotifier.cpp
+++ b/src/share/vm/services/gcNotifier.cpp
@@ -209,7 +209,7 @@
GCNotificationRequest *request = getRequest();
if (request != NULL) {
NotificationMark nm(request);
- Handle objGcInfo = createGcInfo(request->gcManager,
request->gcStatInfo, THREAD);
+ Handle objGcInfo = createGcInfo(request->gcManager,
request->gcStatInfo, CHECK);
Handle objName =
java_lang_String::create_from_str(request->gcManager->name(), CHECK);
Handle objAction =
java_lang_String::create_from_str(request->gcAction, CHECK);
kwalls at klaptop:~/work/bugs/8023478.gcbean/hotspot-rt$
http://bugs.sun.com/view_bug.do?bug_id=8023478
http://cr.openjdk.java.net/~kevinw/8023478/webrev.00/ (the above one line)
Thanks
Kevin
--------
PS
As the bug is not available on the bugs site at the moment, this is part
of the crashing stack to give some context:
V [libjvm.so+0x7069d0] void report_vm_error(const char*,int,const
char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78
V [libjvm.so+0x63125c] void
CollectedHeap::check_for_valid_allocation_state()+0x4c;;
__1cNCollectedHeapbGcheck_for_valid_allocation_state6F_v_+0x4c
V [libjvm.so+0x911f68] instanceOop
InstanceKlass::allocate_instance(Thread*)+0x78;;
__1cNInstanceKlassRallocate_instance6MpnGThread__nLinstanceOop__+0x78
V [libjvm.so+0x9ffd7c] Handle
java_lang_String::basic_create(int,Thread*)+0x174;;
__1cQjava_lang_StringMbasic_create6FipnGThread__nGHandle__+0x174
V [libjvm.so+0xa00520] Handle java_lang_String::create_from_str(const
char*,Thread*)+0x40;;
__1cQjava_lang_StringPcreate_from_str6FpkcpnGThread__nGHandle__+0x40
V [libjvm.so+0x83eb0c] void
GCNotifier::sendNotificationInternal(Thread*)+0x8c;;
__1cKGCNotifierYsendNotificationInternal6FpnGThread__v_+0x8c
V [libjvm.so+0x83ea4c] void GCNotifier::sendNotification(Thread*)+0xc;;
__1cKGCNotifierQsendNotification6FpnGThread__v_+0xc
V [libjvm.so+0x103faf8] void
ServiceThread::service_thread_entry(JavaThread*,Thread*)+0x4a0;;
__1cNServiceThreadUservice_thread_entry6FpnKJavaThread_pnGThread__v_+0x4a0
From staffan.larsen at oracle.com Thu Sep 5 06:35:52 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 5 Sep 2013 15:35:52 +0200
Subject: RR(XXS) 8023478: Test fails with HS crash in GCNotifier.
In-Reply-To: <52288327.5080809@oracle.com>
References: <52288327.5080809@oracle.com>
Message-ID:
I agree that your change looks good, but there are a couple of things that bug me.
Why did createGcInfo() fail? Hard to tell if you can't repro the failure, though.
The code below will make sure we swallow any exceptions that occurred without reporting them. This isn't good practice. I would like these exceptions to be logged somehow. This isn't your code or part of your change, it just makes me worried.
void GCNotifier::sendNotification(TRAPS) {
GCNotifier::sendNotificationInternal(THREAD);
// Clearing pending exception to avoid premature termination of
// the service thread
if (HAS_PENDING_EXCEPTION) {
CLEAR_PENDING_EXCEPTION;
}
}
/Staffan
On 5 sep 2013, at 15:12, Kevin Walls wrote:
> Hi,
>
> If I have my CHECK and THREAD thinking straight, I have a small review request in gcNotifier, to avoid a crash that came up in testing recently.
>
> The report is a hotspot crash in a test, where there's an exception pending when calling java_lang_String::create_from_str, which allocates.
>
> We are in GCNotifier::sendNotificationInternal and before the call that crashes, we called createGcInfo which have several allocations can return a null handle if an exception occurs.
>
> If we have returned from createGcInfo, which returns null for an exception,
> we need to return rather than continue in sendNotificationInternal, which will try to allocate again.
>
> sendNotificationInternal has a caller that clears any exception.
>
> So that should be a very small change:
>
> $ hg diff src/share/vm/services/gcNotifier.cpp
> diff --git a/src/share/vm/services/gcNotifier.cpp b/src/share/vm/services/gcNotifier.cpp
> --- a/src/share/vm/services/gcNotifier.cpp
> +++ b/src/share/vm/services/gcNotifier.cpp
> @@ -209,7 +209,7 @@
> GCNotificationRequest *request = getRequest();
> if (request != NULL) {
> NotificationMark nm(request);
> - Handle objGcInfo = createGcInfo(request->gcManager, request->gcStatInfo, THREAD);
> + Handle objGcInfo = createGcInfo(request->gcManager, request->gcStatInfo, CHECK);
>
> Handle objName = java_lang_String::create_from_str(request->gcManager->name(), CHECK);
> Handle objAction = java_lang_String::create_from_str(request->gcAction, CHECK);
> kwalls at klaptop:~/work/bugs/8023478.gcbean/hotspot-rt$
>
>
>
> http://bugs.sun.com/view_bug.do?bug_id=8023478
> http://cr.openjdk.java.net/~kevinw/8023478/webrev.00/ (the above one line)
>
>
> Thanks
> Kevin
> --------
> PS
> As the bug is not available on the bugs site at the moment, this is part of the crashing stack to give some context:
>
> V [libjvm.so+0x7069d0] void report_vm_error(const char*,int,const char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78
> V [libjvm.so+0x63125c] void CollectedHeap::check_for_valid_allocation_state()+0x4c;; __1cNCollectedHeapbGcheck_for_valid_allocation_state6F_v_+0x4c
> V [libjvm.so+0x911f68] instanceOop InstanceKlass::allocate_instance(Thread*)+0x78;; __1cNInstanceKlassRallocate_instance6MpnGThread__nLinstanceOop__+0x78
> V [libjvm.so+0x9ffd7c] Handle java_lang_String::basic_create(int,Thread*)+0x174;; __1cQjava_lang_StringMbasic_create6FipnGThread__nGHandle__+0x174
> V [libjvm.so+0xa00520] Handle java_lang_String::create_from_str(const char*,Thread*)+0x40;; __1cQjava_lang_StringPcreate_from_str6FpkcpnGThread__nGHandle__+0x40
> V [libjvm.so+0x83eb0c] void GCNotifier::sendNotificationInternal(Thread*)+0x8c;; __1cKGCNotifierYsendNotificationInternal6FpnGThread__v_+0x8c
> V [libjvm.so+0x83ea4c] void GCNotifier::sendNotification(Thread*)+0xc;; __1cKGCNotifierQsendNotification6FpnGThread__v_+0xc
> V [libjvm.so+0x103faf8] void ServiceThread::service_thread_entry(JavaThread*,Thread*)+0x4a0;; __1cNServiceThreadUservice_thread_entry6FpnKJavaThread_pnGThread__v_+0x4a0
>
>
From kevin.walls at oracle.com Thu Sep 5 07:17:38 2013
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 05 Sep 2013 15:17:38 +0100
Subject: RR(XXS) 8023478: Test fails with HS crash in GCNotifier.
In-Reply-To:
References: <52288327.5080809@oracle.com>
Message-ID: <52289282.10005@oracle.com>
Hi Staffan --
Yes, I made some attempts but didn't reproduce it, though anything that
allocates can presumably cause an exception if the timing and memory
usage is right (or wrong).
On the clearing of exceptions... All about not crashing the Service
Thread I suppose, but it may not have been obivous where if anywhere any
exceptions should be logged: should the running app's output be
interrupted with exceptions because somebody attached jconsole to
monitor it?... (that's one way of getting these GC notifications turned on).
I'm thinking the call to createGcInfo was just an oversight, the calls
such as for String creation are done with CHECK, and yes any failures
there would get caught and cleared by the caller, sendNotification, as
you mention.
Thanks
Kevin
On 05/09/13 14:35, Staffan Larsen wrote:
> I agree that your change looks good, but there are a couple of things that bug me.
>
> Why did createGcInfo() fail? Hard to tell if you can't repro the failure, though.
>
> The code below will make sure we swallow any exceptions that occurred without reporting them. This isn't good practice. I would like these exceptions to be logged somehow. This isn't your code or part of your change, it just makes me worried.
>
> void GCNotifier::sendNotification(TRAPS) {
> GCNotifier::sendNotificationInternal(THREAD);
> // Clearing pending exception to avoid premature termination of
> // the service thread
> if (HAS_PENDING_EXCEPTION) {
> CLEAR_PENDING_EXCEPTION;
> }
> }
>
>
> /Staffan
>
> On 5 sep 2013, at 15:12, Kevin Walls wrote:
>
>> Hi,
>>
>> If I have my CHECK and THREAD thinking straight, I have a small review request in gcNotifier, to avoid a crash that came up in testing recently.
>>
>> The report is a hotspot crash in a test, where there's an exception pending when calling java_lang_String::create_from_str, which allocates.
>>
>> We are in GCNotifier::sendNotificationInternal and before the call that crashes, we called createGcInfo which have several allocations can return a null handle if an exception occurs.
>>
>> If we have returned from createGcInfo, which returns null for an exception,
>> we need to return rather than continue in sendNotificationInternal, which will try to allocate again.
>>
>> sendNotificationInternal has a caller that clears any exception.
>>
>> So that should be a very small change:
>>
>> $ hg diff src/share/vm/services/gcNotifier.cpp
>> diff --git a/src/share/vm/services/gcNotifier.cpp b/src/share/vm/services/gcNotifier.cpp
>> --- a/src/share/vm/services/gcNotifier.cpp
>> +++ b/src/share/vm/services/gcNotifier.cpp
>> @@ -209,7 +209,7 @@
>> GCNotificationRequest *request = getRequest();
>> if (request != NULL) {
>> NotificationMark nm(request);
>> - Handle objGcInfo = createGcInfo(request->gcManager, request->gcStatInfo, THREAD);
>> + Handle objGcInfo = createGcInfo(request->gcManager, request->gcStatInfo, CHECK);
>>
>> Handle objName = java_lang_String::create_from_str(request->gcManager->name(), CHECK);
>> Handle objAction = java_lang_String::create_from_str(request->gcAction, CHECK);
>> kwalls at klaptop:~/work/bugs/8023478.gcbean/hotspot-rt$
>>
>>
>>
>> http://bugs.sun.com/view_bug.do?bug_id=8023478
>> http://cr.openjdk.java.net/~kevinw/8023478/webrev.00/ (the above one line)
>>
>>
>> Thanks
>> Kevin
>> --------
>> PS
>> As the bug is not available on the bugs site at the moment, this is part of the crashing stack to give some context:
>>
>> V [libjvm.so+0x7069d0] void report_vm_error(const char*,int,const char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78
>> V [libjvm.so+0x63125c] void CollectedHeap::check_for_valid_allocation_state()+0x4c;; __1cNCollectedHeapbGcheck_for_valid_allocation_state6F_v_+0x4c
>> V [libjvm.so+0x911f68] instanceOop InstanceKlass::allocate_instance(Thread*)+0x78;; __1cNInstanceKlassRallocate_instance6MpnGThread__nLinstanceOop__+0x78
>> V [libjvm.so+0x9ffd7c] Handle java_lang_String::basic_create(int,Thread*)+0x174;; __1cQjava_lang_StringMbasic_create6FipnGThread__nGHandle__+0x174
>> V [libjvm.so+0xa00520] Handle java_lang_String::create_from_str(const char*,Thread*)+0x40;; __1cQjava_lang_StringPcreate_from_str6FpkcpnGThread__nGHandle__+0x40
>> V [libjvm.so+0x83eb0c] void GCNotifier::sendNotificationInternal(Thread*)+0x8c;; __1cKGCNotifierYsendNotificationInternal6FpnGThread__v_+0x8c
>> V [libjvm.so+0x83ea4c] void GCNotifier::sendNotification(Thread*)+0xc;; __1cKGCNotifierQsendNotification6FpnGThread__v_+0xc
>> V [libjvm.so+0x103faf8] void ServiceThread::service_thread_entry(JavaThread*,Thread*)+0x4a0;; __1cNServiceThreadUservice_thread_entry6FpnKJavaThread_pnGThread__v_+0x4a0
>>
>>
From staffan.larsen at oracle.com Thu Sep 5 07:26:38 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 5 Sep 2013 16:26:38 +0200
Subject: RR(XXS) 8023478: Test fails with HS crash in GCNotifier.
In-Reply-To: <52289282.10005@oracle.com>
References: <52288327.5080809@oracle.com>
<52289282.10005@oracle.com>
Message-ID:
Yeah, I agree that it is hard to know where to log these failures to, although I don't like them being swallowed. We should have a standardized way of logging all JVM failures, warnings, etc. (JEP 158 anyone?)
Anyway, that's unrelated to your patch, which looks good to me.
/Staffan
On 5 sep 2013, at 16:17, Kevin Walls wrote:
>
> Hi Staffan --
>
> Yes, I made some attempts but didn't reproduce it, though anything that allocates can presumably cause an exception if the timing and memory usage is right (or wrong).
>
> On the clearing of exceptions... All about not crashing the Service Thread I suppose, but it may not have been obivous where if anywhere any exceptions should be logged: should the running app's output be interrupted with exceptions because somebody attached jconsole to monitor it?... (that's one way of getting these GC notifications turned on).
>
>
> I'm thinking the call to createGcInfo was just an oversight, the calls such as for String creation are done with CHECK, and yes any failures there would get caught and cleared by the caller, sendNotification, as you mention.
>
> Thanks
> Kevin
>
>
> On 05/09/13 14:35, Staffan Larsen wrote:
>> I agree that your change looks good, but there are a couple of things that bug me.
>>
>> Why did createGcInfo() fail? Hard to tell if you can't repro the failure, though.
>>
>> The code below will make sure we swallow any exceptions that occurred without reporting them. This isn't good practice. I would like these exceptions to be logged somehow. This isn't your code or part of your change, it just makes me worried.
>>
>> void GCNotifier::sendNotification(TRAPS) {
>> GCNotifier::sendNotificationInternal(THREAD);
>> // Clearing pending exception to avoid premature termination of
>> // the service thread
>> if (HAS_PENDING_EXCEPTION) {
>> CLEAR_PENDING_EXCEPTION;
>> }
>> }
>>
>>
>> /Staffan
>>
>> On 5 sep 2013, at 15:12, Kevin Walls wrote:
>>
>>> Hi,
>>>
>>> If I have my CHECK and THREAD thinking straight, I have a small review request in gcNotifier, to avoid a crash that came up in testing recently.
>>>
>>> The report is a hotspot crash in a test, where there's an exception pending when calling java_lang_String::create_from_str, which allocates.
>>>
>>> We are in GCNotifier::sendNotificationInternal and before the call that crashes, we called createGcInfo which have several allocations can return a null handle if an exception occurs.
>>>
>>> If we have returned from createGcInfo, which returns null for an exception,
>>> we need to return rather than continue in sendNotificationInternal, which will try to allocate again.
>>>
>>> sendNotificationInternal has a caller that clears any exception.
>>>
>>> So that should be a very small change:
>>>
>>> $ hg diff src/share/vm/services/gcNotifier.cpp
>>> diff --git a/src/share/vm/services/gcNotifier.cpp b/src/share/vm/services/gcNotifier.cpp
>>> --- a/src/share/vm/services/gcNotifier.cpp
>>> +++ b/src/share/vm/services/gcNotifier.cpp
>>> @@ -209,7 +209,7 @@
>>> GCNotificationRequest *request = getRequest();
>>> if (request != NULL) {
>>> NotificationMark nm(request);
>>> - Handle objGcInfo = createGcInfo(request->gcManager, request->gcStatInfo, THREAD);
>>> + Handle objGcInfo = createGcInfo(request->gcManager, request->gcStatInfo, CHECK);
>>>
>>> Handle objName = java_lang_String::create_from_str(request->gcManager->name(), CHECK);
>>> Handle objAction = java_lang_String::create_from_str(request->gcAction, CHECK);
>>> kwalls at klaptop:~/work/bugs/8023478.gcbean/hotspot-rt$
>>>
>>>
>>>
>>> http://bugs.sun.com/view_bug.do?bug_id=8023478
>>> http://cr.openjdk.java.net/~kevinw/8023478/webrev.00/ (the above one line)
>>>
>>>
>>> Thanks
>>> Kevin
>>> --------
>>> PS
>>> As the bug is not available on the bugs site at the moment, this is part of the crashing stack to give some context:
>>>
>>> V [libjvm.so+0x7069d0] void report_vm_error(const char*,int,const char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78
>>> V [libjvm.so+0x63125c] void CollectedHeap::check_for_valid_allocation_state()+0x4c;; __1cNCollectedHeapbGcheck_for_valid_allocation_state6F_v_+0x4c
>>> V [libjvm.so+0x911f68] instanceOop InstanceKlass::allocate_instance(Thread*)+0x78;; __1cNInstanceKlassRallocate_instance6MpnGThread__nLinstanceOop__+0x78
>>> V [libjvm.so+0x9ffd7c] Handle java_lang_String::basic_create(int,Thread*)+0x174;; __1cQjava_lang_StringMbasic_create6FipnGThread__nGHandle__+0x174
>>> V [libjvm.so+0xa00520] Handle java_lang_String::create_from_str(const char*,Thread*)+0x40;; __1cQjava_lang_StringPcreate_from_str6FpkcpnGThread__nGHandle__+0x40
>>> V [libjvm.so+0x83eb0c] void GCNotifier::sendNotificationInternal(Thread*)+0x8c;; __1cKGCNotifierYsendNotificationInternal6FpnGThread__v_+0x8c
>>> V [libjvm.so+0x83ea4c] void GCNotifier::sendNotification(Thread*)+0xc;; __1cKGCNotifierQsendNotification6FpnGThread__v_+0xc
>>> V [libjvm.so+0x103faf8] void ServiceThread::service_thread_entry(JavaThread*,Thread*)+0x4a0;; __1cNServiceThreadUservice_thread_entry6FpnKJavaThread_pnGThread__v_+0x4a0
>>>
>>>
>
From coleen.phillimore at oracle.com Thu Sep 5 08:33:16 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Sep 2013 11:33:16 -0400
Subject: RFR 8022887: Assertion hit while using class and redefining it with
RedefineClasses s,imultaneously
Message-ID: <5228A43C.4000602@oracle.com>
Summary: Need to refetch the methods array from InstanceKlass after
safepoint.
open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
Tested with the test cases in the bug, and with internal SQE tests
(nsk.quick.testlist).
thanks,
Coleen
From daniel.daugherty at oracle.com Thu Sep 5 09:23:52 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 05 Sep 2013 10:23:52 -0600
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <5228A43C.4000602@oracle.com>
References: <5228A43C.4000602@oracle.com>
Message-ID: <5228B018.5000903@oracle.com>
On 9/5/13 9:33 AM, Coleen Phillimore wrote:
> Summary: Need to refetch the methods array from InstanceKlass after
> safepoint.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
The "frames" links are broken in this webrev. I had to
write down the changed line numbers for jvm.cpp and then
use the "new" link to see the context of the changes.
src/share/vm/oops/instanceKlass.cpp
Nice catch. The old code could return an 'm' value that
referred to a method that wasn't a match. Ouch.
src/share/vm/prims/jvm.cpp
Nice catch of the use of potentially stale method array, but I
think there might be more issues here.
In JVM_GetClassDeclaredMethods:
line 1865: ++num_methods;
line 1871: objArrayOop r =
oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
num_methods, CHECK_NULL);
line 1876: methods = k->methods();
line 1877: methods_length = methods->length();
line 1885: result->obj_at_put(out_idx, m);
line 1890: assert(out_idx == num_methods, "just checking");
So num_methods is computed before the new_objArray() call that
can result in a safepoint which can permit a RedefineClasses()
operation to complete. You refresh methods and methods_length,
but num_methods still has its pre-RedefineClasses value and
the size of the result array is also at the pre-RedefineClasses
size. Isn't it possible that we could overflow the result array
here? And maybe fire that assert() on line 1890.
In JVM_GetClassDeclaredConstructors(), similar concerns for these
lines:
line 1922: ++num_constructors;
line 1928: objArrayOop r =
oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
num_constructors, CHECK_NULL);
line 1942: result->obj_at_put(out_idx, m);
line 1947: assert(out_idx == num_constructors, "just checking");
Yes, this RedefineClasses() stuff is a serious pain in the butt
because it can change your assumed invariants in the middle of
your function.
Dan
> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>
> Tested with the test cases in the bug, and with internal SQE tests
> (nsk.quick.testlist).
>
> thanks,
> Coleen
From coleen.phillimore at oracle.com Thu Sep 5 09:35:33 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 05 Sep 2013 12:35:33 -0400
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <5228B018.5000903@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
Message-ID: <5228B2D5.6060803@oracle.com>
Dan,
Thank you for looking at this so quickly. You are right, we are not
only getting public methods, whose number cannot change right now with
redefine classes.
I have to rework this change.
Thanks,
Coleen
On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>> Summary: Need to refetch the methods array from InstanceKlass after
>> safepoint.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>
> The "frames" links are broken in this webrev. I had to
> write down the changed line numbers for jvm.cpp and then
> use the "new" link to see the context of the changes.
>
> src/share/vm/oops/instanceKlass.cpp
> Nice catch. The old code could return an 'm' value that
> referred to a method that wasn't a match. Ouch.
>
yes, it was a bit of a red herring for a while.
> src/share/vm/prims/jvm.cpp
> Nice catch of the use of potentially stale method array, but I
> think there might be more issues here.
>
> In JVM_GetClassDeclaredMethods:
>
> line 1865: ++num_methods;
>
>
>
> line 1871: objArrayOop r =
> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
> num_methods, CHECK_NULL);
>
>
>
> line 1876: methods = k->methods();
> line 1877: methods_length = methods->length();
>
>
>
> line 1885: result->obj_at_put(out_idx, m);
>
>
>
> line 1890: assert(out_idx == num_methods, "just checking");
>
> So num_methods is computed before the new_objArray() call that
> can result in a safepoint which can permit a RedefineClasses()
> operation to complete. You refresh methods and methods_length,
> but num_methods still has its pre-RedefineClasses value and
> the size of the result array is also at the pre-RedefineClasses
> size. Isn't it possible that we could overflow the result array
> here? And maybe fire that assert() on line 1890.
>
>
> In JVM_GetClassDeclaredConstructors(), similar concerns for these
> lines:
>
> line 1922: ++num_constructors;
>
>
>
> line 1928: objArrayOop r =
> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(), num_constructors,
> CHECK_NULL);
>
>
>
> line 1942: result->obj_at_put(out_idx, m);
>
>
>
> line 1947: assert(out_idx == num_constructors, "just checking");
>
>
> Yes, this RedefineClasses() stuff is a serious pain in the butt
> because it can change your assumed invariants in the middle of
> your function.
>
> Dan
>
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>
>> Tested with the test cases in the bug, and with internal SQE tests
>> (nsk.quick.testlist).
>>
>> thanks,
>> Coleen
>
From daniel.daugherty at oracle.com Thu Sep 5 09:39:18 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 05 Sep 2013 10:39:18 -0600
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <5228B2D5.6060803@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
<5228B2D5.6060803@oracle.com>
Message-ID: <5228B3B6.7010108@oracle.com>
On 9/5/13 10:35 AM, Coleen Phillimore wrote:
>
> Dan,
> Thank you for looking at this so quickly.
No problem. What motivated this was I just finished analyzing that
SIGSEGV crash in my AdHoc test run that I thought might be this bug.
I felt like I had enough context...
> You are right, we are not only getting public methods, whose number
> cannot change right now with redefine classes.
Still an outstanding find on the stale method array stuff and on
the "wrong" method match return...
> I have to rework this change.
I'll keep an eye open for the new version.
Dan
> Thanks,
> Coleen
>
> On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
>> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>>> Summary: Need to refetch the methods array from InstanceKlass after
>>> safepoint.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>>
>> The "frames" links are broken in this webrev. I had to
>> write down the changed line numbers for jvm.cpp and then
>> use the "new" link to see the context of the changes.
>>
>> src/share/vm/oops/instanceKlass.cpp
>> Nice catch. The old code could return an 'm' value that
>> referred to a method that wasn't a match. Ouch.
>>
>
> yes, it was a bit of a red herring for a while.
>
>> src/share/vm/prims/jvm.cpp
>> Nice catch of the use of potentially stale method array, but I
>> think there might be more issues here.
>>
>> In JVM_GetClassDeclaredMethods:
>>
>> line 1865: ++num_methods;
>>
>>
>>
>> line 1871: objArrayOop r =
>> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
>> num_methods, CHECK_NULL);
>>
>>
>>
>> line 1876: methods = k->methods();
>> line 1877: methods_length = methods->length();
>>
>>
>>
>> line 1885: result->obj_at_put(out_idx, m);
>>
>>
>>
>> line 1890: assert(out_idx == num_methods, "just checking");
>>
>> So num_methods is computed before the new_objArray() call that
>> can result in a safepoint which can permit a RedefineClasses()
>> operation to complete. You refresh methods and methods_length,
>> but num_methods still has its pre-RedefineClasses value and
>> the size of the result array is also at the pre-RedefineClasses
>> size. Isn't it possible that we could overflow the result array
>> here? And maybe fire that assert() on line 1890.
>>
>>
>> In JVM_GetClassDeclaredConstructors(), similar concerns for these
>> lines:
>>
>> line 1922: ++num_constructors;
>>
>>
>>
>> line 1928: objArrayOop r =
>> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
>> num_constructors, CHECK_NULL);
>>
>>
>>
>> line 1942: result->obj_at_put(out_idx, m);
>>
>>
>>
>> line 1947: assert(out_idx == num_constructors, "just checking");
>>
>>
>> Yes, this RedefineClasses() stuff is a serious pain in the butt
>> because it can change your assumed invariants in the middle of
>> your function.
>>
>> Dan
>>
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>>
>>> Tested with the test cases in the bug, and with internal SQE tests
>>> (nsk.quick.testlist).
>>>
>>> thanks,
>>> Coleen
>>
>
From naoto.sato at oracle.com Thu Sep 5 10:16:36 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 05 Sep 2013 17:16:36 +0000
Subject: hg: jdk8/tl/jdk: 8023943: Method description fix for
String.toLower/UpperCase() methods
Message-ID: <20130905171649.D9E73625AC@hg.openjdk.java.net>
Changeset: 4c711ef41bfa
Author: naoto
Date: 2013-09-05 10:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c711ef41bfa
8023943: Method description fix for String.toLower/UpperCase() methods
Reviewed-by: okutsu
! src/share/classes/java/lang/String.java
From john.coomes at oracle.com Thu Sep 5 10:58:16 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 05 Sep 2013 17:58:16 +0000
Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b106 for changeset
2e3a056c84a7
Message-ID: <20130905175819.56D7C625CF@hg.openjdk.java.net>
Changeset: 23fc34133152
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/23fc34133152
Added tag jdk8-b106 for changeset 2e3a056c84a7
! .hgtags
From john.coomes at oracle.com Thu Sep 5 10:58:10 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 05 Sep 2013 17:58:10 +0000
Subject: hg: hsx/hotspot-rt: 6 new changesets
Message-ID: <20130905175810.B7C88625CE@hg.openjdk.java.net>
Changeset: 21198f51bc7e
Author: erikj
Date: 2013-08-29 15:47 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/21198f51bc7e
8003162: build-infra: Improve suggestions for missing packages on linux
Reviewed-by: tbell, omajid
! common/autoconf/generated-configure.sh
! common/autoconf/help.m4
! common/autoconf/libraries.m4
Changeset: 92facce22941
Author: erikj
Date: 2013-08-30 10:13 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/92facce22941
8023957: Lock down version of autoconf
Reviewed-by: chegar, dsamersoff, tbell, dholmes
! README-builds.html
! common/autoconf/autogen.sh
! common/autoconf/configure.ac
! common/autoconf/generated-configure.sh
Changeset: 2aacc7080d36
Author: katleman
Date: 2013-09-03 13:48 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/2aacc7080d36
Merge
Changeset: 0f6dde6231bd
Author: ihse
Date: 2013-09-04 10:15 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/0f6dde6231bd
8024155: Fix 'make CONF= '
Reviewed-by: erikj, tbell
! NewMakefile.gmk
! common/makefiles/Main.gmk
Changeset: 8e7b4d9fb00f
Author: erikj
Date: 2013-09-04 10:37 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/8e7b4d9fb00f
Merge
! NewMakefile.gmk
! common/makefiles/Main.gmk
Changeset: 58f1b6f32b47
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/58f1b6f32b47
Added tag jdk8-b106 for changeset 8e7b4d9fb00f
! .hgtags
From john.coomes at oracle.com Thu Sep 5 10:58:27 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 05 Sep 2013 17:58:27 +0000
Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b106 for changeset
d3be8e3b429d
Message-ID: <20130905175835.ADF34625D0@hg.openjdk.java.net>
Changeset: d6a32e3831aa
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d6a32e3831aa
Added tag jdk8-b106 for changeset d3be8e3b429d
! .hgtags
From john.coomes at oracle.com Thu Sep 5 10:58:44 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 05 Sep 2013 17:58:44 +0000
Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b106 for changeset
6908370afe83
Message-ID: <20130905175852.BE914625D1@hg.openjdk.java.net>
Changeset: e3c9328f7563
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/e3c9328f7563
Added tag jdk8-b106 for changeset 6908370afe83
! .hgtags
From john.coomes at oracle.com Thu Sep 5 10:59:06 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 05 Sep 2013 17:59:06 +0000
Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b106 for changeset c817276bd870
Message-ID: <20130905180005.805B1625D2@hg.openjdk.java.net>
Changeset: aafc0f332658
Author: cl
Date: 2013-09-05 02:46 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/aafc0f332658
Added tag jdk8-b106 for changeset c817276bd870
! .hgtags
From john.coomes at oracle.com Thu Sep 5 11:01:14 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 05 Sep 2013 18:01:14 +0000
Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b106 for changeset
fcd768844b99
Message-ID: <20130905180129.A4261625D3@hg.openjdk.java.net>
Changeset: 3f274927ec18
Author: cl
Date: 2013-09-05 02:46 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3f274927ec18
Added tag jdk8-b106 for changeset fcd768844b99
! .hgtags
From john.coomes at oracle.com Thu Sep 5 11:01:48 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 05 Sep 2013 18:01:48 +0000
Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b106 for changeset
bf70cbd2c836
Message-ID: <20130905180152.00320625D4@hg.openjdk.java.net>
Changeset: f35e1255024b
Author: cl
Date: 2013-09-05 02:46 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f35e1255024b
Added tag jdk8-b106 for changeset bf70cbd2c836
! .hgtags
From serguei.spitsyn at oracle.com Thu Sep 5 11:20:52 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 05 Sep 2013 11:20:52 -0700
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <5228B2D5.6060803@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
<5228B2D5.6060803@oracle.com>
Message-ID: <5228CB84.7010400@oracle.com>
Coleen,
This is great finding, and also a nice catch by Dan.
Waiting for a new webrev from you.
Thanks,
Serguei
On 9/5/13 9:35 AM, Coleen Phillimore wrote:
>
> Dan,
> Thank you for looking at this so quickly. You are right, we are not
> only getting public methods, whose number cannot change right now with
> redefine classes.
> I have to rework this change.
> Thanks,
> Coleen
>
> On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
>> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>>> Summary: Need to refetch the methods array from InstanceKlass after
>>> safepoint.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>>
>> The "frames" links are broken in this webrev. I had to
>> write down the changed line numbers for jvm.cpp and then
>> use the "new" link to see the context of the changes.
>>
>> src/share/vm/oops/instanceKlass.cpp
>> Nice catch. The old code could return an 'm' value that
>> referred to a method that wasn't a match. Ouch.
>>
>
> yes, it was a bit of a red herring for a while.
>
>> src/share/vm/prims/jvm.cpp
>> Nice catch of the use of potentially stale method array, but I
>> think there might be more issues here.
>>
>> In JVM_GetClassDeclaredMethods:
>>
>> line 1865: ++num_methods;
>>
>>
>>
>> line 1871: objArrayOop r =
>> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
>> num_methods, CHECK_NULL);
>>
>>
>>
>> line 1876: methods = k->methods();
>> line 1877: methods_length = methods->length();
>>
>>
>>
>> line 1885: result->obj_at_put(out_idx, m);
>>
>>
>>
>> line 1890: assert(out_idx == num_methods, "just checking");
>>
>> So num_methods is computed before the new_objArray() call that
>> can result in a safepoint which can permit a RedefineClasses()
>> operation to complete. You refresh methods and methods_length,
>> but num_methods still has its pre-RedefineClasses value and
>> the size of the result array is also at the pre-RedefineClasses
>> size. Isn't it possible that we could overflow the result array
>> here? And maybe fire that assert() on line 1890.
>>
>>
>> In JVM_GetClassDeclaredConstructors(), similar concerns for these
>> lines:
>>
>> line 1922: ++num_constructors;
>>
>>
>>
>> line 1928: objArrayOop r =
>> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
>> num_constructors, CHECK_NULL);
>>
>>
>>
>> line 1942: result->obj_at_put(out_idx, m);
>>
>>
>>
>> line 1947: assert(out_idx == num_constructors, "just checking");
>>
>>
>> Yes, this RedefineClasses() stuff is a serious pain in the butt
>> because it can change your assumed invariants in the middle of
>> your function.
>>
>> Dan
>>
>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>>
>>> Tested with the test cases in the bug, and with internal SQE tests
>>> (nsk.quick.testlist).
>>>
>>> thanks,
>>> Coleen
>>
>
From mandy.chung at oracle.com Thu Sep 5 11:37:15 2013
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 05 Sep 2013 11:37:15 -0700
Subject: jmx-dev RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <5226D9B8.1040402@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
<5226D9B8.1040402@oracle.com>
Message-ID: <5228CF5B.5010207@oracle.com>
On 9/3/13 11:56 PM, Jaroslav Bachorik wrote:
>
> Ok, let's go back to the basics :)
>
> The reason for the test to fail intermittently are stale reads from the
> "waiting" variable. In order to minimize the changes it seems sufficient
> to make the "waiting" variable volatile to prevent the stale reads. The
> code modifying the "waiting" variable is already guarded by the
> semaphore so we are good there.
>
> The changes in Locks.java are about more consistent approach to waiting
> for a thread to enter a desired state. I took Erik's recommendation to
> just wait indefinitely for the desired thread state and let the harness
> deal with timeouts.
>
> The very simplified patch is at
> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
This simple change looks good. There are a couple of other tests using
ThreadExecutionSynchronizer. Not sure if they run into this
intermittent issue; if so, similiar fix might apply - just to mention
it. Anyway this fix is good to go.
> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
> simplify java.lang.management tests using it.
>
Thanks for filing the bug for JDK9.
Mandy
From robert.field at oracle.com Thu Sep 5 14:59:32 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Thu, 05 Sep 2013 21:59:32 +0000
Subject: hg: jdk8/tl/jdk: 8024283: 10 nashorn tests fail with similar stack
trace InternalError with cause being NoClassDefFoundError
Message-ID: <20130905220001.4BF14625E2@hg.openjdk.java.net>
Changeset: 9cc74675a854
Author: rfield
Date: 2013-09-05 14:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9cc74675a854
8024283: 10 nashorn tests fail with similar stack trace InternalError with cause being NoClassDefFoundError
Summary: Fix pre-existing 292 bug tickled by combo of nashorn code and MethodHandleInfo changes
Reviewed-by: jrose
Contributed-by: vladimir.x.ivanov at oracle.com
! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
From bhavesh.x.patel at oracle.com Thu Sep 5 16:36:37 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 05 Sep 2013 23:36:37 +0000
Subject: hg: jdk8/tl/langtools: 8023608: method grouping tabs folding issue
Message-ID: <20130905233642.86159625E6@hg.openjdk.java.net>
Changeset: e32a8a29643a
Author: bpatel
Date: 2013-09-05 16:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e32a8a29643a
8023608: method grouping tabs folding issue
Reviewed-by: jjg
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css
! test/com/sun/javadoc/testStylesheet/TestStylesheet.java
From david.holmes at oracle.com Thu Sep 5 19:18:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 06 Sep 2013 12:18:01 +1000
Subject: RFR: 6815130 intermittent ThreadMXBean/Locks.java failure
In-Reply-To: <52287E7C.3050107@oracle.com>
References: <5225C4D5.6040805@oracle.com> <522699F3.5000904@oracle.com>
<5226D9B8.1040402@oracle.com> <5226EF51.8010402@oracle.com>
<5226F049.9090108@oracle.com> <52287E7C.3050107@oracle.com>
Message-ID: <52293B59.90608@oracle.com>
Seems good to go to me.
David
On 5/09/2013 10:52 PM, Jaroslav Bachorik wrote:
> On 09/04/2013 10:33 AM, Jaroslav Bachorik wrote:
>> On 09/04/2013 10:29 AM, David Holmes wrote:
>>> On 4/09/2013 4:56 PM, Jaroslav Bachorik wrote:
>>>> On 09/04/2013 04:24 AM, Mandy Chung wrote:
>>>>> Hi Jaroslav,
>>>>>
>>>>> Like Daniel and David said, CyclicBarrier and other j.u.concurrent
>>>>> utility seem a good replacement with the ThreadExecutionSynchronizer
>>>>> class. ThreadMXBean/Locks.java was written prior to j.u.concurrent
>>>>> added to the platform (both java.util.concurrent and
>>>>> java.lang.management were added in JDK 5). Later
>>>>> ThreadExecutionSynchronizer was added to fix some intermittent issue.
>>>>>
>>>>> I think it's worth the investigation to replace the existing logic with
>>>>> j.u.concurrent and get rid of ThreadExecutionSynchronizer (which is used
>>>>> by a few other tests).
>>>>
>>>>
>>>> Ok, let's go back to the basics :)
>>>>
>>>> The reason for the test to fail intermittently are stale reads from the
>>>> "waiting" variable. In order to minimize the changes it seems sufficient
>>>> to make the "waiting" variable volatile to prevent the stale reads. The
>>>> code modifying the "waiting" variable is already guarded by the
>>>> semaphore so we are good there.
>>>
>>> Yes that seems valid.
>>>
>>>> The changes in Locks.java are about more consistent approach to waiting
>>>> for a thread to enter a desired state. I took Erik's recommendation to
>>>> just wait indefinitely for the desired thread state and let the harness
>>>> deal with timeouts.
>>>
>>> Yes that seems good too.
>>>
>>>> The very simplified patch is at
>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.03
>>>
>>> One thing you "fixed" in the original version but is no longer "fixed"
>>> is findOwnerInfo where you made the break exit both loops. I'm unclear
>>> if that is a correctness issue or just an optimization? I suspect an
>>> optimization and that once you have found what you need,
>>> lock.equals(blockedLock) will not be true for any other ThreadInfo objects.
>>
>> Exactly. It was an optimization and I excluded the change to keep the
>> fix very simple - given that the whole test would very likely be
>> rewritten for JDK9.
>
> Task for removal of
> java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer filed -
> JDK-8024326
>
> So, is this change good to go?
>
> Thanks,
>
> -JB-
>
>>
>> -JB-
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> I will file a task for JDK9 to remove ThreadExecutionSynchronizer and
>>>> simplify java.lang.management tests using it.
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>> Mandy
>>>>>
>>>>> On 9/3/2013 4:15 AM, Jaroslav Bachorik wrote:
>>>>>> Please, review the following patch of the intermittently failing test:
>>>>>> http://cr.openjdk.java.net/~jbachorik/6815130/webrev.01
>>>>>>
>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6815130
>>>>>>
>>>>>>
>>>>>> Sometimes the ThreadExecutionSynchronizer class failes to achieve the
>>>>>> desired synchronization (due to possible data races when evaluating and
>>>>>> setting the "waiting" variable) leading to test failures.
>>>>>>
>>>>>> The patch fixes the possibility of data race. Also the Locks class is
>>>>>> tidied up a bit.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -JB-
>>>>>
>>>>
>>
>
From serguei.spitsyn at oracle.com Fri Sep 6 00:35:10 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 06 Sep 2013 00:35:10 -0700
Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to
handle appendix arguments
In-Reply-To:
References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com>
<51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com>
<51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com>
<51F7F13E.8040104@oracle.com>
<5213C0AA.5030706@oracle.com>
Message-ID: <522985AE.2060205@oracle.com>
New bug:
https://bugs.openjdk.java.net/browse/JDK-8024380
JSR-292: new internal contract between linker primitives and
PopFrame is hard to support
Thanks!
Serguei
On 9/4/13 12:01 PM, John Rose wrote:
> Yes, please file this bug. I'm working on MH-related optimizations, and I am finding that preserving the required code pattern is blocking some optimizations, notably making customized variations of direct MHs.
>
> (The required code pattern is that the DMH in Local#0 has a member field which supplies the missing argument to the outgoing linker call. Making a variant DMH with a customized calling sequence is possible, but then it has wrong interactions with the MethodHandleInfo API. It would be easier to make a customized non-DMH, with no member field.)
>
> ? John
>
> On Aug 20, 2013, at 12:16 PM, serguei.spitsyn at oracle.com wrote:
>
>> John,
>>
>> Thank you for the comments!
>> In fact, I was very reluctant to implement it the way as it is in the webrev.
>> I'm in favor of the choice #3, and think, it is much better from the stability point of view.
>> Restoring the MemberName slot at deoptimization is not going to cause a performance degradation.
>>
>> If you and Christian are Ok with it I can file a new compiler bug to cover this issue.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 8/12/13 3:30 PM, John Rose wrote:
>>> This fix will be delicate and may have regressions if the exact code shape (of the PopFrame-ed invokestatic call) changes.
>>>
>>> Note that member_name_arg_or_null assumes that the value in Local#0 is a DMH; there will be asserts thrown if this fails. It also assumes that the member name held by the DMH in fact corresponds to the linker call (linkToStatic, linkToVirtual, etc.) being PopFrame-ed.
>>>
>>> In fact, the linker call might in some cases be run from another source than "aload0; getfield member". Requiring that this correspondence exist always is a new internal interface that is hard to document and verify; it may also inhibit present or future optimizations.
>>>
>>> There are other approaches that might be more robust:
>>> 1. Do not allow PopFrame to linker calls, since they (by definition) throw away their trailing MemberName argument.
>>> 2. Do not make such frames visible to the user.
>>> 3. Modify the linker primitives to store a copy of their trailing MemberName argument to a new slot in the interpreter frame and compiled frame. Be sure to populate this new slot on deoptimization.
>>>
>>> ? John
>>>
>>> P.S. Sorry about the delay in commenting; I am just digging out from under JVMLS business!
>>>
>>> On Jul 30, 2013, at 10:00 AM, serguei.spitsyn at oracle.com wrote:
>>>
>>>> The updated webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 7/29/13 10:11 PM, David Holmes wrote:
>>>>> Hi Serguei,
>>>>>
>>>>> I'm fine with restoring to what was in the first webrev.
>>>>>
>>>>> Further trimming of the JVMTI code is something the embedded folk could look at. It may not be worthwhile.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote:
>>>>>> On 7/29/13 8:22 PM, David Holmes wrote:
>>>>>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Christian and David,
>>>>>>>>
>>>>>>>> Thank you for the quick review and comments!
>>>>>>>>
>>>>>>>> This is a new version of webrev:
>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2
>>>>>>>>
>>>>>>> Sorry. You need that guard after all - at least you do if you continue
>>>>>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null
>>>>>>> will not exist:
>>>>>>>
>>>>>>> __ call_VM(rax, CAST_FROM_FN_PTR(address,
>>>>>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi);
>>>>>>>
>>>>>> You are right, nice catch again.
>>>>>> Probably, it was the reason, I did not remove the #if/#endif in the
>>>>>> first place. :)
>>>>>>
>>>>>>> I'm a little surprised that the assembly code does not have that whole
>>>>>>> section guarded with INCLUDE_JVMTI - perhaps it should?
>>>>>> It should.
>>>>>> But it can be non-trivial because of other dependencies like the above.
>>>>>> To make it right, both _remove_activation_preserving_args_entry and
>>>>>> generate_earlyret_entry_for
>>>>>> must be isolated with #if INCLUDE_JVMTI.
>>>>>> Then more files have to be involved in this chain of changes:
>>>>>> interpreter/templateInterpreter.hpp
>>>>>> interpreter/templateInterpreter.hpp
>>>>>> memory/universe.hpp
>>>>>> memory/universe.cpp
>>>>>> code/codeCache.hpp
>>>>>> code/codeCache.cpp
>>>>>> . . . etc ..
>>>>>>
>>>>>> Please, note, that the HOTSWAP macro is used in many places as well.
>>>>>> I'm not sure we still need it, so that another decision is needed for it.
>>>>>>
>>>>>> So, it seems that this kind of clean up is going far beyond my fix.
>>>>>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3
>>>>>> platform-dependent files as it was in the webrev v1.
>>>>>> I'm a little bit reluctant to open another clean-up bug for this issue
>>>>>> but maybe it is needed.
>>>>>> Please, let me know if you are comfortable with this solution.
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>>> Run this through a JPRT test build for productEmb to check that the
>>>>>>> minimal VM builds ok.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/28/13 9:11 PM, David Holmes wrote:
>>>>>>>>> Hi Serguei,
>>>>>>>>>
>>>>>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>> Please, review the fix for:
>>>>>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554
>>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554
>>>>>>>>>>
>>>>>>>>>> Open webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> In the templateInterpreter code why did you put this guard on your new
>>>>>>>>> code (from x86_32 version):
>>>>>>>>>
>>>>>>>>> 1923 #if INCLUDE_JVMTI
>>>>>>>>>
>>>>>>>>> when the whole chunk of code this is situated in is specifically for
>>>>>>>>> JVMTI support
>>>>>>>>>
>>>>>>>>> 1824 //
>>>>>>>>> 1825 // JVMTI PopFrame support
>>>>>>>>> 1826 //
>>>>>>>>>
>>>>>>>>> ???
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> Summary:
>>>>>>>>>> Restore the appendix argument of a polymorphic intrinsic call
>>>>>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame().
>>>>>>>>>>
>>>>>>>>>> Description
>>>>>>>>>> When JVMTI's PopFrame removes a frame that was called via a call
>>>>>>>>>> site
>>>>>>>>>> that
>>>>>>>>>> takes an appendix and that call site is reexecuted the appendix is
>>>>>>>>>> not on
>>>>>>>>>> the stack anymore because it got removed by the adapter.
>>>>>>>>>> This fix is to detect such a case and push the appendix on the
>>>>>>>>>> stack
>>>>>>>>>> again before reexecution.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Testing:
>>>>>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist,
>>>>>>>>>> nsk.jdi.testlist
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Serguei
From robert.field at oracle.com Fri Sep 6 00:44:06 2013
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Fri, 06 Sep 2013 07:44:06 +0000
Subject: hg: jdk8/tl/jdk: 8024260: 10 closed/java/lang/invoke/* tests failing
after overhaul to MethodHandleInfo
Message-ID: <20130906074430.44542625F9@hg.openjdk.java.net>
Changeset: f2487bb0c0d2
Author: rfield
Date: 2013-09-06 00:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2487bb0c0d2
8024260: 10 closed/java/lang/invoke/* tests failing after overhaul to MethodHandleInfo
Reviewed-by: vlivanov, briangoetz
Contributed-by: john.r.rose at oracle.com
! src/share/classes/java/lang/invoke/MethodHandle.java
From jaroslav.bachorik at oracle.com Fri Sep 6 01:05:26 2013
From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com)
Date: Fri, 06 Sep 2013 08:05:26 +0000
Subject: hg: jdk8/tl/jdk: 6815130: Intermittent ThreadMXBean/Locks.java test
failure
Message-ID: <20130906080549.C7D84625FB@hg.openjdk.java.net>
Changeset: da9de6f5cd6f
Author: jbachorik
Date: 2013-09-06 10:03 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da9de6f5cd6f
6815130: Intermittent ThreadMXBean/Locks.java test failure
Summary: Preventing stale reads from ThreadExecutionSynchronizer.waiting flag
Reviewed-by: dholmes, mchung, dfuchs
! test/java/lang/management/ThreadMXBean/Locks.java
! test/java/lang/management/ThreadMXBean/ThreadExecutionSynchronizer.java
From vicente.romero at oracle.com Fri Sep 6 01:54:15 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Fri, 06 Sep 2013 08:54:15 +0000
Subject: hg: jdk8/tl/langtools: 8024039: javac,
previous solution for JDK-8022186 was incorrect
Message-ID: <20130906085421.6D160625FC@hg.openjdk.java.net>
Changeset: 7c7b4aea6d50
Author: vromero
Date: 2013-09-06 09:53 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7c7b4aea6d50
8024039: javac, previous solution for JDK-8022186 was incorrect
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java
From shanliang.jiang at oracle.com Fri Sep 6 04:24:34 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Fri, 06 Sep 2013 13:24:34 +0200
Subject: Codereview request: 8023529 MBean*Info.equals: throw NPE
Message-ID: <5229BB72.4060502@oracle.com>
Hi,
Thanks to review the following fix:
webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
bug: https://bugs.openjdk.java.net/browse/JDK-8023954
Shanliang
From mattis.castegren at oracle.com Fri Sep 6 04:32:08 2013
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Fri, 6 Sep 2013 04:32:08 -0700 (PDT)
Subject: Project to improve hs_err files
Message-ID:
Hi (re-sending mail after joining the mailing lists, sorry if you get this mail twice)
My name is Mattis and I work with the JVM sustaining engineering team at Oracle. I am starting up a project to improve the data we get in the hs_err files when the JVM crashes. I have filed a JEP, but it has not yet been approved. See my attachment for the initial draft including motivation and scope. The main goal is not to completely solve new bugs by just using an hs_err file, but to help users, support and development to debug their problems, find duplicates of fixed bugs or application errors. It is also to provide more information that can be helpful when doing core file debugging on new issues.
The first step in this project is to gather suggestions of data that could help us when we see crashes. I am talking to the rest of the sustaining engineering team and also to the Java support team, but I also wanted to ask if anyone on these aliases have any thoughts on what data would help when we get an hs_err file. I'm looking for both big and small suggestions. Deciding if the suggestions are feasible or not can be discussed later.
Suggestions so far:
* Bigger changes
- Re-structure hs_err file to put more important data first, maybe include a summary header. End users can't be expected to read through the entire hs_err file. If we can put important hints of what went wrong at the top, that could save a lot of time. Also, many web tools truncate hs_err files, so we may never see the end of the files. This would also help us to faster triage incoming incidents
- Look at context sensitive data. If we crash when compiling a method, what additional data could we provide. Can we provide anything when crashing in GC, or when running interpreted code?
- Could we verify data structures? If we could list that some GC table had been corrupted, that could give a hint at the problem as well as help with finding duplicates and known issues
- Suggest workarounds/first debug steps. Sometimes we immediately know what the first debug step is. If we crash when running a compiled method, try to disable compilation of that method. If we crash after several OOMs, try increasing the Java heap or lower heap usage. If we could print these first steps, this could lead to bug filers providing more data when they file a bug. We could also highlight "dangerous" options, like -Xverify:none
* Additional Data
- The GC Strategy used
- The classpath variable
- Have we seen any OutOfMemoryErrors, StackOverflowErrors or C Heap allocation fails?
- Include Hypervisor information. If we run on Xen or VMWare, that is very interesting data
- Heap usage and permgen usage (JDK7) after the last full GC. If the heap is 99% full, that is a good hint that we might have run into a corner case in OOM handling for example
- Write the names of the last exceptions thrown. We currently list the addresses of the last exceptions. Giving the type instead would be very good. Did we crash after 10 StackOverflowErrors? That's a good hint of what went wrong
- Make the GC Heap History more easy to read. It's a great feature, but it is somewhat hard to read if an event is a full GC or a YC etc.
- Assembler instructions in dump files. Right now, we print the code around the IP in hex format. This isn't very helpful. If we could get the crashing instructions as assembler instead, that would help a lot
- Growing and shrinking of heap. We have seen a few issues when growing or shrinking the java heap. Saving the last few increases and decreases with a timestamp would help finding out if this could be an issue
- Highlight if third party JNI libs have been used
Please let me know if you have ideas of what information would make hs_err files more useful, and I will add them to my list.
Kind Regards
/Mattis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130906/753014a3/attachment.html
-------------- next part --------------
Title: Include more useful information in hs_err files
Author: Mattis Castegren
Organization: Oracle
Owner: Mattis Castegren
Created: 2013/9/27
Type: Feature
State: Draft
Exposure: Open
Component: vm/svc
Scope: Impl
JSR:
RFE:
Discussion: serviceability dash dev at openjdk dot java dot net
Start: 2013/Q2
Depends:
Blocks:
Effort: S
Duration: L
Template: 1.0
Internal-refs:
Reviewed-by:
Endorsed-by:
Funded-by:
Summary
-------
Work to get more useful data in hs_err files, to make it easier for customers, support and development to find the reason of crashes without core file debugging. Work to point out common issues like OOMs and SOEs, and make it easier to verify known issues.
Goals
-----
Many of the Java Incidents and test failures that come in are about crashes, and have little more information than an hs_err file. If we can point out common problems and include more debug information in the hs_err files, that could save a lot of work.
If the header of an hs_err file says that "you have had 1400 OutOfMemoryErrors before the crash", the user can start by investigating these issues.
The focus of this project should be both advanced users, like Dev or Sustaining Engineering, and regular users who see a crash in some application. The output must therefore be easy to understand, yet contain enough detail for advanced debugging.
Non-Goals
---------
The goal is not to find new bugs using only an hs_err file. This project may help in some cases, but if it's really a new bug we will usually need a core file or a reproducer.
Success Metrics
---------------
Motivation
----------
We get thousands of Crash Reports against Java. By including better information in the hs_err files, we can easily filter out bugs caused by user errors, known issues, etc.
Better hs_err files will also allow more bugs to be resolved either by the customer or by support, leading to lower costs in both the support organization and the development organizations
Description
-----------
The first part of this project should be to investigate what information would help Dev, Sustaining and Support. We should look at solved crashes and see what information would have helped. We should also see what crashes turns out to be caused by user errors.
This should be done at both the jvm, core and client areas, as all teams run into crashes. For core and client, these crashes are more often in the native libraries.
This investigation should result in several enhancement requests. Each of these can then be discussed independently on the open jdk aliases.
Alternatives
------------
Testing
-------
Testing can be difficult, as we will sometimes add features to make other debugging easier. Some of the features may therefore be hard to test if there are no known ways to trigger the problem.
We should run any testing we do have for hs_err files to make sure that the new features don't interfere with what is already there.
Risks and Assumptions
---------------------
The risks of these features will be small. When they are triggered, the program is already crashed. The biggest risk is that the new features may in turn contain bugs that could cause the hs_err files to be truncated, giving even less information instead of more.
Dependencies
-----------
Impact
------
Low, should only be noticeable when Java crashes.
From volker.simonis at gmail.com Fri Sep 6 05:44:00 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 6 Sep 2013 14:44:00 +0200
Subject: Project to improve hs_err files
In-Reply-To:
References:
Message-ID:
Hi Mattis,
just some quick comments:
On Fri, Sep 6, 2013 at 1:32 PM, Mattis Castegren
wrote:
>
> Hi (re-sending mail after joining the mailing lists, sorry if you get this mail twice)
>
>
>
> My name is Mattis and I work with the JVM sustaining engineering team at Oracle. I am starting up a project to improve the data we get in the hs_err files when the JVM crashes. I have filed a JEP, but it has not yet been approved. See my attachment for the initial draft including motivation and scope.
There is already a similar JEP: JEP 146: Improve Fatal Error Logs
(http://openjdk.java.net/jeps/146)
Are they somehow related? Maybe the efforts should be combined?
>
> The main goal is not to completely solve new bugs by just using an hs_err file, but to help users, support and development to debug their problems, find duplicates of fixed bugs or application errors. It is also to provide more information that can be helpful when doing core file debugging on new issues.
>
>
>
> The first step in this project is to gather suggestions of data that could help us when we see crashes. I am talking to the rest of the sustaining engineering team and also to the Java support team, but I also wanted to ask if anyone on these aliases have any thoughts on what data would help when we get an hs_err file. I?m looking for both big and small suggestions. Deciding if the suggestions are feasible or not can be discussed later.
>
> Suggestions so far:
>
>
>
> * Bigger changes
>
> - Re-structure hs_err file to put more important data first, maybe include a summary header. End users can?t be expected to read through the entire hs_err file. If we can put important hints of what went wrong at the top, that could save a lot of time. Also, many web tools truncate hs_err files, so we may never see the end of the files. This would also help us to faster triage incoming incidents
>
> - Look at context sensitive data. If we crash when compiling a method, what additional data could we provide. Can we provide anything when crashing in GC, or when running interpreted code?
>
> - Could we verify data structures? If we could list that some GC table had been corrupted, that could give a hint at the problem as well as help with finding duplicates and known issues
>
> - Suggest workarounds/first debug steps. Sometimes we immediately know what the first debug step is. If we crash when running a compiled method, try to disable compilation of that method. If we crash after several OOMs, try increasing the Java heap or lower heap usage. If we could print these first steps, this could lead to bug filers providing more data when they file a bug. We could also highlight "dangerous" options, like -Xverify:none
>
>
- Catch crashes in the compiler and recompile the same method with
full debug output turned on (i.e. dump the graphs of every
optimization step until the crash)
>
> * Additional Data
>
> - The GC Strategy used
>
> - The classpath variable
>
> - Have we seen any OutOfMemoryErrors, StackOverflowErrors or C Heap allocation fails?
>
> - Include Hypervisor information. If we run on Xen or VMWare, that is very interesting data
>
> - Heap usage and permgen usage (JDK7) after the last full GC. If the heap is 99% full, that is a good hint that we might have run into a corner case in OOM handling for example
>
> - Write the names of the last exceptions thrown. We currently list the addresses of the last exceptions. Giving the type instead would be very good. Did we crash after 10 StackOverflowErrors? That?s a good hint of what went wrong
>
> - Make the GC Heap History more easy to read. It?s a great feature, but it is somewhat hard to read if an event is a full GC or a YC etc.
>
> - Assembler instructions in dump files. Right now, we print the code around the IP in hex format. This isn?t very helpful. If we could get the crashing instructions as assembler instead, that would help a lot
>
This can easily be done with the hsdis-library. Unfortunately the
hsdis-library can not bundeled with a commercial JDK because it is
based on the GNU-binutils which are GPL-only.
But we could do two things:
- provide hsdis as a separate download (but this wouldn't help after a crash)
- provide a simple tool based on hsdis which can post-process the
hs_err-file and translate the hex-dump into readable assembler.
> - Growing and shrinking of heap. We have seen a few issues when growing or shrinking the java heap. Saving the last few increases and decreases with a timestamp would help finding out if this could be an issue
>
> - Highlight if third party JNI libs have been used
>
>
>
> Please let me know if you have ideas of what information would make hs_err files more useful, and I will add them to my list.
>
>
>
> Kind Regards
>
> /Mattis
From daniel.fuchs at oracle.com Fri Sep 6 05:44:55 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 06 Sep 2013 14:44:55 +0200
Subject: jmx-dev Codereview request: 8023529 MBean*Info.equals: throw NPE
In-Reply-To: <5229BB72.4060502@oracle.com>
References: <5229BB72.4060502@oracle.com>
Message-ID: <5229CE47.7080802@oracle.com>
On 9/6/13 1:24 PM, shanliang wrote:
> Hi,
>
> Thanks to review the following fix:
>
> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8023954
>
> Shanliang
>
Hi Shanliang,
Looks good - but it looks as if some hashCode() will suffer from the
same issue (for instance MBeanOperationInfo.hashCode)
Do you have an other defect to track that?
I have to wonder why we allow to create an MBeanOperationInfo
with a null name though... I wished the first implementation
had thrown NPE at construction time.
-- daniel
From staffan.larsen at oracle.com Fri Sep 6 06:15:45 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 6 Sep 2013 15:15:45 +0200
Subject: Project to improve hs_err files
In-Reply-To:
References:
Message-ID: <09BE45D2-9FE3-49DC-9603-8CB566BAAB2E@oracle.com>
On 6 sep 2013, at 14:44, Volker Simonis wrote:
>> My name is Mattis and I work with the JVM sustaining engineering team at Oracle. I am starting up a project to improve the data we get in the hs_err files when the JVM crashes. I have filed a JEP, but it has not yet been approved. See my attachment for the initial draft including motivation and scope.
>
> There is already a similar JEP: JEP 146: Improve Fatal Error Logs
> (http://openjdk.java.net/jeps/146)
> Are they somehow related? Maybe the efforts should be combined?
JEP 146 has already been delivered into the JVM. The JEP should be marked Complete.
http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/aa3d708d67c4
Thanks,
/Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130906/99005673/attachment-0001.html
From shanliang.jiang at oracle.com Fri Sep 6 06:17:00 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Fri, 06 Sep 2013 15:17:00 +0200
Subject: jmx-dev Codereview request: 8023529 MBean*Info.equals: throw NPE
In-Reply-To: <5229CE47.7080802@oracle.com>
References: <5229BB72.4060502@oracle.com> <5229CE47.7080802@oracle.com>
Message-ID: <5229D5CC.3030006@oracle.com>
Daniel Fuchs wrote:
> On 9/6/13 1:24 PM, shanliang wrote:
>> Hi,
>>
>> Thanks to review the following fix:
>>
>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8023954
>>
>> Shanliang
>>
>
> Hi Shanliang,
>
> Looks good - but it looks as if some hashCode() will suffer from the
> same issue (for instance MBeanOperationInfo.hashCode)
>
> Do you have an other defect to track that?
We have another bug JDK-8023669 and thank you for having done the code
review :) I am waiting a reviewer's review for push the fix
>
> I have to wonder why we allow to create an MBeanOperationInfo
> with a null name though... I wished the first implementation
> had thrown NPE at construction time.
I had same wondering, but I had no intention to modify it because that
is related to the specification.
The class OpenMBeanOperation does refuse a null or empty class name.
Shanliang
>
> -- daniel
From joel.franck at oracle.com Fri Sep 6 06:18:20 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Fri, 06 Sep 2013 13:18:20 +0000
Subject: hg: jdk8/tl/jdk: 5047859: (reflect) Class.getField can't find
String[].length
Message-ID: <20130906131923.F3C7B62604@hg.openjdk.java.net>
Changeset: 2064b2077a62
Author: jfranck
Date: 2013-09-06 14:20 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2064b2077a62
5047859: (reflect) Class.getField can't find String[].length
Reviewed-by: darcy, mchung
! src/share/classes/java/lang/Class.java
+ test/java/lang/Class/getField/ArrayLength.java
From sean.mullan at oracle.com Fri Sep 6 09:18:33 2013
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Fri, 06 Sep 2013 16:18:33 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130906161859.057FC6260C@hg.openjdk.java.net>
Changeset: 0aba8b6232af
Author: mullan
Date: 2013-09-06 12:04 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0aba8b6232af
8023362: Don't allow soft-fail behavior if OCSP responder returns "unauthorized"
Reviewed-by: vinnie, xuelei
! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
+ test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java
Changeset: f23a84a1cf8e
Author: mullan
Date: 2013-09-06 12:10 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f23a84a1cf8e
Merge
- src/share/classes/java/util/stream/CloseableStream.java
- src/share/classes/java/util/stream/DelegatingStream.java
- test/java/util/Map/TreeBinSplitBackToEntries.java
- test/sun/tools/jconsole/ImmutableResourceTest.java
- test/sun/tools/jconsole/ImmutableResourceTest.sh
From kumar.x.srinivasan at oracle.com Fri Sep 6 13:17:55 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 06 Sep 2013 13:17:55 -0700
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522A2B1F.7010803@oracle.com>
References: <522A0712.90702@oracle.com> <522A2B1F.7010803@oracle.com>
Message-ID: <522A3873.1090309@oracle.com>
On 9/6/2013 12:21 PM, Alan Bateman wrote:
> On 06/09/2013 17:47, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>> distros,
>> at this time the dual mode support in the launcher is being disabled.
>>
>> Message regarding this:
>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>
>>
>> The jdk changes are here:
>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>
>> The top forest changes are here:
>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
> I haven't studied the changes yet but I see you've updated
> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh.
> I don't think you need the changes at L42-48, instead you can just "hg
> rm" the 32-bit libraries that are in
> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib.
Will do, I was wondering about those libraries.
>
> You might want to bring the changes to serviceability-dev because of
> the change to the JDI launching connector and the JDI tests.
cc'ed.
Thanks
Kumar
>
> -Alan.
>
>
From headius at headius.com Fri Sep 6 15:00:47 2013
From: headius at headius.com (Charles Oliver Nutter)
Date: Fri, 6 Sep 2013 17:00:47 -0500
Subject: DTrace on BSD, future support
Message-ID:
Hello all!
I'm working with a GSoC student adding dtrace probe support to JRuby,
and ran into the issue that user-defined dtrace probes only work on
Solaris. So I started poking around hotspot source and found that both
the linux and bsd JSDT sources are empty and return false for
isSupported. Only solaris has JSDT support.
(The student is developing on Solaris, but I am on OS X.)
Obviously my next step was to simply copy the solaris source into the
BSD location and enable dtrace in the build. It didn't compile, but
there were only a handful of errors.
So at this point I'm wondering a few things:
* Is there any good reason why BSD (and Linux) support for JSDT has
not been ported or implemented?
* What is the current thought on the future of DTrace support in OpenJDK?
Our steps going forward, if we want to support JRuby dtrace probes on
platforms other than Solaris, will be to either implement or coerce
someone into implementing BSD/Linux DTrace JSDT support in OpenJDK or
to use a third-party library and our own JNI bindings. I'd prefer to
just get it working in OpenJDK proper.
Thoughts?
- Charlie
P.S. The files in question are
hotspot/src/os/bsd/vm/dtraceJSDT_bsd.cpp,
hotspot/src/os/linux/vm/dtraceJSDT_linux.cpp, and
hotspot/src/os/solaris/vm/dtraceJSDT_solaris.cpp.
From ioi.lam at oracle.com Fri Sep 6 14:57:11 2013
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Fri, 06 Sep 2013 21:57:11 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022335: Native stack walk while
generating hs_err does not work on Windows x64
Message-ID: <20130906215716.E7A1262617@hg.openjdk.java.net>
Changeset: 38f750491293
Author: iklam
Date: 2013-09-06 08:42 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/38f750491293
8022335: Native stack walk while generating hs_err does not work on Windows x64
Summary: Use WinDbg API StackWalk64()
Reviewed-by: zgu, dholmes
! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/decoder_windows.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp
From jonathan.gibbons at oracle.com Fri Sep 6 15:32:11 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 06 Sep 2013 22:32:11 +0000
Subject: hg: jdk8/tl/langtools: 8024434: problem running javadoc tests in
samevm mode on Windows
Message-ID: <20130906223218.3827162619@hg.openjdk.java.net>
Changeset: 64328fe5e4a6
Author: jjg
Date: 2013-09-06 15:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64328fe5e4a6
8024434: problem running javadoc tests in samevm mode on Windows
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java
! test/tools/javadoc/api/basic/APITest.java
! test/tools/javadoc/api/basic/GetTask_FileManagerTest.java
From lana.steuck at oracle.com Fri Sep 6 17:10:57 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:10:57 +0000
Subject: hg: jdk8/tl: 11 new changesets
Message-ID: <20130907001059.37A9262620@hg.openjdk.java.net>
Changeset: f8405a0fa69c
Author: erikj
Date: 2013-08-26 13:43 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/f8405a0fa69c
8023216: Feedback on README-builds.html
Reviewed-by: anthony, robilad, tbell
! README-builds.html
Changeset: 5166118c5917
Author: katleman
Date: 2013-08-26 17:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/5166118c5917
Merge
Changeset: 246cdbaa6c62
Author: cl
Date: 2013-08-29 09:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/246cdbaa6c62
Added tag jdk8-b105 for changeset 5166118c5917
! .hgtags
Changeset: 4ac867c44467
Author: lana
Date: 2013-08-29 16:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/4ac867c44467
Merge
Changeset: 21198f51bc7e
Author: erikj
Date: 2013-08-29 15:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/21198f51bc7e
8003162: build-infra: Improve suggestions for missing packages on linux
Reviewed-by: tbell, omajid
! common/autoconf/generated-configure.sh
! common/autoconf/help.m4
! common/autoconf/libraries.m4
Changeset: 92facce22941
Author: erikj
Date: 2013-08-30 10:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/92facce22941
8023957: Lock down version of autoconf
Reviewed-by: chegar, dsamersoff, tbell, dholmes
! README-builds.html
! common/autoconf/autogen.sh
! common/autoconf/configure.ac
! common/autoconf/generated-configure.sh
Changeset: 2aacc7080d36
Author: katleman
Date: 2013-09-03 13:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/2aacc7080d36
Merge
Changeset: 0f6dde6231bd
Author: ihse
Date: 2013-09-04 10:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/0f6dde6231bd
8024155: Fix 'make CONF= '
Reviewed-by: erikj, tbell
! NewMakefile.gmk
! common/makefiles/Main.gmk
Changeset: 8e7b4d9fb00f
Author: erikj
Date: 2013-09-04 10:37 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/rev/8e7b4d9fb00f
Merge
! NewMakefile.gmk
! common/makefiles/Main.gmk
Changeset: 58f1b6f32b47
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/58f1b6f32b47
Added tag jdk8-b106 for changeset 8e7b4d9fb00f
! .hgtags
Changeset: 73355c4c1bc8
Author: lana
Date: 2013-09-06 14:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/73355c4c1bc8
Merge
From lana.steuck at oracle.com Fri Sep 6 17:11:00 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:11:00 +0000
Subject: hg: jdk8/tl/nashorn: 4 new changesets
Message-ID: <20130907001105.D617E62622@hg.openjdk.java.net>
Changeset: 824d33e678f2
Author: cl
Date: 2013-08-29 09:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/824d33e678f2
Added tag jdk8-b105 for changeset f484bfb624dd
! .hgtags
Changeset: bf70cbd2c836
Author: lana
Date: 2013-08-29 16:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bf70cbd2c836
Merge
Changeset: f35e1255024b
Author: cl
Date: 2013-09-05 02:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f35e1255024b
Added tag jdk8-b106 for changeset bf70cbd2c836
! .hgtags
Changeset: 9e4acaa1bb7e
Author: lana
Date: 2013-09-06 14:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9e4acaa1bb7e
Merge
From lana.steuck at oracle.com Fri Sep 6 17:10:52 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:10:52 +0000
Subject: hg: jdk8/tl/corba: 3 new changesets
Message-ID: <20130907001055.A93A06261F@hg.openjdk.java.net>
Changeset: 2e3a056c84a7
Author: cl
Date: 2013-08-29 09:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2e3a056c84a7
Added tag jdk8-b105 for changeset 4e38de7c767e
! .hgtags
Changeset: 23fc34133152
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/23fc34133152
Added tag jdk8-b106 for changeset 2e3a056c84a7
! .hgtags
Changeset: 4853dc082c7d
Author: lana
Date: 2013-09-06 14:15 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4853dc082c7d
Merge
From lana.steuck at oracle.com Fri Sep 6 17:10:56 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:10:56 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20130907001105.3F75662621@hg.openjdk.java.net>
Changeset: d3be8e3b429d
Author: cl
Date: 2013-08-29 09:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d3be8e3b429d
Added tag jdk8-b105 for changeset 09a46ec11f88
! .hgtags
Changeset: d6a32e3831aa
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d6a32e3831aa
Added tag jdk8-b106 for changeset d3be8e3b429d
! .hgtags
From lana.steuck at oracle.com Fri Sep 6 17:10:57 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:10:57 +0000
Subject: hg: jdk8/tl/jaxws: 3 new changesets
Message-ID: <20130907001110.5846962623@hg.openjdk.java.net>
Changeset: 01be6f93d0a4
Author: cl
Date: 2013-08-29 09:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/01be6f93d0a4
Added tag jdk8-b105 for changeset 88390df7ed2c
! .hgtags
Changeset: 6908370afe83
Author: lana
Date: 2013-08-29 16:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6908370afe83
Merge
Changeset: e3c9328f7563
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e3c9328f7563
Added tag jdk8-b106 for changeset 6908370afe83
! .hgtags
From lana.steuck at oracle.com Fri Sep 6 17:11:04 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:11:04 +0000
Subject: hg: jdk8/tl/langtools: 5 new changesets
Message-ID: <20130907001122.B4D5962624@hg.openjdk.java.net>
Changeset: e431c9bfb171
Author: cl
Date: 2013-08-29 09:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e431c9bfb171
Added tag jdk8-b105 for changeset 375834b5cf08
! .hgtags
Changeset: fcd768844b99
Author: lana
Date: 2013-08-29 16:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fcd768844b99
Merge
- test/com/sun/javadoc/testNavagation/TestNavagation.java
- test/com/sun/javadoc/testNavagation/pkg/A.java
- test/com/sun/javadoc/testNavagation/pkg/C.java
- test/com/sun/javadoc/testNavagation/pkg/E.java
- test/com/sun/javadoc/testNavagation/pkg/I.java
- test/tools/javac/8015701/AnonymousParameters.java
Changeset: 3f274927ec18
Author: cl
Date: 2013-09-05 02:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3f274927ec18
Added tag jdk8-b106 for changeset fcd768844b99
! .hgtags
Changeset: c9d6f4749f87
Author: lana
Date: 2013-09-06 14:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c9d6f4749f87
Merge
Changeset: e84587462a47
Author: lana
Date: 2013-09-06 17:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e84587462a47
Merge
From lana.steuck at oracle.com Fri Sep 6 17:11:30 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:11:30 +0000
Subject: hg: jdk8/tl/hotspot: 70 new changesets
Message-ID: <20130907001401.11CA962625@hg.openjdk.java.net>
Changeset: 37165c3618a3
Author: amurillo
Date: 2013-08-16 04:24 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37165c3618a3
8023152: new hotspot build - hs25-b47
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: d96f52012aaa
Author: rdurbin
Date: 2013-08-14 15:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d96f52012aaa
8005073: [TESTBUG] remove crufty '_g' support from HS tests
Summary: remove crufty '_g' support from HS tests
Reviewed-by: dcubed, sla
! test/Makefile
Changeset: 740e263c80c6
Author: hseigel
Date: 2013-08-15 20:04 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/740e263c80c6
8003424: Enable Class Data Sharing for CompressedOops
8016729: ObjectAlignmentInBytes=16 now forces the use of heap based compressed oops
8005933: The -Xshare:auto option is ignored for -server
Summary: Move klass metaspace above the heap and support CDS with compressed klass ptrs.
Reviewed-by: coleenp, kvn, mgerdin, tschatzl, stefank
! src/cpu/sparc/vm/macroAssembler_sparc.cpp
! src/cpu/sparc/vm/macroAssembler_sparc.hpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/macroAssembler_x86.cpp
! src/cpu/x86/vm/macroAssembler_x86.hpp
! src/cpu/x86/vm/relocInfo_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klass.inline.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java
+ test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java
+ test/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java
Changeset: e5003079dfa5
Author: dcubed
Date: 2013-08-16 10:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5003079dfa5
Merge
! src/share/vm/utilities/globalDefinitions.hpp
Changeset: b1fd869e7df0
Author: minqi
Date: 2013-08-19 09:16 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1fd869e7df0
8023188: Unsafe volatile double store on bsd is broken
Reviewed-by: dcubed, dholmes
Contributed-by: yumin.qi at oracle.com
! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp
Changeset: 1a8fb39bdbc4
Author: ehelin
Date: 2013-08-07 16:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a8fb39bdbc4
8014659: NPG: performance counters for compressed klass space
Reviewed-by: mgerdin, coleenp, hseigel, jmasa, ctornqvi
! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/metaspaceCounters.cpp
! src/share/vm/memory/metaspaceCounters.hpp
! src/share/vm/memory/universe.cpp
+ test/gc/metaspace/TestMetaspacePerfCounters.java
+ test/testlibrary/AssertsTest.java
+ test/testlibrary/com/oracle/java/testlibrary/Asserts.java
+ test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java
+ test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java
+ test/testlibrary/com/oracle/java/testlibrary/InputArguments.java
+ test/testlibrary/com/oracle/java/testlibrary/PerfCounter.java
+ test/testlibrary/com/oracle/java/testlibrary/PerfCounters.java
Changeset: 878bb0b7e799
Author: ehelin
Date: 2013-08-19 17:29 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/878bb0b7e799
Merge
Changeset: 10c59b8021ec
Author: kevinw
Date: 2013-08-19 14:28 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10c59b8021ec
8022655: ClassDump ignored jarStream setting
Reviewed-by: minqi, sla
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java
! test/compiler/ciReplay/common.sh
Changeset: 9011aa6843ce
Author: kevinw
Date: 2013-08-19 22:28 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9011aa6843ce
Merge
Changeset: e22ee8e7ae62
Author: jiangli
Date: 2013-08-19 14:59 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e22ee8e7ae62
8021948: Change InstanceKlass::_source_file_name and _generic_signature from Symbol* to constant pool indexes.
Summary: Change InstanceKlass::_source_file_name and _generic_signature to u2 fields.
Reviewed-by: coleenp, iklam
! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/runtime/vmStructs.cpp
Changeset: aeebffb56606
Author: jiangli
Date: 2013-08-20 00:48 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aeebffb56606
Merge
Changeset: 9d6c9b0a8f15
Author: dcubed
Date: 2013-08-20 13:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d6c9b0a8f15
8023287: HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3"
Summary: Recognize 0x5120 as "Sun Studio 12u3".
Reviewed-by: dholmes, coleenp
! src/share/vm/runtime/vm_version.cpp
Changeset: afbe18ae0905
Author: bharadwaj
Date: 2013-08-15 11:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/afbe18ae0905
8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases
Summary: Corrected details
Reviewed-by: kvn, twisti, rbackman
Contributed-by: david.r.chase at oracle.com
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
Changeset: adb9a7d94cb5
Author: adlertz
Date: 2013-08-16 10:23 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/adb9a7d94cb5
8023003: Cleanup the public interface to PhaseCFG
Summary: public methods that don't need to be public should be private.
Reviewed-by: kvn, twisti
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/vmStructs.cpp
Changeset: 6c72125a2f40
Author: iignatyev
Date: 2013-08-16 17:34 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c72125a2f40
8016456: ciReplay test assumes TIERED compilation is available
Reviewed-by: vlivanov, kvn, dholmes
! test/compiler/ciReplay/common.sh
Changeset: f99558245e5c
Author: iignatyev
Date: 2013-08-14 23:50 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f99558245e5c
8022832: Add WB APIs for OSR compilation
Reviewed-by: kvn
! src/share/vm/oops/method.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
Changeset: d18b10b1fd09
Author: iignatyev
Date: 2013-08-16 13:39 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d18b10b1fd09
Merge
Changeset: 4b2838704fd5
Author: kvn
Date: 2013-08-16 14:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b2838704fd5
8021898: Broken JIT compiler optimization for loop unswitching
Summary: fix method clone_projs() to clone all related MachProj nodes.
Reviewed-by: roland, adlertz
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/utilities/vmError.cpp
Changeset: 6725044c5725
Author: rbackman
Date: 2013-08-19 09:33 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6725044c5725
Merge
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/share/vm/oops/method.cpp
Changeset: e16282db4946
Author: twisti
Date: 2013-08-20 10:57 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e16282db4946
8022956: Clang: enable return type warnings on BSD
Reviewed-by: coleenp, sla
! make/bsd/makefiles/gcc.make
! src/cpu/zero/vm/assembler_zero.cpp
! src/cpu/zero/vm/cppInterpreter_zero.cpp
! src/cpu/zero/vm/frame_zero.cpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/cpu/zero/vm/icBuffer_zero.cpp
! src/cpu/zero/vm/interp_masm_zero.hpp
! src/cpu/zero/vm/interpreter_zero.cpp
! src/cpu/zero/vm/nativeInst_zero.hpp
! src/cpu/zero/vm/register_zero.cpp
! src/cpu/zero/vm/relocInfo_zero.cpp
! src/cpu/zero/vm/sharedRuntime_zero.cpp
! src/cpu/zero/vm/vtableStubs_zero.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp
Changeset: acedd49a1bce
Author: rbackman
Date: 2013-08-08 03:16 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acedd49a1bce
8022675: Redundant class init check
Reviewed-by: kvn, twisti
! src/share/vm/opto/library_call.cpp
Changeset: 4dece0730c50
Author: rbackman
Date: 2013-08-22 18:37 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4dece0730c50
Merge
! src/share/vm/runtime/vmStructs.cpp
! test/compiler/ciReplay/common.sh
Changeset: 5888334c9c24
Author: johnc
Date: 2013-08-15 10:52 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5888334c9c24
7145569: G1: optimize nmethods scanning
Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead.
Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp
! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
! src/share/vm/gc_interface/collectedHeap.cpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/iterator.cpp
! src/share/vm/runtime/sweeper.hpp
! src/share/vm/utilities/growableArray.hpp
Changeset: 8088d93a63e6
Author: brutisso
Date: 2013-08-15 13:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8088d93a63e6
Merge
Changeset: 9720d338b1d5
Author: brutisso
Date: 2013-08-16 11:26 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9720d338b1d5
8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0
Reviewed-by: stefank, mgerdin
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
Changeset: d0afbee540e0
Author: stefank
Date: 2013-08-19 13:44 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0afbee540e0
8023227: Enhance layout_helper_log2_element_size assert
Reviewed-by: mgerdin, jmasa
! src/share/vm/oops/klass.hpp
Changeset: 422920730903
Author: ehelin
Date: 2013-08-19 18:17 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/422920730903
8023219: NPG: MetaspaceMemoryPool should report statistics for all of metaspace
Reviewed-by: stefank, sjohanss
! src/share/vm/services/memoryPool.cpp
Changeset: 57600c4aeabe
Author: jmasa
Date: 2013-08-19 08:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57600c4aeabe
Merge
- src/os_cpu/bsd_x86/vm/bsd_x86_32.ad
- src/os_cpu/bsd_x86/vm/bsd_x86_64.ad
- src/os_cpu/linux_x86/vm/linux_x86_32.ad
- src/os_cpu/linux_x86/vm/linux_x86_64.ad
- src/os_cpu/solaris_sparc/vm/solaris_sparc.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_32.ad
- src/os_cpu/solaris_x86/vm/solaris_x86_64.ad
- src/os_cpu/windows_x86/vm/windows_x86_32.ad
- src/os_cpu/windows_x86/vm/windows_x86_64.ad
Changeset: 31f220c1f789
Author: jmasa
Date: 2013-08-20 10:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f220c1f789
Merge
Changeset: 61521bd65100
Author: tschatzl
Date: 2013-08-21 10:32 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/61521bd65100
8022784: TaskQueue misses minimal documentation and references for analysis
Summary: Add appropriate documentation and references to publication to allow easier analysis of the TaskQueue implementation.
Reviewed-by: dholmes, ehelin
! src/share/vm/utilities/taskqueue.hpp
Changeset: cb9da55b1990
Author: jmasa
Date: 2013-08-14 19:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb9da55b1990
8021809: Partitioning based on eden sampling during allocation not reset correctly
Reviewed-by: ysr, hiroshi
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
Changeset: b51aee2dd8bb
Author: jmasa
Date: 2013-08-22 11:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b51aee2dd8bb
Merge
! src/share/vm/oops/klass.hpp
Changeset: 8009adb44523
Author: jmasa
Date: 2013-08-22 14:03 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8009adb44523
Merge
Changeset: c1604d5885a6
Author: amurillo
Date: 2013-08-23 03:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1604d5885a6
Merge
Changeset: acac3bde66b2
Author: amurillo
Date: 2013-08-23 03:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acac3bde66b2
Added tag hs25-b47 for changeset c1604d5885a6
! .hgtags
Changeset: b649cfa58604
Author: cl
Date: 2013-08-29 09:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b649cfa58604
Added tag jdk8-b105 for changeset acac3bde66b2
! .hgtags
Changeset: 73921c720b94
Author: amurillo
Date: 2013-08-23 03:14 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/73921c720b94
8023635: new hotspot build - hs25-b48
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: c6ec0a97b30a
Author: sla
Date: 2013-08-21 13:18 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c6ec0a97b30a
8022808: Kitchensink hangs on macos
Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources
Reviewed-by: dholmes, rbackman
! src/os/bsd/vm/os_bsd.cpp
Changeset: 3a57fa7a4cd0
Author: hseigel
Date: 2013-08-22 11:52 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a57fa7a4cd0
7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris
8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX
Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX.
Reviewed-by: coleenp, dholmes, mseledtsov, ccheung
! src/os/bsd/vm/os_bsd.cpp
- test/runtime/7051189/Xchecksig.sh
+ test/runtime/XCheckJniJsig/XCheckJSig.java
Changeset: e37ab280bbce
Author: allwin
Date: 2013-07-23 14:32 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e37ab280bbce
8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__"
Reviewed-by: sla, sundar, kmo
Contributed-by: yunda.mly at taobao.com
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js
Changeset: 669d9a235486
Author: sla
Date: 2013-08-22 14:56 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/669d9a235486
Merge
Changeset: c062a6e1fa33
Author: iklam
Date: 2013-08-22 10:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c062a6e1fa33
8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1
Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1
Reviewed-by: dcubed, sla, tbell
! make/windows/build_vm_def.sh
! make/windows/makefiles/debug.make
! make/windows/makefiles/fastdebug.make
! make/windows/makefiles/product.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make
Changeset: 811aea34d5e7
Author: iklam
Date: 2013-08-22 13:53 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/811aea34d5e7
Merge
Changeset: ff2520b97b00
Author: jiangli
Date: 2013-08-22 19:27 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff2520b97b00
8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 .
Summary: Need to check if the constant pool mapping returns 0.
Reviewed-by: coleenp, sspitsyn
! src/share/vm/prims/jvmtiRedefineClasses.cpp
Changeset: 887db75613f8
Author: jiangli
Date: 2013-08-22 17:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/887db75613f8
Merge
Changeset: a70566600baf
Author: poonam
Date: 2013-08-21 22:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a70566600baf
8020530: Non heap memory size calculated incorrectly
Reviewed-by: coleenp, sla
Contributed-by: vladimir.kempik at oracle.com
! src/share/vm/services/management.cpp
Changeset: 730210728146
Author: poonam
Date: 2013-08-22 18:09 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/730210728146
Merge
- test/runtime/7051189/Xchecksig.sh
Changeset: 817e46dd5864
Author: poonam
Date: 2013-08-22 21:23 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/817e46dd5864
Merge
Changeset: 739c309fd729
Author: mgronlun
Date: 2013-08-23 10:36 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/739c309fd729
8023457: Event based tracing framework needs a mutex for thread groups
Reviewed-by: acorn, sla
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
Changeset: cacc421f39d7
Author: dcubed
Date: 2013-08-23 10:39 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cacc421f39d7
Merge
- test/runtime/7051189/Xchecksig.sh
Changeset: badf4244ceae
Author: hseigel
Date: 2013-08-25 21:21 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/badf4244ceae
8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking
Summary: Explicitly specify -fno-omit-frame-pointer.
Reviewed-by: coleenp, dholmes, dcubed
! make/linux/makefiles/amd64.make
! make/linux/makefiles/gcc.make
Changeset: faf2631b9334
Author: dsimms
Date: 2013-08-26 09:33 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/faf2631b9334
8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM
Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and GetArrayElements family of functions.
Reviewed-by: dholmes, coleenp
! src/share/vm/memory/allocation.hpp
! src/share/vm/prims/jni.cpp
Changeset: 4c84d351cca9
Author: stefank
Date: 2013-08-16 13:22 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c84d351cca9
8007074: SIGSEGV at ParMarkBitMap::verify_clear()
Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages.
Reviewed-by: tschatzl, dcubed, brutisso
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/globals_linux.hpp
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/virtualspace.cpp
! src/share/vm/runtime/virtualspace.hpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/utilities/globalDefinitions.hpp
Changeset: 21ffbaa691b5
Author: stefank
Date: 2013-08-26 07:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/21ffbaa691b5
Merge
! src/share/vm/prims/jni.cpp
Changeset: 1bb10d3170fa
Author: jmasa
Date: 2013-08-16 06:12 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1bb10d3170fa
8022817: CMS should not shrink if compaction was not done
Reviewed-by: ysr, mgerdin
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
Changeset: f7d3b4387a16
Author: brutisso
Date: 2013-08-21 22:35 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7d3b4387a16
8022872: G1: Use correct GC cause for young GC triggered by humongous allocations
Reviewed-by: tonyp, tschatzl
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp
Changeset: c31eb8c86a50
Author: brutisso
Date: 2013-08-22 04:14 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c31eb8c86a50
Merge
Changeset: ec145d04eda8
Author: jmasa
Date: 2013-08-23 15:59 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec145d04eda8
Merge
Changeset: 1624a68007bd
Author: jmasa
Date: 2013-08-27 18:55 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1624a68007bd
Merge
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
Changeset: f92b82d454fa
Author: bpittore
Date: 2013-08-23 20:33 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f92b82d454fa
8014135: The JVMTI specification does not conform to recent changes in JNI specification
Summary: Added support for statically linked agents
Reviewed-by: sspitsyn, bobv, coleenp
! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/prims/jvmti.xml
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp
Changeset: 5fd8e2fbafd4
Author: cjplummer
Date: 2013-08-23 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5fd8e2fbafd4
8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported
Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported.
Reviewed-by: dholmes, coleenp
! src/share/vm/prims/whitebox.cpp
! test/runtime/NMT/ThreadedVirtualAllocTestType.java
! test/runtime/NMT/VirtualAllocTestType.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
Changeset: 7aa0c1fb6fdb
Author: dholmes
Date: 2013-08-27 22:05 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7aa0c1fb6fdb
8006164: [TESTBUG] compact profile hotspot test issues
Summary: Define profile-based test groups.
Reviewed-by: dcubed, mchung
! test/TEST.ROOT
+ test/TEST.groups
Changeset: 1fedf3c7f923
Author: bpittore
Date: 2013-08-28 14:44 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1fedf3c7f923
8023580: Add jtreg test for 8004051 and 8005722
Summary: Tests checks an assertion dealing with the number of args passed in registers
Reviewed-by: mseledtsov, kvn
+ test/compiler/8004051/Test8004051.java
Changeset: b1fb293d92c4
Author: jiangli
Date: 2013-08-28 12:01 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1fb293d92c4
Merge
Changeset: 2b113b65a051
Author: dholmes
Date: 2013-08-28 19:25 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b113b65a051
8023900: [TESTBUG] Initial compact profile test groups need adjusting
Reviewed-by: dcubed, mchung, hseigel
! test/TEST.groups
Changeset: 54dfd798deaf
Author: dholmes
Date: 2013-08-28 21:42 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54dfd798deaf
Merge
Changeset: 62f527c674d2
Author: dholmes
Date: 2013-08-29 00:22 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/62f527c674d2
Merge
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp
Changeset: 18b4798adbc4
Author: amurillo
Date: 2013-08-30 00:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18b4798adbc4
Merge
- test/runtime/7051189/Xchecksig.sh
Changeset: aed585cafc0d
Author: amurillo
Date: 2013-08-30 00:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aed585cafc0d
Added tag hs25-b48 for changeset 18b4798adbc4
! .hgtags
Changeset: 3f4392035ec7
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f4392035ec7
Added tag jdk8-b106 for changeset aed585cafc0d
! .hgtags
From lana.steuck at oracle.com Fri Sep 6 17:11:27 2013
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sat, 07 Sep 2013 00:11:27 +0000
Subject: hg: jdk8/tl/jdk: 6 new changesets
Message-ID: <20130907001405.323CF62626@hg.openjdk.java.net>
Changeset: 0417358184a1
Author: omajid
Date: 2013-08-22 16:00 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0417358184a1
8023480: Create a jvm.cfg for zero on 32 bit architectures
Reviewed-by: dholmes, erikj
! makefiles/CopyFiles.gmk
Changeset: 1fe211ae3d2b
Author: katleman
Date: 2013-08-26 17:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fe211ae3d2b
Merge
Changeset: 1a2a8d143583
Author: cl
Date: 2013-08-29 09:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a2a8d143583
Added tag jdk8-b105 for changeset 1fe211ae3d2b
! .hgtags
Changeset: c817276bd870
Author: lana
Date: 2013-08-29 16:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c817276bd870
Merge
- src/share/classes/sun/misc/Compare.java
- src/share/classes/sun/misc/Sort.java
Changeset: aafc0f332658
Author: cl
Date: 2013-09-05 02:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aafc0f332658
Added tag jdk8-b106 for changeset c817276bd870
! .hgtags
Changeset: 257de3e3a278
Author: lana
Date: 2013-09-06 14:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/257de3e3a278
Merge
From gnu.andrew at redhat.com Fri Sep 6 20:22:42 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 6 Sep 2013 23:22:42 -0400 (EDT)
Subject: DTrace on BSD, future support
In-Reply-To:
References:
Message-ID: <1183444067.8786662.1378524162044.JavaMail.root@redhat.com>
----- Original Message -----
> Hello all!
>
> I'm working with a GSoC student adding dtrace probe support to JRuby,
> and ran into the issue that user-defined dtrace probes only work on
> Solaris. So I started poking around hotspot source and found that both
> the linux and bsd JSDT sources are empty and return false for
> isSupported. Only solaris has JSDT support.
>
Linux doesn't use DTrace. It uses SystemTap.
CCing Mark Wielaard who added this support:
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71
> (The student is developing on Solaris, but I am on OS X.)
>
> Obviously my next step was to simply copy the solaris source into the
> BSD location and enable dtrace in the build. It didn't compile, but
> there were only a handful of errors.
>
> So at this point I'm wondering a few things:
>
> * Is there any good reason why BSD (and Linux) support for JSDT has
> not been ported or implemented?
> * What is the current thought on the future of DTrace support in OpenJDK?
>
> Our steps going forward, if we want to support JRuby dtrace probes on
> platforms other than Solaris, will be to either implement or coerce
> someone into implementing BSD/Linux DTrace JSDT support in OpenJDK or
> to use a third-party library and our own JNI bindings. I'd prefer to
> just get it working in OpenJDK proper.
>
> Thoughts?
>
> - Charlie
>
> P.S. The files in question are
> hotspot/src/os/bsd/vm/dtraceJSDT_bsd.cpp,
> hotspot/src/os/linux/vm/dtraceJSDT_linux.cpp, and
> hotspot/src/os/solaris/vm/dtraceJSDT_solaris.cpp.
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
From staffan.larsen at oracle.com Sat Sep 7 03:50:38 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Sat, 7 Sep 2013 12:50:38 +0200
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522A3873.1090309@oracle.com>
References: <522A0712.90702@oracle.com> <522A2B1F.7010803@oracle.com>
<522A3873.1090309@oracle.com>
Message-ID:
This is a welcome change. I've looked at the serviceability test and the changes look good except:
test/demo/jvmti/DemoRun.java
test/sun/tools/jhat/HatRun.java
- Looks like there are still some -d64 remnants that I wasn't expecting.
Thanks,
/Staffan
On 6 sep 2013, at 22:17, Kumar Srinivasan wrote:
> On 9/6/2013 12:21 PM, Alan Bateman wrote:
>> On 06/09/2013 17:47, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> Please review the changes to remove Solaris 32-bit binaries from JDK8 distros,
>>> at this time the dual mode support in the launcher is being disabled.
>>>
>>> Message regarding this:
>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>
>>> The jdk changes are here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>
>>> The top forest changes are here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>> I haven't studied the changes yet but I see you've updated test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh. I don't think you need the changes at L42-48, instead you can just "hg rm" the 32-bit libraries that are in test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib.
>
> Will do, I was wondering about those libraries.
>
>>
>> You might want to bring the changes to serviceability-dev because of the change to the JDI launching connector and the JDI tests.
>
> cc'ed.
>
> Thanks
>
> Kumar
>
>>
>> -Alan.
>>
>>
>
From xuelei.fan at oracle.com Sat Sep 7 17:06:45 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Sun, 08 Sep 2013 00:06:45 +0000
Subject: hg: jdk8/tl/jdk: 7188657: There should be a way to reorder the JSSE
ciphers
Message-ID: <20130908000711.8577962660@hg.openjdk.java.net>
Changeset: 0f47f9f622d9
Author: xuelei
Date: 2013-09-07 17:05 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f47f9f622d9
7188657: There should be a way to reorder the JSSE ciphers
Reviewed-by: weijun, wetmore
! src/share/classes/javax/net/ssl/SSLParameters.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
+ test/sun/security/ssl/javax/net/ssl/SSLParameters/UseCipherSuitesOrder.java
From vicente.romero at oracle.com Sun Sep 8 03:55:38 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sun, 08 Sep 2013 10:55:38 +0000
Subject: hg: jdk8/tl/langtools: 8024398: javac,
compiler crashes with try with empty body
Message-ID: <20130908105552.66ADD62668@hg.openjdk.java.net>
Changeset: 2de3750d65a5
Author: vromero
Date: 2013-09-08 11:54 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2de3750d65a5
8024398: javac, compiler crashes with try with empty body
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T8024398/NPETryTest.java
From headius at headius.com Sun Sep 8 07:28:36 2013
From: headius at headius.com (Charles Oliver Nutter)
Date: Sun, 8 Sep 2013 09:28:36 -0500
Subject: DTrace on BSD, future support
In-Reply-To: <1183444067.8786662.1378524162044.JavaMail.root@redhat.com>
References:
<1183444067.8786662.1378524162044.JavaMail.root@redhat.com>
Message-ID:
On Fri, Sep 6, 2013 at 10:22 PM, Andrew Hughes wrote:
> Linux doesn't use DTrace. It uses SystemTap.
>
> CCing Mark Wielaard who added this support:
>
> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71
Ok, then I imagine the Linux folks will not be as interested in
getting dtrace support added.
So... OS X/BSD folks? As I mentioned, simply copying the code over
from Solaris appeared to *almost* work. I'd love to see this get in,
and might even have time to hack at it...but if someone has a free
hour maybe they could assess how much work is required.
You all need more projects to work on, right?!
- Charlie
From mark at klomp.org Sun Sep 8 09:26:13 2013
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 8 Sep 2013 18:26:13 +0200
Subject: DTrace on BSD, future support
In-Reply-To: <1183444067.8786662.1378524162044.JavaMail.root@redhat.com>
References:
<1183444067.8786662.1378524162044.JavaMail.root@redhat.com>
Message-ID: <20130908162612.GA26174@toonder.wildebeest.org>
Hi,
Adding the systemtap list which has some smart people on it who
can probably help out.
Disclaimer: I have played a bit and hacked a bit on Systemtap
and as Andrew said I did make dtrace probes in hotspot work
nicely together with Systemtap a couple of years ago:
http://gnu.wildebeest.org/blog/mjw/2009/08/06/i-love-it-when-a-plan-comes-together-systemtap-meets-java/
But I never have used macosx and the few times I tried to use
Solaris/OpenIndiana dtrace it crashed my system. So I don't
really know much about dtrace itself. When I added the dtrace
SDT probe support on GNU/Linux I did ask for the hotspot/dtrace
testcases to make sure everything was working well. But these
testcases are apparently secret making it hard to make any
compatibility claims :{
On Fri, Sep 06, 2013 at 11:22:42PM -0400, Andrew Hughes wrote:
> > I'm working with a GSoC student adding dtrace probe support to JRuby,
> > and ran into the issue that user-defined dtrace probes only work on
> > Solaris. So I started poking around hotspot source and found that both
> > the linux and bsd JSDT sources are empty and return false for
> > isSupported. Only solaris has JSDT support.
> >
> Linux doesn't use DTrace. It uses SystemTap.
>
> CCing Mark Wielaard who added this support:
>
> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/c707a5af0d71
"added support" is a bit much for that simple hack. The support
was always there, all I did was tweak the Makefile a bit to get
it compiled in (yes, that simple patch took months to get accepted,
but that wasn't because the patch was deep or difficult).
On GNU/Linux sys/sdt.h probes are available to systemtap, gdb and perf
simply by recompiling the source with a recent enough GCC. The DTRACE
markers are source compatible, so with that simple tweak you can now
easily use them from any of the observability, debugging, tracing or
profiling tools on GNU/Linux that can read SDT probes in ELF files.
That is in general the case with any dtrace SDT probes. Just rebuild
the sources with /usr/include/sys/sdt.h installed (and maybe a
small configure check or define added) and tada!
> > So at this point I'm wondering a few things:
> >
> > * Is there any good reason why BSD (and Linux) support for JSDT has
> > not been ported or implemented?
> > * What is the current thought on the future of DTrace support in OpenJDK?
> >
> > Our steps going forward, if we want to support JRuby dtrace probes on
> > platforms other than Solaris, will be to either implement or coerce
> > someone into implementing BSD/Linux DTrace JSDT support in OpenJDK or
> > to use a third-party library and our own JNI bindings. I'd prefer to
> > just get it working in OpenJDK proper.
> >
> > Thoughts?
JSDT is a general framework for providing some tracing support in
hotspot/openjdk introduced with 1.7. One provider is based on dtrace
(solaris specific atm). I am not sure there is "official" documentation
for it. It openjdk specific and lives in the private package
com.sun.tracing.*.
One idea is to just implement a tracing provider through Byteman.
https://www.jboss.org/byteman That would give you a "pure java"
tracing factory, which might interface easier with JRuby.
As a bonus systemtap comes with some Byteman hooks to use Byteman
rewrite rules to make trace points visible as SDT probes in a
JNI library that can be observed by systemtap.
https://lukasberk.wordpress.com/2013/06/20/probing-java-methods-with-systemtap/
The JSDT DTraceProviderFactory makes use of a feature that is dtrace/kernel
specific. So it takes a bit more to implement it than just a recompile
as is the case with normal SDT markers. It opens a special file
/dev/dtrace/helper with which it does a secret handshake to tell dtrace
on solaris where the hotspot JIT created markers in the code and the
name it wants these probes points to have. This is communicated by
creating a fake SUNW_DOF ELF section that is specific to how dtrace
handles SDT probes.
There doesn't seem to be much documentation on these dtrace specific
special file helper and the SUNW_DOF ELF section. But the concept is
clear. For GNU/Linux we currently don't have such a registration service
for new SDT probes. So we should create one. Probably based on the
stapsdt NOTEs that the various tools already use to detect SDT probes.
I am not sure it needs to be a special linux kernel device or proc file.
Maybe it can be a generic daemon (using dbus to register and query
which probe providers are currently active maybe?). It just has to
make sure things are synchronized so tools won't place a probe at
a point that has been removed already. And we should make sure that
all tools (gdb, systemtap, perf) can query it and agree on the format.
The only issue I see is that the current uprobes support in the linux
kernel is inode/offset based, which might make it a little harder to
probe these none-file-backed JIT code pages (except for gdb of course
which doesn't use uprobes directly).
One idea would be to add support for such a new service to libusdt
https://github.com/chrisa/libusdt and reimplement the hotspot JSDT
provider in terms of libusdt to make everything magically work on
all systems. And as added bonus make these more dynamic SDT probes
also magically work everywhere by just a simple recompile like
normal (DTRACE) SDT probes.
Cheers,
Mark
From tim.bell at oracle.com Sun Sep 8 11:53:23 2013
From: tim.bell at oracle.com (Tim Bell)
Date: Sun, 08 Sep 2013 11:53:23 -0700
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To:
References: <522A0712.90702@oracle.com> <522A2B1F.7010803@oracle.com>
<522A3873.1090309@oracle.com>
Message-ID: <522CC7A3.3020303@oracle.com>
Kumar - the makefile changes look good to me.
Tim
On 09/ 7/13 03:50 AM, Staffan Larsen wrote:
> This is a welcome change. I've looked at the serviceability test and the changes look good except:
>
> test/demo/jvmti/DemoRun.java
> test/sun/tools/jhat/HatRun.java
> - Looks like there are still some -d64 remnants that I wasn't expecting.
>
> Thanks,
> /Staffan
>
> On 6 sep 2013, at 22:17, Kumar Srinivasan wrote:
>
>> On 9/6/2013 12:21 PM, Alan Bateman wrote:
>>> On 06/09/2013 17:47, Kumar Srinivasan wrote:
>>>> Hello,
>>>>
>>>> Please review the changes to remove Solaris 32-bit binaries from JDK8 distros,
>>>> at this time the dual mode support in the launcher is being disabled.
>>>>
>>>> Message regarding this:
>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>>
>>>> The jdk changes are here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>
>>>> The top forest changes are here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>> I haven't studied the changes yet but I see you've updated test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh. I don't think you need the changes at L42-48, instead you can just "hg rm" the 32-bit libraries that are in test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib.
>> Will do, I was wondering about those libraries.
>>
>>> You might want to bring the changes to serviceability-dev because of the change to the JDI launching connector and the JDI tests.
>> cc'ed.
>>
>> Thanks
>>
>> Kumar
>>
>>> -Alan.
>>>
>>>
From david.holmes at oracle.com Sun Sep 8 19:18:08 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Sep 2013 12:18:08 +1000
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522A0712.90702@oracle.com>
References: <522A0712.90702@oracle.com>
Message-ID: <522D2FE0.6030105@oracle.com>
Hi Kumar,
A few minor comments ...
src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
Seems to me this is all dead now:
199 /*
200 * A wrinkle in the environment:
201 * 64-bit executables are stored under
$JAVA_HOME/bin/os_arch
202 * 32-bit executables are stored under $JAVA_HOME/bin
203 */
204 String os_arch = System.getProperty("os.arch");
os_arch is no longer used and the comment no longer applicable.
---
src/solaris/bin/java_md_solinux.c
This seems to force DUAL_MODE off regardless of what the user may set it to:
#ifdef __solaris__
! # ifdef DUAL_MODE
! # undef DUAL_MODE
! # endif
why doesn't it just not define DUAL_MODE?
---
test/demo/jvmti/DemoRun.java
test/sun/tools/jhat/HatRun.java
It isn't clear to me why you need to retain the d64 variable at all.
---
test/tools/launcher/ExecutionEnvironment.java
typo: appopriate
Thanks,
David
----
On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review the changes to remove Solaris 32-bit binaries from JDK8
> distros,
> at this time the dual mode support in the launcher is being disabled.
>
> Message regarding this:
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>
> The jdk changes are here:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>
> The top forest changes are here:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>
>
> Thanks
> Kumar
>
>
From david.holmes at oracle.com Sun Sep 8 19:34:57 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Sep 2013 12:34:57 +1000
Subject: Project to improve hs_err files
In-Reply-To:
References:
Message-ID: <522D33D1.6040808@oracle.com>
Hi Mattis,
There are some interesting ideas here and generally the more crash
information available the better. That said there are trade-offs in
determining what information should be in a crash report versus
logging/tracing output versus what should be left for post-mortem crash
dump analysis.
There are limits on what you can do in the crash reporter due to the
fact that you are executing in the context of a signal handler (and so
you should only be using async-signal-safe library routines and VM
functionality - a rule we already flout but usually get away with it).
One way around this would be to have a dedicated crash reporter thread
that is sitting on a semaphore wait (semaphores are async-signal safe)
which is woken by the crashing thread after the info specific to the
crashing thread (stack etc) has been recorded.
That said, the other limitation is that the process just crashed and you
have no idea what memory corruption has occurred - so the more you try
to do the more likely you will hit a secondary problem. Which implies
ensuring we output data as soon as possible just in case we totally
abort trying to get the next piece.
Cheers,
David
On 6/09/2013 9:32 PM, Mattis Castegren wrote:
> Hi (re-sending mail after joining the mailing lists, sorry if you get
> this mail twice)
>
> My name is Mattis and I work with the JVM sustaining engineering team at
> Oracle. I am starting up a project to improve the data we get in the
> hs_err files when the JVM crashes. I have filed a JEP, but it has not
> yet been approved. See my attachment for the initial draft including
> motivation and scope. The main goal is not to completely solve new bugs
> by just using an hs_err file, but to help users, support and development
> to debug their problems, find duplicates of fixed bugs or application
> errors. It is also to provide more information that can be helpful when
> doing core file debugging on new issues.
>
> The first step in this project is to gather suggestions of data that
> could help us when we see crashes. I am talking to the rest of the
> sustaining engineering team and also to the Java support team, but I
> also wanted to ask if anyone on these aliases have any thoughts on what
> data would help when we get an hs_err file. I?m looking for both big and
> small suggestions. Deciding if the suggestions are feasible or not can
> be discussed later.
>
> Suggestions so far:
>
> * Bigger changes
>
> - Re-structure hs_err file to put more important data first, maybe
> include a summary header. End users can?t be expected to read through
> the entire hs_err file. If we can put important hints of what went wrong
> at the top, that could save a lot of time. Also, many web tools truncate
> hs_err files, so we may never see the end of the files. This would also
> help us to faster triage incoming incidents
>
> - Look at context sensitive data. If we crash when compiling a method,
> what additional data could we provide. Can we provide anything when
> crashing in GC, or when running interpreted code?
>
> - Could we verify data structures? If we could list that some GC table
> had been corrupted, that could give a hint at the problem as well as
> help with finding duplicates and known issues
>
> - Suggest workarounds/first debug steps. Sometimes we immediately know
> what the first debug step is. If we crash when running a compiled
> method, try to disable compilation of that method. If we crash after
> several OOMs, try increasing the Java heap or lower heap usage. If we
> could print these first steps, this could lead to bug filers providing
> more data when they file a bug. We could also highlight "dangerous"
> options, like -Xverify:none
>
> * Additional Data
>
> - The GC Strategy used
>
> - The classpath variable
>
> - Have we seen any OutOfMemoryErrors, StackOverflowErrors or C Heap
> allocation fails?
>
> - Include Hypervisor information. If we run on Xen or VMWare, that is
> very interesting data
>
> - Heap usage and permgen usage (JDK7) after the last full GC. If the
> heap is 99% full, that is a good hint that we might have run into a
> corner case in OOM handling for example
>
> - Write the names of the last exceptions thrown. We currently list the
> addresses of the last exceptions. Giving the type instead would be very
> good. Did we crash after 10 StackOverflowErrors? That?s a good hint of
> what went wrong
>
> - Make the GC Heap History more easy to read. It?s a great feature, but
> it is somewhat hard to read if an event is a full GC or a YC etc.
>
> - Assembler instructions in dump files. Right now, we print the code
> around the IP in hex format. This isn?t very helpful. If we could get
> the crashing instructions as assembler instead, that would help a lot
>
> - Growing and shrinking of heap. We have seen a few issues when growing
> or shrinking the java heap. Saving the last few increases and decreases
> with a timestamp would help finding out if this could be an issue
>
> - Highlight if third party JNI libs have been used
>
> Please let me know if you have ideas of what information would make
> hs_err files more useful, and I will add them to my list.
>
> Kind Regards
>
> /Mattis
>
From weijun.wang at oracle.com Sun Sep 8 20:07:32 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 09 Sep 2013 03:07:32 +0000
Subject: hg: jdk8/tl/jdk: 8024046: Test sun/security/krb5/runNameEquals.sh
failed on 7u45 Embedded linux-ppc*
Message-ID: <20130909030758.71F4E62673@hg.openjdk.java.net>
Changeset: 6bfabb71ae1e
Author: weijun
Date: 2013-09-09 11:08 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bfabb71ae1e
8024046: Test sun/security/krb5/runNameEquals.sh failed on 7u45 Embedded linux-ppc*
Reviewed-by: xuelei
! test/sun/security/krb5/runNameEquals.sh
From kumar.x.srinivasan at oracle.com Sun Sep 8 20:09:57 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sun, 08 Sep 2013 20:09:57 -0700
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522D2FE0.6030105@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
Message-ID: <522D3C05.2000403@oracle.com>
Hi David, Staffan, Alan,
I have addressed all the issues pointed and some more I found while jprt
testing.
The updated webrev for jdk is here:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
and the delta webrev since the last review webrev is here:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
Thanks
Kumar
> Hi Kumar,
>
> A few minor comments ...
>
> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>
> Seems to me this is all dead now:
>
> 199 /*
> 200 * A wrinkle in the environment:
> 201 * 64-bit executables are stored under
> $JAVA_HOME/bin/os_arch
> 202 * 32-bit executables are stored under
> $JAVA_HOME/bin
> 203 */
> 204 String os_arch = System.getProperty("os.arch");
>
> os_arch is no longer used and the comment no longer applicable.
>
> ---
>
> src/solaris/bin/java_md_solinux.c
>
> This seems to force DUAL_MODE off regardless of what the user may set
> it to:
>
> #ifdef __solaris__
> ! # ifdef DUAL_MODE
> ! # undef DUAL_MODE
> ! # endif
>
> why doesn't it just not define DUAL_MODE?
>
> ---
>
> test/demo/jvmti/DemoRun.java
> test/sun/tools/jhat/HatRun.java
>
> It isn't clear to me why you need to retain the d64 variable at all.
>
> ---
>
> test/tools/launcher/ExecutionEnvironment.java
>
> typo: appopriate
>
>
> Thanks,
> David
> ----
>
>
>
> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>> distros,
>> at this time the dual mode support in the launcher is being disabled.
>>
>> Message regarding this:
>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>
>>
>> The jdk changes are here:
>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>
>> The top forest changes are here:
>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>
>>
>> Thanks
>> Kumar
>>
>>
From david.holmes at oracle.com Sun Sep 8 20:28:36 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Sep 2013 13:28:36 +1000
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522D3C05.2000403@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
<522D3C05.2000403@oracle.com>
Message-ID: <522D4064.70703@oracle.com>
Hi Kumar,
This is still dead code in
src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
String os_arch = System.getProperty("os.arch");
Also:
test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
I know this already exist but I thought binaries were disallowed in the
open repo?
Davud
On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
> Hi David, Staffan, Alan,
>
> I have addressed all the issues pointed and some more I found while jprt
> testing.
>
> The updated webrev for jdk is here:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>
> and the delta webrev since the last review webrev is here:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
>
>
> Thanks
> Kumar
>
>
>> Hi Kumar,
>>
>> A few minor comments ...
>>
>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>
>> Seems to me this is all dead now:
>>
>> 199 /*
>> 200 * A wrinkle in the environment:
>> 201 * 64-bit executables are stored under
>> $JAVA_HOME/bin/os_arch
>> 202 * 32-bit executables are stored under
>> $JAVA_HOME/bin
>> 203 */
>> 204 String os_arch = System.getProperty("os.arch");
>>
>> os_arch is no longer used and the comment no longer applicable.
>>
>> ---
>>
>> src/solaris/bin/java_md_solinux.c
>>
>> This seems to force DUAL_MODE off regardless of what the user may set
>> it to:
>>
>> #ifdef __solaris__
>> ! # ifdef DUAL_MODE
>> ! # undef DUAL_MODE
>> ! # endif
>>
>> why doesn't it just not define DUAL_MODE?
>>
>> ---
>>
>> test/demo/jvmti/DemoRun.java
>> test/sun/tools/jhat/HatRun.java
>>
>> It isn't clear to me why you need to retain the d64 variable at all.
>>
>> ---
>>
>> test/tools/launcher/ExecutionEnvironment.java
>>
>> typo: appopriate
>>
>>
>> Thanks,
>> David
>> ----
>>
>>
>>
>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>>> distros,
>>> at this time the dual mode support in the launcher is being disabled.
>>>
>>> Message regarding this:
>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>
>>>
>>> The jdk changes are here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>
>>> The top forest changes are here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>
>>>
>>> Thanks
>>> Kumar
>>>
>>>
>
From joel.franck at oracle.com Mon Sep 9 01:00:15 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Mon, 09 Sep 2013 08:00:15 +0000
Subject: hg: jdk8/tl/langtools: 8022260: Rename javac.code.Annotations to
javac.code.SymbolMetadata
Message-ID: <20130909080019.DF01F62678@hg.openjdk.java.net>
Changeset: 6cffcd15a17e
Author: jfranck
Date: 2013-09-09 09:58 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6cffcd15a17e
8022260: Rename javac.code.Annotations to javac.code.SymbolMetadata
Reviewed-by: jfranck, jjg
Contributed-by: Andreas Lundblad
- src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java
! test/tools/javac/lib/DPrinter.java
From Alan.Bateman at oracle.com Mon Sep 9 01:26:28 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 09 Sep 2013 09:26:28 +0100
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522D4064.70703@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
Message-ID: <522D8634.9090202@oracle.com>
On 09/09/2013 04:28, David Holmes wrote:
> :
>
> Also:
>
> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
>
>
> I know this already exist but I thought binaries were disallowed in
> the open repo?
Right, we don't want binary files checked in. The test needs to exercise
System.inheritedChannel and so requires launching the VM with
stdin/stdout/stderr connected to various types of networking sockets (to
emulate launching from inetd/xnetd). That's an awkward scenario to setup
so the test uses a custom launcher. We originally checked it in because
we couldn't assume there would be compilers installed on all machines
running the test. There's a bug open (JDK-6930061) to look at
alternatives. It's not blocker to Kumar's changes of course.
-Alan
From kevin.walls at oracle.com Mon Sep 9 04:35:11 2013
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Mon, 09 Sep 2013 11:35:11 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8023478: Test fails with HS crash in
GCNotifier.
Message-ID: <20130909113514.2905D6267A@hg.openjdk.java.net>
Changeset: 592520c14121
Author: kevinw
Date: 2013-09-09 10:01 +0100
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/592520c14121
8023478: Test fails with HS crash in GCNotifier.
Reviewed-by: sla
! src/share/vm/services/gcNotifier.cpp
From daniel.fuchs at oracle.com Mon Sep 9 05:23:17 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Mon, 09 Sep 2013 12:23:17 +0000
Subject: hg: jdk8/tl/jdk: 8023168: Cleanup LogManager class initialization and
LogManager/LoggerContext relationship; ...
Message-ID: <20130909122409.BD02C6267B@hg.openjdk.java.net>
Changeset: 4afdf10de648
Author: dfuchs
Date: 2013-09-09 13:59 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4afdf10de648
8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship
8021003: java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java fails intermittently
8019945: test/java/util/logging/LogManagerInstanceTest.java failing intermittently
Summary: This fix untangles the class initialization of Logger and LogManager, and also cleans up the relationship between LogManager, LoggerContext, and Logger, which were at the root cause of some intermittent test failures.
Reviewed-by: mchung, martin, plevart
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java
! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java
! test/java/util/logging/Logger/getGlobal/policy
! test/java/util/logging/ParentLoggersTest.java
! test/java/util/logging/TestAppletLoggerContext.java
From chris.hegarty at oracle.com Mon Sep 9 05:45:17 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 09 Sep 2013 12:45:17 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130909124541.538C16267D@hg.openjdk.java.net>
Changeset: 02064634bc88
Author: msheppar
Date: 2013-09-06 15:00 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02064634bc88
8023326: [TESTBUG] java/net/CookieHandler/LocalHostCookie.java misplaced try/finally
Summary: amended test to be more robust to set of potential exceptions thrown
Reviewed-by: chegar, khazra
! test/java/net/CookieHandler/LocalHostCookie.java
Changeset: 4fd7abaf0a5f
Author: msheppar
Date: 2013-09-09 13:44 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fd7abaf0a5f
8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address
Summary: amended src/windows/native/java/net/NetworkInterface_winXP.c to "properly" handle Ipv6IfIndex
Reviewed-by: chegar, dsamersoff
! src/windows/native/java/net/NetworkInterface_winXP.c
+ test/java/net/NetworkInterface/UniqueMacAddressesTest.java
From kumar.x.srinivasan at oracle.com Mon Sep 9 08:12:58 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 09 Sep 2013 08:12:58 -0700
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522D4064.70703@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
Message-ID: <522DE57A.1030907@oracle.com>
Hi David,
> Hi Kumar,
>
> This is still dead code in
> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>
> String os_arch = System.getProperty("os.arch");
Ah, I will take care of it. Thanks for spotting this.
>
> Also:
>
> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
>
>
> I know this already exist but I thought binaries were disallowed in
> the open repo?
Alan, are the nio changes acceptable? Let me know if you need more time
to go over all
the changes.
Kumar
>
> Davud
>
> On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
>> Hi David, Staffan, Alan,
>>
>> I have addressed all the issues pointed and some more I found while jprt
>> testing.
>>
>> The updated webrev for jdk is here:
>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>>
>> and the delta webrev since the last review webrev is here:
>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
>>
>>
>>
>> Thanks
>> Kumar
>>
>>
>>> Hi Kumar,
>>>
>>> A few minor comments ...
>>>
>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>
>>> Seems to me this is all dead now:
>>>
>>> 199 /*
>>> 200 * A wrinkle in the environment:
>>> 201 * 64-bit executables are stored under
>>> $JAVA_HOME/bin/os_arch
>>> 202 * 32-bit executables are stored under
>>> $JAVA_HOME/bin
>>> 203 */
>>> 204 String os_arch = System.getProperty("os.arch");
>>>
>>> os_arch is no longer used and the comment no longer applicable.
>>>
>>> ---
>>>
>>> src/solaris/bin/java_md_solinux.c
>>>
>>> This seems to force DUAL_MODE off regardless of what the user may set
>>> it to:
>>>
>>> #ifdef __solaris__
>>> ! # ifdef DUAL_MODE
>>> ! # undef DUAL_MODE
>>> ! # endif
>>>
>>> why doesn't it just not define DUAL_MODE?
>>>
>>> ---
>>>
>>> test/demo/jvmti/DemoRun.java
>>> test/sun/tools/jhat/HatRun.java
>>>
>>> It isn't clear to me why you need to retain the d64 variable at all.
>>>
>>> ---
>>>
>>> test/tools/launcher/ExecutionEnvironment.java
>>>
>>> typo: appopriate
>>>
>>>
>>> Thanks,
>>> David
>>> ----
>>>
>>>
>>>
>>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>>> Hello,
>>>>
>>>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>>>> distros,
>>>> at this time the dual mode support in the launcher is being disabled.
>>>>
>>>> Message regarding this:
>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>>
>>>>
>>>>
>>>> The jdk changes are here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>
>>>> The top forest changes are here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>>
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>
From Alan.Bateman at oracle.com Mon Sep 9 08:20:13 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 09 Sep 2013 16:20:13 +0100
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522DE57A.1030907@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
<522DE57A.1030907@oracle.com>
Message-ID: <522DE72D.3040605@oracle.com>
On 09/09/2013 16:12, Kumar Srinivasan wrote:
>
> Alan, are the nio changes acceptable? Let me know if you need more
> time to go over all
> the changes.
>
It looks fine (sorry I should have made that clearer). I skimmed over
the other tests too (the launcher tests in particular) and don't see any
other issues.
-Alan.
From vicente.romero at oracle.com Mon Sep 9 08:32:43 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Mon, 09 Sep 2013 15:32:43 +0000
Subject: hg: jdk8/tl/langtools: 8024154: Fix for 8016177: structural most
specific and stuckness breaks 6 langtools tests
Message-ID: <20130909153246.7040062685@hg.openjdk.java.net>
Changeset: a4b9a8859e58
Author: vromero
Date: 2013-09-09 16:32 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a4b9a8859e58
8024154: Fix for 8016177: structural most specific and stuckness breaks 6 langtools tests
Reviewed-by: jjg, jfranck
! test/tools/javac/lambda/MethodReference41.java
! test/tools/javac/lambda/MethodReference41.out
! test/tools/javac/lambda/MethodReference42.java
! test/tools/javac/lambda/MethodReference42.out
! test/tools/javac/lambda/MethodReference43.java
! test/tools/javac/lambda/MethodReference43.out
! test/tools/javac/lambda/MethodReference44.java
! test/tools/javac/lambda/MethodReference44.out
! test/tools/javac/lambda/MethodReference46.java
! test/tools/javac/lambda/MethodReference46.out
! test/tools/javac/lambda/MethodReference48.java
! test/tools/javac/lambda/MethodReference48.out
From jason.uh at oracle.com Mon Sep 9 10:53:39 2013
From: jason.uh at oracle.com (jason.uh at oracle.com)
Date: Mon, 09 Sep 2013 17:53:39 +0000
Subject: hg: jdk8/tl/jdk: 8024432: Fix doclint issues in java.security
Message-ID: <20130909175352.2A1E76268B@hg.openjdk.java.net>
Changeset: be0bcd6a904e
Author: juh
Date: 2013-09-09 10:52 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be0bcd6a904e
8024432: Fix doclint issues in java.security
Reviewed-by: darcy, mullan
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/security/AlgorithmParameters.java
! src/share/classes/java/security/AlgorithmParametersSpi.java
! src/share/classes/java/security/KeyFactory.java
! src/share/classes/java/security/KeyFactorySpi.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/Principal.java
! src/share/classes/java/security/cert/CertPathBuilderSpi.java
! src/share/classes/java/security/cert/CertPathValidatorSpi.java
! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java
! src/share/classes/java/security/interfaces/RSAPrivateCrtKey.java
! src/share/classes/java/security/interfaces/RSAPrivateKey.java
! src/share/classes/java/security/interfaces/RSAPublicKey.java
From sundararajan.athijegannathan at oracle.com Mon Sep 9 11:07:34 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 09 Sep 2013 18:07:34 +0000
Subject: hg: jdk8/tl/nashorn: 3 new changesets
Message-ID: <20130909180738.014156268C@hg.openjdk.java.net>
Changeset: 7ae169639485
Author: sundar
Date: 2013-09-05 21:17 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7ae169639485
8024255: When a keyword is used as object property name, the property can not be deleted
Reviewed-by: jlaskey, lagergren
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8024255.js
Changeset: c3b6ce7b74bf
Author: sundar
Date: 2013-09-09 20:10 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c3b6ce7b74bf
8024180: Incorrect handling of expression and parent scope in 'with' statements
Reviewed-by: jlaskey, hannesw
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/GlobalObject.java
! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java
! src/jdk/nashorn/internal/runtime/ScriptObject.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/WithObject.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
+ test/script/basic/8024180/global_var_delete.js
+ test/script/basic/8024180/global_var_delete.js.EXPECTED
+ test/script/basic/8024180/global_var_shadow.js
+ test/script/basic/8024180/global_var_shadow.js.EXPECTED
+ test/script/basic/8024180/scope_no_such_prop.js
+ test/script/basic/8024180/scope_no_such_prop.js.EXPECTED
+ test/script/basic/8024180/with_expr_prop_add.js
+ test/script/basic/8024180/with_expr_prop_add.js.EXPECTED
+ test/script/basic/8024180/with_expr_proto_prop_add.js
+ test/script/basic/8024180/with_expr_proto_prop_add.js.EXPECTED
+ test/script/basic/8024180/with_java_object.js
+ test/script/basic/8024180/with_java_object.js.EXPECTED
! test/src/jdk/nashorn/internal/runtime/ContextTest.java
Changeset: 1eca380a221f
Author: sundar
Date: 2013-09-09 20:16 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1eca380a221f
Merge
From dmitry.samersoff at oracle.com Mon Sep 9 13:16:10 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 10 Sep 2013 00:16:10 +0400
Subject: Project to improve hs_err files
In-Reply-To:
References:
Message-ID: <522E2C8A.3080506@oracle.com>
Mattis,
I see three problems here:
1. As David already mentioned we are in context of crash handler, so
increasing the number of calls we are doing, we increase the probability
to finally get nothing.
2. With too many information the hs_err file become unreadable and not
suitable for quick, pre-sustaining check on support side.
3. Crash is always a bad situation from security standpoint, so with too
many information customer might become reluctant to share it and we need
additional efforts to protect data.
***
So first thing I would like to see is some kind of staging. i.e. I would
prefer to write down minimal hs_err.log, similar to one we have in 1.5
and than attempt to write as much information as possible to a separate
file with an option to turn it off.
Also on my opinion it's good to have some industry standard monitoring
options (SNMP, syslog etc) available on hotspot level to be able to
report JVM crash sysadmin friendly manner.
-Dmitry
On 2013-09-06 15:32, Mattis Castegren wrote:
> Hi (re-sending mail after joining the mailing lists, sorry if you get
> this mail twice)
>
>
>
> My name is Mattis and I work with the JVM sustaining engineering team at
> Oracle. I am starting up a project to improve the data we get in the
> hs_err files when the JVM crashes. I have filed a JEP, but it has not
> yet been approved. See my attachment for the initial draft including
> motivation and scope. The main goal is not to completely solve new bugs
> by just using an hs_err file, but to help users, support and development
> to debug their problems, find duplicates of fixed bugs or application
> errors. It is also to provide more information that can be helpful when
> doing core file debugging on new issues.
>
>
>
> The first step in this project is to gather suggestions of data that
> could help us when we see crashes. I am talking to the rest of the
> sustaining engineering team and also to the Java support team, but I
> also wanted to ask if anyone on these aliases have any thoughts on what
> data would help when we get an hs_err file. I?m looking for both big and
> small suggestions. Deciding if the suggestions are feasible or not can
> be discussed later.
>
> Suggestions so far:
>
>
>
> * Bigger changes
>
> - Re-structure hs_err file to put more important data first, maybe
> include a summary header. End users can?t be expected to read through
> the entire hs_err file. If we can put important hints of what went wrong
> at the top, that could save a lot of time. Also, many web tools truncate
> hs_err files, so we may never see the end of the files. This would also
> help us to faster triage incoming incidents
>
> - Look at context sensitive data. If we crash when compiling a method,
> what additional data could we provide. Can we provide anything when
> crashing in GC, or when running interpreted code?
>
> - Could we verify data structures? If we could list that some GC table
> had been corrupted, that could give a hint at the problem as well as
> help with finding duplicates and known issues
>
> - Suggest workarounds/first debug steps. Sometimes we immediately know
> what the first debug step is. If we crash when running a compiled
> method, try to disable compilation of that method. If we crash after
> several OOMs, try increasing the Java heap or lower heap usage. If we
> could print these first steps, this could lead to bug filers providing
> more data when they file a bug. We could also highlight "dangerous"
> options, like -Xverify:none
>
>
>
> * Additional Data
>
> - The GC Strategy used
>
> - The classpath variable
>
> - Have we seen any OutOfMemoryErrors, StackOverflowErrors or C Heap
> allocation fails?
>
> - Include Hypervisor information. If we run on Xen or VMWare, that is
> very interesting data
>
> - Heap usage and permgen usage (JDK7) after the last full GC. If the
> heap is 99% full, that is a good hint that we might have run into a
> corner case in OOM handling for example
>
> - Write the names of the last exceptions thrown. We currently list the
> addresses of the last exceptions. Giving the type instead would be very
> good. Did we crash after 10 StackOverflowErrors? That?s a good hint of
> what went wrong
>
> - Make the GC Heap History more easy to read. It?s a great feature, but
> it is somewhat hard to read if an event is a full GC or a YC etc.
>
> - Assembler instructions in dump files. Right now, we print the code
> around the IP in hex format. This isn?t very helpful. If we could get
> the crashing instructions as assembler instead, that would help a lot
>
> - Growing and shrinking of heap. We have seen a few issues when growing
> or shrinking the java heap. Saving the last few increases and decreases
> with a timestamp would help finding out if this could be an issue
>
> - Highlight if third party JNI libs have been used
>
>
>
> Please let me know if you have ideas of what information would make
> hs_err files more useful, and I will add them to my list.
>
>
>
> Kind Regards
>
> /Mattis
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
From eric.mccorkle at oracle.com Mon Sep 9 13:28:22 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Mon, 09 Sep 2013 20:28:22 +0000
Subject: hg: jdk8/tl/langtools: 8022322: Reject default and static methods in
annotation
Message-ID: <20130909202825.ACA2762691@hg.openjdk.java.net>
Changeset: f4efd6ef6e80
Author: emc
Date: 2013-09-09 16:26 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4efd6ef6e80
8022322: Reject default and static methods in annotation
Summary: Causes javac to reject static and default method declarations inside an annotation
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/annotations/neg/NoDefault.java
+ test/tools/javac/annotations/neg/NoDefault.out
+ test/tools/javac/annotations/neg/NoDefaultAbstract.java
+ test/tools/javac/annotations/neg/NoDefaultAbstract.out
+ test/tools/javac/annotations/neg/NoStatic.java
+ test/tools/javac/annotations/neg/NoStatic.out
+ test/tools/javac/annotations/neg/NoStaticAbstract.java
+ test/tools/javac/annotations/neg/NoStaticAbstract.out
From eric.mccorkle at oracle.com Mon Sep 9 14:12:18 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Mon, 09 Sep 2013 21:12:18 +0000
Subject: hg: jdk8/tl/langtools: 8015322: Javac template test framework
Message-ID: <20130909211221.965C962696@hg.openjdk.java.net>
Changeset: 67c5110c60fe
Author: emc
Date: 2013-09-09 17:11 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67c5110c60fe
8015322: Javac template test framework
Summary: Putback of the javac template test framework from the Lambda repository
Reviewed-by: jjg
Contributed-by: brian.goetz at oracle.com
! README
+ test/lib/combo/TEST.properties
+ test/lib/combo/tools/javac/combo/Diagnostics.java
+ test/lib/combo/tools/javac/combo/JavacTemplateTestBase.java
+ test/lib/combo/tools/javac/combo/Template.java
+ test/lib/combo/tools/javac/combo/TemplateTest.java
+ test/tools/javac/lambda/bridge/template_tests/BridgeMethodTestCase.java
+ test/tools/javac/lambda/bridge/template_tests/BridgeMethodsTemplateTest.java
+ test/tools/javac/lambda/bridge/template_tests/TEST.properties
From harold.seigel at oracle.com Mon Sep 9 13:40:38 2013
From: harold.seigel at oracle.com (harold.seigel at oracle.com)
Date: Mon, 09 Sep 2013 20:40:38 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8023167: JVM allows duplicate
Runtime[In]VisibleTypeAnnotations attributes in
ClassFile/field_info/method_info structures
Message-ID: <20130909204047.8E79562692@hg.openjdk.java.net>
Changeset: b6767a18b379
Author: hseigel
Date: 2013-09-09 14:44 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b6767a18b379
8023167: JVM allows duplicate Runtime[In]VisibleTypeAnnotations attributes in ClassFile/field_info/method_info structures
Summary: Add checks for duplicates and issue errors when detected.
Reviewed-by: coleenp, zgu
! src/share/vm/classfile/classFileParser.cpp
From stuart.marks at oracle.com Mon Sep 9 15:29:50 2013
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Mon, 09 Sep 2013 22:29:50 +0000
Subject: hg: jdk8/tl/jdk: 8023447: change specification to allow RMI
activation to be optional
Message-ID: <20130909223015.4CD136269F@hg.openjdk.java.net>
Changeset: 6731ea9123f2
Author: smarks
Date: 2013-09-09 14:11 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6731ea9123f2
8023447: change specification to allow RMI activation to be optional
Reviewed-by: darcy, alanb, olagneau
! src/share/classes/java/rmi/activation/Activatable.java
! src/share/classes/java/rmi/activation/ActivationDesc.java
! src/share/classes/java/rmi/activation/ActivationGroup.java
! src/share/classes/java/rmi/activation/ActivationGroupID.java
! src/share/classes/java/rmi/activation/ActivationID.java
! src/share/classes/java/rmi/activation/package.html
From jonathan.gibbons at oracle.com Mon Sep 9 17:44:09 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 10 Sep 2013 00:44:09 +0000
Subject: hg: jdk8/tl/langtools: 8019521: Enhanced rethrow disabled in lambdas
Message-ID: <20130910004412.7EC8C626A6@hg.openjdk.java.net>
Changeset: 77d395862700
Author: jlahoda
Date: 2013-09-09 23:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/77d395862700
8019521: Enhanced rethrow disabled in lambdas
Summary: Fixing effectively final detection inside lambdas, small cleanup related to thrown types detection in lambdas
Reviewed-by: mcimadamore, jjg
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/lambda/EffectivelyFinalThrows.java
From jonathan.gibbons at oracle.com Mon Sep 9 17:37:03 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 10 Sep 2013 00:37:03 +0000
Subject: hg: jdk8/tl/langtools: 8006972: jtreg test fails:
test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
Message-ID: <20130910003707.22141626A2@hg.openjdk.java.net>
Changeset: 7439356a7dc5
Author: jjg
Date: 2013-09-09 17:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7439356a7dc5
8006972: jtreg test fails: test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
Reviewed-by: darcy
! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java
! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref
From xuelei.fan at oracle.com Mon Sep 9 19:08:04 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Tue, 10 Sep 2013 02:08:04 +0000
Subject: hg: jdk8/tl/jdk: 8024444: Change to use othervm mode of tests in
SSLEngineImpl
Message-ID: <20130910020831.9BF82626AA@hg.openjdk.java.net>
Changeset: f80b8af9c218
Author: xuelei
Date: 2013-09-09 19:07 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f80b8af9c218
8024444: Change to use othervm mode of tests in SSLEngineImpl
Reviewed-by: mullan
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseEngineException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseInboundException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/CloseStart.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EmptyExtensionData.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/EngineEnforceUseClientMode.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java
From alan.bateman at oracle.com Tue Sep 10 02:46:21 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 10 Sep 2013 09:46:21 +0000
Subject: hg: jdk8/tl/jdk: 8023878: (fs) TEST_BUG
java/nio/file/WatchService/SensitivityModifier.java fails
intermittently
Message-ID: <20130910094719.96C3E626B3@hg.openjdk.java.net>
Changeset: 909aced59bef
Author: alanb
Date: 2013-09-10 10:42 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/909aced59bef
8023878: (fs) TEST_BUG java/nio/file/WatchService/SensitivityModifier.java fails intermittently
Reviewed-by: alanb
Contributed-by: yiming.wang at oracle.com
! test/java/nio/file/WatchService/SensitivityModifier.java
From staffan.larsen at oracle.com Tue Sep 10 04:03:07 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 10 Sep 2013 14:03:07 +0300
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522DE57A.1030907@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
<522DE57A.1030907@oracle.com>
Message-ID: <9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
In SunCommandLineLauncher.java:
198 if (home.length() > 0) {
199 String os_arch = System.getProperty("os.arch");
200 if ("SunOS".equals(System.getProperty("os.name"))) {
201 exePath = home + File.separator + "bin" + File.separator + exe;
202 }
203 } else {
204 exePath = exe;
205 }
I think this should be:
198 if (home.length() > 0) {
201 exePath = home + File.separator + "bin" + File.separator + exe;
203 } else {
204 exePath = exe;
205 }
Thanks,
/Staffan
On 9 sep 2013, at 18:12, Kumar Srinivasan wrote:
> Hi David,
>
>> Hi Kumar,
>>
>> This is still dead code in src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>
>> String os_arch = System.getProperty("os.arch");
>
> Ah, I will take care of it. Thanks for spotting this.
>>
>> Also:
>>
>> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
>>
>> I know this already exist but I thought binaries were disallowed in the open repo?
>
> Alan, are the nio changes acceptable? Let me know if you need more time to go over all
> the changes.
>
> Kumar
>
>>
>> Davud
>>
>> On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
>>> Hi David, Staffan, Alan,
>>>
>>> I have addressed all the issues pointed and some more I found while jprt
>>> testing.
>>>
>>> The updated webrev for jdk is here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>>>
>>> and the delta webrev since the last review webrev is here:
>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
>>>
>>>
>>> Thanks
>>> Kumar
>>>
>>>
>>>> Hi Kumar,
>>>>
>>>> A few minor comments ...
>>>>
>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>>
>>>> Seems to me this is all dead now:
>>>>
>>>> 199 /*
>>>> 200 * A wrinkle in the environment:
>>>> 201 * 64-bit executables are stored under
>>>> $JAVA_HOME/bin/os_arch
>>>> 202 * 32-bit executables are stored under
>>>> $JAVA_HOME/bin
>>>> 203 */
>>>> 204 String os_arch = System.getProperty("os.arch");
>>>>
>>>> os_arch is no longer used and the comment no longer applicable.
>>>>
>>>> ---
>>>>
>>>> src/solaris/bin/java_md_solinux.c
>>>>
>>>> This seems to force DUAL_MODE off regardless of what the user may set
>>>> it to:
>>>>
>>>> #ifdef __solaris__
>>>> ! # ifdef DUAL_MODE
>>>> ! # undef DUAL_MODE
>>>> ! # endif
>>>>
>>>> why doesn't it just not define DUAL_MODE?
>>>>
>>>> ---
>>>>
>>>> test/demo/jvmti/DemoRun.java
>>>> test/sun/tools/jhat/HatRun.java
>>>>
>>>> It isn't clear to me why you need to retain the d64 variable at all.
>>>>
>>>> ---
>>>>
>>>> test/tools/launcher/ExecutionEnvironment.java
>>>>
>>>> typo: appopriate
>>>>
>>>>
>>>> Thanks,
>>>> David
>>>> ----
>>>>
>>>>
>>>>
>>>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>>>>> distros,
>>>>> at this time the dual mode support in the launcher is being disabled.
>>>>>
>>>>> Message regarding this:
>>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>>>
>>>>>
>>>>> The jdk changes are here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>>
>>>>> The top forest changes are here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>>>
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>
>>>
>
From joel.franck at oracle.com Tue Sep 10 04:55:22 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Tue, 10 Sep 2013 11:55:22 +0000
Subject: hg: jdk8/tl/langtools: 8005222: Fixed bugs should have tests with
bugid in @bug tag
Message-ID: <20130910115526.1BEE4626B8@hg.openjdk.java.net>
Changeset: bb7271e64ef6
Author: jfranck
Date: 2013-09-10 13:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb7271e64ef6
8005222: Fixed bugs should have tests with bugid in @bug tag
Reviewed-by: jfranck, jjg
Contributed-by: Andreas Lundblad
! test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java
! test/tools/javac/defaultMethods/Neg01.java
! test/tools/javac/defaultMethods/Neg02.java
! test/tools/javac/defaultMethods/Neg03.java
! test/tools/javac/defaultMethods/Neg04.java
! test/tools/javac/defaultMethods/Neg05.java
! test/tools/javac/defaultMethods/Neg06.java
! test/tools/javac/defaultMethods/Neg07.java
! test/tools/javac/defaultMethods/Neg08.java
! test/tools/javac/defaultMethods/Neg09.java
! test/tools/javac/defaultMethods/Neg10.java
! test/tools/javac/defaultMethods/Neg11.java
! test/tools/javac/defaultMethods/Neg12.java
! test/tools/javac/defaultMethods/Neg13.java
! test/tools/javac/defaultMethods/Neg14.java
! test/tools/javac/defaultMethods/Neg15.java
! test/tools/javac/defaultMethods/Neg16.java
! test/tools/javac/defaultMethods/Pos01.java
! test/tools/javac/defaultMethods/Pos02.java
! test/tools/javac/defaultMethods/Pos04.java
! test/tools/javac/defaultMethods/Pos05.java
! test/tools/javac/defaultMethods/Pos06.java
! test/tools/javac/defaultMethods/Pos07.java
! test/tools/javac/defaultMethods/Pos08.java
! test/tools/javac/defaultMethods/Pos10.java
! test/tools/javac/defaultMethods/Pos11.java
! test/tools/javac/defaultMethods/Pos12.java
! test/tools/javac/defaultMethods/Pos13.java
! test/tools/javac/defaultMethods/Pos14.java
! test/tools/javac/defaultMethods/Pos15.java
! test/tools/javac/defaultMethods/Pos16.java
! test/tools/javac/defaultMethods/TestDefaultBody.java
! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java
! test/tools/javac/defaultMethods/crossCompile/CrossCompile.java
! test/tools/javac/defaultMethods/separate/Separate.java
! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java
! test/tools/javac/lambda/EffectivelyFinalTest.java
From mattis.castegren at oracle.com Tue Sep 10 06:32:08 2013
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Tue, 10 Sep 2013 06:32:08 -0700 (PDT)
Subject: Project to improve hs_err files
In-Reply-To: <522E2C8A.3080506@oracle.com>
References:
<522E2C8A.3080506@oracle.com>
Message-ID: <625c3198-2b76-4f62-a324-64eb7a35f62c@default>
Hi
I don't think these problems will be critical:
"1. As David already mentioned we are in context of crash handler, so
increasing the number of calls we are doing, we increase the probability
to finally get nothing."
Right now I am gathering feedback on what information would really help different teams. I am not investigating how feasible the changes are, that will be the next step. Some things, like printing the number of OOM Errors would be a very easy implementation that should not be a problem in a crash handler. Other things, like printing assembler around the PC may be too risky. Some of these suggestions may even have to be solved with a script you can run on the file afterwards, though that will make it a lot harder to do quick triaging, and will also make it a lot harder for end users to use. As David pointed out, there may be ways to improve stability, for example by having a crash dumper thread on standby.
"2. With too many information the hs_err file become unreadable and not
suitable for quick, pre-sustaining check on support side."
Yes, that is why I ask for feedback on what information would be really useful, not only for developers but for support and sustaining. Today, hs_err files start by dumping registers and stacks as raw hex data, while information that Support really needs like system information and VM Arguments is hidden in the middle of the file. We are currently not at a place where the hs_err files are easily readable. That is why my main focus is to ask support what they want so that we can make the hs_err files easier for quick, pre-sustaining (and even pre-support) checks. This project actually aims to solve this problem, not add to it.
"3. Crash is always a bad situation from security standpoint, so with too
many information customer might become reluctant to share it and we need
additional efforts to protect data."
Considering that we will need core files for most debugging anyway, I don't think this will be an issue. None of the current suggestions for improvements contain customer sensitive information. Once we do the implementation, this will probably be split into several enhancement requests. Securing sensitive data can be one thing to look at when we work these enhancements, but I don't think it makes sense to remove important information just because the customer MAY not want to share paths, JVM flags, etc. Since this is in clear text, they can make a pass themselves and remove things if they really want.
Kind Regards
/Mattis
-----Original Message-----
From: Dmitry Samersoff
Sent: den 9 september 2013 22:16
To: Mattis Castegren
Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: Project to improve hs_err files
Mattis,
I see three problems here:
1. As David already mentioned we are in context of crash handler, so
increasing the number of calls we are doing, we increase the probability
to finally get nothing.
2. With too many information the hs_err file become unreadable and not
suitable for quick, pre-sustaining check on support side.
3. Crash is always a bad situation from security standpoint, so with too
many information customer might become reluctant to share it and we need
additional efforts to protect data.
***
So first thing I would like to see is some kind of staging. i.e. I would
prefer to write down minimal hs_err.log, similar to one we have in 1.5
and than attempt to write as much information as possible to a separate
file with an option to turn it off.
Also on my opinion it's good to have some industry standard monitoring
options (SNMP, syslog etc) available on hotspot level to be able to
report JVM crash sysadmin friendly manner.
-Dmitry
On 2013-09-06 15:32, Mattis Castegren wrote:
> Hi (re-sending mail after joining the mailing lists, sorry if you get
> this mail twice)
>
>
>
> My name is Mattis and I work with the JVM sustaining engineering team at
> Oracle. I am starting up a project to improve the data we get in the
> hs_err files when the JVM crashes. I have filed a JEP, but it has not
> yet been approved. See my attachment for the initial draft including
> motivation and scope. The main goal is not to completely solve new bugs
> by just using an hs_err file, but to help users, support and development
> to debug their problems, find duplicates of fixed bugs or application
> errors. It is also to provide more information that can be helpful when
> doing core file debugging on new issues.
>
>
>
> The first step in this project is to gather suggestions of data that
> could help us when we see crashes. I am talking to the rest of the
> sustaining engineering team and also to the Java support team, but I
> also wanted to ask if anyone on these aliases have any thoughts on what
> data would help when we get an hs_err file. I'm looking for both big and
> small suggestions. Deciding if the suggestions are feasible or not can
> be discussed later.
>
> Suggestions so far:
>
>
>
> * Bigger changes
>
> - Re-structure hs_err file to put more important data first, maybe
> include a summary header. End users can't be expected to read through
> the entire hs_err file. If we can put important hints of what went wrong
> at the top, that could save a lot of time. Also, many web tools truncate
> hs_err files, so we may never see the end of the files. This would also
> help us to faster triage incoming incidents
>
> - Look at context sensitive data. If we crash when compiling a method,
> what additional data could we provide. Can we provide anything when
> crashing in GC, or when running interpreted code?
>
> - Could we verify data structures? If we could list that some GC table
> had been corrupted, that could give a hint at the problem as well as
> help with finding duplicates and known issues
>
> - Suggest workarounds/first debug steps. Sometimes we immediately know
> what the first debug step is. If we crash when running a compiled
> method, try to disable compilation of that method. If we crash after
> several OOMs, try increasing the Java heap or lower heap usage. If we
> could print these first steps, this could lead to bug filers providing
> more data when they file a bug. We could also highlight "dangerous"
> options, like -Xverify:none
>
>
>
> * Additional Data
>
> - The GC Strategy used
>
> - The classpath variable
>
> - Have we seen any OutOfMemoryErrors, StackOverflowErrors or C Heap
> allocation fails?
>
> - Include Hypervisor information. If we run on Xen or VMWare, that is
> very interesting data
>
> - Heap usage and permgen usage (JDK7) after the last full GC. If the
> heap is 99% full, that is a good hint that we might have run into a
> corner case in OOM handling for example
>
> - Write the names of the last exceptions thrown. We currently list the
> addresses of the last exceptions. Giving the type instead would be very
> good. Did we crash after 10 StackOverflowErrors? That's a good hint of
> what went wrong
>
> - Make the GC Heap History more easy to read. It's a great feature, but
> it is somewhat hard to read if an event is a full GC or a YC etc.
>
> - Assembler instructions in dump files. Right now, we print the code
> around the IP in hex format. This isn't very helpful. If we could get
> the crashing instructions as assembler instead, that would help a lot
>
> - Growing and shrinking of heap. We have seen a few issues when growing
> or shrinking the java heap. Saving the last few increases and decreases
> with a timestamp would help finding out if this could be an issue
>
> - Highlight if third party JNI libs have been used
>
>
>
> Please let me know if you have ideas of what information would make
> hs_err files more useful, and I will add them to my list.
>
>
>
> Kind Regards
>
> /Mattis
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
From shanliang.jiang at oracle.com Tue Sep 10 07:15:33 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Tue, 10 Sep 2013 16:15:33 +0200
Subject: jmx-dev Codereview request: 8023529
OpenMBeanInfoSupport.equals/hashCode throw NPE
In-Reply-To: <522863F5.20709@oracle.com>
References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com>
Message-ID: <522F2985.80207@oracle.com>
Jaroslav Bachorik wrote:
> On 09/05/2013 10:37 AM, shanliang wrote:
>
>> I have added 2 tasts to make sure that call
>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE
>> The unit tests and JCK tests are passed.
>>
>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023529
>>
>
> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>
> * rename the "obj1", "obj2" parameters to something more explicit - eg.
> "referenceInfo" and "nullValueinfo" or something similar
>
No reference object here, the test has to call both obj1.equals and
obj2.equals.
> * when testing "obj.equals(null);" the messages should not contain
> reference to the parameter since you are not, in fact, testing the null
> value of the given parameter but rather a null info object
> * the message "got NPE if null paramer" should read "got NPE for null
> paramter"
>
Right, should be "a null object" instead of "a null parameter."
> * "Thread.sleep(100);" on line 153 is necessary?
>
It is not necessary for the test, removed now.
> -----
>
> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
>
> * the message "got NPE if null paramer" should read "got NPE for null
> paramter"
> * "Thread.sleep(100);" on line 143 is necessary?
>
Thanks for the review, here is the new version:
http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
Shanliang
>
> -JB-
>
>
>> Thanks,
>>
>> Shanliang
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130910/c2ab9f86/attachment.html
From vicente.romero at oracle.com Tue Sep 10 08:58:48 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Tue, 10 Sep 2013 15:58:48 +0000
Subject: hg: jdk8/tl/langtools: 8024414: javac,
should facilitate the use of the bootstrap compiler for debugging
Message-ID: <20130910155851.CE352626C5@hg.openjdk.java.net>
Changeset: d87f017ec217
Author: mcimadamore
Date: 2013-09-10 16:47 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d87f017ec217
8024414: javac, should facilitate the use of the bootstrap compiler for debugging
Reviewed-by: jjg
! make/netbeans/langtools/build.xml
! make/tools/anttasks/SelectToolTask.java
From kumar.x.srinivasan at oracle.com Tue Sep 10 15:00:41 2013
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 10 Sep 2013 15:00:41 -0700
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
<522DE57A.1030907@oracle.com>
<9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
Message-ID: <522F9689.4090809@oracle.com>
Here are the updated changes:
The build changes are here:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/
the delta changes since last reviewed:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html
The jdk changes are here:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/
The delta changes since last reviewed:
http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/webrev.delta/index.html
Thanks
Kumar
> In SunCommandLineLauncher.java:
>
> 198 if (home.length() > 0) {
> 199 String os_arch = System.getProperty("os.arch");
> 200 if ("SunOS".equals(System.getProperty("os.name"))) {
> 201 exePath = home + File.separator + "bin" + File.separator + exe;
> 202 }
> 203 } else {
> 204 exePath = exe;
> 205 }
>
> I think this should be:
>
> 198 if (home.length() > 0) {
> 201 exePath = home + File.separator + "bin" + File.separator + exe;
> 203 } else {
> 204 exePath = exe;
> 205 }
>
>
> Thanks,
> /Staffan
>
>
> On 9 sep 2013, at 18:12, Kumar Srinivasan wrote:
>
>> Hi David,
>>
>>> Hi Kumar,
>>>
>>> This is still dead code in src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>
>>> String os_arch = System.getProperty("os.arch");
>> Ah, I will take care of it. Thanks for spotting this.
>>> Also:
>>>
>>> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
>>>
>>> I know this already exist but I thought binaries were disallowed in the open repo?
>> Alan, are the nio changes acceptable? Let me know if you need more time to go over all
>> the changes.
>>
>> Kumar
>>
>>> Davud
>>>
>>> On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
>>>> Hi David, Staffan, Alan,
>>>>
>>>> I have addressed all the issues pointed and some more I found while jprt
>>>> testing.
>>>>
>>>> The updated webrev for jdk is here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>>>>
>>>> and the delta webrev since the last review webrev is here:
>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
>>>>
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>>>> Hi Kumar,
>>>>>
>>>>> A few minor comments ...
>>>>>
>>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>>>
>>>>> Seems to me this is all dead now:
>>>>>
>>>>> 199 /*
>>>>> 200 * A wrinkle in the environment:
>>>>> 201 * 64-bit executables are stored under
>>>>> $JAVA_HOME/bin/os_arch
>>>>> 202 * 32-bit executables are stored under
>>>>> $JAVA_HOME/bin
>>>>> 203 */
>>>>> 204 String os_arch = System.getProperty("os.arch");
>>>>>
>>>>> os_arch is no longer used and the comment no longer applicable.
>>>>>
>>>>> ---
>>>>>
>>>>> src/solaris/bin/java_md_solinux.c
>>>>>
>>>>> This seems to force DUAL_MODE off regardless of what the user may set
>>>>> it to:
>>>>>
>>>>> #ifdef __solaris__
>>>>> ! # ifdef DUAL_MODE
>>>>> ! # undef DUAL_MODE
>>>>> ! # endif
>>>>>
>>>>> why doesn't it just not define DUAL_MODE?
>>>>>
>>>>> ---
>>>>>
>>>>> test/demo/jvmti/DemoRun.java
>>>>> test/sun/tools/jhat/HatRun.java
>>>>>
>>>>> It isn't clear to me why you need to retain the d64 variable at all.
>>>>>
>>>>> ---
>>>>>
>>>>> test/tools/launcher/ExecutionEnvironment.java
>>>>>
>>>>> typo: appopriate
>>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> ----
>>>>>
>>>>>
>>>>>
>>>>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the changes to remove Solaris 32-bit binaries from JDK8
>>>>>> distros,
>>>>>> at this time the dual mode support in the launcher is being disabled.
>>>>>>
>>>>>> Message regarding this:
>>>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>>>>
>>>>>>
>>>>>> The jdk changes are here:
>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>>>
>>>>>> The top forest changes are here:
>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Kumar
>>>>>>
>>>>>>
From david.holmes at oracle.com Tue Sep 10 16:48:48 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2013 09:48:48 +1000
Subject: jmx-dev Codereview request: 8023529
OpenMBeanInfoSupport.equals/hashCode throw NPE
In-Reply-To: <522F2985.80207@oracle.com>
References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com>
<522F2985.80207@oracle.com>
Message-ID: <522FAFE0.1050304@oracle.com>
I'm a bit confused. The two webrevs are vastly different:
http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
Should they be combined somehow?
David
-----
On 11/09/2013 12:15 AM, shanliang wrote:
> Jaroslav Bachorik wrote:
>> On 09/05/2013 10:37 AM, shanliang wrote:
>>
>>> I have added 2 tasts to make sure that call
>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE
>>> The unit tests and JCK tests are passed.
>>>
>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529
>>>
>>
>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>>
>> * rename the "obj1", "obj2" parameters to something more explicit - eg.
>> "referenceInfo" and "nullValueinfo" or something similar
>>
> No reference object here, the test has to call both obj1.equals and
> obj2.equals.
>> * when testing "obj.equals(null);" the messages should not contain
>> reference to the parameter since you are not, in fact, testing the null
>> value of the given parameter but rather a null info object
>> * the message "got NPE if null paramer" should read "got NPE for null
>> paramter"
>>
> Right, should be "a null object" instead of "a null parameter."
>> * "Thread.sleep(100);" on line 153 is necessary?
>>
> It is not necessary for the test, removed now.
>> -----
>>
>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
>>
>> * the message "got NPE if null paramer" should read "got NPE for null
>> paramter"
>> * "Thread.sleep(100);" on line 143 is necessary?
>>
> Thanks for the review, here is the new version:
>
> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
>
> Shanliang
>>
>> -JB-
>>
>>
>>> Thanks,
>>>
>>> Shanliang
>>>
>>
>>
>
From david.holmes at oracle.com Tue Sep 10 17:05:17 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2013 10:05:17 +1000
Subject: Codereview request for JDK-8023669: MBean*Info.hashCode : NPE
In-Reply-To: <521F5697.3040108@oracle.com>
References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com>
<521F5697.3040108@oracle.com>
Message-ID: <522FB3BD.2040008@oracle.com>
On 30/08/2013 12:11 AM, shanliang wrote:
> Here is the new version:
> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
This seems good to address the NPE potential.
You are changing the values of the hashcodes though - is that a problem?
In javax/management/MBeanInfo.java
Objects.hash(getClassName(), getDescriptor().hashCode())
should, I think, be
Objects.hash(getClassName(), getDescriptor())
David
-----
> Indeed, calling Objects.hash(Object ...) is a good idea, which
> simplifies the code.
>
> I used also Arrays.hashCode() to simplify the code, now the fix likes
> really simple.
>
> I have passed JCK tests, unit tests of management are passed too in my
> desk.
>
> toString() worked perfectly in the test, nothing to fix.
>
> Shanliang
>
> Daniel Fuchs wrote:
>> On 8/29/13 9:34 AM, shanliang wrote:
>>> Hi,
>>>
>>> Please review following fix, it addresses the issue only in the method
>>> "hashCode":
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669
>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
>>>
>>> Thanks,
>>> Shanliang
>>>
>>
>> Hi Shanliang,
>>
>>
>>
>>
>> I suggest to simplify this by calling:
>>
>> public int hashCode() {
>> return Objects.hash(getName(), getType());
>> }
>>
>> (see
>> )
>>
>>
>>
>>
>>
>> int hash = getName() == null ? 10 : getName().hashCode();
>>
>> could be replaced by:
>>
>> int hash = Objects.hashCode(getName());
>>
>> Generally - and that stands for the other files you modified, you can
>> simplify things by replacing x.hashCode() with Objects.hashCode(x)
>> whenever there's the possibility that x can be null.
>>
>> Note however that Objects is an API @since JDK 7 - so if you intend
>> to backport this fix to 6 & 5 you will need to alter your changeset
>> when backporting it.
>>
>>
>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest
>> to use Objects.hash(...);
>>
>> best regards,
>>
>> -- daniel
>>
>> BTW: one more question: you're also testing toString() in the test
>> and that's good - but are there any toString() that will require
>> fixing?
>>
>>
>
From david.holmes at oracle.com Tue Sep 10 18:26:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2013 11:26:01 +1000
Subject: RFR: Changes to disable and/or remove Solaris 32-bit from JDK8
In-Reply-To: <522F9689.4090809@oracle.com>
References: <522A0712.90702@oracle.com> <522D2FE0.6030105@oracle.com>
<522D3C05.2000403@oracle.com> <522D4064.70703@oracle.com>
<522DE57A.1030907@oracle.com>
<9673F09F-061E-439C-AE1C-FD428AC4AB61@oracle.com>
<522F9689.4090809@oracle.com>
Message-ID: <522FC6A9.2070203@oracle.com>
On 11/09/2013 8:00 AM, Kumar Srinivasan wrote:
> Here are the updated changes:
Looks okay to me.
David
> The build changes are here:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/
> the delta changes since last reviewed:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.1/webrev.delta/index.html
>
>
> The jdk changes are here:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/
> The delta changes since last reviewed:
> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.2/webrev.delta/index.html
>
>
>
> Thanks
> Kumar
>
>
>
>> In SunCommandLineLauncher.java:
>>
>> 198 if (home.length() > 0) {
>> 199 String os_arch = System.getProperty("os.arch");
>> 200 if
>> ("SunOS".equals(System.getProperty("os.name"))) {
>> 201 exePath = home + File.separator + "bin" +
>> File.separator + exe;
>> 202 }
>> 203 } else {
>> 204 exePath = exe;
>> 205 }
>>
>> I think this should be:
>>
>> 198 if (home.length() > 0) {
>> 201 exePath = home + File.separator + "bin" +
>> File.separator + exe;
>> 203 } else {
>> 204 exePath = exe;
>> 205 }
>>
>>
>> Thanks,
>> /Staffan
>>
>>
>> On 9 sep 2013, at 18:12, Kumar Srinivasan
>> wrote:
>>
>>> Hi David,
>>>
>>>> Hi Kumar,
>>>>
>>>> This is still dead code in
>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>>
>>>> String os_arch = System.getProperty("os.arch");
>>> Ah, I will take care of it. Thanks for spotting this.
>>>> Also:
>>>>
>>>> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
>>>>
>>>>
>>>> I know this already exist but I thought binaries were disallowed in
>>>> the open repo?
>>> Alan, are the nio changes acceptable? Let me know if you need more
>>> time to go over all
>>> the changes.
>>>
>>> Kumar
>>>
>>>> Davud
>>>>
>>>> On 9/09/2013 1:09 PM, Kumar Srinivasan wrote:
>>>>> Hi David, Staffan, Alan,
>>>>>
>>>>> I have addressed all the issues pointed and some more I found while
>>>>> jprt
>>>>> testing.
>>>>>
>>>>> The updated webrev for jdk is here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/
>>>>>
>>>>> and the delta webrev since the last review webrev is here:
>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.1/webrev.delta/index.html
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>
>>>>>> Hi Kumar,
>>>>>>
>>>>>> A few minor comments ...
>>>>>>
>>>>>> src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
>>>>>>
>>>>>> Seems to me this is all dead now:
>>>>>>
>>>>>> 199 /*
>>>>>> 200 * A wrinkle in the environment:
>>>>>> 201 * 64-bit executables are stored under
>>>>>> $JAVA_HOME/bin/os_arch
>>>>>> 202 * 32-bit executables are stored under
>>>>>> $JAVA_HOME/bin
>>>>>> 203 */
>>>>>> 204 String os_arch = System.getProperty("os.arch");
>>>>>>
>>>>>> os_arch is no longer used and the comment no longer applicable.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/solaris/bin/java_md_solinux.c
>>>>>>
>>>>>> This seems to force DUAL_MODE off regardless of what the user may set
>>>>>> it to:
>>>>>>
>>>>>> #ifdef __solaris__
>>>>>> ! # ifdef DUAL_MODE
>>>>>> ! # undef DUAL_MODE
>>>>>> ! # endif
>>>>>>
>>>>>> why doesn't it just not define DUAL_MODE?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> test/demo/jvmti/DemoRun.java
>>>>>> test/sun/tools/jhat/HatRun.java
>>>>>>
>>>>>> It isn't clear to me why you need to retain the d64 variable at all.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> test/tools/launcher/ExecutionEnvironment.java
>>>>>>
>>>>>> typo: appopriate
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> ----
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/09/2013 2:47 AM, Kumar Srinivasan wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the changes to remove Solaris 32-bit binaries from
>>>>>>> JDK8
>>>>>>> distros,
>>>>>>> at this time the dual mode support in the launcher is being
>>>>>>> disabled.
>>>>>>>
>>>>>>> Message regarding this:
>>>>>>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/003159.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The jdk changes are here:
>>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk.0/
>>>>>>>
>>>>>>> The top forest changes are here:
>>>>>>> http://cr.openjdk.java.net/~ksrini/8020552/webrev.jdk8.0/
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Kumar
>>>>>>>
>>>>>>>
>
From xuelei.fan at oracle.com Tue Sep 10 21:44:45 2013
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 11 Sep 2013 04:44:45 +0000
Subject: hg: jdk8/tl/jdk: 8024501: sun.security.mscapi.Key has no definition
of serialVersionUID
Message-ID: <20130911044514.DF6A6626E9@hg.openjdk.java.net>
Changeset: c9083205e6eb
Author: xuelei
Date: 2013-09-10 21:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9083205e6eb
8024501: sun.security.mscapi.Key has no definition of serialVersionUID
Reviewed-by: weijun
! src/windows/classes/sun/security/mscapi/Key.java
From masayoshi.okutsu at oracle.com Tue Sep 10 23:30:34 2013
From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com)
Date: Wed, 11 Sep 2013 06:30:34 +0000
Subject: hg: jdk8/tl/jdk: 8024141: Unexpected timezone display name
Message-ID: <20130911063111.3DFBC626EE@hg.openjdk.java.net>
Changeset: 13ee370ee8b3
Author: okutsu
Date: 2013-09-11 15:29 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ee370ee8b3
8024141: Unexpected timezone display name
Reviewed-by: peytoia
! src/share/classes/sun/util/locale/provider/LocaleResources.java
+ test/sun/util/locale/provider/Bug8024141.java
From shanliang.jiang at oracle.com Tue Sep 10 23:44:12 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 11 Sep 2013 08:44:12 +0200
Subject: Codereview request for JDK-8023669: MBean*Info.hashCode : NPE
In-Reply-To: <522FB3BD.2040008@oracle.com>
References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com>
<521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com>
Message-ID: <5230113C.1010308@oracle.com>
David Holmes wrote:
> On 30/08/2013 12:11 AM, shanliang wrote:
>> Here is the new version:
>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
>
> This seems good to address the NPE potential.
>
> You are changing the values of the hashcodes though - is that a problem?
Good question!
It should not be a problem. The value "hashCode" is declared as "private
transient", so it must be always same for an MBeanInfo instance within a VM.
>
> In javax/management/MBeanInfo.java
>
> Objects.hash(getClassName(), getDescriptor().hashCode())
>
> should, I think, be
>
> Objects.hash(getClassName(), getDescriptor())
Yes you are right, corrected in the new version:
http://cr.openjdk.java.net/~sjiang/jdk-8023669/02/
thanks,
Shanliang
>
> David
> -----
>
>> Indeed, calling Objects.hash(Object ...) is a good idea, which
>> simplifies the code.
>>
>> I used also Arrays.hashCode() to simplify the code, now the fix likes
>> really simple.
>>
>> I have passed JCK tests, unit tests of management are passed too in my
>> desk.
>>
>> toString() worked perfectly in the test, nothing to fix.
>>
>> Shanliang
>>
>> Daniel Fuchs wrote:
>>> On 8/29/13 9:34 AM, shanliang wrote:
>>>> Hi,
>>>>
>>>> Please review following fix, it addresses the issue only in the method
>>>> "hashCode":
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669
>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
>>>>
>>>> Thanks,
>>>> Shanliang
>>>>
>>>
>>> Hi Shanliang,
>>>
>>>
>>>
>>>
>>>
>>> I suggest to simplify this by calling:
>>>
>>> public int hashCode() {
>>> return Objects.hash(getName(), getType());
>>> }
>>>
>>> (see
>>> )
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> int hash = getName() == null ? 10 : getName().hashCode();
>>>
>>> could be replaced by:
>>>
>>> int hash = Objects.hashCode(getName());
>>>
>>> Generally - and that stands for the other files you modified, you can
>>> simplify things by replacing x.hashCode() with Objects.hashCode(x)
>>> whenever there's the possibility that x can be null.
>>>
>>> Note however that Objects is an API @since JDK 7 - so if you intend
>>> to backport this fix to 6 & 5 you will need to alter your changeset
>>> when backporting it.
>>>
>>>
>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest
>>> to use Objects.hash(...);
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> BTW: one more question: you're also testing toString() in the test
>>> and that's good - but are there any toString() that will require
>>> fixing?
>>>
>>>
>>
From shanliang.jiang at oracle.com Wed Sep 11 00:33:52 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 11 Sep 2013 09:33:52 +0200
Subject: jmx-dev Codereview request: 8023529
OpenMBeanInfoSupport.equals/hashCode throw NPE
In-Reply-To: <522FAFE0.1050304@oracle.com>
References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com>
<522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com>
Message-ID: <52301CE0.2040407@oracle.com>
David Holmes wrote:
> I'm a bit confused. The two webrevs are vastly different:
>
> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
>
> http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
>
> Should they be combined somehow?
The version 01 is correct.
The version 00 was a mistake, yesterday I had some problems to generate
the version 01, so the version 00 was re-generated by mistake with
another fix, sorry for this confusing.
Thanks,
Shanliang
>
> David
> -----
>
> On 11/09/2013 12:15 AM, shanliang wrote:
>> Jaroslav Bachorik wrote:
>>> On 09/05/2013 10:37 AM, shanliang wrote:
>>>
>>>> I have added 2 tasts to make sure that call
>>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE
>>>> The unit tests and JCK tests are passed.
>>>>
>>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529
>>>>
>>>
>>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>>>
>>> * rename the "obj1", "obj2" parameters to something more explicit - eg.
>>> "referenceInfo" and "nullValueinfo" or something similar
>>>
>> No reference object here, the test has to call both obj1.equals and
>> obj2.equals.
>>> * when testing "obj.equals(null);" the messages should not contain
>>> reference to the parameter since you are not, in fact, testing the null
>>> value of the given parameter but rather a null info object
>>> * the message "got NPE if null paramer" should read "got NPE for null
>>> paramter"
>>>
>> Right, should be "a null object" instead of "a null parameter."
>>> * "Thread.sleep(100);" on line 153 is necessary?
>>>
>> It is not necessary for the test, removed now.
>>> -----
>>>
>>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
>>>
>>> * the message "got NPE if null paramer" should read "got NPE for null
>>> paramter"
>>> * "Thread.sleep(100);" on line 143 is necessary?
>>>
>> Thanks for the review, here is the new version:
>>
>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
>>
>> Shanliang
>>>
>>> -JB-
>>>
>>>
>>>> Thanks,
>>>>
>>>> Shanliang
>>>>
>>>
>>>
>>
From daniel.fuchs at oracle.com Wed Sep 11 00:37:01 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 11 Sep 2013 09:37:01 +0200
Subject: Codereview request for JDK-8023669: MBean*Info.hashCode : NPE
In-Reply-To: <522FB3BD.2040008@oracle.com>
References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com>
<521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com>
Message-ID: <52301D9D.1040706@oracle.com>
On 9/11/13 2:05 AM, David Holmes wrote:
> On 30/08/2013 12:11 AM, shanliang wrote:
>> Here is the new version:
>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
>
> This seems good to address the NPE potential.
>
> You are changing the values of the hashcodes though - is that a problem?
Hi David,
The algorithm by which hashCode() is computed isn't specified - so it
shouldn't
be an issue changing it - should it?
I must say I don't know how HashMap is serialized - for instance. So
assuming
we have an App1 sending a Map of MBeanInfos to an App2 over the wire, is
that
a problem if in App2 the MBeanInfo hashCodes resolve to different values?
I assume it doesn't...
I have never considered values of hashCode() to be part of the standard/API.
Since the algorithm isn't specified, then 2 implementations of the
standard should
be free to use different algorithms - and this shouldn't prevent then to
interoperate. So I hope we're safe in modifying the hashCode algorithm.
The important part is that it still satisfies the hashCode/equals contract.
cheers,
-- daniel
>
> In javax/management/MBeanInfo.java
>
> Objects.hash(getClassName(), getDescriptor().hashCode())
>
> should, I think, be
>
> Objects.hash(getClassName(), getDescriptor())
> David
> -----
>
>> Indeed, calling Objects.hash(Object ...) is a good idea, which
>> simplifies the code.
>>
>> I used also Arrays.hashCode() to simplify the code, now the fix likes
>> really simple.
>>
>> I have passed JCK tests, unit tests of management are passed too in my
>> desk.
>>
>> toString() worked perfectly in the test, nothing to fix.
>>
>> Shanliang
>>
>> Daniel Fuchs wrote:
>>> On 8/29/13 9:34 AM, shanliang wrote:
>>>> Hi,
>>>>
>>>> Please review following fix, it addresses the issue only in the method
>>>> "hashCode":
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669
>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
>>>>
>>>> Thanks,
>>>> Shanliang
>>>>
>>>
>>> Hi Shanliang,
>>>
>>>
>>>
>>>
>>>
>>> I suggest to simplify this by calling:
>>>
>>> public int hashCode() {
>>> return Objects.hash(getName(), getType());
>>> }
>>>
>>> (see
>>> )
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> int hash = getName() == null ? 10 : getName().hashCode();
>>>
>>> could be replaced by:
>>>
>>> int hash = Objects.hashCode(getName());
>>>
>>> Generally - and that stands for the other files you modified, you can
>>> simplify things by replacing x.hashCode() with Objects.hashCode(x)
>>> whenever there's the possibility that x can be null.
>>>
>>> Note however that Objects is an API @since JDK 7 - so if you intend
>>> to backport this fix to 6 & 5 you will need to alter your changeset
>>> when backporting it.
>>>
>>>
>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest
>>> to use Objects.hash(...);
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> BTW: one more question: you're also testing toString() in the test
>>> and that's good - but are there any toString() that will require
>>> fixing?
>>>
>>>
>>
From shanliang.jiang at oracle.com Wed Sep 11 00:54:52 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 11 Sep 2013 09:54:52 +0200
Subject: Codereview request for JDK-8023669: MBean*Info.hashCode : NPE
In-Reply-To: <52301D9D.1040706@oracle.com>
References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com>
<521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com>
<52301D9D.1040706@oracle.com>
Message-ID: <523021CC.3050506@oracle.com>
Daniel Fuchs wrote:
> On 9/11/13 2:05 AM, David Holmes wrote:
>> On 30/08/2013 12:11 AM, shanliang wrote:
>>> Here is the new version:
>>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
>>
>> This seems good to address the NPE potential.
>>
>> You are changing the values of the hashcodes though - is that a problem?
> Hi David,
>
> The algorithm by which hashCode() is computed isn't specified - so it
> shouldn't
> be an issue changing it - should it?
>
> I must say I don't know how HashMap is serialized - for instance. So
> assuming
> we have an App1 sending a Map of MBeanInfos to an App2 over the wire,
> is that
> a problem if in App2 the MBeanInfo hashCodes resolve to different values?
> I assume it doesn't...
If app1 sends a Map to app2, the hashCode of each key
(MBeanInfo) will be re-calculated in app2, it is because the variable
"hashCode" of an MBeanOInfo is declared as "transient", the value
calculated in the app1 is not serialized and sent to the app2. So must
no problem here.
An exception is that we have Map, and the key "int" here is
hashCode of an MBeanInfo, if app1 sends this map to app2, then app2 uses
an MBenInfo's hashCode to look for a value in the map. But this seems
little possible.
Thanks,
Shanliang
>
> I have never considered values of hashCode() to be part of the
> standard/API.
> Since the algorithm isn't specified, then 2 implementations of the
> standard should
> be free to use different algorithms - and this shouldn't prevent then to
> interoperate. So I hope we're safe in modifying the hashCode algorithm.
>
> The important part is that it still satisfies the hashCode/equals
> contract.
>
> cheers,
>
> -- daniel
>
>>
>> In javax/management/MBeanInfo.java
>>
>> Objects.hash(getClassName(), getDescriptor().hashCode())
>>
>> should, I think, be
>>
>> Objects.hash(getClassName(), getDescriptor())
>> David
>> -----
>>
>>> Indeed, calling Objects.hash(Object ...) is a good idea, which
>>> simplifies the code.
>>>
>>> I used also Arrays.hashCode() to simplify the code, now the fix likes
>>> really simple.
>>>
>>> I have passed JCK tests, unit tests of management are passed too in my
>>> desk.
>>>
>>> toString() worked perfectly in the test, nothing to fix.
>>>
>>> Shanliang
>>>
>>> Daniel Fuchs wrote:
>>>> On 8/29/13 9:34 AM, shanliang wrote:
>>>>> Hi,
>>>>>
>>>>> Please review following fix, it addresses the issue only in the
>>>>> method
>>>>> "hashCode":
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669
>>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
>>>>>
>>>>> Thanks,
>>>>> Shanliang
>>>>>
>>>>
>>>> Hi Shanliang,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I suggest to simplify this by calling:
>>>>
>>>> public int hashCode() {
>>>> return Objects.hash(getName(), getType());
>>>> }
>>>>
>>>> (see
>>>> )
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> int hash = getName() == null ? 10 : getName().hashCode();
>>>>
>>>> could be replaced by:
>>>>
>>>> int hash = Objects.hashCode(getName());
>>>>
>>>> Generally - and that stands for the other files you modified, you can
>>>> simplify things by replacing x.hashCode() with Objects.hashCode(x)
>>>> whenever there's the possibility that x can be null.
>>>>
>>>> Note however that Objects is an API @since JDK 7 - so if you intend
>>>> to backport this fix to 6 & 5 you will need to alter your changeset
>>>> when backporting it.
>>>>
>>>>
>>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest
>>>> to use Objects.hash(...);
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> BTW: one more question: you're also testing toString() in the test
>>>> and that's good - but are there any toString() that will require
>>>> fixing?
>>>>
>>>>
>>>
>
From jaroslav.bachorik at oracle.com Wed Sep 11 01:16:43 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 11 Sep 2013 10:16:43 +0200
Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode
: NPE
In-Reply-To: <523021CC.3050506@oracle.com>
References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com>
<521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com>
<52301D9D.1040706@oracle.com> <523021CC.3050506@oracle.com>
Message-ID: <523026EB.8090801@oracle.com>
On 09/11/2013 09:54 AM, shanliang wrote:
> Daniel Fuchs wrote:
>> On 9/11/13 2:05 AM, David Holmes wrote:
>>> On 30/08/2013 12:11 AM, shanliang wrote:
>>>> Here is the new version:
>>>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
>>>
>>> This seems good to address the NPE potential.
>>>
>>> You are changing the values of the hashcodes though - is that a problem?
>> Hi David,
>>
>> The algorithm by which hashCode() is computed isn't specified - so it
>> shouldn't
>> be an issue changing it - should it?
>>
>> I must say I don't know how HashMap is serialized - for instance. So
>> assuming
>> we have an App1 sending a Map of MBeanInfos to an App2 over the wire,
>> is that
>> a problem if in App2 the MBeanInfo hashCodes resolve to different values?
>> I assume it doesn't...
> If app1 sends a Map to app2, the hashCode of each key
> (MBeanInfo) will be re-calculated in app2, it is because the variable
> "hashCode" of an MBeanOInfo is declared as "transient", the value
> calculated in the app1 is not serialized and sent to the app2. So must
> no problem here.
>
> An exception is that we have Map, and the key "int" here is
> hashCode of an MBeanInfo, if app1 sends this map to app2, then app2 uses
> an MBenInfo's hashCode to look for a value in the map. But this seems
> little possible.
Storing objects in a map by their hashcodes makes little sense. Two
distinct objects can share the same hashcode easily - thus this kind of
usage would mess up the application anyway.
-JB-
>
> Thanks,
> Shanliang
>>
>> I have never considered values of hashCode() to be part of the
>> standard/API.
>> Since the algorithm isn't specified, then 2 implementations of the
>> standard should
>> be free to use different algorithms - and this shouldn't prevent then to
>> interoperate. So I hope we're safe in modifying the hashCode algorithm.
>>
>> The important part is that it still satisfies the hashCode/equals
>> contract.
>>
>> cheers,
>>
>> -- daniel
>>
>>>
>>> In javax/management/MBeanInfo.java
>>>
>>> Objects.hash(getClassName(), getDescriptor().hashCode())
>>>
>>> should, I think, be
>>>
>>> Objects.hash(getClassName(), getDescriptor())
>>> David
>>> -----
>>>
>>>> Indeed, calling Objects.hash(Object ...) is a good idea, which
>>>> simplifies the code.
>>>>
>>>> I used also Arrays.hashCode() to simplify the code, now the fix likes
>>>> really simple.
>>>>
>>>> I have passed JCK tests, unit tests of management are passed too in my
>>>> desk.
>>>>
>>>> toString() worked perfectly in the test, nothing to fix.
>>>>
>>>> Shanliang
>>>>
>>>> Daniel Fuchs wrote:
>>>>> On 8/29/13 9:34 AM, shanliang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review following fix, it addresses the issue only in the
>>>>>> method
>>>>>> "hashCode":
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669
>>>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
>>>>>>
>>>>>> Thanks,
>>>>>> Shanliang
>>>>>>
>>>>>
>>>>> Hi Shanliang,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I suggest to simplify this by calling:
>>>>>
>>>>> public int hashCode() {
>>>>> return Objects.hash(getName(), getType());
>>>>> }
>>>>>
>>>>> (see
>>>>> )
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> int hash = getName() == null ? 10 : getName().hashCode();
>>>>>
>>>>> could be replaced by:
>>>>>
>>>>> int hash = Objects.hashCode(getName());
>>>>>
>>>>> Generally - and that stands for the other files you modified, you can
>>>>> simplify things by replacing x.hashCode() with Objects.hashCode(x)
>>>>> whenever there's the possibility that x can be null.
>>>>>
>>>>> Note however that Objects is an API @since JDK 7 - so if you intend
>>>>> to backport this fix to 6 & 5 you will need to alter your changeset
>>>>> when backporting it.
>>>>>
>>>>>
>>>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest
>>>>> to use Objects.hash(...);
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>> BTW: one more question: you're also testing toString() in the test
>>>>> and that's good - but are there any toString() that will require
>>>>> fixing?
>>>>>
>>>>>
>>>>
>>
>
From david.holmes at oracle.com Wed Sep 11 01:20:30 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2013 18:20:30 +1000
Subject: Codereview request for JDK-8023669: MBean*Info.hashCode : NPE
In-Reply-To: <52301D9D.1040706@oracle.com>
References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com>
<521F5697.3040108@oracle.com> <522FB3BD.2040008@oracle.com>
<52301D9D.1040706@oracle.com>
Message-ID: <523027CE.4020009@oracle.com>
On 11/09/2013 5:37 PM, Daniel Fuchs wrote:
> On 9/11/13 2:05 AM, David Holmes wrote:
>> On 30/08/2013 12:11 AM, shanliang wrote:
>>> Here is the new version:
>>> http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/
>>
>> This seems good to address the NPE potential.
>>
>> You are changing the values of the hashcodes though - is that a problem?
> Hi David,
>
> The algorithm by which hashCode() is computed isn't specified - so it
> shouldn't be an issue changing it - should it?
It shouldn't :) But that was why I asked. Even though the exact hashcode
is not part of the contract/spec we need to think about what impact it
might have just in case we suddenly realize it is a problem somewhere.
The main effect of the change would be on how maps store and traverse
these objects. Nobody should be relying on such details of course, but
there always seems to be someone who does.
Anyway I raised the question and it's been explored and I don't see any
flashing red lights so no problem. :)
Reviewed.
Cheers,
David
>
> I must say I don't know how HashMap is serialized - for instance. So
> assuming
> we have an App1 sending a Map of MBeanInfos to an App2 over the wire, is
> that
> a problem if in App2 the MBeanInfo hashCodes resolve to different values?
> I assume it doesn't...
>
> I have never considered values of hashCode() to be part of the
> standard/API.
> Since the algorithm isn't specified, then 2 implementations of the
> standard should
> be free to use different algorithms - and this shouldn't prevent then to
> interoperate. So I hope we're safe in modifying the hashCode algorithm.
>
> The important part is that it still satisfies the hashCode/equals contract.
>
> cheers,
>
> -- daniel
>
>>
>> In javax/management/MBeanInfo.java
>>
>> Objects.hash(getClassName(), getDescriptor().hashCode())
>>
>> should, I think, be
>>
>> Objects.hash(getClassName(), getDescriptor())
>> David
>> -----
>>
>>> Indeed, calling Objects.hash(Object ...) is a good idea, which
>>> simplifies the code.
>>>
>>> I used also Arrays.hashCode() to simplify the code, now the fix likes
>>> really simple.
>>>
>>> I have passed JCK tests, unit tests of management are passed too in my
>>> desk.
>>>
>>> toString() worked perfectly in the test, nothing to fix.
>>>
>>> Shanliang
>>>
>>> Daniel Fuchs wrote:
>>>> On 8/29/13 9:34 AM, shanliang wrote:
>>>>> Hi,
>>>>>
>>>>> Please review following fix, it addresses the issue only in the method
>>>>> "hashCode":
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669
>>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/
>>>>>
>>>>> Thanks,
>>>>> Shanliang
>>>>>
>>>>
>>>> Hi Shanliang,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I suggest to simplify this by calling:
>>>>
>>>> public int hashCode() {
>>>> return Objects.hash(getName(), getType());
>>>> }
>>>>
>>>> (see
>>>> )
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> int hash = getName() == null ? 10 : getName().hashCode();
>>>>
>>>> could be replaced by:
>>>>
>>>> int hash = Objects.hashCode(getName());
>>>>
>>>> Generally - and that stands for the other files you modified, you can
>>>> simplify things by replacing x.hashCode() with Objects.hashCode(x)
>>>> whenever there's the possibility that x can be null.
>>>>
>>>> Note however that Objects is an API @since JDK 7 - so if you intend
>>>> to backport this fix to 6 & 5 you will need to alter your changeset
>>>> when backporting it.
>>>>
>>>>
>>>> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest
>>>> to use Objects.hash(...);
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> BTW: one more question: you're also testing toString() in the test
>>>> and that's good - but are there any toString() that will require
>>>> fixing?
>>>>
>>>>
>>>
>
From david.holmes at oracle.com Wed Sep 11 01:30:48 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2013 18:30:48 +1000
Subject: jmx-dev Codereview request: 8023529
OpenMBeanInfoSupport.equals/hashCode throw NPE
In-Reply-To: <52301CE0.2040407@oracle.com>
References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com>
<522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com>
<52301CE0.2040407@oracle.com>
Message-ID: <52302A38.1020800@oracle.com>
On 11/09/2013 5:33 PM, shanliang wrote:
> David Holmes wrote:
>> I'm a bit confused. The two webrevs are vastly different:
>>
>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
>>
>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
>>
>> Should they be combined somehow?
> The version 01 is correct.
> The version 00 was a mistake, yesterday I had some problems to generate
> the version 01, so the version 00 was re-generated by mistake with
> another fix, sorry for this confusing.
Ok functional change seems fine.
Looking at the tests a few minor nits:
test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
163 obj1.equals(null);
...
184 obj1.equals(null);
I think line 163 can be deleted.
In both tests ...
Use spaces around the + operator in strings eg:
"OK-1: "+obj1.get...
The message "with a null object" isn't quite reflective of what is being
tested. "null attribute" or even "null field" perhaps?
When you catch NPE and report an error it would be good to also print
the NPE stacktrace so we can see where we hit the unexpected NPE.
The tests are a little verbose ie printing each successful test result,
but that might be normal style in this area.
David
-----
> Thanks,
> Shanliang
>>
>> David
>> -----
>>
>> On 11/09/2013 12:15 AM, shanliang wrote:
>>> Jaroslav Bachorik wrote:
>>>> On 09/05/2013 10:37 AM, shanliang wrote:
>>>>
>>>>> I have added 2 tasts to make sure that call
>>>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE
>>>>> The unit tests and JCK tests are passed.
>>>>>
>>>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529
>>>>>
>>>>
>>>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>>>>
>>>> * rename the "obj1", "obj2" parameters to something more explicit - eg.
>>>> "referenceInfo" and "nullValueinfo" or something similar
>>>>
>>> No reference object here, the test has to call both obj1.equals and
>>> obj2.equals.
>>>> * when testing "obj.equals(null);" the messages should not contain
>>>> reference to the parameter since you are not, in fact, testing the null
>>>> value of the given parameter but rather a null info object
>>>> * the message "got NPE if null paramer" should read "got NPE for null
>>>> paramter"
>>>>
>>> Right, should be "a null object" instead of "a null parameter."
>>>> * "Thread.sleep(100);" on line 153 is necessary?
>>>>
>>> It is not necessary for the test, removed now.
>>>> -----
>>>>
>>>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
>>>>
>>>> * the message "got NPE if null paramer" should read "got NPE for null
>>>> paramter"
>>>> * "Thread.sleep(100);" on line 143 is necessary?
>>>>
>>> Thanks for the review, here is the new version:
>>>
>>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
>>>
>>> Shanliang
>>>>
>>>> -JB-
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Shanliang
>>>>>
>>>>
>>>>
>>>
>
From joel.franck at oracle.com Wed Sep 11 02:02:30 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Wed, 11 Sep 2013 09:02:30 +0000
Subject: hg: jdk8/tl/jdk: 4987375: (reflect) Class.get{Declared}Method{s} does
not return clone() for array types
Message-ID: <20130911090255.16560626F4@hg.openjdk.java.net>
Changeset: b271ea30f440
Author: jfranck
Date: 2013-09-11 09:45 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b271ea30f440
4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array types
Summary: Update spec to match long standing behavior
Reviewed-by: darcy, mchung
! src/share/classes/java/lang/Class.java
+ test/java/lang/Class/ArrayMethods.java
From chris.hegarty at oracle.com Wed Sep 11 03:05:06 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 11 Sep 2013 10:05:06 +0000
Subject: hg: jdk8/tl/jdk: 8024508: Fix doclint issues in com.sun.nio.sctp
Message-ID: <20130911100541.0C8DA626F7@hg.openjdk.java.net>
Changeset: 517c5e99fb2f
Author: chegar
Date: 2013-09-11 11:03 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/517c5e99fb2f
8024508: Fix doclint issues in com.sun.nio.sctp
Reviewed-by: alanb
! src/share/classes/com/sun/nio/sctp/Association.java
! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java
! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java
! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java
! src/share/classes/com/sun/nio/sctp/MessageInfo.java
! src/share/classes/com/sun/nio/sctp/Notification.java
! src/share/classes/com/sun/nio/sctp/SctpChannel.java
! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java
! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java
From chris.hegarty at oracle.com Wed Sep 11 03:33:20 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 11 Sep 2013 10:33:20 +0000
Subject: hg: jdk8/tl/jdk: 8023090: Additional debug info for
java/net/NetworkInterface/Equals.java
Message-ID: <20130911103406.0A0C7626FB@hg.openjdk.java.net>
Changeset: d389dedd1ccb
Author: chegar
Date: 2013-09-11 11:32 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d389dedd1ccb
8023090: Additional debug info for java/net/NetworkInterface/Equals.java
Reviewed-by: alanb
! test/java/net/NetworkInterface/Equals.java
From dmitry.samersoff at oracle.com Wed Sep 11 04:05:36 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 11 Sep 2013 15:05:36 +0400
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation
for invokedynamic
In-Reply-To: <52279988.6070809@oracle.com>
References: <52279988.6070809@oracle.com>
Message-ID: <52304E80.3010004@oracle.com>
Any reviewers?
On 2013-09-05 00:35, Dmitry Samersoff wrote:
> Please, review the changes.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/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 shanliang.jiang at oracle.com Wed Sep 11 05:32:26 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 11 Sep 2013 14:32:26 +0200
Subject: jmx-dev Codereview request: 8023529
OpenMBeanInfoSupport.equals/hashCode throw NPE
In-Reply-To: <52302A38.1020800@oracle.com>
References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com>
<522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com>
<52301CE0.2040407@oracle.com> <52302A38.1020800@oracle.com>
Message-ID: <523062DA.20804@oracle.com>
David Holmes wrote:
> Ok functional change seems fine.
>
> Looking at the tests a few minor nits:
>
> test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>
> 163 obj1.equals(null);
> ...
> 184 obj1.equals(null);
>
> I think line 163 can be deleted.
Yes.
>
> In both tests ...
>
> Use spaces around the + operator in strings eg:
>
> "OK-1: "+obj1.get...
>
>
> The message "with a null object" isn't quite reflective of what is
> being tested. "null attribute" or even "null field" perhaps?
>
> When you catch NPE and report an error it would be good to also print
> the NPE stacktrace so we can see where we hit the unexpected NPE.
OK.
>
> The tests are a little verbose ie printing each successful test
> result, but that might be normal style in this area.
Here we need to test all fields so I print out what we test, so easy to
check no missed.
I get used to add more info, because sometime we miss info when a test
fails.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/jdk-8023529/02/
Thanks,
Shanliang
>
> David
> -----
>
>> Thanks,
>> Shanliang
>>>
>>> David
>>> -----
>>>
>>> On 11/09/2013 12:15 AM, shanliang wrote:
>>>> Jaroslav Bachorik wrote:
>>>>> On 09/05/2013 10:37 AM, shanliang wrote:
>>>>>
>>>>>> I have added 2 tasts to make sure that call
>>>>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE
>>>>>> The unit tests and JCK tests are passed.
>>>>>>
>>>>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529
>>>>>>
>>>>>
>>>>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>>>>>
>>>>> * rename the "obj1", "obj2" parameters to something more explicit
>>>>> - eg.
>>>>> "referenceInfo" and "nullValueinfo" or something similar
>>>>>
>>>> No reference object here, the test has to call both obj1.equals and
>>>> obj2.equals.
>>>>> * when testing "obj.equals(null);" the messages should not contain
>>>>> reference to the parameter since you are not, in fact, testing the
>>>>> null
>>>>> value of the given parameter but rather a null info object
>>>>> * the message "got NPE if null paramer" should read "got NPE for null
>>>>> paramter"
>>>>>
>>>> Right, should be "a null object" instead of "a null parameter."
>>>>> * "Thread.sleep(100);" on line 153 is necessary?
>>>>>
>>>> It is not necessary for the test, removed now.
>>>>> -----
>>>>>
>>>>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
>>>>>
>>>>> * the message "got NPE if null paramer" should read "got NPE for null
>>>>> paramter"
>>>>> * "Thread.sleep(100);" on line 143 is necessary?
>>>>>
>>>> Thanks for the review, here is the new version:
>>>>
>>>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
>>>>
>>>> Shanliang
>>>>>
>>>>> -JB-
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Shanliang
>>>>>>
>>>>>
>>>>>
>>>>
>>
From eric.mccorkle at oracle.com Wed Sep 11 05:31:30 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Wed, 11 Sep 2013 12:31:30 +0000
Subject: hg: jdk8/tl/langtools: 8024510:
lib/combo/tools/javac/combo/TemplateTest.java fails
Message-ID: <20130911123135.C7961626FD@hg.openjdk.java.net>
Changeset: 65c218b25b61
Author: emc
Date: 2013-09-11 08:30 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65c218b25b61
8024510: lib/combo/tools/javac/combo/TemplateTest.java fails
Summary: Edit regex in Template to allow "MAJOR." pattern.
Reviewed-by: briangoetz
! test/lib/combo/tools/javac/combo/Template.java
From naoto.sato at oracle.com Wed Sep 11 05:40:34 2013
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 11 Sep 2013 12:40:34 +0000
Subject: hg: jdk8/tl/jdk: 8024332: sun/util/resources/en split between rt.jar
and localedata.jar
Message-ID: <20130911124112.88013626FE@hg.openjdk.java.net>
Changeset: 7bfe3da4fad6
Author: naoto
Date: 2013-09-11 05:38 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bfe3da4fad6
8024332: sun/util/resources/en split between rt.jar and localedata.jar
Reviewed-by: alanb, erikj
! make/java/java/genlocales.gmk
! make/java/java/localegen.sh
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/java/util/FILES_properties.gmk
! make/sun/text/FILES_java.gmk
! make/sun/text/FILES_properties.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template
From dmitry.samersoff at oracle.com Wed Sep 11 06:15:22 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 11 Sep 2013 17:15:22 +0400
Subject: RR(S): JDK-8009213 sun/management/jdp/JdpTest.sh fails with exit
code 1
Message-ID: <52306CEA.2060208@oracle.com>
Please, review shell script changes.
Problem:
Sometimes, server process JVM start slowly than client process jvm, so
test can't get server process pid and fails.
Solution:
Attempt to find server process up to 10 times, with 1 sec delay between
attempts.
-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 eric.mccorkle at oracle.com Wed Sep 11 06:25:06 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Wed, 11 Sep 2013 13:25:06 +0000
Subject: hg: jdk8/tl/jdk: 6962494: Update documentation on
Executable.getParameterAnnotations()
Message-ID: <20130911132547.5191962701@hg.openjdk.java.net>
Changeset: c3ef78cd9081
Author: emc
Date: 2013-09-11 09:24 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3ef78cd9081
6962494: Update documentation on Executable.getParameterAnnotations()
Summary: Update javadoc comments on getParameterAnnotations to correctly describe its behavior
Reviewed-by: darcy, jfranck
! src/share/classes/java/lang/reflect/Executable.java
From michael.x.mcmahon at oracle.com Wed Sep 11 07:03:41 2013
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Wed, 11 Sep 2013 14:03:41 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130911140529.8038862703@hg.openjdk.java.net>
Changeset: 1ec241501e60
Author: michaelm
Date: 2013-09-11 15:00 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ec241501e60
8024601: Windows networking code prevents use of -Xlint:auxiliaryclass in jdk build
Reviewed-by: chegar
! src/share/classes/java/net/AbstractPlainSocketImpl.java
+ src/share/classes/java/net/InetAddressContainer.java
Changeset: 7dcb9d944910
Author: michaelm
Date: 2013-09-11 15:02 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dcb9d944910
Merge
From roger.riggs at oracle.com Wed Sep 11 07:41:31 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Wed, 11 Sep 2013 14:41:31 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130911144215.1F3506270D@hg.openjdk.java.net>
Changeset: 292d93f32aa1
Author: rriggs
Date: 2013-09-11 10:16 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/292d93f32aa1
8024164: JSR310 serialization should be described in details
Summary: The serialized-form.html should specify the stream format for interoperability
Reviewed-by: alanb
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Ser.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/Ser.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
! src/share/classes/java/time/zone/Ser.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRules.java
! test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
Changeset: 8b4aef582087
Author: rriggs
Date: 2013-09-11 10:35 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b4aef582087
Merge
From jaroslav.bachorik at oracle.com Wed Sep 11 07:51:53 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 11 Sep 2013 16:51:53 +0200
Subject: RFR: 8022220 Intermittent test failures in
javax/management/remote/mandatory/connection/RMIConnectionIdTest.java
Message-ID: <52308389.6060001@oracle.com>
Please, review this simple patch for an intermittently failing test.
The test fails in cases when the connection loopback is resolved to be
127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The
test does not anticipate this possibility and requires the loopback
address to be exactly 127.0.0.1
The test will end comparing 127.0.0.1 against 127.0.1.1 and will
consider them non equal even though they are both the same loopback. The
patch adds a bit of flexibility to the test allowing for any two valid
loopback addresses (127.0.0.0/8) to be equal.
Issue : JDK-8022220
Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00
Thanks,
-JB-
From shanliang.jiang at oracle.com Wed Sep 11 08:06:10 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 11 Sep 2013 17:06:10 +0200
Subject: RFR: 8022220 Intermittent test failures in
javax/management/remote/mandatory/connection/RMIConnectionIdTest.java
In-Reply-To: <52308389.6060001@oracle.com>
References: <52308389.6060001@oracle.com>
Message-ID: <523086E2.4050307@oracle.com>
The fix looks OK for me.
I am wondering that in case of loopback address, is it better to always
using "127.0.0.1" to generate a connectionId? this will make sure to
have a unique id.
Shanliang
Jaroslav Bachorik wrote:
> Please, review this simple patch for an intermittently failing test.
>
> The test fails in cases when the connection loopback is resolved to be
> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The
> test does not anticipate this possibility and requires the loopback
> address to be exactly 127.0.0.1
>
> The test will end comparing 127.0.0.1 against 127.0.1.1 and will
> consider them non equal even though they are both the same loopback. The
> patch adds a bit of flexibility to the test allowing for any two valid
> loopback addresses (127.0.0.0/8) to be equal.
>
> Issue : JDK-8022220
> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00
>
> Thanks,
>
> -JB-
>
From jaroslav.bachorik at oracle.com Wed Sep 11 08:20:59 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 11 Sep 2013 17:20:59 +0200
Subject: RFR: 8022220 Intermittent test failures in
javax/management/remote/mandatory/connection/RMIConnectionIdTest.java
In-Reply-To: <523086E2.4050307@oracle.com>
References: <52308389.6060001@oracle.com> <523086E2.4050307@oracle.com>
Message-ID: <52308A5B.8020206@oracle.com>
On 09/11/2013 05:06 PM, shanliang wrote:
> The fix looks OK for me.
>
> I am wondering that in case of loopback address, is it better to always
> using "127.0.0.1" to generate a connectionId? this will make sure to
> have a unique id.
I am afraid we are getting the 127.0.1.1 variant from RMI
(java.rmi.server.RemoteServer#getClientHost()). I don't know what else
might break if we start fiddling around with it. For now I would better
keep it the simplest possible.
-JB-
>
> Shanliang
>
> Jaroslav Bachorik wrote:
>> Please, review this simple patch for an intermittently failing test.
>>
>> The test fails in cases when the connection loopback is resolved to be
>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The
>> test does not anticipate this possibility and requires the loopback
>> address to be exactly 127.0.0.1
>>
>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will
>> consider them non equal even though they are both the same loopback. The
>> patch adds a bit of flexibility to the test allowing for any two valid
>> loopback addresses (127.0.0.0/8) to be equal.
>>
>> Issue : JDK-8022220
>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00
>>
>> Thanks,
>>
>> -JB-
>>
>
From jaroslav.bachorik at oracle.com Wed Sep 11 08:39:56 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 11 Sep 2013 17:39:56 +0200
Subject: RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
Message-ID: <52308ECC.1050304@oracle.com>
Please, review the patch for an intermittently failing test.
The test is a shell test, using files for the interprocess
synchronization. This leads to intermittent failures.
In order to fix this the test is rewritten in Java - the original
functionality and outputs should be 100% preserved. The patch is
unfortunately a bit difficult to follow since there is no similarity
between the *.sh and *.java file so one needs to go through the new
source in whole.
The changes in "launcher" files are all about adding permissions to
execute (0755) and as such the webrev shows no differences.
Thanks,
Issue : JDK-8004926
Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
-JB-
From christian.thalinger at oracle.com Wed Sep 11 09:37:20 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Sep 2013 09:37:20 -0700
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation for
invokedynamic
In-Reply-To: <52283363.8030504@oracle.com>
References: <52279988.6070809@oracle.com>
<48AEBE20-A4D6-43A5-8BA4-572B94C949D0@oracle.com>
<52283363.8030504@oracle.com>
Message-ID: <1B48ECDA-FF3F-4D88-BA4A-04686C8F206E@oracle.com>
On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff wrote:
> On 2013-09-05 02:30, Christian Thalinger wrote:
>>
>> On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff wrote:
>>
>>> Please, review the changes.
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/webrev.01/
>>
>> With this change you can dump the boot class path classes again?
>>
> Yes. Also I manually checked generated classes with javap.
>
> But I'll much appreciate you if you can apply the patch and confirm that
> output is OK from compiler team point of view.
Sorry. I missed this email. Let me give it a try today.
-- Chris
>
> -Dmitry
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the source code.
From dmitry.samersoff at oracle.com Wed Sep 11 10:39:58 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 11 Sep 2013 21:39:58 +0400
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation
for invokedynamic
In-Reply-To: <1B48ECDA-FF3F-4D88-BA4A-04686C8F206E@oracle.com>
References: <52279988.6070809@oracle.com>
<48AEBE20-A4D6-43A5-8BA4-572B94C949D0@oracle.com>
<52283363.8030504@oracle.com>
<1B48ECDA-FF3F-4D88-BA4A-04686C8F206E@oracle.com>
Message-ID: <5230AAEE.3080105@oracle.com>
Thanks!
On 2013-09-11 20:37, Christian Thalinger wrote:
>
> On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff wrote:
>
>> On 2013-09-05 02:30, Christian Thalinger wrote:
>>>
>>> On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff wrote:
>>>
>>>> Please, review the changes.
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/webrev.01/
>>>
>>> With this change you can dump the boot class path classes again?
>>>
>> Yes. Also I manually checked generated classes with javap.
>>
>> But I'll much appreciate you if you can apply the patch and confirm that
>> output is OK from compiler team point of view.
>
> Sorry. I missed this email. Let me give it a try today.
>
> -- Chris
>
>>
>> -Dmitry
>>
>> --
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the source code.
>
--
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 sundararajan.athijegannathan at oracle.com Wed Sep 11 11:05:42 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 11 Sep 2013 18:05:42 +0000
Subject: hg: jdk8/tl/nashorn: 6 new changesets
Message-ID: <20130911180549.ACF6962728@hg.openjdk.java.net>
Changeset: b6c7cd8b962b
Author: jlaskey
Date: 2013-09-09 13:35 -0300
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b6c7cd8b962b
8024397: Nashorn FX Libraries need to be finalized.
Reviewed-by: sundar, hannesw, lagergren
Contributed-by: james.laskey at oracle.com
! src/jdk/nashorn/internal/runtime/resources/fx/base.js
! src/jdk/nashorn/internal/runtime/resources/fx/fxml.js
! src/jdk/nashorn/internal/runtime/resources/fx/graphics.js
! src/jdk/nashorn/internal/runtime/resources/fx/media.js
! src/jdk/nashorn/internal/runtime/resources/fx/swing.js
! src/jdk/nashorn/internal/runtime/resources/fx/swt.js
! src/jdk/nashorn/internal/runtime/resources/fx/web.js
Changeset: 483b42e56da4
Author: jlaskey
Date: 2013-09-10 14:21 -0300
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/483b42e56da4
8024539: FX Libraries update missing file
Reviewed-by: sundar
Contributed-by: james.laskey at oracle.com
! src/jdk/nashorn/internal/runtime/resources/fx/controls.js
Changeset: badf750dda21
Author: attila
Date: 2013-09-11 10:27 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/badf750dda21
8024130: We no longer need slots for temporaries in self-assign indices
Reviewed-by: jlaskey, lagergren
! src/jdk/nashorn/internal/codegen/Attr.java
Changeset: 2d4c8fa8a5f4
Author: sundar
Date: 2013-09-11 20:49 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2d4c8fa8a5f4
8024615: Refactor ScriptObjectMirror and JSObject to support external JSObject implementations
Reviewed-by: jlaskey, hannesw
! src/jdk/nashorn/api/scripting/JSObject.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeFunction.java
! src/jdk/nashorn/internal/runtime/ScriptRuntime.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java
! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java
+ src/jdk/nashorn/internal/runtime/arrays/JSObjectIterator.java
+ src/jdk/nashorn/internal/runtime/arrays/ReverseJSObjectIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java
+ test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java
! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java
Changeset: 66db7354e7e2
Author: sundar
Date: 2013-09-11 22:51 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/66db7354e7e2
8024644: PluggableJSObject.iteratingJSObjectTest fails with jdk8-tl build
Reviewed-by: jlaskey, hannesw
! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java
Changeset: aa86166c6770
Author: sundar
Date: 2013-09-11 22:53 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa86166c6770
Merge
- src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectMirrorIterator.java
- src/jdk/nashorn/internal/runtime/arrays/ScriptObjectMirrorIterator.java
From xueming.shen at oracle.com Wed Sep 11 11:29:05 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Wed, 11 Sep 2013 18:29:05 +0000
Subject: hg: jdk8/tl/jdk: 8024338: Constant fields introduced by JDK-4759491
fix in b94 are exposed as public fields in public API
Message-ID: <20130911182930.33DE56272A@hg.openjdk.java.net>
Changeset: 60b4cbdb446d
Author: sherman
Date: 2013-09-11 11:29 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60b4cbdb446d
8024338: Constant fields introduced by JDK-4759491 fix in b94 are exposed as public fields in public API
Summary: to move the new constants out of ZipConstants.java
Reviewed-by: martin
! src/share/classes/java/util/zip/ZipConstants.java
! src/share/classes/java/util/zip/ZipConstants64.java
! src/share/classes/java/util/zip/ZipEntry.java
From henry.jen at oracle.com Wed Sep 11 11:46:32 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Wed, 11 Sep 2013 18:46:32 +0000
Subject: hg: jdk8/tl/jdk: 8024500: Missing API coverage for
java.util.function.BiFunction andThen
Message-ID: <20130911184656.8E3266272B@hg.openjdk.java.net>
Changeset: 70aab3db56de
Author: henryjen
Date: 2013-09-11 11:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70aab3db56de
8024500: Missing API coverage for java.util.function.BiFunction andThen
Reviewed-by: mduigou, alanb
+ test/java/util/Collections/SingletonIterator.java
+ test/java/util/function/BiFunction/BiFunctionTest.java
From christian.thalinger at oracle.com Wed Sep 11 12:09:35 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 11 Sep 2013 12:09:35 -0700
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation for
invokedynamic
In-Reply-To: <5230AAEE.3080105@oracle.com>
References: <52279988.6070809@oracle.com>
<48AEBE20-A4D6-43A5-8BA4-572B94C949D0@oracle.com>
<52283363.8030504@oracle.com>
<1B48ECDA-FF3F-4D88-BA4A-04686C8F206E@oracle.com>
<5230AAEE.3080105@oracle.com>
Message-ID:
Yes, the dumping works but when I try to use the boot.jar file it complains about missing BootstrapMethods attributes:
$ /java/re/jdk/8/promoted/all/b95/binaries/linux-amd64/fastdebug/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid26233.log -Xbootclasspath/p:boot.jar -cp app.jar
Error occurred during initialization of VM
java/lang/ClassFormatError: Missing BootstrapMethods attribute in class file java/lang/CharSequence
Unfortunately I was expecting that.
-- Chris
On Sep 11, 2013, at 10:39 AM, Dmitry Samersoff wrote:
> Thanks!
>
>
> On 2013-09-11 20:37, Christian Thalinger wrote:
>>
>> On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff wrote:
>>
>>> On 2013-09-05 02:30, Christian Thalinger wrote:
>>>>
>>>> On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff wrote:
>>>>
>>>>> Please, review the changes.
>>>>>
>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/webrev.01/
>>>>
>>>> With this change you can dump the boot class path classes again?
>>>>
>>> Yes. Also I manually checked generated classes with javap.
>>>
>>> But I'll much appreciate you if you can apply the patch and confirm that
>>> output is OK from compiler team point of view.
>>
>> Sorry. I missed this email. Let me give it a try today.
>>
>> -- Chris
>>
>>>
>>> -Dmitry
>>>
>>> --
>>> Dmitry Samersoff
>>> Oracle Java development team, Saint Petersburg, Russia
>>> * I would love to change the world, but they won't give me the source code.
>>
>
>
> --
> 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 Wed Sep 11 12:29:50 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 11 Sep 2013 23:29:50 +0400
Subject: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation
for invokedynamic
In-Reply-To:
References: <52279988.6070809@oracle.com>
<48AEBE20-A4D6-43A5-8BA4-572B94C949D0@oracle.com>
<52283363.8030504@oracle.com>
<1B48ECDA-FF3F-4D88-BA4A-04686C8F206E@oracle.com>
<5230AAEE.3080105@oracle.com>
Message-ID: <5230C4AE.9010509@oracle.com>
Chris,
Thank you for the verification.
I withdraw this review request and will go further. Any advice is much
appreciated.
-Dmitry
On 2013-09-11 23:09, Christian Thalinger wrote:
> Yes, the dumping works but when I try to use the boot.jar file it complains about missing BootstrapMethods attributes:
>
> $ /java/re/jdk/8/promoted/all/b95/binaries/linux-amd64/fastdebug/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid26233.log -Xbootclasspath/p:boot.jar -cp app.jar
> Error occurred during initialization of VM
> java/lang/ClassFormatError: Missing BootstrapMethods attribute in class file java/lang/CharSequence
>
> Unfortunately I was expecting that.
>
> -- Chris
>
> On Sep 11, 2013, at 10:39 AM, Dmitry Samersoff wrote:
>
>> Thanks!
>>
>>
>> On 2013-09-11 20:37, Christian Thalinger wrote:
>>>
>>> On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff wrote:
>>>
>>>> On 2013-09-05 02:30, Christian Thalinger wrote:
>>>>>
>>>>> On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff wrote:
>>>>>
>>>>>> Please, review the changes.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/webrev.01/
>>>>>
>>>>> With this change you can dump the boot class path classes again?
>>>>>
>>>> Yes. Also I manually checked generated classes with javap.
>>>>
>>>> But I'll much appreciate you if you can apply the patch and confirm that
>>>> output is OK from compiler team point of view.
>>>
>>> Sorry. I missed this email. Let me give it a try today.
>>>
>>> -- Chris
>>>
>>>>
>>>> -Dmitry
>>>>
>>>> --
>>>> Dmitry Samersoff
>>>> Oracle Java development team, Saint Petersburg, Russia
>>>> * I would love to change the world, but they won't give me the source code.
>>>
>>
>>
>> --
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the sources.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From serguei.spitsyn at oracle.com Wed Sep 11 14:39:32 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 11 Sep 2013 14:39:32 -0700
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
Message-ID: <5230E314.4010508@oracle.com>
Please, review the fix for:
bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
Summary:
Handle pending exceptions instead of firing a guarantee() in the
JVMTI rewrite_cp_refs_in_method().
Testing:
UTE tests - in progress: vm.quick-pcl.testlist with limited
Metaspace memory,
nsk.jvmti.testlist,
nsk.jdi.testlist,
Jtreg java/lang/instrument
Thanks,
Serguei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130911/16a1d2a5/attachment.html
From bhavesh.x.patel at oracle.com Wed Sep 11 14:50:54 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Wed, 11 Sep 2013 21:50:54 +0000
Subject: hg: jdk8/tl/langtools: 8015496: Information that package is
deprecated is missing in profiles view
Message-ID: <20130911215105.B8C1B62734@hg.openjdk.java.net>
Changeset: cf37c3775397
Author: bpatel
Date: 2013-09-11 14:50 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf37c3775397
8015496: Information that package is deprecated is missing in profiles view
Reviewed-by: jjg
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java
+ test/com/sun/javadoc/testProfiles/profile-rtjar-includes-nopkgs.txt
From serguei.spitsyn at oracle.com Wed Sep 11 15:02:59 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 11 Sep 2013 15:02:59 -0700
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed: resolving
NULL _value' from VM_RedefineClasses::set_new_constant_pool
Message-ID: <5230E893.8040603@oracle.com>
Please, review the fix for:
bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
Summary:
The OOME's in the JVMTI merge_cp_and_rewrite and
set_new_constant_pool must be handled correctly.
Testing:
UTE tests - in progress: vm.quick-pcl.testlist with limited
Metaspace memory,
nsk.jvmti.testlist,
nsk.jdi.testlist,
Jtreg java/lang/instrument
Thanks,
Serguei
From serguei.spitsyn at oracle.com Wed Sep 11 15:13:15 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 11 Sep 2013 15:13:15 -0700
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark -
assert(!_thread->has_pending_exception())
failed: unexpected exception generated
Message-ID: <5230EAFB.5040908@oracle.com>
Please, review the fix for:
bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
Summary:
Pending exceptions must be handled properly after a call to the JVMTI
merge_cp_and_rewrite.
Testing:
UTE tests - in progress: vm.quick-pcl.testlist with limited
Metaspace memory,
nsk.jvmti.testlist,
nsk.jdi.testlist,
Jtreg java/lang/instrument
Thanks,
Serguei
From david.holmes at oracle.com Wed Sep 11 17:37:53 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 10:37:53 +1000
Subject: jmx-dev Codereview request: 8023529
OpenMBeanInfoSupport.equals/hashCode throw NPE
In-Reply-To: <523062DA.20804@oracle.com>
References: <522842DA.6010908@oracle.com> <522863F5.20709@oracle.com>
<522F2985.80207@oracle.com> <522FAFE0.1050304@oracle.com>
<52301CE0.2040407@oracle.com> <52302A38.1020800@oracle.com>
<523062DA.20804@oracle.com>
Message-ID: <52310CE1.4080207@oracle.com>
You didn't print the NPE stacktrace in OpenMBeanInfoHashCodeNPETest.java
Otherwise ok.
No need to rereview if you add the stacktrace printing.
Thanks,
David
On 11/09/2013 10:32 PM, shanliang wrote:
> David Holmes wrote:
>> Ok functional change seems fine.
>>
>> Looking at the tests a few minor nits:
>>
>> test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>>
>> 163 obj1.equals(null);
>> ...
>> 184 obj1.equals(null);
>>
>> I think line 163 can be deleted.
> Yes.
>>
>> In both tests ...
>>
>> Use spaces around the + operator in strings eg:
>>
>> "OK-1: "+obj1.get...
>>
>>
>> The message "with a null object" isn't quite reflective of what is
>> being tested. "null attribute" or even "null field" perhaps?
>>
>> When you catch NPE and report an error it would be good to also print
>> the NPE stacktrace so we can see where we hit the unexpected NPE.
> OK.
>>
>> The tests are a little verbose ie printing each successful test
>> result, but that might be normal style in this area.
> Here we need to test all fields so I print out what we test, so easy to
> check no missed.
> I get used to add more info, because sometime we miss info when a test
> fails.
>
> Here is the new version:
> http://cr.openjdk.java.net/~sjiang/jdk-8023529/02/
>
> Thanks,
> Shanliang
>
>>
>> David
>> -----
>>
>>> Thanks,
>>> Shanliang
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 11/09/2013 12:15 AM, shanliang wrote:
>>>>> Jaroslav Bachorik wrote:
>>>>>> On 09/05/2013 10:37 AM, shanliang wrote:
>>>>>>
>>>>>>> I have added 2 tasts to make sure that call
>>>>>>> OpenMBean*InfoSupport.equals/hashCode do not throw NPE
>>>>>>> The unit tests and JCK tests are passed.
>>>>>>>
>>>>>>> Webrev:http://cr.openjdk.java.net/~sjiang/JDK-8023529/00/
>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8023529
>>>>>>>
>>>>>>
>>>>>> javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
>>>>>>
>>>>>> * rename the "obj1", "obj2" parameters to something more explicit
>>>>>> - eg.
>>>>>> "referenceInfo" and "nullValueinfo" or something similar
>>>>>>
>>>>> No reference object here, the test has to call both obj1.equals and
>>>>> obj2.equals.
>>>>>> * when testing "obj.equals(null);" the messages should not contain
>>>>>> reference to the parameter since you are not, in fact, testing the
>>>>>> null
>>>>>> value of the given parameter but rather a null info object
>>>>>> * the message "got NPE if null paramer" should read "got NPE for null
>>>>>> paramter"
>>>>>>
>>>>> Right, should be "a null object" instead of "a null parameter."
>>>>>> * "Thread.sleep(100);" on line 153 is necessary?
>>>>>>
>>>>> It is not necessary for the test, removed now.
>>>>>> -----
>>>>>>
>>>>>> javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
>>>>>>
>>>>>> * the message "got NPE if null paramer" should read "got NPE for null
>>>>>> paramter"
>>>>>> * "Thread.sleep(100);" on line 143 is necessary?
>>>>>>
>>>>> Thanks for the review, here is the new version:
>>>>>
>>>>> http://cr.openjdk.java.net/~sjiang/jdk-8023529/01/
>>>>>
>>>>> Shanliang
>>>>>>
>>>>>> -JB-
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Shanliang
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>
From dmitry.samersoff at oracle.com Wed Sep 11 19:42:40 2013
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Thu, 12 Sep 2013 02:42:40 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8024056:
runtime/InitialThreadOverflow/testme.sh fails
Message-ID: <20130912024242.F137D6273B@hg.openjdk.java.net>
Changeset: 0f648fbe4404
Author: dsamersoff
Date: 2013-09-11 14:30 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0f648fbe4404
8024056: runtime/InitialThreadOverflow/testme.sh fails
Summary: on some macines gcc not able to link cxx program
Reviewed-by: dholmes
! test/runtime/InitialThreadOverflow/testme.sh
From david.holmes at oracle.com Wed Sep 11 20:45:15 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 13:45:15 +1000
Subject: RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <52308ECC.1050304@oracle.com>
References: <52308ECC.1050304@oracle.com>
Message-ID: <523138CB.9040401@oracle.com>
Hi Jaroslav,
You need a copyright notice in the new file.
As written this test can only run on a full JDK - so please add it to
the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
from the test-jdk? And use the VMOPTS passed to the test?)
Is there a reason this test can't run on OSX? I know it would need
further modification but was wondering if there is something inherent in
the test that makes it inapplicable to OSX.
I think the test would be a lot simpler if the jdk tests had the hotspot
test library's process tools available. :(
David
-----
On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
> Please, review the patch for an intermittently failing test.
>
> The test is a shell test, using files for the interprocess
> synchronization. This leads to intermittent failures.
>
> In order to fix this the test is rewritten in Java - the original
> functionality and outputs should be 100% preserved. The patch is
> unfortunately a bit difficult to follow since there is no similarity
> between the *.sh and *.java file so one needs to go through the new
> source in whole.
>
> The changes in "launcher" files are all about adding permissions to
> execute (0755) and as such the webrev shows no differences.
>
> Thanks,
>
> Issue : JDK-8004926
> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>
> -JB-
>
From david.holmes at oracle.com Wed Sep 11 20:54:07 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 13:54:07 +1000
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <5230E314.4010508@oracle.com>
References: <5230E314.4010508@oracle.com>
Message-ID: <52313ADF.2060505@oracle.com>
Hi Dmitry,
It seems odd that you install the new_method even if there was an
exception. What if the new_method is not valid because of the exception ?
Also once you've cleared the exception and returned false, the user has
no information as to why this failed. I understand we don't want to hit
the guarantee here, but it seems there is a hole in the error flow.
David
On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>
> Summary:
> Handle pending exceptions instead of firing a guarantee() in the
> JVMTI rewrite_cp_refs_in_method().
>
>
> Testing:
> UTE tests - in progress: vm.quick-pcl.testlist with limited
> Metaspace memory,
> nsk.jvmti.testlist,
> nsk.jdi.testlist,
> Jtreg java/lang/instrument
>
> Thanks,
> Serguei
From david.holmes at oracle.com Wed Sep 11 20:58:31 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 13:58:31 +1000
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52313ADF.2060505@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
Message-ID: <52313BE7.7030704@oracle.com>
On 12/09/2013 1:54 PM, David Holmes wrote:
> Hi Dmitry,
Sorry Serguei.
David
> It seems odd that you install the new_method even if there was an
> exception. What if the new_method is not valid because of the exception ?
>
> Also once you've cleared the exception and returned false, the user has
> no information as to why this failed. I understand we don't want to hit
> the guarantee here, but it seems there is a hole in the error flow.
>
> David
>
> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>
>>
>> Summary:
>> Handle pending exceptions instead of firing a guarantee() in the
>> JVMTI rewrite_cp_refs_in_method().
>>
>>
>> Testing:
>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>> Metaspace memory,
>> nsk.jvmti.testlist,
>> nsk.jdi.testlist,
>> Jtreg java/lang/instrument
>>
>> Thanks,
>> Serguei
From david.holmes at oracle.com Wed Sep 11 21:04:04 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 14:04:04 +1000
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <5230E893.8040603@oracle.com>
References: <5230E893.8040603@oracle.com>
Message-ID: <52313D34.5090605@oracle.com>
Hi Serguei,
Typo:
2489 // scratch_cp is a merged constant po/ ol
In VM_RedefineClasses::set_new_constant_pool do you not need to
de-allocate smaller_cp if you return due to an exception here:
2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, 1,
CHECK);
David
-----
On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>
>
> Summary:
> The OOME's in the JVMTI merge_cp_and_rewrite and
> set_new_constant_pool must be handled correctly.
>
>
> Testing:
> UTE tests - in progress: vm.quick-pcl.testlist with limited
> Metaspace memory,
> nsk.jvmti.testlist,
> nsk.jdi.testlist,
> Jtreg java/lang/instrument
>
> Thanks,
> Serguei
From david.holmes at oracle.com Wed Sep 11 21:09:07 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 14:09:07 +1000
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark
- assert(!_thread->has_pending_exception()) failed: unexpected
exception generated
In-Reply-To: <5230EAFB.5040908@oracle.com>
References: <5230EAFB.5040908@oracle.com>
Message-ID: <52313E63.8010904@oracle.com>
Hi Serguei,
This is more consistent with the surrounding code, but:
1. Why no RC_TRACE_WITH_THREAD for this case?
2. If an exception is pending, that isn't OOME, shouldn't "res" already
not be JVMTI_ERROR_NONE and so res should be returned in the non-OOME case?
David
On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote:
>
> Please, review the fix for:
> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
>
>
> Summary:
> Pending exceptions must be handled properly after a call to the JVMTI
> merge_cp_and_rewrite.
>
>
>
> Testing:
> UTE tests - in progress: vm.quick-pcl.testlist with limited
> Metaspace memory,
> nsk.jvmti.testlist,
> nsk.jdi.testlist,
> Jtreg java/lang/instrument
>
> Thanks,
> Serguei
>
From shanliang.jiang at oracle.com Thu Sep 12 00:41:56 2013
From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com)
Date: Thu, 12 Sep 2013 07:41:56 +0000
Subject: hg: jdk8/tl/jdk: 8023529: OpenMBeanInfoSupport.equals/hashCode throw
NPE
Message-ID: <20130912074211.8C4CB62746@hg.openjdk.java.net>
Changeset: e407df8093dc
Author: sjiang
Date: 2013-09-12 09:41 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e407df8093dc
8023529: OpenMBeanInfoSupport.equals/hashCode throw NPE
Reviewed-by: dholmes, dfuchs
! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java
+ test/javax/management/openmbean/OpenMBeanInfoEqualsNPETest.java
+ test/javax/management/openmbean/OpenMBeanInfoHashCodeNPETest.java
From chris.hegarty at oracle.com Thu Sep 12 01:12:50 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Sep 2013 09:12:50 +0100
Subject: RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <523138CB.9040401@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
Message-ID: <52317782.1060300@oracle.com>
On 09/12/2013 04:45 AM, David Holmes wrote:
> Hi Jaroslav,
>
> You need a copyright notice in the new file.
>
> As written this test can only run on a full JDK - so please add it to
> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
> from the test-jdk? And use the VMOPTS passed to the test?)
>
> Is there a reason this test can't run on OSX? I know it would need
> further modification but was wondering if there is something inherent in
> the test that makes it inapplicable to OSX.
>
> I think the test would be a lot simpler if the jdk tests had the hotspot
> test library's process tools available. :(
We have some, is there an obvious gap?
http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
-Chris.
>
> David
> -----
>
> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>> Please, review the patch for an intermittently failing test.
>>
>> The test is a shell test, using files for the interprocess
>> synchronization. This leads to intermittent failures.
>>
>> In order to fix this the test is rewritten in Java - the original
>> functionality and outputs should be 100% preserved. The patch is
>> unfortunately a bit difficult to follow since there is no similarity
>> between the *.sh and *.java file so one needs to go through the new
>> source in whole.
>>
>> The changes in "launcher" files are all about adding permissions to
>> execute (0755) and as such the webrev shows no differences.
>>
>> Thanks,
>>
>> Issue : JDK-8004926
>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>
>> -JB-
>>
From jaroslav.bachorik at oracle.com Thu Sep 12 01:22:32 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 12 Sep 2013 10:22:32 +0200
Subject: RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <52317782.1060300@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com>
Message-ID: <523179C8.50606@oracle.com>
On 09/12/2013 10:12 AM, Chris Hegarty wrote:
> On 09/12/2013 04:45 AM, David Holmes wrote:
>> Hi Jaroslav,
>>
>> You need a copyright notice in the new file.
>>
>> As written this test can only run on a full JDK - so please add it to
>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>> from the test-jdk? And use the VMOPTS passed to the test?)
>>
>> Is there a reason this test can't run on OSX? I know it would need
>> further modification but was wondering if there is something inherent in
>> the test that makes it inapplicable to OSX.
>>
>> I think the test would be a lot simpler if the jdk tests had the hotspot
>> test library's process tools available. :(
>
> We have some, is there an obvious gap?
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
Hm, thanks for the info. I should have used this library instead.
Please, stand by for the updated webrev.
-JB-
>
>
> -Chris.
>
>>
>> David
>> -----
>>
>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>> Please, review the patch for an intermittently failing test.
>>>
>>> The test is a shell test, using files for the interprocess
>>> synchronization. This leads to intermittent failures.
>>>
>>> In order to fix this the test is rewritten in Java - the original
>>> functionality and outputs should be 100% preserved. The patch is
>>> unfortunately a bit difficult to follow since there is no similarity
>>> between the *.sh and *.java file so one needs to go through the new
>>> source in whole.
>>>
>>> The changes in "launcher" files are all about adding permissions to
>>> execute (0755) and as such the webrev shows no differences.
>>>
>>> Thanks,
>>>
>>> Issue : JDK-8004926
>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>
>>> -JB-
>>>
From joe.darcy at oracle.com Thu Sep 12 01:47:32 2013
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 12 Sep 2013 08:47:32 +0000
Subject: hg: jdk8/tl/jdk: 8024643: Turn on javac lint checking in building the
jdk repo
Message-ID: <20130912084746.1C41C6274A@hg.openjdk.java.net>
Changeset: 262a625809fd
Author: darcy
Date: 2013-09-12 01:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/262a625809fd
8024643: Turn on javac lint checking in building the jdk repo
Reviewed-by: erikj, ihse, smarks
! makefiles/Setup.gmk
From david.holmes at oracle.com Thu Sep 12 03:06:56 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 20:06:56 +1000
Subject: RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <52317782.1060300@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com>
Message-ID: <52319240.9010005@oracle.com>
On 12/09/2013 6:12 PM, Chris Hegarty wrote:
> On 09/12/2013 04:45 AM, David Holmes wrote:
>> Hi Jaroslav,
>>
>> You need a copyright notice in the new file.
>>
>> As written this test can only run on a full JDK - so please add it to
>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>> from the test-jdk? And use the VMOPTS passed to the test?)
>>
>> Is there a reason this test can't run on OSX? I know it would need
>> further modification but was wondering if there is something inherent in
>> the test that makes it inapplicable to OSX.
>>
>> I think the test would be a lot simpler if the jdk tests had the hotspot
>> test library's process tools available. :(
>
> We have some, is there an obvious gap?
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
Thanks! I had managed not to find that path.
So Jaroslav may be able to use that for launching jcmd and checking
process output.
David
-----
>
> -Chris.
>
>>
>> David
>> -----
>>
>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>> Please, review the patch for an intermittently failing test.
>>>
>>> The test is a shell test, using files for the interprocess
>>> synchronization. This leads to intermittent failures.
>>>
>>> In order to fix this the test is rewritten in Java - the original
>>> functionality and outputs should be 100% preserved. The patch is
>>> unfortunately a bit difficult to follow since there is no similarity
>>> between the *.sh and *.java file so one needs to go through the new
>>> source in whole.
>>>
>>> The changes in "launcher" files are all about adding permissions to
>>> execute (0755) and as such the webrev shows no differences.
>>>
>>> Thanks,
>>>
>>> Issue : JDK-8004926
>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>
>>> -JB-
>>>
From dmitry.samersoff at oracle.com Thu Sep 12 04:43:57 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 12 Sep 2013 15:43:57 +0400
Subject: testlibrary (was Re: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out)
In-Reply-To: <52317782.1060300@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com>
Message-ID: <5231A8FD.8060603@oracle.com>
Chris,
Does I understand correctly that we have two independent copy of
testlibrary - one in hotspot workspace and other one in jdk workspace?
-Dmitry
On 2013-09-12 12:12, Chris Hegarty wrote:
> On 09/12/2013 04:45 AM, David Holmes wrote:
>> Hi Jaroslav,
>>
>> You need a copyright notice in the new file.
>>
>> As written this test can only run on a full JDK - so please add it to
>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>> from the test-jdk? And use the VMOPTS passed to the test?)
>>
>> Is there a reason this test can't run on OSX? I know it would need
>> further modification but was wondering if there is something inherent in
>> the test that makes it inapplicable to OSX.
>>
>> I think the test would be a lot simpler if the jdk tests had the hotspot
>> test library's process tools available. :(
>
> We have some, is there an obvious gap?
>
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>
>
> -Chris.
>
>>
>> David
>> -----
>>
>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>> Please, review the patch for an intermittently failing test.
>>>
>>> The test is a shell test, using files for the interprocess
>>> synchronization. This leads to intermittent failures.
>>>
>>> In order to fix this the test is rewritten in Java - the original
>>> functionality and outputs should be 100% preserved. The patch is
>>> unfortunately a bit difficult to follow since there is no similarity
>>> between the *.sh and *.java file so one needs to go through the new
>>> source in whole.
>>>
>>> The changes in "launcher" files are all about adding permissions to
>>> execute (0755) and as such the webrev shows no differences.
>>>
>>> Thanks,
>>>
>>> Issue : JDK-8004926
>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>
>>> -JB-
>>>
--
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 chris.hegarty at oracle.com Thu Sep 12 04:48:11 2013
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Sep 2013 12:48:11 +0100
Subject: testlibrary (was Re: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out)
In-Reply-To: <5231A8FD.8060603@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com> <5231A8FD.8060603@oracle.com>
Message-ID: <5231A9FB.7090401@oracle.com>
On 09/12/2013 12:43 PM, Dmitry Samersoff wrote:
> Chris,
>
> Does I understand correctly that we have two independent copy of
> testlibrary - one in hotspot workspace and other one in jdk workspace?
Unfortunately, I believe that is the case.
Are you seeing differences between them?
-Chris.
>
> -Dmitry
>
>
> On 2013-09-12 12:12, Chris Hegarty wrote:
>> On 09/12/2013 04:45 AM, David Holmes wrote:
>>> Hi Jaroslav,
>>>
>>> You need a copyright notice in the new file.
>>>
>>> As written this test can only run on a full JDK - so please add it to
>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>>> from the test-jdk? And use the VMOPTS passed to the test?)
>>>
>>> Is there a reason this test can't run on OSX? I know it would need
>>> further modification but was wondering if there is something inherent in
>>> the test that makes it inapplicable to OSX.
>>>
>>> I think the test would be a lot simpler if the jdk tests had the hotspot
>>> test library's process tools available. :(
>>
>> We have some, is there an obvious gap?
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>>
>>
>> -Chris.
>>
>>>
>>> David
>>> -----
>>>
>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>>> Please, review the patch for an intermittently failing test.
>>>>
>>>> The test is a shell test, using files for the interprocess
>>>> synchronization. This leads to intermittent failures.
>>>>
>>>> In order to fix this the test is rewritten in Java - the original
>>>> functionality and outputs should be 100% preserved. The patch is
>>>> unfortunately a bit difficult to follow since there is no similarity
>>>> between the *.sh and *.java file so one needs to go through the new
>>>> source in whole.
>>>>
>>>> The changes in "launcher" files are all about adding permissions to
>>>> execute (0755) and as such the webrev shows no differences.
>>>>
>>>> Thanks,
>>>>
>>>> Issue : JDK-8004926
>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>>
>>>> -JB-
>>>>
>
>
From david.holmes at oracle.com Thu Sep 12 05:03:45 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2013 22:03:45 +1000
Subject: testlibrary (was Re: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out)
In-Reply-To: <5231A9FB.7090401@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com> <5231A8FD.8060603@oracle.com>
<5231A9FB.7090401@oracle.com>
Message-ID: <5231ADA1.6060508@oracle.com>
On 12/09/2013 9:48 PM, Chris Hegarty wrote:
> On 09/12/2013 12:43 PM, Dmitry Samersoff wrote:
>> Chris,
>>
>> Does I understand correctly that we have two independent copy of
>> testlibrary - one in hotspot workspace and other one in jdk workspace?
>
> Unfortunately, I believe that is the case.
>
> Are you seeing differences between them?
There is now as a change has been pushed through hotspot-compiler to
hotspot-main. :( And that change is in dispute.
David
> -Chris.
>
>>
>> -Dmitry
>>
>>
>> On 2013-09-12 12:12, Chris Hegarty wrote:
>>> On 09/12/2013 04:45 AM, David Holmes wrote:
>>>> Hi Jaroslav,
>>>>
>>>> You need a copyright notice in the new file.
>>>>
>>>> As written this test can only run on a full JDK - so please add it to
>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>>>> from the test-jdk? And use the VMOPTS passed to the test?)
>>>>
>>>> Is there a reason this test can't run on OSX? I know it would need
>>>> further modification but was wondering if there is something
>>>> inherent in
>>>> the test that makes it inapplicable to OSX.
>>>>
>>>> I think the test would be a lot simpler if the jdk tests had the
>>>> hotspot
>>>> test library's process tools available. :(
>>>
>>> We have some, is there an obvious gap?
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>>>
>>>
>>>
>>> -Chris.
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>>>> Please, review the patch for an intermittently failing test.
>>>>>
>>>>> The test is a shell test, using files for the interprocess
>>>>> synchronization. This leads to intermittent failures.
>>>>>
>>>>> In order to fix this the test is rewritten in Java - the original
>>>>> functionality and outputs should be 100% preserved. The patch is
>>>>> unfortunately a bit difficult to follow since there is no similarity
>>>>> between the *.sh and *.java file so one needs to go through the new
>>>>> source in whole.
>>>>>
>>>>> The changes in "launcher" files are all about adding permissions to
>>>>> execute (0755) and as such the webrev shows no differences.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Issue : JDK-8004926
>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>>>
>>>>> -JB-
>>>>>
>>
>>
From jaroslav.bachorik at oracle.com Thu Sep 12 07:17:08 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 12 Sep 2013 16:17:08 +0200
Subject: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <523179C8.50606@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com> <523179C8.50606@oracle.com>
Message-ID: <5231CCE4.7060902@oracle.com>
On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote:
> On 09/12/2013 10:12 AM, Chris Hegarty wrote:
>> On 09/12/2013 04:45 AM, David Holmes wrote:
>>> Hi Jaroslav,
>>>
>>> You need a copyright notice in the new file.
>>>
>>> As written this test can only run on a full JDK - so please add it to
>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>>> from the test-jdk? And use the VMOPTS passed to the test?)
>>>
>>> Is there a reason this test can't run on OSX? I know it would need
>>> further modification but was wondering if there is something inherent in
>>> the test that makes it inapplicable to OSX.
>>>
>>> I think the test would be a lot simpler if the jdk tests had the hotspot
>>> test library's process tools available. :(
>>
>> We have some, is there an obvious gap?
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>
> Hm, thanks for the info. I should have used this library instead.
>
> Please, stand by for the updated webrev.
I was able to get rid off the JCMD. Using the testlibrary the target
application can recognize its own PID and print it to its stdout. The
main application then just reads the stdout to parse the PID. No need
for JCMD any more.
I could not find a way to remove the dependency on "test.jdk" system
property. According to the jtreg web documentation
(http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java"
system property should be available but in fact is not. But it seems
that the testlibrary uses "test.jdk" system property too.
The test does not run on OSX because nobody built the launcher binary :)
I think it is a kind of DIY so I took the liberty of adding a
linux-amd64 launcher while working on the test.
While working with the test library I realized I was missing a crucial
feature (at least for my purposes) - waiting for a certain message to
appear in the stdout/stderr of the launched process. Very often I need
to wait for the target process to get to certain point before the test
can be allowed to continue - and the point is indicated by a message in
stdout/stderr. Currently all the proc tools are designed to work in
"batch" mode - the whole stdout/stderr is captured in strings and
analyzed after the target process died - and are not suitable for this
kind of usage.
Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01
>
> -JB-
>
>>
>>
>> -Chris.
>>
>>>
>>> David
>>> -----
>>>
>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>>> Please, review the patch for an intermittently failing test.
>>>>
>>>> The test is a shell test, using files for the interprocess
>>>> synchronization. This leads to intermittent failures.
>>>>
>>>> In order to fix this the test is rewritten in Java - the original
>>>> functionality and outputs should be 100% preserved. The patch is
>>>> unfortunately a bit difficult to follow since there is no similarity
>>>> between the *.sh and *.java file so one needs to go through the new
>>>> source in whole.
>>>>
>>>> The changes in "launcher" files are all about adding permissions to
>>>> execute (0755) and as such the webrev shows no differences.
>>>>
>>>> Thanks,
>>>>
>>>> Issue : JDK-8004926
>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>>
>>>> -JB-
>>>>
>
From dmitry.samersoff at oracle.com Thu Sep 12 08:13:31 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 12 Sep 2013 19:13:31 +0400
Subject: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <5231CCE4.7060902@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com> <523179C8.50606@oracle.com>
<5231CCE4.7060902@oracle.com>
Message-ID: <5231DA1B.4070706@oracle.com>
Jaroslav,
CustomLauncherTest.java:
102: this check could be moved to switch at ll. 108
otherwise test fails on "sunos" and "linux" because PLATFORM remains unset.
129: I would prefer don't have pattern like this one ever in shell
script. Could you prepare a list of VM's to check and just loop over it?
It makes test better readable. Also I think nowdays we can always use
server VM.
-Dmitry
On 2013-09-12 18:17, Jaroslav Bachorik wrote:
> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote:
>> On 09/12/2013 10:12 AM, Chris Hegarty wrote:
>>> On 09/12/2013 04:45 AM, David Holmes wrote:
>>>> Hi Jaroslav,
>>>>
>>>> You need a copyright notice in the new file.
>>>>
>>>> As written this test can only run on a full JDK - so please add it to
>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>>>> from the test-jdk? And use the VMOPTS passed to the test?)
>>>>
>>>> Is there a reason this test can't run on OSX? I know it would need
>>>> further modification but was wondering if there is something inherent in
>>>> the test that makes it inapplicable to OSX.
>>>>
>>>> I think the test would be a lot simpler if the jdk tests had the hotspot
>>>> test library's process tools available. :(
>>>
>>> We have some, is there an obvious gap?
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>>
>> Hm, thanks for the info. I should have used this library instead.
>>
>> Please, stand by for the updated webrev.
>
> I was able to get rid off the JCMD. Using the testlibrary the target
> application can recognize its own PID and print it to its stdout. The
> main application then just reads the stdout to parse the PID. No need
> for JCMD any more.
>
> I could not find a way to remove the dependency on "test.jdk" system
> property. According to the jtreg web documentation
> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java"
> system property should be available but in fact is not. But it seems
> that the testlibrary uses "test.jdk" system property too.
>
> The test does not run on OSX because nobody built the launcher binary :)
> I think it is a kind of DIY so I took the liberty of adding a
> linux-amd64 launcher while working on the test.
>
> While working with the test library I realized I was missing a crucial
> feature (at least for my purposes) - waiting for a certain message to
> appear in the stdout/stderr of the launched process. Very often I need
> to wait for the target process to get to certain point before the test
> can be allowed to continue - and the point is indicated by a message in
> stdout/stderr. Currently all the proc tools are designed to work in
> "batch" mode - the whole stdout/stderr is captured in strings and
> analyzed after the target process died - and are not suitable for this
> kind of usage.
>
> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01
>
>>
>> -JB-
>>
>>>
>>>
>>> -Chris.
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>>>> Please, review the patch for an intermittently failing test.
>>>>>
>>>>> The test is a shell test, using files for the interprocess
>>>>> synchronization. This leads to intermittent failures.
>>>>>
>>>>> In order to fix this the test is rewritten in Java - the original
>>>>> functionality and outputs should be 100% preserved. The patch is
>>>>> unfortunately a bit difficult to follow since there is no similarity
>>>>> between the *.sh and *.java file so one needs to go through the new
>>>>> source in whole.
>>>>>
>>>>> The changes in "launcher" files are all about adding permissions to
>>>>> execute (0755) and as such the webrev shows no differences.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Issue : JDK-8004926
>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>>>
>>>>> -JB-
>>>>>
>>
>
--
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 Sep 12 08:24:51 2013
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Thu, 12 Sep 2013 15:24:51 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8022617: Openjdk hotspot build is broken
on BSD platforms using gcc
Message-ID: <20130912152459.0411662768@hg.openjdk.java.net>
Changeset: 1c6b721a3fbf
Author: dsamersoff
Date: 2013-09-12 15:53 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1c6b721a3fbf
8022617: Openjdk hotspot build is broken on BSD platforms using gcc
Summary: Enforce of preprocessing of all assembly sources by assembler-with-cpp
Reviewed-by: dholmes, erikj
! make/bsd/makefiles/gcc.make
From jaroslav.bachorik at oracle.com Thu Sep 12 08:31:53 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 12 Sep 2013 17:31:53 +0200
Subject: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <5231DA1B.4070706@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com> <523179C8.50606@oracle.com>
<5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com>
Message-ID: <5231DE69.7090309@oracle.com>
On 09/12/2013 05:13 PM, Dmitry Samersoff wrote:
> Jaroslav,
>
> CustomLauncherTest.java:
>
> 102: this check could be moved to switch at ll. 108
> otherwise test fails on "sunos" and "linux" because PLATFORM remains unset.
Good idea. Thanks.
>
> 129: I would prefer don't have pattern like this one ever in shell
> script. Could you prepare a list of VM's to check and just loop over it?
> It makes test better readable. Also I think nowdays we can always use
> server VM.
I tried to mirror the original shell test as closely as possible. It
would be nice if we could rely on the "server" vm only. Definitely more
readable.
-JB-
>
> -Dmitry
>
>
> On 2013-09-12 18:17, Jaroslav Bachorik wrote:
>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote:
>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote:
>>>> On 09/12/2013 04:45 AM, David Holmes wrote:
>>>>> Hi Jaroslav,
>>>>>
>>>>> You need a copyright notice in the new file.
>>>>>
>>>>> As written this test can only run on a full JDK - so please add it to
>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>>>>> from the test-jdk? And use the VMOPTS passed to the test?)
>>>>>
>>>>> Is there a reason this test can't run on OSX? I know it would need
>>>>> further modification but was wondering if there is something inherent in
>>>>> the test that makes it inapplicable to OSX.
>>>>>
>>>>> I think the test would be a lot simpler if the jdk tests had the hotspot
>>>>> test library's process tools available. :(
>>>>
>>>> We have some, is there an obvious gap?
>>>>
>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>>>
>>> Hm, thanks for the info. I should have used this library instead.
>>>
>>> Please, stand by for the updated webrev.
>>
>> I was able to get rid off the JCMD. Using the testlibrary the target
>> application can recognize its own PID and print it to its stdout. The
>> main application then just reads the stdout to parse the PID. No need
>> for JCMD any more.
>>
>> I could not find a way to remove the dependency on "test.jdk" system
>> property. According to the jtreg web documentation
>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java"
>> system property should be available but in fact is not. But it seems
>> that the testlibrary uses "test.jdk" system property too.
>>
>> The test does not run on OSX because nobody built the launcher binary :)
>> I think it is a kind of DIY so I took the liberty of adding a
>> linux-amd64 launcher while working on the test.
>>
>> While working with the test library I realized I was missing a crucial
>> feature (at least for my purposes) - waiting for a certain message to
>> appear in the stdout/stderr of the launched process. Very often I need
>> to wait for the target process to get to certain point before the test
>> can be allowed to continue - and the point is indicated by a message in
>> stdout/stderr. Currently all the proc tools are designed to work in
>> "batch" mode - the whole stdout/stderr is captured in strings and
>> analyzed after the target process died - and are not suitable for this
>> kind of usage.
>>
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01
>>
>>>
>>> -JB-
>>>
>>>>
>>>>
>>>> -Chris.
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>>>>> Please, review the patch for an intermittently failing test.
>>>>>>
>>>>>> The test is a shell test, using files for the interprocess
>>>>>> synchronization. This leads to intermittent failures.
>>>>>>
>>>>>> In order to fix this the test is rewritten in Java - the original
>>>>>> functionality and outputs should be 100% preserved. The patch is
>>>>>> unfortunately a bit difficult to follow since there is no similarity
>>>>>> between the *.sh and *.java file so one needs to go through the new
>>>>>> source in whole.
>>>>>>
>>>>>> The changes in "launcher" files are all about adding permissions to
>>>>>> execute (0755) and as such the webrev shows no differences.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Issue : JDK-8004926
>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>>>>
>>>>>> -JB-
>>>>>>
>>>
>>
>
>
From daniel.fuchs at oracle.com Thu Sep 12 08:31:00 2013
From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com)
Date: Thu, 12 Sep 2013 15:31:00 +0000
Subject: hg: jdk8/tl/jdk: 8024525: Make Logger log methods call isLoggable()
Message-ID: <20130912153131.4636262769@hg.openjdk.java.net>
Changeset: 631c8dcd91f4
Author: dfuchs
Date: 2013-09-12 17:01 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/631c8dcd91f4
8024525: Make Logger log methods call isLoggable()
Summary: This changeset makes the various Logger logging method call isLoggable() instead of inlining the level checks.
Reviewed-by: mchung, alanb
! src/share/classes/java/util/logging/Logger.java
+ test/java/util/logging/Logger/isLoggable/TestIsLoggable.java
From dmitry.samersoff at oracle.com Thu Sep 12 08:53:10 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 12 Sep 2013 19:53:10 +0400
Subject: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <5231DE69.7090309@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com> <523179C8.50606@oracle.com>
<5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com>
<5231DE69.7090309@oracle.com>
Message-ID: <5231E366.1020206@oracle.com>
Jaroslav,
I'm not sure that replacing 50 lines shell script with 250 lines Java
program we should keep it close to original. ;)
-Dmitry
On 2013-09-12 19:31, Jaroslav Bachorik wrote:
> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote:
>> Jaroslav,
>>
>> CustomLauncherTest.java:
>>
>> 102: this check could be moved to switch at ll. 108
>> otherwise test fails on "sunos" and "linux" because PLATFORM remains unset.
>
> Good idea. Thanks.
>
>>
>> 129: I would prefer don't have pattern like this one ever in shell
>> script. Could you prepare a list of VM's to check and just loop over it?
>> It makes test better readable. Also I think nowdays we can always use
>> server VM.
>
> I tried to mirror the original shell test as closely as possible. It
> would be nice if we could rely on the "server" vm only. Definitely more
> readable.
>
> -JB-
>
>>
>> -Dmitry
>>
>>
>> On 2013-09-12 18:17, Jaroslav Bachorik wrote:
>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote:
>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote:
>>>>> On 09/12/2013 04:45 AM, David Holmes wrote:
>>>>>> Hi Jaroslav,
>>>>>>
>>>>>> You need a copyright notice in the new file.
>>>>>>
>>>>>> As written this test can only run on a full JDK - so please add it to
>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>>>>>> from the test-jdk? And use the VMOPTS passed to the test?)
>>>>>>
>>>>>> Is there a reason this test can't run on OSX? I know it would need
>>>>>> further modification but was wondering if there is something inherent in
>>>>>> the test that makes it inapplicable to OSX.
>>>>>>
>>>>>> I think the test would be a lot simpler if the jdk tests had the hotspot
>>>>>> test library's process tools available. :(
>>>>>
>>>>> We have some, is there an obvious gap?
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>>>>
>>>> Hm, thanks for the info. I should have used this library instead.
>>>>
>>>> Please, stand by for the updated webrev.
>>>
>>> I was able to get rid off the JCMD. Using the testlibrary the target
>>> application can recognize its own PID and print it to its stdout. The
>>> main application then just reads the stdout to parse the PID. No need
>>> for JCMD any more.
>>>
>>> I could not find a way to remove the dependency on "test.jdk" system
>>> property. According to the jtreg web documentation
>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java"
>>> system property should be available but in fact is not. But it seems
>>> that the testlibrary uses "test.jdk" system property too.
>>>
>>> The test does not run on OSX because nobody built the launcher binary :)
>>> I think it is a kind of DIY so I took the liberty of adding a
>>> linux-amd64 launcher while working on the test.
>>>
>>> While working with the test library I realized I was missing a crucial
>>> feature (at least for my purposes) - waiting for a certain message to
>>> appear in the stdout/stderr of the launched process. Very often I need
>>> to wait for the target process to get to certain point before the test
>>> can be allowed to continue - and the point is indicated by a message in
>>> stdout/stderr. Currently all the proc tools are designed to work in
>>> "batch" mode - the whole stdout/stderr is captured in strings and
>>> analyzed after the target process died - and are not suitable for this
>>> kind of usage.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01
>>>
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>>
>>>>> -Chris.
>>>>>
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>>>>>> Please, review the patch for an intermittently failing test.
>>>>>>>
>>>>>>> The test is a shell test, using files for the interprocess
>>>>>>> synchronization. This leads to intermittent failures.
>>>>>>>
>>>>>>> In order to fix this the test is rewritten in Java - the original
>>>>>>> functionality and outputs should be 100% preserved. The patch is
>>>>>>> unfortunately a bit difficult to follow since there is no similarity
>>>>>>> between the *.sh and *.java file so one needs to go through the new
>>>>>>> source in whole.
>>>>>>>
>>>>>>> The changes in "launcher" files are all about adding permissions to
>>>>>>> execute (0755) and as such the webrev shows no differences.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Issue : JDK-8004926
>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>>>>>
>>>>>>> -JB-
>>>>>>>
>>>>
>>>
>>
>>
>
--
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 Sep 12 09:05:19 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 12 Sep 2013 18:05:19 +0200
Subject: jmx-dev RFR: 8004926
sun/management/jmxremote/bootstrap/CustomLauncherTest.sh
oftenly times out
In-Reply-To: <5231E366.1020206@oracle.com>
References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com>
<52317782.1060300@oracle.com> <523179C8.50606@oracle.com>
<5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com>
<5231DE69.7090309@oracle.com> <5231E366.1020206@oracle.com>
Message-ID: <5231E63F.7070903@oracle.com>
On 09/12/2013 05:53 PM, Dmitry Samersoff wrote:
> Jaroslav,
>
> I'm not sure that replacing 50 lines shell script with 250 lines Java
> program we should keep it close to original. ;)
Well, I've deliberately dropped the intermittent failure generator ;)
And it's 150 against 250 ...
What I meant was that reviewers were often complaining when the old and
the new version had nothing in common at all. So, when I saw something like
105 if [ ! -f "${JVMLIB}" ]; then
106 JVMLIB="${TESTJAVA}/jre/lib/${LIBARCH}/server/libjvm.so"
107 if [ ! -f "${JVMLIB}" ]; then
108 JVMLIB="${TESTJAVA}/lib/${LIBARCH}/client/libjvm.so"
109 if [ ! -f "${JVMLIB}" ]; then
110 JVMLIB="${TESTJAVA}/lib/${LIBARCH}/serevr/libjvm.so"
111 if [ ! -f "${JVMLIB}" ]; then
112 echo "Unable to locate libjvm.so in ${TESTJAVA}"
113 exit 1
114 fi
115 fi
116 fi
117 fi
I just directly copied it to java. It's nasty but at least one can see
where it came from and that it used to work before ...
But this is just nitpicking. I completely agree that it can (and should)
be made more readable. Always leave the code in the better state than
before the fix, I say.
-JB-
>
> -Dmitry
>
>
> On 2013-09-12 19:31, Jaroslav Bachorik wrote:
>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote:
>>> Jaroslav,
>>>
>>> CustomLauncherTest.java:
>>>
>>> 102: this check could be moved to switch at ll. 108
>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains unset.
>>
>> Good idea. Thanks.
>>
>>>
>>> 129: I would prefer don't have pattern like this one ever in shell
>>> script. Could you prepare a list of VM's to check and just loop over it?
>>> It makes test better readable. Also I think nowdays we can always use
>>> server VM.
>>
>> I tried to mirror the original shell test as closely as possible. It
>> would be nice if we could rely on the "server" vm only. Definitely more
>> readable.
>>
>> -JB-
>>
>>>
>>> -Dmitry
>>>
>>>
>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote:
>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote:
>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote:
>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote:
>>>>>>> Hi Jaroslav,
>>>>>>>
>>>>>>> You need a copyright notice in the new file.
>>>>>>>
>>>>>>> As written this test can only run on a full JDK - so please add it to
>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come
>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?)
>>>>>>>
>>>>>>> Is there a reason this test can't run on OSX? I know it would need
>>>>>>> further modification but was wondering if there is something inherent in
>>>>>>> the test that makes it inapplicable to OSX.
>>>>>>>
>>>>>>> I think the test would be a lot simpler if the jdk tests had the hotspot
>>>>>>> test library's process tools available. :(
>>>>>>
>>>>>> We have some, is there an obvious gap?
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/
>>>>>
>>>>> Hm, thanks for the info. I should have used this library instead.
>>>>>
>>>>> Please, stand by for the updated webrev.
>>>>
>>>> I was able to get rid off the JCMD. Using the testlibrary the target
>>>> application can recognize its own PID and print it to its stdout. The
>>>> main application then just reads the stdout to parse the PID. No need
>>>> for JCMD any more.
>>>>
>>>> I could not find a way to remove the dependency on "test.jdk" system
>>>> property. According to the jtreg web documentation
>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a "test.java"
>>>> system property should be available but in fact is not. But it seems
>>>> that the testlibrary uses "test.jdk" system property too.
>>>>
>>>> The test does not run on OSX because nobody built the launcher binary :)
>>>> I think it is a kind of DIY so I took the liberty of adding a
>>>> linux-amd64 launcher while working on the test.
>>>>
>>>> While working with the test library I realized I was missing a crucial
>>>> feature (at least for my purposes) - waiting for a certain message to
>>>> appear in the stdout/stderr of the launched process. Very often I need
>>>> to wait for the target process to get to certain point before the test
>>>> can be allowed to continue - and the point is indicated by a message in
>>>> stdout/stderr. Currently all the proc tools are designed to work in
>>>> "batch" mode - the whole stdout/stderr is captured in strings and
>>>> analyzed after the target process died - and are not suitable for this
>>>> kind of usage.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01
>>>>
>>>>>
>>>>> -JB-
>>>>>
>>>>>>
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote:
>>>>>>>> Please, review the patch for an intermittently failing test.
>>>>>>>>
>>>>>>>> The test is a shell test, using files for the interprocess
>>>>>>>> synchronization. This leads to intermittent failures.
>>>>>>>>
>>>>>>>> In order to fix this the test is rewritten in Java - the original
>>>>>>>> functionality and outputs should be 100% preserved. The patch is
>>>>>>>> unfortunately a bit difficult to follow since there is no similarity
>>>>>>>> between the *.sh and *.java file so one needs to go through the new
>>>>>>>> source in whole.
>>>>>>>>
>>>>>>>> The changes in "launcher" files are all about adding permissions to
>>>>>>>> execute (0755) and as such the webrev shows no differences.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Issue : JDK-8004926
>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00
>>>>>>>>
>>>>>>>> -JB-
>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
From roger.riggs at oracle.com Thu Sep 12 09:19:46 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Thu, 12 Sep 2013 16:19:46 +0000
Subject: hg: jdk8/tl/jdk: 8024618: Issues with French locale on compact1,
2: expected: but was:
Message-ID: <20130912162020.78E956276C@hg.openjdk.java.net>
Changeset: 672f349fbad7
Author: rriggs
Date: 2013-09-12 10:58 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/672f349fbad7
8024618: Issues with French locale on compact1,2: expected: but was:
Summary: Tests against the data of the French locale are not valid as conformance tests and are redundant with testing of the US Locale above
Reviewed-by: alanb
! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
From lance.andersen at oracle.com Thu Sep 12 10:21:06 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Thu, 12 Sep 2013 17:21:06 +0000
Subject: hg: jdk8/tl/jdk: 8015340: remove erroneous @since tag
Message-ID: <20130912172120.2783962773@hg.openjdk.java.net>
Changeset: 60d6f60416ca
Author: lancea
Date: 2013-09-12 13:20 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60d6f60416ca
8015340: remove erroneous @since tag
Reviewed-by: darcy
! src/share/classes/java/sql/PreparedStatement.java
From serguei.spitsyn at oracle.com Thu Sep 12 11:37:09 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 11:37:09 -0700
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52313BE7.7030704@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52313BE7.7030704@oracle.com>
Message-ID: <523209D5.1090101@oracle.com>
On 9/11/13 8:58 PM, David Holmes wrote:
> On 12/09/2013 1:54 PM, David Holmes wrote:
>> Hi Dmitry,
>
> Sorry Serguei.
I'm Ok. :)
Thank you for review!
Thanks,
Serguei
>
> David
>
>> It seems odd that you install the new_method even if there was an
>> exception. What if the new_method is not valid because of the
>> exception ?
>>
>> Also once you've cleared the exception and returned false, the user has
>> no information as to why this failed. I understand we don't want to hit
>> the guarantee here, but it seems there is a hole in the error flow.
>>
>> David
>>
>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>
>>>
>>>
>>> Summary:
>>> Handle pending exceptions instead of firing a guarantee() in the
>>> JVMTI rewrite_cp_refs_in_method().
>>>
>>>
>>> Testing:
>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>> Metaspace memory,
>>> nsk.jvmti.testlist,
>>> nsk.jdi.testlist,
>>> Jtreg java/lang/instrument
>>>
>>> Thanks,
>>> Serguei
From eric.mccorkle at oracle.com Thu Sep 12 11:53:25 2013
From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com)
Date: Thu, 12 Sep 2013 18:53:25 +0000
Subject: hg: jdk8/tl/langtools: 8013846: javac fails to reject semantically
equivalent generic method declarations
Message-ID: <20130912185328.60D716277E@hg.openjdk.java.net>
Changeset: 5d2d484a1216
Author: emc
Date: 2013-09-12 14:52 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5d2d484a1216
8013846: javac fails to reject semantically equivalent generic method declarations
Summary: Cause javac to consider intersection types with the same elements to be equal regardless of order.
Reviewed-by: jjg, vromero
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/neg/OrderedIntersections.java
+ test/tools/javac/generics/neg/OrderedIntersections.out
From serguei.spitsyn at oracle.com Thu Sep 12 12:21:43 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 12:21:43 -0700
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52313ADF.2060505@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
Message-ID: <52321447.4000405@oracle.com>
On 9/11/13 8:54 PM, David Holmes wrote:
> Hi Dmitry,
>
> It seems odd that you install the new_method even if there was an
> exception. What if the new_method is not valid because of the exception ?
Coleen suggested this fragment.
New methods will be deallocated with the scratch class in a case of
exception.
It is handled in the doit_prologue where the scratch classes are added
to the CL deallocation list.
>
> Also once you've cleared the exception and returned false, the user
> has no information as to why this failed. I understand we don't want
> to hit the guarantee here, but it seems there is a hole in the error
> flow.
This issue is fixed in a separate bug fix for 8024346 (see another
review request).
Sorry for the confusion here.
The whole error flow is not perfect but I'm not targetting to make it
perfect now.
Multiple bugs on the limited Metaspace topic were filed by Stefan:
8017230, 8024345, 8024346.
My role is to apply/test fixes suggested by Stefan and Coleen in the
order the issues were discovered.
Thanks,
Serguei
>
> David
>
> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>
>>
>> Summary:
>> Handle pending exceptions instead of firing a guarantee() in the
>> JVMTI rewrite_cp_refs_in_method().
>>
>>
>> Testing:
>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>> Metaspace memory,
>> nsk.jvmti.testlist,
>> nsk.jdi.testlist,
>> Jtreg java/lang/instrument
>>
>> Thanks,
>> Serguei
From stefan.karlsson at oracle.com Thu Sep 12 12:58:26 2013
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 12 Sep 2013 21:58:26 +0200
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52321447.4000405@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com>
Message-ID: <52321CE2.9020307@oracle.com>
On 9/12/13 9:21 PM, serguei.spitsyn at oracle.com wrote:
> On 9/11/13 8:54 PM, David Holmes wrote:
>> Hi Dmitry,
>>
>> It seems odd that you install the new_method even if there was an
>> exception. What if the new_method is not valid because of the
>> exception ?
>
> Coleen suggested this fragment.
> New methods will be deallocated with the scratch class in a case of
> exception.
> It is handled in the doit_prologue where the scratch classes are added
> to the CL deallocation list.
>
>>
>> Also once you've cleared the exception and returned false, the user
>> has no information as to why this failed. I understand we don't want
>> to hit the guarantee here, but it seems there is a hole in the error
>> flow.
>
> This issue is fixed in a separate bug fix for 8024346 (see another
> review request).
> Sorry for the confusion here.
>
> The whole error flow is not perfect but I'm not targetting to make it
> perfect now.
> Multiple bugs on the limited Metaspace topic were filed by Stefan:
> 8017230, 8024345, 8024346.
> My role is to apply/test fixes suggested by Stefan and Coleen in the
> order the issues were discovered.
>
Just understand that my suggested patches were just temporary patches to
get me past the bugs, not final fixes.
thanks,
StefanK
>
> Thanks,
> Serguei
>
>>
>> David
>>
>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>
>>>
>>> Summary:
>>> Handle pending exceptions instead of firing a guarantee() in the
>>> JVMTI rewrite_cp_refs_in_method().
>>>
>>>
>>> Testing:
>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>> Metaspace memory,
>>> nsk.jvmti.testlist,
>>> nsk.jdi.testlist,
>>> Jtreg java/lang/instrument
>>>
>>> Thanks,
>>> Serguei
>
From daniel.daugherty at oracle.com Thu Sep 12 13:00:39 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 12 Sep 2013 14:00:39 -0600
Subject: Code review request for Linux version id fix (6986195)
Message-ID: <52321D67.8030308@oracle.com>
Greetings,
I am sponsoring the following code review for Jerry Thornbrugh.
Since this code review request is going to two aliases, please make
sure you include BOTH aliases in your replies.
Dan
OpenJDK bug:
6986195 correctly identify Ubuntu as the operating system in crash
report instead of "Debian"
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6986195
Internal (for now) bug:
JDK-6986195 correctly identify Ubuntu as the operating system in crash
report instead of "Debian"
https://bugs.openjdk.java.net/browse/JDK-6986195
External Webrev:
http://cr.openjdk.java.net/~dcubed/for_gthornbr/6986195-webrev/
Internal Webrev:
http://javaweb.us.oracle.com/~gthornbr/6986195-webrev/
Background:
The current Linux print_distro_info() function incorrectly reports an
Ubuntu OS as a Debian
OS because it does not look for the Ubuntu release information file
(/etc/lsb-release) and
instead finds the Debian release information file (/etc/debian_version).
Because of this
Ubuntu releases are identified as Debian releases.
Here are some other issues that I have found:
The "lsb-release" file is the new Linux standard so it is now in the list.
Some Debian OS's have very poor /etc/debian_version files that report
something like "wheesy/sid".
Now a "Debian " in printed before the contents of the
/etc/debian_version file is printed for better
identification.
Some Linuxes based on Redhat have their own "xxx-release" files. Because
of this "xxx-release" files
for Redhat based linuxes should be looked for before the
"redhat-release" file.
Since Redhat has a "lsb-release" file that is not very descriptive the
"redhat-release" file needs
to be looked for before the "lsb-release" file.
I also added the "system-release" and "os-release" files since they are
an old standard.
I have complete some testing on all major Linux distributions and some
minor ones.
The differences I have found between the new and old algorithm are below:
Ubuntu Linux Mint 15
Before (using /etc/debian_version):
.
.
.
--------------- S Y S T E M ---------------
OS:wheezy/sid
.
.
.
After (using /etc/lsb-release):
.
.
.
--------------- S Y S T E M ---------------
OS:DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=15
DISTRIB_CODENAME=olivia
DISTRIB_DESCRIPTION="Linux Mint 15 Olivia"
.
.
.
Oracle Linux
Before (using /etc/redhat-release)
.
.
.
--------------- S Y S T E M ---------------
OS:Red Hat Enterprise Linux Server release 6.3 (Santiago)
.
.
.
After (using /etc/oracle-release)
.
.
.
--------------- S Y S T E M ---------------
OS:Oracle Linux Server release 6.3
.
.
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130912/f9ad0876/attachment.html
From serguei.spitsyn at oracle.com Thu Sep 12 13:03:09 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 13:03:09 -0700
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark
- assert(!_thread->has_pending_exception()) failed: unexpected
exception generated
In-Reply-To: <52313E63.8010904@oracle.com>
References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com>
Message-ID: <52321DFD.3070904@oracle.com>
On 9/11/13 9:09 PM, David Holmes wrote:
> Hi Serguei,
>
> This is more consistent with the surrounding code, but:
>
> 1. Why no RC_TRACE_WITH_THREAD for this case?
Ok, I'll add tracing code.
>
> 2. If an exception is pending, that isn't OOME, shouldn't "res"
> already not be JVMTI_ERROR_NONE and so res should be returned in the
> non-OOME case?
Initially it was my concern as well.
But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL
are expected from the merge_cp_and_rewrite().
So, it is better to keep it simple as in the webrev.
Thanks,
Serguei
>
> David
>
> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote:
>>
>> Please, review the fix for:
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
>>
>>
>>
>> Summary:
>> Pending exceptions must be handled properly after a call to the JVMTI
>> merge_cp_and_rewrite.
>>
>>
>>
>> Testing:
>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>> Metaspace memory,
>> nsk.jvmti.testlist,
>> nsk.jdi.testlist,
>> Jtreg java/lang/instrument
>>
>> Thanks,
>> Serguei
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130912/408484b0/attachment.html
From serguei.spitsyn at oracle.com Thu Sep 12 13:08:16 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 13:08:16 -0700
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52321CE2.9020307@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com> <52321CE2.9020307@oracle.com>
Message-ID: <52321F30.9030102@oracle.com>
On 9/12/13 12:58 PM, Stefan Karlsson wrote:
> On 9/12/13 9:21 PM, serguei.spitsyn at oracle.com wrote:
>> On 9/11/13 8:54 PM, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> It seems odd that you install the new_method even if there was an
>>> exception. What if the new_method is not valid because of the
>>> exception ?
>>
>> Coleen suggested this fragment.
>> New methods will be deallocated with the scratch class in a case of
>> exception.
>> It is handled in the doit_prologue where the scratch classes are
>> added to the CL deallocation list.
>>
>>>
>>> Also once you've cleared the exception and returned false, the user
>>> has no information as to why this failed. I understand we don't want
>>> to hit the guarantee here, but it seems there is a hole in the error
>>> flow.
>>
>> This issue is fixed in a separate bug fix for 8024346 (see another
>> review request).
>> Sorry for the confusion here.
>>
>> The whole error flow is not perfect but I'm not targetting to make it
>> perfect now.
>> Multiple bugs on the limited Metaspace topic were filed by Stefan:
>> 8017230, 8024345, 8024346.
>> My role is to apply/test fixes suggested by Stefan and Coleen in the
>> order the issues were discovered.
>>
> Just understand that my suggested patches were just temporary patches
> to get me past the bugs, not final fixes.
Yes, of course.
It is my resp. to double-check and make it final.
But you deserved the credit for this investigation anyway. :)
Thanks,
Serguei
>
> thanks,
> StefanK
>>
>> Thanks,
>> Serguei
>>
>>>
>>> David
>>>
>>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the fix for:
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>>
>>>>
>>>> Summary:
>>>> Handle pending exceptions instead of firing a guarantee() in the
>>>> JVMTI rewrite_cp_refs_in_method().
>>>>
>>>>
>>>> Testing:
>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>> Metaspace memory,
>>>> nsk.jvmti.testlist,
>>>> nsk.jdi.testlist,
>>>> Jtreg java/lang/instrument
>>>>
>>>> Thanks,
>>>> Serguei
>>
>
From henry.jen at oracle.com Thu Sep 12 12:36:16 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Thu, 12 Sep 2013 19:36:16 +0000
Subject: hg: jdk8/tl/jdk: 8011916: Spec update for java.util.stream; ...
Message-ID: <20130912193642.118F762781@hg.openjdk.java.net>
Changeset: be6f5f027bc2
Author: henryjen
Date: 2013-09-06 22:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be6f5f027bc2
8011916: Spec update for java.util.stream
8024339: j.u.s.Stream.reduce(BinaryOperator) throws unexpected NPE
Reviewed-by: mduigou
Contributed-by: brian.goetz at oracle.com
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/function/package-info.java
! src/share/classes/java/util/stream/BaseStream.java
! src/share/classes/java/util/stream/Collector.java
! src/share/classes/java/util/stream/Collectors.java
! 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/PipelineHelper.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/package-info.java
From daniel.daugherty at oracle.com Thu Sep 12 13:15:17 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 12 Sep 2013 14:15:17 -0600
Subject: Code review request for Linux version id fix (6986195)
In-Reply-To: <52321D67.8030308@oracle.com>
References: <52321D67.8030308@oracle.com>
Message-ID: <523220D5.7050600@oracle.com>
> http://cr.openjdk.java.net/~dcubed/for_gthornbr/6986195-webrev/
src/os/linux/vm/os_linux.cpp
No comments.
Thumbs up.
Just for the record, the internal review team was:
dcubed
dsamersoff
coleenp
iklam
Dan
On 9/12/13 2:00 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I am sponsoring the following code review for Jerry Thornbrugh.
> Since this code review request is going to two aliases, please make
> sure you include BOTH aliases in your replies.
>
> Dan
>
>
>
> OpenJDK bug:
>
> 6986195 correctly identify Ubuntu as the operating system in crash
> report instead of "Debian"
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6986195
>
> Internal (for now) bug:
>
> JDK-6986195 correctly identify Ubuntu as the operating system in crash
> report instead of "Debian"
> https://bugs.openjdk.java.net/browse/JDK-6986195
>
>
> External Webrev:
>
> http://cr.openjdk.java.net/~dcubed/for_gthornbr/6986195-webrev/
>
> Internal Webrev:
> http://javaweb.us.oracle.com/~gthornbr/6986195-webrev/
>
>
> Background:
>
> The current Linux print_distro_info() function incorrectly reports an
> Ubuntu OS as a Debian
> OS because it does not look for the Ubuntu release information file
> (/etc/lsb-release) and
> instead finds the Debian release information file
> (/etc/debian_version). Because of this
> Ubuntu releases are identified as Debian releases.
>
> Here are some other issues that I have found:
>
> The "lsb-release" file is the new Linux standard so it is now in the
> list.
>
> Some Debian OS's have very poor /etc/debian_version files that report
> something like "wheesy/sid".
> Now a "Debian " in printed before the contents of the
> /etc/debian_version file is printed for better
> identification.
>
> Some Linuxes based on Redhat have their own "xxx-release" files.
> Because of this "xxx-release" files
> for Redhat based linuxes should be looked for before the
> "redhat-release" file.
>
> Since Redhat has a "lsb-release" file that is not very descriptive the
> "redhat-release" file needs
> to be looked for before the "lsb-release" file.
>
> I also added the "system-release" and "os-release" files since they
> are an old standard.
>
> I have complete some testing on all major Linux distributions and some
> minor ones.
> The differences I have found between the new and old algorithm are below:
>
> Ubuntu Linux Mint 15
>
> Before (using /etc/debian_version):
> .
> .
> .
> --------------- S Y S T E M ---------------
>
> OS:wheezy/sid
> .
> .
> .
>
> After (using /etc/lsb-release):
> .
> .
> .
> --------------- S Y S T E M ---------------
>
> OS:DISTRIB_ID=LinuxMint
> DISTRIB_RELEASE=15
> DISTRIB_CODENAME=olivia
> DISTRIB_DESCRIPTION="Linux Mint 15 Olivia"
> .
> .
> .
>
>
>
> Oracle Linux
>
> Before (using /etc/redhat-release)
> .
> .
> .
> --------------- S Y S T E M ---------------
>
> OS:Red Hat Enterprise Linux Server release 6.3 (Santiago)
> .
> .
> .
>
> After (using /etc/oracle-release)
> .
> .
> .
> --------------- S Y S T E M ---------------
>
> OS:Oracle Linux Server release 6.3
> .
> .
> .
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130912/77263c33/attachment.html
From omajid at redhat.com Thu Sep 12 14:11:09 2013
From: omajid at redhat.com (Omair Majid)
Date: Thu, 12 Sep 2013 17:11:09 -0400
Subject: Code review request for Linux version id fix (6986195)
In-Reply-To: <52321D67.8030308@oracle.com>
References: <52321D67.8030308@oracle.com>
Message-ID: <52322DED.9040608@redhat.com>
Hi,
On 09/12/2013 04:00 PM, Daniel D. Daugherty wrote:
> The "lsb-release" file is the new Linux standard so it is now in the list.
> I also added the "system-release" and "os-release" files since they are
> an old standard.
Actually, /etc/os-release is a fairly new thing [1] that is required by
systemd. systemd is a new init system (among other things) used by a
number of newer distributions, including Fedora >= 15, RHEL 7 [2], Arch
Linux, and openSUSE [3]. So all these distributions now contain
/etc/os-release. However, even distributions like Debian and Ubuntu
(which only optionally support systemd) provide a valid /etc/os-release
file [4].
In fact, on these distributions, perhaps it should be searched first,
before any of the others. Unlike /etc/lsb-release, /etc/os-release is
always guaranteed to be present on a base install of these distributions.
I see that os_print_info is called by the error handler, so it probably
doesn't matter, but since the format of /etc/os-release is standardized,
it should be possible to seek and print just NAME and VERSION.
Thanks,
Omair
[1] http://www.freedesktop.org/software/systemd/man/os-release.html
[2]
http://rhsummit.files.wordpress.com/2013/06/poettering_f_0945_getting_ready_for_systemd-the-new-red-hat-enterprise-linux-7-service-manager.pdf
[3] http://en.wikipedia.org/wiki/Systemd
[4] https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/947236
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From dmitry.samersoff at oracle.com Thu Sep 12 14:22:54 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 13 Sep 2013 01:22:54 +0400
Subject: RR(S): JDK-8009213 sun/management/jdp/JdpTest.sh fails with exit
code 1
In-Reply-To: <52306CEA.2060208@oracle.com>
References: <52306CEA.2060208@oracle.com>
Message-ID: <523230AE.6030705@oracle.com>
Forgot to include webrev link. Sorry!
http://cr.openjdk.java.net/~dsamersoff/JDK-8009213/webrev.01/
On 2013-09-11 17:15, Dmitry Samersoff wrote:
> Please, review shell script changes.
>
> Problem:
>
> Sometimes, server process JVM start slowly than client process jvm, so
> test can't get server process pid and fails.
>
> Solution:
>
> Attempt to find server process up to 10 times, with 1 sec delay between
> attempts.
>
> -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 Thu Sep 12 14:35:13 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 14:35:13 -0700
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <52313D34.5090605@oracle.com>
References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com>
Message-ID: <52323391.3050108@oracle.com>
On 9/11/13 9:04 PM, David Holmes wrote:
> Hi Serguei,
>
> Typo:
>
> 2489 // scratch_cp is a merged constant po/ ol
Fixed, thanks!
>
>
> In VM_RedefineClasses::set_new_constant_pool do you not need to
> de-allocate smaller_cp if you return due to an exception here:
>
> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, 1,
> CHECK);
Good catch.
It is better to deallocate it even if it is not very useful.
The only exception possible here is an OOME (Metadata shortage).
Thanks,
Serguei
>
> David
> -----
>
> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>>
>>
>>
>> Summary:
>> The OOME's in the JVMTI merge_cp_and_rewrite and
>> set_new_constant_pool must be handled correctly.
>>
>>
>> Testing:
>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>> Metaspace memory,
>> nsk.jvmti.testlist,
>> nsk.jdi.testlist,
>> Jtreg java/lang/instrument
>>
>> Thanks,
>> Serguei
From vicente.romero at oracle.com Thu Sep 12 14:41:43 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Thu, 12 Sep 2013 21:41:43 +0000
Subject: hg: jdk8/tl/langtools: 8023558: Javac creates invalid bootstrap
methods for complex lambda/methodref case
Message-ID: <20130912214149.3271F6278A@hg.openjdk.java.net>
Changeset: 3ae1814f7c59
Author: vromero
Date: 2013-09-12 22:40 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ae1814f7c59
8023558: Javac creates invalid bootstrap methods for complex lambda/methodref case
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com, vicente.romero at oracle.com
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/8023558/T8023558a.java
+ test/tools/javac/lambda/8023558/T8023558b.java
+ test/tools/javac/lambda/8023558/T8023558c.java
From john.coomes at oracle.com Thu Sep 12 15:10:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 12 Sep 2013 22:10:31 +0000
Subject: hg: hsx/hotspot-rt: 2 new changesets
Message-ID: <20130912221031.8E8E7627A3@hg.openjdk.java.net>
Changeset: 0874bb4707b7
Author: omajid
Date: 2013-09-11 12:08 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/0874bb4707b7
8024320: Add s390(x) detection to platform.m4
Reviewed-by: erikj, ihse, dsamersoff
! common/autoconf/generated-configure.sh
! common/autoconf/platform.m4
Changeset: 14fe208b657c
Author: cl
Date: 2013-09-12 11:08 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/14fe208b657c
Added tag jdk8-b107 for changeset 0874bb4707b7
! .hgtags
From john.coomes at oracle.com Thu Sep 12 15:10:38 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 12 Sep 2013 22:10:38 +0000
Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b107 for changeset
23fc34133152
Message-ID: <20130912221041.B3C7A627A4@hg.openjdk.java.net>
Changeset: 260f00a95705
Author: cl
Date: 2013-09-12 11:08 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/260f00a95705
Added tag jdk8-b107 for changeset 23fc34133152
! .hgtags
From john.coomes at oracle.com Thu Sep 12 15:10:50 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 12 Sep 2013 22:10:50 +0000
Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b107 for changeset
d6a32e3831aa
Message-ID: <20130912221100.7DAD2627A5@hg.openjdk.java.net>
Changeset: 8ade3eed63da
Author: cl
Date: 2013-09-12 11:09 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/8ade3eed63da
Added tag jdk8-b107 for changeset d6a32e3831aa
! .hgtags
From john.coomes at oracle.com Thu Sep 12 15:11:10 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 12 Sep 2013 22:11:10 +0000
Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b107 for changeset
e3c9328f7563
Message-ID: <20130912221117.B2C75627A6@hg.openjdk.java.net>
Changeset: d1ea68556fd7
Author: cl
Date: 2013-09-12 11:09 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/d1ea68556fd7
Added tag jdk8-b107 for changeset e3c9328f7563
! .hgtags
From john.coomes at oracle.com Thu Sep 12 15:11:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 12 Sep 2013 22:11:31 +0000
Subject: hg: hsx/hotspot-rt/jdk: 2 new changesets
Message-ID: <20130912221258.61650627A7@hg.openjdk.java.net>
Changeset: eea685b9ccaa
Author: amurillo
Date: 2013-09-10 05:46 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eea685b9ccaa
8024515: ProblemList.txt updates to exclude tests that fail with hs25-b49
Reviewed-by: alanb, chegar
! test/ProblemList.txt
Changeset: b67c8099ba28
Author: cl
Date: 2013-09-12 11:09 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b67c8099ba28
Added tag jdk8-b107 for changeset eea685b9ccaa
! .hgtags
From john.coomes at oracle.com Thu Sep 12 15:14:07 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 12 Sep 2013 22:14:07 +0000
Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b107 for changeset
3f274927ec18
Message-ID: <20130912221420.10969627A8@hg.openjdk.java.net>
Changeset: 1b7f5a27c4ba
Author: cl
Date: 2013-09-12 11:09 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1b7f5a27c4ba
Added tag jdk8-b107 for changeset 3f274927ec18
! .hgtags
From john.coomes at oracle.com Thu Sep 12 15:14:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Thu, 12 Sep 2013 22:14:31 +0000
Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b107 for changeset
f35e1255024b
Message-ID: <20130912221435.1133B627A9@hg.openjdk.java.net>
Changeset: a1f980cc1355
Author: cl
Date: 2013-09-12 11:09 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/a1f980cc1355
Added tag jdk8-b107 for changeset f35e1255024b
! .hgtags
From serguei.spitsyn at oracle.com Thu Sep 12 17:13:43 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 17:13:43 -0700
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <52323391.3050108@oracle.com>
References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com>
<52323391.3050108@oracle.com>
Message-ID: <523258B7.4000409@oracle.com>
The updated webrev:
http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
Thanks,
Serguei
On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote:
> On 9/11/13 9:04 PM, David Holmes wrote:
>> Hi Serguei,
>>
>> Typo:
>>
>> 2489 // scratch_cp is a merged constant po/ ol
>
> Fixed, thanks!
>
>>
>>
>> In VM_RedefineClasses::set_new_constant_pool do you not need to
>> de-allocate smaller_cp if you return due to an exception here:
>>
>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp,
>> 1, CHECK);
>
> Good catch.
> It is better to deallocate it even if it is not very useful.
> The only exception possible here is an OOME (Metadata shortage).
>
>
> Thanks,
> Serguei
>
>>
>> David
>> -----
>>
>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>>>
>>>
>>>
>>> Summary:
>>> The OOME's in the JVMTI merge_cp_and_rewrite and
>>> set_new_constant_pool must be handled correctly.
>>>
>>>
>>> Testing:
>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>> Metaspace memory,
>>> nsk.jvmti.testlist,
>>> nsk.jdi.testlist,
>>> Jtreg java/lang/instrument
>>>
>>> Thanks,
>>> Serguei
>
From serguei.spitsyn at oracle.com Thu Sep 12 17:19:13 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 17:19:13 -0700
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <523258B7.4000409@oracle.com>
References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com>
<52323391.3050108@oracle.com> <523258B7.4000409@oracle.com>
Message-ID: <52325A01.9090405@oracle.com>
The update open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
Thanks,
Serguei
On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote:
> The updated webrev:
> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>
>
> Thanks,
> Serguei
>
>
> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote:
>> On 9/11/13 9:04 PM, David Holmes wrote:
>>> Hi Serguei,
>>>
>>> Typo:
>>>
>>> 2489 // scratch_cp is a merged constant po/ ol
>>
>> Fixed, thanks!
>>
>>>
>>>
>>> In VM_RedefineClasses::set_new_constant_pool do you not need to
>>> de-allocate smaller_cp if you return due to an exception here:
>>>
>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp,
>>> 1, CHECK);
>>
>> Good catch.
>> It is better to deallocate it even if it is not very useful.
>> The only exception possible here is an OOME (Metadata shortage).
>>
>>
>> Thanks,
>> Serguei
>>
>>>
>>> David
>>> -----
>>>
>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the fix for:
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>>>>
>>>>
>>>>
>>>> Summary:
>>>> The OOME's in the JVMTI merge_cp_and_rewrite and
>>>> set_new_constant_pool must be handled correctly.
>>>>
>>>>
>>>> Testing:
>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>> Metaspace memory,
>>>> nsk.jvmti.testlist,
>>>> nsk.jdi.testlist,
>>>> Jtreg java/lang/instrument
>>>>
>>>> Thanks,
>>>> Serguei
>>
>
From serguei.spitsyn at oracle.com Thu Sep 12 17:21:00 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 17:21:00 -0700
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark
- assert(!_thread->has_pending_exception()) failed: unexpected
exception generated
In-Reply-To: <52321DFD.3070904@oracle.com>
References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com>
<52321DFD.3070904@oracle.com>
Message-ID: <52325A6C.7050007@oracle.com>
The updated open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/
Thanks,
Serguei
On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote:
> On 9/11/13 9:09 PM, David Holmes wrote:
>> Hi Serguei,
>>
>> This is more consistent with the surrounding code, but:
>>
>> 1. Why no RC_TRACE_WITH_THREAD for this case?
>
> Ok, I'll add tracing code.
>
>>
>> 2. If an exception is pending, that isn't OOME, shouldn't "res"
>> already not be JVMTI_ERROR_NONE and so res should be returned in the
>> non-OOME case?
>
> Initially it was my concern as well.
> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL
> are expected from the merge_cp_and_rewrite().
> So, it is better to keep it simple as in the webrev.
>
>
> Thanks,
> Serguei
>
>>
>> David
>>
>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote:
>>>
>>> Please, review the fix for:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
>>>
>>>
>>>
>>> Summary:
>>> Pending exceptions must be handled properly after a call to the
>>> JVMTI
>>> merge_cp_and_rewrite.
>>>
>>>
>>>
>>> Testing:
>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>> Metaspace memory,
>>> nsk.jvmti.testlist,
>>> nsk.jdi.testlist,
>>> Jtreg java/lang/instrument
>>>
>>> Thanks,
>>> Serguei
>>>
>
From coleen.phillimore at oracle.com Thu Sep 12 17:47:17 2013
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Thu, 12 Sep 2013 20:47:17 -0400
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark
- assert(!_thread->has_pending_exception()) failed: unexpected
exception generated
In-Reply-To: <52325A6C.7050007@oracle.com>
References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com>
<52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com>
Message-ID: <52326095.8080702@oracle.com>
This looks good.
Coleen
On 9/12/2013 8:21 PM, serguei.spitsyn at oracle.com wrote:
> The updated open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/
>
>
> Thanks,
> Serguei
>
> On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote:
>> On 9/11/13 9:09 PM, David Holmes wrote:
>>> Hi Serguei,
>>>
>>> This is more consistent with the surrounding code, but:
>>>
>>> 1. Why no RC_TRACE_WITH_THREAD for this case?
>>
>> Ok, I'll add tracing code.
>>
>>>
>>> 2. If an exception is pending, that isn't OOME, shouldn't "res"
>>> already not be JVMTI_ERROR_NONE and so res should be returned in the
>>> non-OOME case?
>>
>> Initially it was my concern as well.
>> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL
>> are expected from the merge_cp_and_rewrite().
>> So, it is better to keep it simple as in the webrev.
>>
>>
>> Thanks,
>> Serguei
>>
>>>
>>> David
>>>
>>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote:
>>>>
>>>> Please, review the fix for:
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
>>>>
>>>>
>>>>
>>>> Summary:
>>>> Pending exceptions must be handled properly after a call to the
>>>> JVMTI
>>>> merge_cp_and_rewrite.
>>>>
>>>>
>>>>
>>>> Testing:
>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>> Metaspace memory,
>>>> nsk.jvmti.testlist,
>>>> nsk.jdi.testlist,
>>>> Jtreg java/lang/instrument
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>
>
From serguei.spitsyn at oracle.com Thu Sep 12 17:50:52 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 17:50:52 -0700
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark
- assert(!_thread->has_pending_exception()) failed: unexpected
exception generated
In-Reply-To: <52326095.8080702@oracle.com>
References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com>
<52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com>
<52326095.8080702@oracle.com>
Message-ID: <5232616C.2060400@oracle.com>
Thank you, Coleen!
Serguei
On 9/12/13 5:47 PM, Coleen Phillmore wrote:
>
> This looks good.
> Coleen
>
> On 9/12/2013 8:21 PM, serguei.spitsyn at oracle.com wrote:
>> The updated open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/
>>
>>
>> Thanks,
>> Serguei
>>
>> On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote:
>>> On 9/11/13 9:09 PM, David Holmes wrote:
>>>> Hi Serguei,
>>>>
>>>> This is more consistent with the surrounding code, but:
>>>>
>>>> 1. Why no RC_TRACE_WITH_THREAD for this case?
>>>
>>> Ok, I'll add tracing code.
>>>
>>>>
>>>> 2. If an exception is pending, that isn't OOME, shouldn't "res"
>>>> already not be JVMTI_ERROR_NONE and so res should be returned in
>>>> the non-OOME case?
>>>
>>> Initially it was my concern as well.
>>> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL
>>> are expected from the merge_cp_and_rewrite().
>>> So, it is better to keep it simple as in the webrev.
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> David
>>>>
>>>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote:
>>>>>
>>>>> Please, review the fix for:
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
>>>>>
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>> Pending exceptions must be handled properly after a call to the
>>>>> JVMTI
>>>>> merge_cp_and_rewrite.
>>>>>
>>>>>
>>>>>
>>>>> Testing:
>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>> Metaspace memory,
>>>>> nsk.jvmti.testlist,
>>>>> nsk.jdi.testlist,
>>>>> Jtreg java/lang/instrument
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>
>>
>
From coleen.phillimore at oracle.com Thu Sep 12 17:52:33 2013
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Thu, 12 Sep 2013 20:52:33 -0400
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <52325A01.9090405@oracle.com>
References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com>
<52323391.3050108@oracle.com> <523258B7.4000409@oracle.com>
<52325A01.9090405@oracle.com>
Message-ID: <523261D1.6000506@oracle.com>
This looks good too. Thanks for catching the smaller_cp case.
Coleen
On 9/12/2013 8:19 PM, serguei.spitsyn at oracle.com wrote:
> The update open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>
>
> Thanks,
> Serguei
>
>
> On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote:
>> The updated webrev:
>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote:
>>> On 9/11/13 9:04 PM, David Holmes wrote:
>>>> Hi Serguei,
>>>>
>>>> Typo:
>>>>
>>>> 2489 // scratch_cp is a merged constant po/ ol
>>>
>>> Fixed, thanks!
>>>
>>>>
>>>>
>>>> In VM_RedefineClasses::set_new_constant_pool do you not need to
>>>> de-allocate smaller_cp if you return due to an exception here:
>>>>
>>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp,
>>>> 1, CHECK);
>>>
>>> Good catch.
>>> It is better to deallocate it even if it is not very useful.
>>> The only exception possible here is an OOME (Metadata shortage).
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the fix for:
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>>>>>
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>> The OOME's in the JVMTI merge_cp_and_rewrite and
>>>>> set_new_constant_pool must be handled correctly.
>>>>>
>>>>>
>>>>> Testing:
>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>> Metaspace memory,
>>>>> nsk.jvmti.testlist,
>>>>> nsk.jdi.testlist,
>>>>> Jtreg java/lang/instrument
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>
>>
>
From serguei.spitsyn at oracle.com Thu Sep 12 17:57:05 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 17:57:05 -0700
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <523261D1.6000506@oracle.com>
References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com>
<52323391.3050108@oracle.com> <523258B7.4000409@oracle.com>
<52325A01.9090405@oracle.com> <523261D1.6000506@oracle.com>
Message-ID: <523262E1.5070609@oracle.com>
Thanks!
Serguei
On 9/12/13 5:52 PM, Coleen Phillmore wrote:
>
> This looks good too. Thanks for catching the smaller_cp case.
>
> Coleen
>
> On 9/12/2013 8:19 PM, serguei.spitsyn at oracle.com wrote:
>> The update open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote:
>>> The updated webrev:
>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote:
>>>> On 9/11/13 9:04 PM, David Holmes wrote:
>>>>> Hi Serguei,
>>>>>
>>>>> Typo:
>>>>>
>>>>> 2489 // scratch_cp is a merged constant po/ ol
>>>>
>>>> Fixed, thanks!
>>>>
>>>>>
>>>>>
>>>>> In VM_RedefineClasses::set_new_constant_pool do you not need to
>>>>> de-allocate smaller_cp if you return due to an exception here:
>>>>>
>>>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1,
>>>>> smaller_cp, 1, CHECK);
>>>>
>>>> Good catch.
>>>> It is better to deallocate it even if it is not very useful.
>>>> The only exception possible here is an OOME (Metadata shortage).
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
>>>>>> Please, review the fix for:
>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>>>>>>
>>>>>>
>>>>>> Open webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>> The OOME's in the JVMTI merge_cp_and_rewrite and
>>>>>> set_new_constant_pool must be handled correctly.
>>>>>>
>>>>>>
>>>>>> Testing:
>>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>>> Metaspace memory,
>>>>>> nsk.jvmti.testlist,
>>>>>> nsk.jdi.testlist,
>>>>>> Jtreg java/lang/instrument
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>
>>>
>>
>
From coleen.phillimore at oracle.com Thu Sep 12 18:10:39 2013
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Thu, 12 Sep 2013 21:10:39 -0400
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52321447.4000405@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com>
Message-ID: <5232660F.1050701@oracle.com>
It took me a while to remember why this change is the way it is. Why do
you clear the pending exception at line 1601?
thanks,
Coleen
On 9/12/2013 3:21 PM, serguei.spitsyn at oracle.com wrote:
> On 9/11/13 8:54 PM, David Holmes wrote:
>> Hi Dmitry,
>>
>> It seems odd that you install the new_method even if there was an
>> exception. What if the new_method is not valid because of the
>> exception ?
>
> Coleen suggested this fragment.
> New methods will be deallocated with the scratch class in a case of
> exception.
> It is handled in the doit_prologue where the scratch classes are added
> to the CL deallocation list.
>
>>
>> Also once you've cleared the exception and returned false, the user
>> has no information as to why this failed. I understand we don't want
>> to hit the guarantee here, but it seems there is a hole in the error
>> flow.
>
> This issue is fixed in a separate bug fix for 8024346 (see another
> review request).
> Sorry for the confusion here.
>
> The whole error flow is not perfect but I'm not targetting to make it
> perfect now.
> Multiple bugs on the limited Metaspace topic were filed by Stefan:
> 8017230, 8024345, 8024346.
> My role is to apply/test fixes suggested by Stefan and Coleen in the
> order the issues were discovered.
>
>
> Thanks,
> Serguei
>
>>
>> David
>>
>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>
>>>
>>> Summary:
>>> Handle pending exceptions instead of firing a guarantee() in the
>>> JVMTI rewrite_cp_refs_in_method().
>>>
>>>
>>> Testing:
>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>> Metaspace memory,
>>> nsk.jvmti.testlist,
>>> nsk.jdi.testlist,
>>> Jtreg java/lang/instrument
>>>
>>> Thanks,
>>> Serguei
>
From coleen.phillimore at oracle.com Thu Sep 12 18:22:06 2013
From: coleen.phillimore at oracle.com (Coleen Phillmore)
Date: Thu, 12 Sep 2013 21:22:06 -0400
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52321F30.9030102@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com> <52321CE2.9020307@oracle.com>
<52321F30.9030102@oracle.com>
Message-ID: <523268BE.7030902@oracle.com>
I see the answer to my question in the mail that hasn't come out yet.
The error handling in this code relies on boolean returns in order to
throw a JVMTI_ERROR code. Maybe a comment to this effect would be good
above CLEAR_PENDING_EXCEPTION. I don't need to rereview this.
> Yes, of course.
> It is my resp. to double-check and make it final.
Yes and thank you for doing the extra work to verify that the changes
that we made weren't just workarounds and are correct and tested. The
error handling here isn't very robust but that would require some
redesign to make it so.
Thanks,
Coleen
> But you deserved the credit for this investigation anyway. :)
>
> Thanks,
> Serguei
>
>>
>> thanks,
>> StefanK
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> David
>>>>
>>>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the fix for:
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>>>
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>>>
>>>>>
>>>>> Summary:
>>>>> Handle pending exceptions instead of firing a guarantee() in the
>>>>> JVMTI rewrite_cp_refs_in_method().
>>>>>
>>>>>
>>>>> Testing:
>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>> Metaspace memory,
>>>>> nsk.jvmti.testlist,
>>>>> nsk.jdi.testlist,
>>>>> Jtreg java/lang/instrument
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>
>>
>
From serguei.spitsyn at oracle.com Thu Sep 12 20:45:26 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 20:45:26 -0700
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <523268BE.7030902@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com> <52321CE2.9020307@oracle.com>
<52321F30.9030102@oracle.com> <523268BE.7030902@oracle.com>
Message-ID: <52328A56.7050003@oracle.com>
On 9/12/13 6:22 PM, Coleen Phillmore wrote:
>
> I see the answer to my question in the mail that hasn't come out
> yet. The error handling in this code relies on boolean returns in
> order to throw a JVMTI_ERROR code. Maybe a comment to this effect
> would be good above CLEAR_PENDING_EXCEPTION. I don't need to
> rereview this. temporary patches to get me past the bugs, not final fixes.
Ok, I will add a comment to this line to make it more clear.
>
> <
>>
>> Yes, of course.
>> It is my resp. to double-check and make it final.
>
> Yes and thank you for doing the extra work to verify that the changes
> that we made weren't just workarounds and are correct and tested.
> The error handling here isn't very robust but that would require some
> redesign to make it so.
Thank you for the review!
Serguei
>
> Thanks,
> Coleen
>
>> But you deserved the credit for this investigation anyway. :)
>>
>> Thanks,
>> Serguei
>>
>>>
>>> thanks,
>>> StefanK
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>>
>>>>> David
>>>>>
>>>>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>>>>> Please, review the fix for:
>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>>>>
>>>>>>
>>>>>> Open webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>> Handle pending exceptions instead of firing a guarantee() in the
>>>>>> JVMTI rewrite_cp_refs_in_method().
>>>>>>
>>>>>>
>>>>>> Testing:
>>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>>> Metaspace memory,
>>>>>> nsk.jvmti.testlist,
>>>>>> nsk.jdi.testlist,
>>>>>> Jtreg java/lang/instrument
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>
>>>
>>
>
From serguei.spitsyn at oracle.com Thu Sep 12 21:17:48 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Sep 2013 21:17:48 -0700
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <5232660F.1050701@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com> <5232660F.1050701@oracle.com>
Message-ID: <523291EC.3070007@oracle.com>
I believe, you found the answer to this in your next email.
Thanks,
Serguei
On 9/12/13 6:10 PM, Coleen Phillmore wrote:
>
> It took me a while to remember why this change is the way it is. Why
> do you clear the pending exception at line 1601?
> thanks,
> Coleen
>
> On 9/12/2013 3:21 PM, serguei.spitsyn at oracle.com wrote:
>> On 9/11/13 8:54 PM, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> It seems odd that you install the new_method even if there was an
>>> exception. What if the new_method is not valid because of the
>>> exception ?
>>
>> Coleen suggested this fragment.
>> New methods will be deallocated with the scratch class in a case of
>> exception.
>> It is handled in the doit_prologue where the scratch classes are
>> added to the CL deallocation list.
>>
>>>
>>> Also once you've cleared the exception and returned false, the user
>>> has no information as to why this failed. I understand we don't want
>>> to hit the guarantee here, but it seems there is a hole in the error
>>> flow.
>>
>> This issue is fixed in a separate bug fix for 8024346 (see another
>> review request).
>> Sorry for the confusion here.
>>
>> The whole error flow is not perfect but I'm not targetting to make it
>> perfect now.
>> Multiple bugs on the limited Metaspace topic were filed by Stefan:
>> 8017230, 8024345, 8024346.
>> My role is to apply/test fixes suggested by Stefan and Coleen in the
>> order the issues were discovered.
>>
>>
>> Thanks,
>> Serguei
>>
>>>
>>> David
>>>
>>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the fix for:
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>>
>>>>
>>>> Summary:
>>>> Handle pending exceptions instead of firing a guarantee() in the
>>>> JVMTI rewrite_cp_refs_in_method().
>>>>
>>>>
>>>> Testing:
>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>> Metaspace memory,
>>>> nsk.jvmti.testlist,
>>>> nsk.jdi.testlist,
>>>> Jtreg java/lang/instrument
>>>>
>>>> Thanks,
>>>> Serguei
>>
>
From shanliang.jiang at oracle.com Fri Sep 13 01:48:45 2013
From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com)
Date: Fri, 13 Sep 2013 08:48:45 +0000
Subject: hg: jdk8/tl/jdk: 8023669: MBean*Info.hashCode : NPE
Message-ID: <20130913084942.465AD627C9@hg.openjdk.java.net>
Changeset: ba0b95f310c8
Author: sjiang
Date: 2013-09-13 10:48 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba0b95f310c8
8023669: MBean*Info.hashCode : NPE
Reviewed-by: dholmes, dfuchs, jbachorik
! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanParameterInfo.java
+ test/javax/management/MBeanInfo/MBeanInfoHashCodeNPETest.java
From david.holmes at oracle.com Fri Sep 13 04:21:07 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Sep 2013 21:21:07 +1000
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <52321447.4000405@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com>
Message-ID: <5232F523.3090701@oracle.com>
On 13/09/2013 5:21 AM, serguei.spitsyn at oracle.com wrote:
> On 9/11/13 8:54 PM, David Holmes wrote:
>> Hi Dmitry,
>>
>> It seems odd that you install the new_method even if there was an
>> exception. What if the new_method is not valid because of the exception ?
>
> Coleen suggested this fragment.
> New methods will be deallocated with the scratch class in a case of
> exception.
> It is handled in the doit_prologue where the scratch classes are added
> to the CL deallocation list.
Ok - I'll take Coleen's word on that ;-)
>>
>> Also once you've cleared the exception and returned false, the user
>> has no information as to why this failed. I understand we don't want
>> to hit the guarantee here, but it seems there is a hole in the error
>> flow.
>
> This issue is fixed in a separate bug fix for 8024346 (see another
> review request).
> Sorry for the confusion here.
Okay.
Thanks,
David
> The whole error flow is not perfect but I'm not targetting to make it
> perfect now.
> Multiple bugs on the limited Metaspace topic were filed by Stefan:
> 8017230, 8024345, 8024346.
> My role is to apply/test fixes suggested by Stefan and Coleen in the
> order the issues were discovered.
>
>
> Thanks,
> Serguei
>
>>
>> David
>>
>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>
>>>
>>> Summary:
>>> Handle pending exceptions instead of firing a guarantee() in the
>>> JVMTI rewrite_cp_refs_in_method().
>>>
>>>
>>> Testing:
>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>> Metaspace memory,
>>> nsk.jvmti.testlist,
>>> nsk.jdi.testlist,
>>> Jtreg java/lang/instrument
>>>
>>> Thanks,
>>> Serguei
>
From david.holmes at oracle.com Fri Sep 13 04:40:13 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Sep 2013 21:40:13 +1000
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark
- assert(!_thread->has_pending_exception()) failed: unexpected
exception generated
In-Reply-To: <52325A6C.7050007@oracle.com>
References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com>
<52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com>
Message-ID: <5232F99D.90101@oracle.com>
Thanks - no further comments.
David
On 13/09/2013 10:21 AM, serguei.spitsyn at oracle.com wrote:
> The updated open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/
>
>
> Thanks,
> Serguei
>
> On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote:
>> On 9/11/13 9:09 PM, David Holmes wrote:
>>> Hi Serguei,
>>>
>>> This is more consistent with the surrounding code, but:
>>>
>>> 1. Why no RC_TRACE_WITH_THREAD for this case?
>>
>> Ok, I'll add tracing code.
>>
>>>
>>> 2. If an exception is pending, that isn't OOME, shouldn't "res"
>>> already not be JVMTI_ERROR_NONE and so res should be returned in the
>>> non-OOME case?
>>
>> Initially it was my concern as well.
>> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL
>> are expected from the merge_cp_and_rewrite().
>> So, it is better to keep it simple as in the webrev.
>>
>>
>> Thanks,
>> Serguei
>>
>>>
>>> David
>>>
>>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote:
>>>>
>>>> Please, review the fix for:
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
>>>>
>>>>
>>>>
>>>> Summary:
>>>> Pending exceptions must be handled properly after a call to the
>>>> JVMTI
>>>> merge_cp_and_rewrite.
>>>>
>>>>
>>>>
>>>> Testing:
>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>> Metaspace memory,
>>>> nsk.jvmti.testlist,
>>>> nsk.jdi.testlist,
>>>> Jtreg java/lang/instrument
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>
>
From david.holmes at oracle.com Fri Sep 13 04:41:59 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Sep 2013 21:41:59 +1000
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <52325A01.9090405@oracle.com>
References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com>
<52323391.3050108@oracle.com> <523258B7.4000409@oracle.com>
<52325A01.9090405@oracle.com>
Message-ID: <5232FA07.2060504@oracle.com>
Looks good to me.
Thanks,
David
On 13/09/2013 10:19 AM, serguei.spitsyn at oracle.com wrote:
> The update open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>
>
> Thanks,
> Serguei
>
>
> On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote:
>> The updated webrev:
>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote:
>>> On 9/11/13 9:04 PM, David Holmes wrote:
>>>> Hi Serguei,
>>>>
>>>> Typo:
>>>>
>>>> 2489 // scratch_cp is a merged constant po/ ol
>>>
>>> Fixed, thanks!
>>>
>>>>
>>>>
>>>> In VM_RedefineClasses::set_new_constant_pool do you not need to
>>>> de-allocate smaller_cp if you return due to an exception here:
>>>>
>>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp,
>>>> 1, CHECK);
>>>
>>> Good catch.
>>> It is better to deallocate it even if it is not very useful.
>>> The only exception possible here is an OOME (Metadata shortage).
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the fix for:
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>>>>>
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>> The OOME's in the JVMTI merge_cp_and_rewrite and
>>>>> set_new_constant_pool must be handled correctly.
>>>>>
>>>>>
>>>>> Testing:
>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>> Metaspace memory,
>>>>> nsk.jvmti.testlist,
>>>>> nsk.jdi.testlist,
>>>>> Jtreg java/lang/instrument
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>
>>
>
From alan.bateman at oracle.com Fri Sep 13 04:59:40 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 13 Sep 2013 11:59:40 +0000
Subject: hg: jdk8/tl/jdk: 8024009: Remove jdk.map.useRandomSeed system property
Message-ID: <20130913120014.A543F627D2@hg.openjdk.java.net>
Changeset: cc2bae7f8fbb
Author: bchristi
Date: 2013-09-12 14:22 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc2bae7f8fbb
8024009: Remove jdk.map.useRandomSeed system property
Summary: Removed usage of hashSeed in Hashtable & WeakHashMap, and removed tests
Reviewed-by: alanb, mduigou
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/WeakHashMap.java
- test/java/util/Map/CheckRandomHashSeed.java
! test/java/util/Map/Collisions.java
From chris.hegarty at oracle.com Fri Sep 13 05:14:50 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 13 Sep 2013 12:14:50 +0000
Subject: hg: jdk8/tl/jdk: 8024675:
java/net/NetworkInterface/UniqueMacAddressesTest.java fails on Windows
Message-ID: <20130913121513.9BD47627D3@hg.openjdk.java.net>
Changeset: c53411f89b4c
Author: msheppar
Date: 2013-09-13 12:20 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c53411f89b4c
8024675: java/net/NetworkInterface/UniqueMacAddressesTest.java fails on Windows
Summary: amended test to add active, i.e. isUp(), NetworkInterfaces to test list
Reviewed-by: alanb, chegar
! test/java/net/NetworkInterface/UniqueMacAddressesTest.java
From sundararajan.athijegannathan at oracle.com Fri Sep 13 05:39:17 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Fri, 13 Sep 2013 12:39:17 +0000
Subject: hg: jdk8/tl/nashorn: 5 new changesets
Message-ID: <20130913123923.3CA8C627D5@hg.openjdk.java.net>
Changeset: e60f6add90d7
Author: hannesw
Date: 2013-09-12 14:02 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e60f6add90d7
8024476: Octane regression on Richards
Reviewed-by: sundar, jlaskey
! src/jdk/nashorn/internal/runtime/JSType.java
Changeset: 572a2e50ba9e
Author: hannesw
Date: 2013-09-12 17:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/572a2e50ba9e
8024512: Regex /[^\[]/ doesn't match
Reviewed-by: jlaskey, sundar
! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8024512.js
+ test/script/basic/JDK-8024512.js.EXPECTED
Changeset: 917b16e509bd
Author: sundar
Date: 2013-09-12 22:16 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/917b16e509bd
8024693: Various minor issues with JSONWriter used by script parser API
Reviewed-by: jlaskey, hannesw
! make/build.xml
! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! test/script/basic/NASHORN-737.js
! test/script/basic/NASHORN-737.js.EXPECTED
+ test/script/basic/parser/assignmentExpr.js
+ test/script/basic/parser/assignmentExpr.js.EXPECTED
+ test/script/basic/parser/binaryExpr.js
+ test/script/basic/parser/binaryExpr.js.EXPECTED
+ test/script/basic/parser/breakStat.js
+ test/script/basic/parser/breakStat.js.EXPECTED
+ test/script/basic/parser/condExpr.js
+ test/script/basic/parser/condExpr.js.EXPECTED
+ test/script/basic/parser/continueStat.js
+ test/script/basic/parser/continueStat.js.EXPECTED
+ test/script/basic/parser/debuggerStat.js
+ test/script/basic/parser/debuggerStat.js.EXPECTED
+ test/script/basic/parser/functions.js
+ test/script/basic/parser/functions.js.EXPECTED
+ test/script/basic/parser/ifStat.js
+ test/script/basic/parser/ifStat.js.EXPECTED
+ test/script/basic/parser/labelledStat.js
+ test/script/basic/parser/labelledStat.js.EXPECTED
+ test/script/basic/parser/lhsExpr.js
+ test/script/basic/parser/lhsExpr.js.EXPECTED
+ test/script/basic/parser/loopStat.js
+ test/script/basic/parser/loopStat.js.EXPECTED
+ test/script/basic/parser/objectLitExpr.js
+ test/script/basic/parser/objectLitExpr.js.EXPECTED
+ test/script/basic/parser/parenExpr.js
+ test/script/basic/parser/parenExpr.js.EXPECTED
+ test/script/basic/parser/primaryExpr.js
+ test/script/basic/parser/primaryExpr.js.EXPECTED
+ test/script/basic/parser/returnStat.js
+ test/script/basic/parser/returnStat.js.EXPECTED
+ test/script/basic/parser/switchStat.js
+ test/script/basic/parser/switchStat.js.EXPECTED
+ test/script/basic/parser/throwStat.js
+ test/script/basic/parser/throwStat.js.EXPECTED
+ test/script/basic/parser/tryCatchStat.js
+ test/script/basic/parser/tryCatchStat.js.EXPECTED
+ test/script/basic/parser/unaryExpr.js
+ test/script/basic/parser/unaryExpr.js.EXPECTED
+ test/script/basic/parser/useStrict.js
+ test/script/basic/parser/useStrict.js.EXPECTED
+ test/script/basic/parser/util.js
+ test/script/basic/parser/varDecl.js
+ test/script/basic/parser/varDecl.js.EXPECTED
+ test/script/basic/parser/withStat.js
+ test/script/basic/parser/withStat.js.EXPECTED
Changeset: 8b0914b25430
Author: sundar
Date: 2013-09-13 16:45 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8b0914b25430
8024619: JDBC java.sql.DriverManager is not usable from JS script
Reviewed-by: jlaskey, lagergren, attila
! make/build.xml
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/ScriptLoader.java
! src/jdk/nashorn/internal/runtime/StructureLoader.java
+ test/script/basic/JDK-8024619.js
+ test/src/META-INF/services/java.sql.Driver
+ test/src/jdk/nashorn/api/NashornSQLDriver.java
Changeset: 5683eca2967a
Author: sundar
Date: 2013-09-13 17:50 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5683eca2967a
Merge
From staffan.larsen at oracle.com Fri Sep 13 08:10:27 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 13 Sep 2013 18:10:27 +0300
Subject: RR(S): JDK-8009213 sun/management/jdp/JdpTest.sh fails with exit
code 1
In-Reply-To: <523230AE.6030705@oracle.com>
References: <52306CEA.2060208@oracle.com> <523230AE.6030705@oracle.com>
Message-ID: <9812CC88-1893-4D68-A9AE-10F20970771C@oracle.com>
Looks ok.
/Staffan
On 13 sep 2013, at 00:22, Dmitry Samersoff wrote:
> Forgot to include webrev link. Sorry!
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8009213/webrev.01/
>
>
> On 2013-09-11 17:15, Dmitry Samersoff wrote:
>> Please, review shell script changes.
>>
>> Problem:
>>
>> Sometimes, server process JVM start slowly than client process jvm, so
>> test can't get server process pid and fails.
>>
>> Solution:
>>
>> Attempt to find server process up to 10 times, with 1 sec delay between
>> attempts.
>>
>> -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 Fri Sep 13 10:36:47 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 13 Sep 2013 10:36:47 -0700
Subject: Review Request (S) 8024345: 'assert(_value != NULL) failed:
resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
In-Reply-To: <5232FA07.2060504@oracle.com>
References: <5230E893.8040603@oracle.com> <52313D34.5090605@oracle.com>
<52323391.3050108@oracle.com> <523258B7.4000409@oracle.com>
<52325A01.9090405@oracle.com> <5232FA07.2060504@oracle.com>
Message-ID: <52334D2F.5080403@oracle.com>
Thank you, David!
Serguei
On 9/13/13 4:41 AM, David Holmes wrote:
> Looks good to me.
>
> Thanks,
> David
>
> On 13/09/2013 10:19 AM, serguei.spitsyn at oracle.com wrote:
>> The update open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>>
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 9/12/13 5:13 PM, serguei.spitsyn at oracle.com wrote:
>>> The updated webrev:
>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/8024345-JVMTI-MEM.2/
>>>
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 9/12/13 2:35 PM, serguei.spitsyn at oracle.com wrote:
>>>> On 9/11/13 9:04 PM, David Holmes wrote:
>>>>> Hi Serguei,
>>>>>
>>>>> Typo:
>>>>>
>>>>> 2489 // scratch_cp is a merged constant po/ ol
>>>>
>>>> Fixed, thanks!
>>>>
>>>>>
>>>>>
>>>>> In VM_RedefineClasses::set_new_constant_pool do you not need to
>>>>> de-allocate smaller_cp if you return due to an exception here:
>>>>>
>>>>> 2504 scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp,
>>>>> 1, CHECK);
>>>>
>>>> Good catch.
>>>> It is better to deallocate it even if it is not very useful.
>>>> The only exception possible here is an OOME (Metadata shortage).
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>> On 12/09/2013 8:02 AM, serguei.spitsyn at oracle.com wrote:
>>>>>> Please, review the fix for:
>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024345
>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024345
>>>>>>
>>>>>>
>>>>>> Open webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024345-JVMTI-MEM.1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>> The OOME's in the JVMTI merge_cp_and_rewrite and
>>>>>> set_new_constant_pool must be handled correctly.
>>>>>>
>>>>>>
>>>>>> Testing:
>>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>>> Metaspace memory,
>>>>>> nsk.jvmti.testlist,
>>>>>> nsk.jdi.testlist,
>>>>>> Jtreg java/lang/instrument
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>
>>>
>>
From serguei.spitsyn at oracle.com Fri Sep 13 10:37:25 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 13 Sep 2013 10:37:25 -0700
Subject: Review Request (S) 8024346: ~CautiouslyPreserveExceptionMark
- assert(!_thread->has_pending_exception()) failed: unexpected
exception generated
In-Reply-To: <5232F99D.90101@oracle.com>
References: <5230EAFB.5040908@oracle.com> <52313E63.8010904@oracle.com>
<52321DFD.3070904@oracle.com> <52325A6C.7050007@oracle.com>
<5232F99D.90101@oracle.com>
Message-ID: <52334D55.8080004@oracle.com>
Thanks!
Serguei
On 9/13/13 4:40 AM, David Holmes wrote:
> Thanks - no further comments.
>
> David
>
> On 13/09/2013 10:21 AM, serguei.spitsyn at oracle.com wrote:
>> The updated open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.2/
>>
>>
>>
>> Thanks,
>> Serguei
>>
>> On 9/12/13 1:03 PM, serguei.spitsyn at oracle.com wrote:
>>> On 9/11/13 9:09 PM, David Holmes wrote:
>>>> Hi Serguei,
>>>>
>>>> This is more consistent with the surrounding code, but:
>>>>
>>>> 1. Why no RC_TRACE_WITH_THREAD for this case?
>>>
>>> Ok, I'll add tracing code.
>>>
>>>>
>>>> 2. If an exception is pending, that isn't OOME, shouldn't "res"
>>>> already not be JVMTI_ERROR_NONE and so res should be returned in the
>>>> non-OOME case?
>>>
>>> Initially it was my concern as well.
>>> But the only JVMTI_ERROR_OUT_OF_MEMORY and JVMTI_ERROR_INTERNAL
>>> are expected from the merge_cp_and_rewrite().
>>> So, it is better to keep it simple as in the webrev.
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> David
>>>>
>>>> On 12/09/2013 8:13 AM, serguei.spitsyn at oracle.com wrote:
>>>>>
>>>>> Please, review the fix for:
>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8024346
>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8024346
>>>>>
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8024346-JVMTI-MEM.1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>> Pending exceptions must be handled properly after a call to the
>>>>> JVMTI
>>>>> merge_cp_and_rewrite.
>>>>>
>>>>>
>>>>>
>>>>> Testing:
>>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>>> Metaspace memory,
>>>>> nsk.jvmti.testlist,
>>>>> nsk.jdi.testlist,
>>>>> Jtreg java/lang/instrument
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>
>>
From serguei.spitsyn at oracle.com Fri Sep 13 10:41:23 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 13 Sep 2013 10:41:23 -0700
Subject: Review Request (S) 8017230: Internal Error
(jvmtiRedefineClasses.cpp:1662):
guarantee(false) failed: insert_space_at() failed
In-Reply-To: <5232F523.3090701@oracle.com>
References: <5230E314.4010508@oracle.com> <52313ADF.2060505@oracle.com>
<52321447.4000405@oracle.com> <5232F523.3090701@oracle.com>
Message-ID: <52334E43.4050902@oracle.com>
Thank you for the review!
Serguei
On 9/13/13 4:21 AM, David Holmes wrote:
> On 13/09/2013 5:21 AM, serguei.spitsyn at oracle.com wrote:
>> On 9/11/13 8:54 PM, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> It seems odd that you install the new_method even if there was an
>>> exception. What if the new_method is not valid because of the
>>> exception ?
>>
>> Coleen suggested this fragment.
>> New methods will be deallocated with the scratch class in a case of
>> exception.
>> It is handled in the doit_prologue where the scratch classes are added
>> to the CL deallocation list.
>
> Ok - I'll take Coleen's word on that ;-)
>
>>>
>>> Also once you've cleared the exception and returned false, the user
>>> has no information as to why this failed. I understand we don't want
>>> to hit the guarantee here, but it seems there is a hole in the error
>>> flow.
>>
>> This issue is fixed in a separate bug fix for 8024346 (see another
>> review request).
>> Sorry for the confusion here.
>
> Okay.
>
> Thanks,
> David
>
>> The whole error flow is not perfect but I'm not targetting to make it
>> perfect now.
>> Multiple bugs on the limited Metaspace topic were filed by Stefan:
>> 8017230, 8024345, 8024346.
>> My role is to apply/test fixes suggested by Stefan and Coleen in the
>> order the issues were discovered.
>>
>>
>> Thanks,
>> Serguei
>>
>>>
>>> David
>>>
>>> On 12/09/2013 7:39 AM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the fix for:
>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8017230
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8017230
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8017230-JVMTI-MEM.1
>>>>
>>>>
>>>>
>>>> Summary:
>>>> Handle pending exceptions instead of firing a guarantee() in the
>>>> JVMTI rewrite_cp_refs_in_method().
>>>>
>>>>
>>>> Testing:
>>>> UTE tests - in progress: vm.quick-pcl.testlist with limited
>>>> Metaspace memory,
>>>> nsk.jvmti.testlist,
>>>> nsk.jdi.testlist,
>>>> Jtreg java/lang/instrument
>>>>
>>>> Thanks,
>>>> Serguei
>>
From zhengyu.gu at oracle.com Fri Sep 13 10:15:24 2013
From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com)
Date: Fri, 13 Sep 2013 17:15:24 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 37 new changesets
Message-ID: <20130913171656.A4AD9627FE@hg.openjdk.java.net>
Changeset: 766fac3395d6
Author: kvn
Date: 2013-08-23 11:41 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/766fac3395d6
8012972: Incremental Inlining should support scalar replaced object in debug info
Summary: store in _first_index not absolute index but an index relative to the last (youngest) jvms->_scloff value
Reviewed-by: roland, twisti
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
Changeset: b17d8f6d9ed7
Author: kvn
Date: 2013-08-23 18:04 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b17d8f6d9ed7
8023472: C2 optimization breaks with G1
Summary: set control edge for previous value load in G1 pre-barrier
Reviewed-by: twisti
! src/share/vm/opto/graphKit.cpp
+ test/compiler/gcbarriers/G1CrashTest.java
Changeset: f98f5d48f511
Author: roland
Date: 2013-08-21 13:34 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f98f5d48f511
7199175: JSR 292: C1 needs patching when invokedynamic/invokehandle call site is not linked
Summary: Do patching rather bailing out for unlinked call with appendix
Reviewed-by: twisti, kvn
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/share/vm/c1/c1_CodeStubs.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/c1/c1_Runtime1.hpp
! src/share/vm/c1/c1_globals.cpp
! src/share/vm/c1/c1_globals.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciObjectFactory.hpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/sharedRuntime.cpp
Changeset: e1fbb86b47e4
Author: roland
Date: 2013-08-26 16:12 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e1fbb86b47e4
8016277: Crash in nmethod::is_compiled_by_c1() on x86
Summary: Method pointer for zombie methods may be invalid
Reviewed-by: kvn, coleenp
! src/share/vm/code/nmethod.cpp
Changeset: e47de6dfec5d
Author: vlivanov
Date: 2013-08-26 17:37 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e47de6dfec5d
8022456: LogCompilation tool does not work with C1 output again
Reviewed-by: kvn
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java
! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java
! src/share/vm/c1/c1_Compilation.cpp
Changeset: 74608df95ba3
Author: vlivanov
Date: 2013-08-26 17:41 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/74608df95ba3
8022595: JSR292: deadlock during class loading of MethodHandles, MethodHandleImpl & MethodHandleNatives
Reviewed-by: kvn, coleenp, dholmes
! src/share/vm/runtime/thread.cpp
+ test/compiler/jsr292/ConcurrentClassLoadingTest.java
Changeset: 022415fe638e
Author: vlivanov
Date: 2013-08-26 21:48 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/022415fe638e
Merge
Changeset: 59982ff9e0ec
Author: rbackman
Date: 2013-08-20 09:37 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/59982ff9e0ec
8022283: Assertion failed: assert(is_loaded() && field->holder()->is_loaded() && klass()->is_subclass_of (field->holder())) failed: invalid access
Reviewed-by: roland, twisti
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/ci/ciInstance.cpp
Changeset: 58e010ab2d06
Author: rbackman
Date: 2013-08-27 19:37 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58e010ab2d06
Merge
Changeset: 650868c062a9
Author: adlertz
Date: 2013-08-26 12:50 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/650868c062a9
8023691: Create interface for nodes in class Block
Summary: Create public methods for accessing the nodes in a block
Reviewed-by: kvn, roland
! src/share/vm/adlc/output_c.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
Changeset: 7181dd13a6c4
Author: adlertz
Date: 2013-08-27 21:16 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7181dd13a6c4
Merge
Changeset: 29aa8936f03c
Author: kvn
Date: 2013-08-28 11:22 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/29aa8936f03c
8023597: Optimize G1 barriers code for unsafe load_store
Summary: Avoid loading old values in G1 pre-barriers for inlined unsafe load_store nodes.
Reviewed-by: kvn, tonyp
Contributed-by: Martin Doerr
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
Changeset: 8947af8a9cec
Author: vlivanov
Date: 2013-08-29 22:44 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8947af8a9cec
8023976: assert(!CompilationPolicy::can_be_compiled(this, comp_level)) failed: sanity check
Reviewed-by: kvn, twisti
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
Changeset: 4b078f877b56
Author: adlertz
Date: 2013-09-01 19:21 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4b078f877b56
8023988: Move local scheduling of nodes to the CFG creation and code motion phase (PhaseCFG)
Summary: Moved local scheduling code from class Block to class PhaseCFG
Reviewed-by: kvn, roland
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/lcm.cpp
Changeset: 40ed2dc92a79
Author: adlertz
Date: 2013-09-01 19:52 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/40ed2dc92a79
Merge
Changeset: 27ffd1c4537b
Author: rbackman
Date: 2013-09-02 13:13 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/27ffd1c4537b
Merge
! src/share/vm/runtime/thread.cpp
Changeset: a9a968364704
Author: adlertz
Date: 2013-09-02 22:44 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a9a968364704
8024095: Missing brackets in local scheduling code.
Summary: Added brackets for if-statement
Reviewed-by: kvn, roland
! src/share/vm/opto/lcm.cpp
Changeset: 3bfb204913de
Author: adlertz
Date: 2013-09-05 10:39 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3bfb204913de
Merge
! src/share/vm/code/nmethod.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/node.hpp
Changeset: 88c255656030
Author: mgerdin
Date: 2013-08-22 10:50 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/88c255656030
8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld
Summary: When using NUMA and large pages we need to ease the requirement on which node the memory should be allocated on. To avoid the SIGBUS we now use the memory policy MPOL_PREFERRED, which prefers a certain node, instead of MPOL_BIND, which requires a certain node.
Reviewed-by: jmasa, pliden
Contributed-by: stefan.johansson at oracle.com
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
Changeset: 0d59407e7e09
Author: jmasa
Date: 2013-08-29 06:53 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0d59407e7e09
Merge
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
Changeset: 84683e78e713
Author: brutisso
Date: 2013-08-30 07:31 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/84683e78e713
8019902: G1: Use the average heap size rather than the minimum heap size to calculate the region size
Reviewed-by: tonyp, tschatzl, sjohanss
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
Changeset: f175e3678be2
Author: ehelin
Date: 2013-08-22 11:23 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f175e3678be2
8020692: TestGCEventMixed.java failed because of timestamp in event after end event
Reviewed-by: mgerdin, stefank
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/shared/gcTraceSend.cpp
Changeset: a701c16e8bbf
Author: jmasa
Date: 2013-09-04 11:41 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a701c16e8bbf
8013938: Native OOME on fastdebug VM on Solaris
Reviewed-by: azeemj, brutisso, kvn, tschatzl
! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
Changeset: 428025878417
Author: jmasa
Date: 2013-09-04 12:56 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/428025878417
Merge
Changeset: bb57d48691f5
Author: tschatzl
Date: 2013-09-05 14:15 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bb57d48691f5
Merge
! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
Changeset: 3f4392035ec7
Author: cl
Date: 2013-09-05 02:45 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3f4392035ec7
Added tag jdk8-b106 for changeset aed585cafc0d
! .hgtags
Changeset: 50794d8ac11c
Author: amurillo
Date: 2013-09-06 11:04 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/50794d8ac11c
Merge
- src/share/vm/classfile/genericSignatures.cpp
- src/share/vm/classfile/genericSignatures.hpp
Changeset: 5b7f90aab3ad
Author: amurillo
Date: 2013-09-06 11:04 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b7f90aab3ad
Added tag hs25-b49 for changeset 50794d8ac11c
! .hgtags
Changeset: 313b724f8911
Author: amurillo
Date: 2013-09-06 11:11 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/313b724f8911
8024258: new hotspot build - hs25-b50
Reviewed-by: jcoomes
! make/hotspot_version
Changeset: ceda33ff54a3
Author: iignatyev
Date: 2013-09-05 16:38 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ceda33ff54a3
8012447: Java CTW implementation
Reviewed-by: vlivanov, kvn, twisti
! test/gc/TestVerifyDuringStartup.java
! test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java
+ test/testlibrary/ctw/Makefile
+ test/testlibrary/ctw/README
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java
+ test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java
+ test/testlibrary/ctw/test/Bar.java
+ test/testlibrary/ctw/test/ClassesDirTest.java
+ test/testlibrary/ctw/test/ClassesListTest.java
+ test/testlibrary/ctw/test/CtwTest.java
+ test/testlibrary/ctw/test/Foo.java
+ test/testlibrary/ctw/test/JarDirTest.java
+ test/testlibrary/ctw/test/JarsTest.java
+ test/testlibrary/ctw/test/classes.lst
+ test/testlibrary/whitebox/Makefile
Changeset: cd16d587b0fa
Author: adlertz
Date: 2013-09-09 19:53 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd16d587b0fa
Merge
Changeset: 72a567cce06f
Author: anoll
Date: 2013-09-10 07:51 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/72a567cce06f
8024473: Remove unused macro: IRT_ENTRY_FOR_NMETHOD
Summary: Removed unused macro
Reviewed-by: kvn, adlertz
! src/share/vm/runtime/interfaceSupport.hpp
Changeset: edb5ab0f3fe5
Author: vlivanov
Date: 2013-09-10 14:51 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/edb5ab0f3fe5
8001107: @Stable annotation for constant folding of lazily evaluated variables
Reviewed-by: rbackman, twisti, kvn
Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com
! src/share/vm/ci/ciArray.cpp
! src/share/vm/ci/ciArray.hpp
! src/share/vm/ci/ciConstant.hpp
! src/share/vm/ci/ciField.cpp
! src/share/vm/ci/ciField.hpp
! src/share/vm/ci/ciFlags.hpp
! src/share/vm/ci/ciInstance.cpp
! src/share/vm/ci/ciTypeArray.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/fieldInfo.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/accessFlags.hpp
Changeset: e0d33d2ce5aa
Author: vlivanov
Date: 2013-09-10 15:28 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e0d33d2ce5aa
Merge
Changeset: 34bd5e86aadb
Author: adlertz
Date: 2013-09-11 09:34 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/34bd5e86aadb
8010941: MinJumpTableSize is set to 18, investigate if that's still optimal
Summary: Lowered the MinJumpTableSize for each platform
Reviewed-by: kvn
! src/cpu/sparc/vm/c2_globals_sparc.hpp
! src/cpu/x86/vm/c2_globals_x86.hpp
! src/share/vm/opto/c2_globals.hpp
Changeset: 0821b5d72ca8
Author: adlertz
Date: 2013-09-12 09:10 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0821b5d72ca8
Merge
Changeset: 225cedaf9a4b
Author: zgu
Date: 2013-09-13 10:34 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/225cedaf9a4b
Merge
! src/share/vm/classfile/classFileParser.cpp
From mike.duigou at oracle.com Fri Sep 13 12:02:30 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 13 Sep 2013 19:02:30 +0000
Subject: hg: jdk8/tl/jdk: 3 new changesets
Message-ID: <20130913190310.4344162806@hg.openjdk.java.net>
Changeset: c65848f2b6a1
Author: mduigou
Date: 2013-09-13 11:18 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c65848f2b6a1
8021591: Additional explicit null checks
Reviewed-by: psandoz, alanb
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/IdentityHashMap.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/javax/security/auth/Subject.java
! test/java/util/Collection/CollectionDefaults.java
- test/java/util/Collection/ListDefaults.java
! test/java/util/Collection/MOAT.java
! test/java/util/Collection/testlibrary/CollectionAsserts.java
! test/java/util/Collection/testlibrary/CollectionSupplier.java
+ test/java/util/Collection/testlibrary/ExtendsAbstractCollection.java
+ test/java/util/Collection/testlibrary/ExtendsAbstractList.java
+ test/java/util/Collection/testlibrary/ExtendsAbstractSet.java
+ test/java/util/List/ListDefaults.java
! test/java/util/Map/Defaults.java
Changeset: 973fdd9506b2
Author: mduigou
Date: 2013-09-13 11:19 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/973fdd9506b2
8024014: TEST.groups - split sub-groups for jdk_collections, jdk_stream, jdk_concurrent, jdk_util_other from jdk_util
Reviewed-by: mchung, dholmes, alanb
! test/TEST.groups
Changeset: 5f81a12fed4d
Author: bchristi
Date: 2013-09-13 11:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f81a12fed4d
7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]
Summary: On MacOS X set user.home to value of NSHomeDirectory()
Reviewed-by: alanb, ddehaven, mduigou
! make/common/Defs-macosx.gmk
! make/java/java/Makefile
! makefiles/CompileNativeLibraries.gmk
! src/solaris/native/java/lang/java_props_macosx.c
! src/solaris/native/java/lang/java_props_macosx.h
! src/solaris/native/java/lang/java_props_md.c
From mike.duigou at oracle.com Fri Sep 13 12:07:28 2013
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Fri, 13 Sep 2013 19:07:28 +0000
Subject: hg: jdk8/tl: 8024201: Update bugdatabase url
Message-ID: <20130913190729.46E1562807@hg.openjdk.java.net>
Changeset: 67f64101616e
Author: mduigou
Date: 2013-09-13 12:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/rev/67f64101616e
8024201: Update bugdatabase url
Reviewed-by: wetmore
! make/scripts/webrev.ksh
From markus.gronlund at oracle.com Fri Sep 13 16:49:31 2013
From: markus.gronlund at oracle.com (markus.gronlund at oracle.com)
Date: Fri, 13 Sep 2013 23:49:31 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130913234938.1738E62813@hg.openjdk.java.net>
Changeset: 623d923529df
Author: mgronlun
Date: 2013-09-13 17:47 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/623d923529df
8021353: Event based tracing is missing thread exit
Reviewed-by: allwin, acorn, dcubed, dholmes, egahlin
! src/share/vm/runtime/thread.cpp
! src/share/vm/trace/traceMacros.hpp
Changeset: b89a1a870965
Author: mgronlun
Date: 2013-09-13 19:20 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b89a1a870965
Merge
! src/share/vm/runtime/thread.cpp
From lance.andersen at oracle.com Fri Sep 13 16:10:58 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Fri, 13 Sep 2013 23:10:58 +0000
Subject: hg: jdk8/tl/jdk: 8014967: EBehavior of
DriverManager.registerDriver(dr) is unspecified if driver is null
Message-ID: <20130913231124.2D25B6280E@hg.openjdk.java.net>
Changeset: 5c7690923663
Author: lancea
Date: 2013-09-13 19:10 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c7690923663
8014967: EBehavior of DriverManager.registerDriver(dr) is unspecified if driver is null
Reviewed-by: alanb
! src/share/classes/java/sql/DriverManager.java
From henry.jen at oracle.com Fri Sep 13 18:51:41 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Sat, 14 Sep 2013 01:51:41 +0000
Subject: hg: jdk8/tl/jdk: 8024825: Some fixes are missing from
java.util.stream spec update
Message-ID: <20130914015206.8D45562818@hg.openjdk.java.net>
Changeset: a7980b099af1
Author: henryjen
Date: 2013-09-06 15:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7980b099af1
8024825: Some fixes are missing from java.util.stream spec update
Reviewed-by: mduigou
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/package-info.java
From serguei.spitsyn at oracle.com Fri Sep 13 22:09:26 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Sat, 14 Sep 2013 05:09:26 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 4 new changesets
Message-ID: <20130914050953.6391C62821@hg.openjdk.java.net>
Changeset: ff8a09595db3
Author: sspitsyn
Date: 2013-09-13 12:46 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ff8a09595db3
8017230: Internal Error (jvmtiRedefineClasses.cpp:1662): guarantee(false) failed: insert_space_at() failed
Summary: Handle pending exceptions instead of firing a guarantee()
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com
! src/share/vm/prims/jvmtiRedefineClasses.cpp
Changeset: ce5ee9de50ce
Author: sspitsyn
Date: 2013-09-13 12:47 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ce5ee9de50ce
8024345: 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
Summary: The OOME's in the JVMTI merge_cp_and_rewrite and set_new_constant_pool must be handled correctly
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com
! src/share/vm/prims/jvmtiRedefineClasses.cpp
Changeset: 0d3ff4d36a31
Author: sspitsyn
Date: 2013-09-13 12:48 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0d3ff4d36a31
8024346: ~CautiouslyPreserveExceptionMark - assert(!_thread->has_pending_exception()) failed: unexpected exception generated
Summary: Pending exceptions must be handled properly after a call to the JVMTI merge_cp_and_rewrite
Reviewed-by: coleenp, dholmes
Contributed-by: serguei.spitsyn at oracle.com
! src/share/vm/prims/jvmtiRedefineClasses.cpp
Changeset: b135b600a66c
Author: sspitsyn
Date: 2013-09-13 16:56 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b135b600a66c
Merge
From vicente.romero at oracle.com Sat Sep 14 07:25:15 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 14 Sep 2013 14:25:15 +0000
Subject: hg: jdk8/tl/langtools: 8024207: javac crash in
Flow.AssignAnalyzer.visitIdent
Message-ID: <20130914142518.A4D456282D@hg.openjdk.java.net>
Changeset: 03c26c60499c
Author: vromero
Date: 2013-09-14 15:23 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/03c26c60499c
8024207: javac crash in Flow.AssignAnalyzer.visitIdent
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/T8024207/FlowCrashTest.java
+ test/tools/javac/T8024207/FlowCrashTest.out
From roger.riggs at oracle.com Sat Sep 14 11:14:02 2013
From: roger.riggs at oracle.com (roger.riggs at oracle.com)
Date: Sat, 14 Sep 2013 18:14:02 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20130914181439.5FDCF62830@hg.openjdk.java.net>
Changeset: 3255a4e348a1
Author: rriggs
Date: 2013-09-14 13:55 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3255a4e348a1
8023639: Difference between LocalTime.now(Clock.systemDefaultZone()) and LocalTime.now() executed successively is more than 100 000 000 nanoseconds for slow machines
Summary: Test timed out on a slow machine; it is not a conformance test and should be in the test subtree
Reviewed-by: darcy, sherman
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/test/java/time/TestLocalTime.java
Changeset: 35bb1c7f227c
Author: rriggs
Date: 2013-09-14 13:55 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35bb1c7f227c
8023556: Update javadoc for start of Meiji era
Summary: correct the javadoc in JapaneseEra.MEIJI to match the implementation
Reviewed-by: darcy, sherman
! src/share/classes/java/time/chrono/JapaneseEra.java
! test/java/time/test/java/time/TestLocalTime.java
From vicente.romero at oracle.com Sat Sep 14 11:21:30 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Sat, 14 Sep 2013 18:21:30 +0000
Subject: hg: jdk8/tl/langtools: 7047734: javac,
the LVT is not generated correctly in several scenarios
Message-ID: <20130914182133.5A34462831@hg.openjdk.java.net>
Changeset: 4932bb04c4b8
Author: vromero
Date: 2013-09-14 19:04 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4932bb04c4b8
7047734: javac, the LVT is not generated correctly in several scenarios
Reviewed-by: jjg, mcimadamore
! src/share/classes/com/sun/tools/javac/code/Lint.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/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
+ src/share/classes/com/sun/tools/javac/jvm/LVTRanges.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/util/Bits.java
+ test/tools/javac/flow/AliveRanges.java
+ test/tools/javac/flow/LVTHarness.java
+ test/tools/javac/flow/tests/TestCaseConditional.java
+ test/tools/javac/flow/tests/TestCaseDoLoop.java
+ test/tools/javac/flow/tests/TestCaseFor.java
+ test/tools/javac/flow/tests/TestCaseForEach.java
+ test/tools/javac/flow/tests/TestCaseIf.java
+ test/tools/javac/flow/tests/TestCaseIfElse.java
+ test/tools/javac/flow/tests/TestCaseSwitch.java
+ test/tools/javac/flow/tests/TestCaseTry.java
+ test/tools/javac/flow/tests/TestCaseWhile.java
From dmitry.samersoff at oracle.com Sun Sep 15 05:59:27 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sun, 15 Sep 2013 16:59:27 +0400
Subject: RR(S): JDK-7133122 SA throws
sun.jvm.hotspot.debugger.UnmappedAddressException when it should not
Message-ID: <5235AF2F.7090105@oracle.com>
Hi Everybody,
http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
Please review the small fix. This patch was contributed by Yasumasa Suenaga.
-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 paul.sandoz at oracle.com Sun Sep 15 06:43:35 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Sun, 15 Sep 2013 13:43:35 +0000
Subject: hg: jdk8/tl/jdk: 8010293:
java/util/concurrent/ConcurrentHashMap/toArray.java fails
intermittently
Message-ID: <20130915134420.CAF1B6284C@hg.openjdk.java.net>
Changeset: ff6c76f7733e
Author: psandoz
Date: 2013-09-02 11:59 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff6c76f7733e
8010293: java/util/concurrent/ConcurrentHashMap/toArray.java fails intermittently
Reviewed-by: forax, chegar, alanb
Contributed-by: Doug Lea , Peter Levart , Paul Sandoz
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! test/java/util/concurrent/ConcurrentHashMap/toArray.java
From paul.sandoz at oracle.com Sun Sep 15 07:18:45 2013
From: paul.sandoz at oracle.com (paul.sandoz at oracle.com)
Date: Sun, 15 Sep 2013 14:18:45 +0000
Subject: hg: jdk8/tl/jdk: 8024837: Rename
java/util/concurrent/ConcurrentHashMap/toArray.java to ToArray.java
Message-ID: <20130915141900.C95516284D@hg.openjdk.java.net>
Changeset: 5025ed287a4a
Author: psandoz
Date: 2013-09-15 16:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5025ed287a4a
8024837: Rename java/util/concurrent/ConcurrentHashMap/toArray.java to ToArray.java
Reviewed-by: alanb
! test/java/util/concurrent/ConcurrentHashMap/ToArray.java < test/java/util/concurrent/ConcurrentHashMap/toArray.java
From xueming.shen at oracle.com Sun Sep 15 11:14:13 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sun, 15 Sep 2013 18:14:13 +0000
Subject: hg: jdk8/tl/jdk: 7186311: (props) "Unicode" is misspelled as
"Uniocde" in JavaDoc and error message
Message-ID: <20130915181435.EEA0762851@hg.openjdk.java.net>
Changeset: b9d59414de23
Author: sherman
Date: 2013-09-15 11:16 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b9d59414de23
7186311: (props) "Unicode" is misspelled as "Uniocde" in JavaDoc and error message
Summary: to correct the typo
Reviewed-by: alanb, chegar
! make/tools/src/build/tools/generatecharacter/CharacterName.java
! src/share/classes/java/util/Properties.java
From xueming.shen at oracle.com Sun Sep 15 13:56:16 2013
From: xueming.shen at oracle.com (xueming.shen at oracle.com)
Date: Sun, 15 Sep 2013 20:56:16 +0000
Subject: hg: jdk8/tl/jdk: 8020687: Deflater.setLevel does not work as expected
Message-ID: <20130915205637.A73BA62856@hg.openjdk.java.net>
Changeset: efa09bf27d39
Author: sherman
Date: 2013-09-15 13:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efa09bf27d39
8020687: Deflater.setLevel does not work as expected
Summary: to clarify the api to match the existing implementation behavior
Reviewed-by: alanb
! src/share/classes/java/util/zip/Deflater.java
From staffan.larsen at oracle.com Sun Sep 15 23:04:02 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 16 Sep 2013 09:04:02 +0300
Subject: RR(S): JDK-7133122 SA throws
sun.jvm.hotspot.debugger.UnmappedAddressException when it should not
In-Reply-To: <5235AF2F.7090105@oracle.com>
References: <5235AF2F.7090105@oracle.com>
Message-ID: <34F79189-6967-482A-ADBA-30BF96666771@oracle.com>
A couple of small nits:
line 721: there is a superfluous + sign at the beginning of the line.
line 729: confliction -> conflict
line 734: to -> with
line 735: overwrite to -> overwrote with
Otherwise looks good.
/Staffan
On 15 sep 2013, at 15:59, Dmitry Samersoff wrote:
> Hi Everybody,
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
>
> Please review the small fix. This patch was contributed by Yasumasa Suenaga.
>
> -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 Mon Sep 16 01:58:26 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 16 Sep 2013 12:58:26 +0400
Subject: RR(S): JDK-7133122 SA throws
sun.jvm.hotspot.debugger.UnmappedAddressException when it should not
In-Reply-To: <34F79189-6967-482A-ADBA-30BF96666771@oracle.com>
References: <5235AF2F.7090105@oracle.com>
<34F79189-6967-482A-ADBA-30BF96666771@oracle.com>
Message-ID: <5236C832.3010907@oracle.com>
Staffan,
Thank you! Fixed (in-place).
http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
-Dmitry
On 2013-09-16 10:04, Staffan Larsen wrote:
> A couple of small nits:
>
> line 721: there is a superfluous + sign at the beginning of the line.
>
> line 729: confliction -> conflict
>
> line 734: to -> with
>
> line 735: overwrite to -> overwrote with
>
>
> Otherwise looks good.
>
> /Staffan
>
> On 15 sep 2013, at 15:59, Dmitry Samersoff wrote:
>
>> Hi Everybody,
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
>>
>> Please review the small fix. This patch was contributed by Yasumasa Suenaga.
>>
>> -Dmitry
>>
>> --
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the sources.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From staffan.larsen at oracle.com Mon Sep 16 02:12:17 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 16 Sep 2013 11:12:17 +0200
Subject: RR(S): JDK-7133122 SA throws
sun.jvm.hotspot.debugger.UnmappedAddressException when it should not
In-Reply-To: <5236C832.3010907@oracle.com>
References: <5235AF2F.7090105@oracle.com>
<34F79189-6967-482A-ADBA-30BF96666771@oracle.com>
<5236C832.3010907@oracle.com>
Message-ID: <9BFBF84E-D786-4DCA-A089-B854F1C82D9E@oracle.com>
Good!
/Staffan
On 16 sep 2013, at 10:58, Dmitry Samersoff wrote:
> Staffan,
>
> Thank you! Fixed (in-place).
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
>
> -Dmitry
>
> On 2013-09-16 10:04, Staffan Larsen wrote:
>> A couple of small nits:
>>
>> line 721: there is a superfluous + sign at the beginning of the line.
>>
>> line 729: confliction -> conflict
>>
>> line 734: to -> with
>>
>> line 735: overwrite to -> overwrote with
>>
>>
>> Otherwise looks good.
>>
>> /Staffan
>>
>> On 15 sep 2013, at 15:59, Dmitry Samersoff wrote:
>>
>>> Hi Everybody,
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
>>>
>>> Please review the small fix. This patch was contributed by Yasumasa Suenaga.
>>>
>>> -Dmitry
>>>
>>> --
>>> Dmitry Samersoff
>>> Oracle Java development team, Saint Petersburg, Russia
>>> * I would love to change the world, but they won't give me the sources.
>>
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
From vicente.romero at oracle.com Mon Sep 16 06:30:27 2013
From: vicente.romero at oracle.com (vicente.romero at oracle.com)
Date: Mon, 16 Sep 2013 13:30:27 +0000
Subject: hg: jdk8/tl/langtools: 8021112: Spurious unchecked warning reported
by javac; ...
Message-ID: <20130916133030.6BBB362873@hg.openjdk.java.net>
Changeset: 4ce8148ffc4f
Author: jlahoda
Date: 2013-09-16 14:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ce8148ffc4f
8021112: Spurious unchecked warning reported by javac
6480588: No way to suppress deprecation warnings when implementing deprecated interface
Summary: Fixing DeferredLintHandler configuration, so lint warnings are reported with correct @SuppressWarnings settings
Reviewed-by: jjg, vromero
! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! test/tools/javac/depDocComment/SuppressDeprecation.out
! test/tools/javac/warnings/6594914/T6594914a.out
! test/tools/javac/warnings/6594914/T6594914b.out
+ test/tools/javac/warnings/suppress/ImplicitTest.java
+ test/tools/javac/warnings/suppress/ImplicitTest.out
+ test/tools/javac/warnings/suppress/PackageInfo.java
+ test/tools/javac/warnings/suppress/PackageInfo.out
+ test/tools/javac/warnings/suppress/T6480588.java
+ test/tools/javac/warnings/suppress/T6480588.out
+ test/tools/javac/warnings/suppress/T8021112a.java
+ test/tools/javac/warnings/suppress/T8021112b.java
+ test/tools/javac/warnings/suppress/T8021112b.out
+ test/tools/javac/warnings/suppress/TypeAnnotations.java
+ test/tools/javac/warnings/suppress/TypeAnnotations.out
+ test/tools/javac/warnings/suppress/VerifySuppressWarnings.java
+ test/tools/javac/warnings/suppress/pack/DeprecatedClass.java
+ test/tools/javac/warnings/suppress/pack/ImplicitMain.java
+ test/tools/javac/warnings/suppress/pack/ImplicitUse.java
+ test/tools/javac/warnings/suppress/pack/package-info.java
From david.holmes at oracle.com Mon Sep 16 06:43:14 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Mon, 16 Sep 2013 13:43:14 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 6900441: PlatformEvent.park(millis) on
Linux could still be affected by changes to the time-of-day clock
Message-ID: <20130916134320.AB13862876@hg.openjdk.java.net>
Changeset: 2e6938dd68f2
Author: dholmes
Date: 2013-09-16 07:38 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2e6938dd68f2
6900441: PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock
Summary: Associate CLOCK_MONOTONIC with the pthread_cond_t objects used for relative timed waits
Reviewed-by: dcubed, shade
! src/os/linux/vm/os_linux.cpp
! src/os/linux/vm/os_linux.hpp
From sundararajan.athijegannathan at oracle.com Mon Sep 16 07:06:12 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Mon, 16 Sep 2013 14:06:12 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130916140615.31F0462878@hg.openjdk.java.net>
Changeset: 38378024a332
Author: sundar
Date: 2013-09-16 15:08 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/38378024a332
8024847: Java.to should accept mirror and external JSObjects as array-like objects as well
Reviewed-by: hannesw, attila, lagergren
! src/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk/nashorn/internal/runtime/ECMAErrors.java
+ src/jdk/nashorn/internal/runtime/JSObjectListAdapter.java
! src/jdk/nashorn/internal/runtime/JSType.java
! src/jdk/nashorn/internal/runtime/ListAdapter.java
+ src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java
! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java
+ test/script/basic/JDK-8024847.js
+ test/script/basic/JDK-8024847.js.EXPECTED
Changeset: f1fd5f0bc84c
Author: attila
Date: 2013-09-16 14:44 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f1fd5f0bc84c
8024846: keep separate internal arguments variable
Reviewed-by: lagergren, sundar
! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/CompilerConstants.java
! src/jdk/nashorn/internal/parser/Parser.java
+ test/script/basic/JDK-8024846.js
From peter.allwin at oracle.com Mon Sep 16 08:44:03 2013
From: peter.allwin at oracle.com (Peter Allwin)
Date: Mon, 16 Sep 2013 17:44:03 +0200
Subject: RFR: 8012923: [parfait] File Descriptor Leak in
jdk/src/windows/demo/jvmti/hprof/hprof_md.c
Message-ID: <29D33878-252C-4B34-A697-E9B9863045DF@oracle.com>
Hello!
Please review this simple fix for a potential socket handle leak in the hprof agent's windows implementation, as discovered by parfait.
bug: https://bugs.openjdk.java.net/browse/JDK-8012923
cr: http://cr.openjdk.java.net/~allwin/8012923/webrev.00/
Thanks!
/peter
From chris.hegarty at oracle.com Mon Sep 16 08:16:05 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 16 Sep 2013 15:16:05 +0000
Subject: hg: jdk8/tl/jdk: 6458027: Disabling IPv6 on a specific network
interface causes problems
Message-ID: <20130916151646.30F2E6287B@hg.openjdk.java.net>
Changeset: db0fc2b71298
Author: msheppar
Date: 2013-09-16 14:51 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db0fc2b71298
6458027: Disabling IPv6 on a specific network interface causes problems
Summary: added a check to test if an interface is configured for IPv6 to native code TwoStacklainDatagramSocketImpl: getMulticastInterface, setMulticastInterface
Reviewed-by: chegar, michaelm
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
+ test/java/net/MulticastSocket/SetGetNetworkInterfaceTest.java
From shanliang.jiang at oracle.com Mon Sep 16 09:17:12 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Mon, 16 Sep 2013 18:17:12 +0200
Subject: jmx-dev Codereview request: 8023954 MBean*Info.equals: throw NPE
In-Reply-To: <5229D5CC.3030006@oracle.com>
References: <5229BB72.4060502@oracle.com> <5229CE47.7080802@oracle.com>
<5229D5CC.3030006@oracle.com>
Message-ID: <52372F08.9060901@oracle.com>
Hi,
Still need OK from a code reviewer, thanks Daniel for the review.
Web: http://cr.openjdk.java.net/~sjiang/jdk-8023954/01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8023954
Thanks,
Shanliang
P.S.
The bug id is 8023954, not 8023529, I put the wrong bug ID in the
previous mails.
Shanliang wrote:
> Daniel Fuchs wrote:
>> On 9/6/13 1:24 PM, shanliang wrote:
>>> Hi,
>>>
>>> Thanks to review the following fix:
>>>
>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023954
>>>
>>> Shanliang
>>>
>>
>> Hi Shanliang,
>>
>> Looks good - but it looks as if some hashCode() will suffer from the
>> same issue (for instance MBeanOperationInfo.hashCode)
>>
>> Do you have an other defect to track that?
> We have another bug JDK-8023669 and thank you for having done the code
> review :) I am waiting a reviewer's review for push the fix
>>
>> I have to wonder why we allow to create an MBeanOperationInfo
>> with a null name though... I wished the first implementation
>> had thrown NPE at construction time.
> I had same wondering, but I had no intention to modify it because that
> is related to the specification.
> The class OpenMBeanOperation does refuse a null or empty class name.
>
> Shanliang
>>
>> -- daniel
>
From omajid at redhat.com Mon Sep 16 10:07:26 2013
From: omajid at redhat.com (Omair Majid)
Date: Mon, 16 Sep 2013 13:07:26 -0400
Subject: Code review request for Linux version id fix (6986195)
In-Reply-To: <5237375A.9050105@oracle.com>
References: <52321D67.8030308@oracle.com> <52322DED.9040608@redhat.com>
<5237375A.9050105@oracle.com>
Message-ID: <52373ACE.5050800@redhat.com>
Hi Gerald,
On 09/16/2013 12:52 PM, Gerald Thornbrugh wrote:
> Sorry about the delay of my response.
No problem :)
> I chose to place the /etc/SuSE-release file in front of the
> /etc/os-release file because the
> SuSE-release file was more clear and concise than the os-release file.
I see. Yes, that does make a lot of sense.
> I propose the following change:
>
> 2181 // Searching system-release (Red Hat) and os-release (other
> linuxes) are a
> 2182 // next to last resort. The os-release file is a new standard that
> contains
> 2183 // distribution information and the os-release file seems to be an
> old standard
> 2184 // that has been replaced by the lsb-release and os-release files.
There seems to be a thinko here: "The os-release file is a ... and the
os-release file seems to be ... that has been replaced by .. os-release"
If you mean there are two different 'standards' for os-release, maybe
it's better to say that.
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From daniel.daugherty at oracle.com Mon Sep 16 10:08:44 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 16 Sep 2013 11:08:44 -0600
Subject: code review request for more StringTable verification code (8019835)
Message-ID: <52373B1C.3040705@oracle.com>
Greetings,
I have some new diagnostic code that I would like to add to the system
that was developed during my hunt for this bug:
8019835 Strings interned in different threads equal but does not ==
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019835
https://bugs.openjdk.java.net/browse/JDK-8019835
Here is the third round HSX-25 webrev URL:
OpenJDK: http://cr.openjdk.java.net/~dcubed/8019835-webrev/2-hsx25/
Internal: http://javaweb.us.oracle.com/~ddaugher/8019835-webrev/2-hsx25/
This fix was reviewed internally by the following OpenJDK users:
rdurbin, sspitsyn, and coleenp.
Please note that while this code does detect StringTable corruption
due to bad memory, that is not the primary purpose. The primary
purpose of the new code is to verify all StringTable invariants.
Testing:
- JPRT build and test on all platforms with the default value of
-XX:VerifyStringTableAtExit set to true
- Aurora Adhoc testing on all platforms with product and fastdebug bits
with the default value of -XX:VerifyStringTableAtExit set to true
- Tested on the system with bad memory named in 8019835 and it nicely
shows various types of StringTable corruptions.
As always, comments, questions and suggestions are welcome.
Dan
P.S.
Changes between second and third rounds:
- removed the redundant code in compare_entries() that Coleen spotted
Changes between first and second rounds:
- add missing String oop check to StringTable::compare_entries(); only
comes into play when an error happens
- add mesg_mode parameter to verify_entry() to clarify when we should
be supressing duplicate error messages
- refactor StringTable::verify_and_compare_entries() into two phases
for clarity:
- phase 1 verifies all entries in the StringTable
- phase 2 compares all entries in the StringTable
From staffan.larsen at oracle.com Mon Sep 16 10:19:57 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 16 Sep 2013 19:19:57 +0200
Subject: RFR: 8012923: [parfait] File Descriptor Leak in
jdk/src/windows/demo/jvmti/hprof/hprof_md.c
In-Reply-To: <29D33878-252C-4B34-A697-E9B9863045DF@oracle.com>
References: <29D33878-252C-4B34-A697-E9B9863045DF@oracle.com>
Message-ID: <6B20987D-9F22-4126-8727-2D187704B0A4@oracle.com>
Looks good.
/Staffan
On 16 sep 2013, at 17:44, Peter Allwin wrote:
> Hello!
>
> Please review this simple fix for a potential socket handle leak in the hprof agent's windows implementation, as discovered by parfait.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8012923
> cr: http://cr.openjdk.java.net/~allwin/8012923/webrev.00/
>
> Thanks!
> /peter
From daniel.daugherty at oracle.com Mon Sep 16 10:26:32 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 16 Sep 2013 11:26:32 -0600
Subject: Code review request for Linux version id fix (6986195)
In-Reply-To: <52373B9C.8080900@oracle.com>
References: <52321D67.8030308@oracle.com> <52322DED.9040608@redhat.com>
<5237375A.9050105@oracle.com> <52373ACE.5050800@redhat.com>
<52373B9C.8080900@oracle.com>
Message-ID: <52373F48.6060400@oracle.com>
On 9/16/13 11:10 AM, Gerald Thornbrugh wrote:
> Hi Omair,
>> Hi Gerald,
>>
>> On 09/16/2013 12:52 PM, Gerald Thornbrugh wrote:
>>> Sorry about the delay of my response.
>> No problem :)
>>
>>> I chose to place the /etc/SuSE-release file in front of the
>>> /etc/os-release file because the
>>> SuSE-release file was more clear and concise than the os-release file.
>> I see. Yes, that does make a lot of sense.
>>
>>> I propose the following change:
>>>
>>> 2181 // Searching system-release (Red Hat) and os-release (other
>>> linuxes) are a
>>> 2182 // next to last resort. The os-release file is a new standard
>>> that
>>> contains
>>> 2183 // distribution information and the os-release file seems to be an
>>> old standard
>>> 2184 // that has been replaced by the lsb-release and os-release
>>> files.
>>
>> There seems to be a thinko here: "The os-release file is a ... and the
>> os-release file seems to be ... that has been replaced by .. os-release"
>>
>> If you mean there are two different 'standards' for os-release, maybe
>> it's better to say that.
> Thanks for the catch, I did mean "system-release" instead of
> "os-release".
>
> I will try this again:
>
> 2181 // Searching system-release (Red Hat) and os-release
> (otherlinuxes) are a
Typo: "otherlinuxes" -> "other Linuxes"
Dan
> 2182 // next to last resort. The os-release file is a new standard
> that contains
> 2183 // distribution information and the system-release file seems to
> be an old standard
> 2184 // that has been replaced by the lsb-release and os-release files.
>
> Is this ok?
>
> Thanks!
>
> Jerry
>>
>> Thanks,
>> Omair
>>
>
From omajid at redhat.com Mon Sep 16 10:32:35 2013
From: omajid at redhat.com (Omair Majid)
Date: Mon, 16 Sep 2013 13:32:35 -0400
Subject: Code review request for Linux version id fix (6986195)
In-Reply-To: <52374054.7040503@oracle.com>
References: <52321D67.8030308@oracle.com> <52322DED.9040608@redhat.com>
<5237375A.9050105@oracle.com> <52373ACE.5050800@redhat.com>
<52373B9C.8080900@oracle.com> <52373F48.6060400@oracle.com>
<52374054.7040503@oracle.com>
Message-ID: <523740B3.90704@redhat.com>
On 09/16/2013 01:31 PM, Gerald Thornbrugh wrote:
> OK, one more time:
>
> 2181 // Searching system-release (Red Hat) and os-release (other
> Linuxes) are a
> 2182 // next to last resort. The os-release file is a new standard that
> contains
> 2183 // distribution information and the system-release file seems to be
> an old standard
> 2184 // that has been replaced by the lsb-release and os-release files.
>
Looks good to me. Thanks for updating this!
Cheers,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
From serguei.spitsyn at oracle.com Mon Sep 16 10:34:47 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 16 Sep 2013 10:34:47 -0700
Subject: RFR: 8012923: [parfait] File Descriptor Leak in
jdk/src/windows/demo/jvmti/hprof/hprof_md.c
In-Reply-To: <29D33878-252C-4B34-A697-E9B9863045DF@oracle.com>
References: <29D33878-252C-4B34-A697-E9B9863045DF@oracle.com>
Message-ID: <52374137.8010006@oracle.com>
Looks good.
Thanks,
Serguei
On 9/16/13 8:44 AM, Peter Allwin wrote:
> Hello!
>
> Please review this simple fix for a potential socket handle leak in the hprof agent's windows implementation, as discovered by parfait.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8012923
> cr: http://cr.openjdk.java.net/~allwin/8012923/webrev.00/
>
> Thanks!
> /peter
From henry.jen at oracle.com Mon Sep 16 10:35:07 2013
From: henry.jen at oracle.com (henry.jen at oracle.com)
Date: Mon, 16 Sep 2013 17:35:07 +0000
Subject: hg: jdk8/tl/jdk: 8024874: Copy-paste typo in the spec for
j.u.Comparator.thenComparing(Function, Comparator)
Message-ID: <20130916173533.3013562888@hg.openjdk.java.net>
Changeset: 86aa8e7503e9
Author: henryjen
Date: 2013-09-16 10:28 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86aa8e7503e9
8024874: Copy-paste typo in the spec for j.u.Comparator.thenComparing(Function, Comparator)
Reviewed-by: mduigou
! src/share/classes/java/util/Comparator.java
From serguei.spitsyn at oracle.com Mon Sep 16 10:43:55 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 16 Sep 2013 10:43:55 -0700
Subject: code review request for more StringTable verification code
(8019835)
In-Reply-To: <52373B1C.3040705@oracle.com>
References: <52373B1C.3040705@oracle.com>
Message-ID: <5237435B.6090305@oracle.com>
Looks nice.
Thanks,
Serguei
On 9/16/13 10:08 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> I have some new diagnostic code that I would like to add to the system
> that was developed during my hunt for this bug:
>
> 8019835 Strings interned in different threads equal but does not ==
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019835
> https://bugs.openjdk.java.net/browse/JDK-8019835
>
> Here is the third round HSX-25 webrev URL:
>
> OpenJDK: http://cr.openjdk.java.net/~dcubed/8019835-webrev/2-hsx25/
> Internal: http://javaweb.us.oracle.com/~ddaugher/8019835-webrev/2-hsx25/
>
> This fix was reviewed internally by the following OpenJDK users:
> rdurbin, sspitsyn, and coleenp.
>
> Please note that while this code does detect StringTable corruption
> due to bad memory, that is not the primary purpose. The primary
> purpose of the new code is to verify all StringTable invariants.
>
> Testing:
> - JPRT build and test on all platforms with the default value of
> -XX:VerifyStringTableAtExit set to true
> - Aurora Adhoc testing on all platforms with product and fastdebug bits
> with the default value of -XX:VerifyStringTableAtExit set to true
> - Tested on the system with bad memory named in 8019835 and it nicely
> shows various types of StringTable corruptions.
>
> As always, comments, questions and suggestions are welcome.
>
> Dan
>
> P.S.
> Changes between second and third rounds:
> - removed the redundant code in compare_entries() that Coleen spotted
>
> Changes between first and second rounds:
> - add missing String oop check to StringTable::compare_entries(); only
> comes into play when an error happens
> - add mesg_mode parameter to verify_entry() to clarify when we should
> be supressing duplicate error messages
> - refactor StringTable::verify_and_compare_entries() into two phases
> for clarity:
> - phase 1 verifies all entries in the StringTable
> - phase 2 compares all entries in the StringTable
From daniel.daugherty at oracle.com Mon Sep 16 10:47:39 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 16 Sep 2013 11:47:39 -0600
Subject: code review request for more StringTable verification code
(8019835)
In-Reply-To: <5237435B.6090305@oracle.com>
References: <52373B1C.3040705@oracle.com> <5237435B.6090305@oracle.com>
Message-ID: <5237443B.6040703@oracle.com>
Thanks for quick re-review!
Dan
On 9/16/13 11:43 AM, serguei.spitsyn at oracle.com wrote:
> Looks nice.
>
> Thanks,
> Serguei
>
> On 9/16/13 10:08 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I have some new diagnostic code that I would like to add to the system
>> that was developed during my hunt for this bug:
>>
>> 8019835 Strings interned in different threads equal but does not ==
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019835
>> https://bugs.openjdk.java.net/browse/JDK-8019835
>>
>> Here is the third round HSX-25 webrev URL:
>>
>> OpenJDK: http://cr.openjdk.java.net/~dcubed/8019835-webrev/2-hsx25/
>> Internal: http://javaweb.us.oracle.com/~ddaugher/8019835-webrev/2-hsx25/
>>
>> This fix was reviewed internally by the following OpenJDK users:
>> rdurbin, sspitsyn, and coleenp.
>>
>> Please note that while this code does detect StringTable corruption
>> due to bad memory, that is not the primary purpose. The primary
>> purpose of the new code is to verify all StringTable invariants.
>>
>> Testing:
>> - JPRT build and test on all platforms with the default value of
>> -XX:VerifyStringTableAtExit set to true
>> - Aurora Adhoc testing on all platforms with product and fastdebug bits
>> with the default value of -XX:VerifyStringTableAtExit set to true
>> - Tested on the system with bad memory named in 8019835 and it nicely
>> shows various types of StringTable corruptions.
>>
>> As always, comments, questions and suggestions are welcome.
>>
>> Dan
>>
>> P.S.
>> Changes between second and third rounds:
>> - removed the redundant code in compare_entries() that Coleen spotted
>>
>> Changes between first and second rounds:
>> - add missing String oop check to StringTable::compare_entries(); only
>> comes into play when an error happens
>> - add mesg_mode parameter to verify_entry() to clarify when we should
>> be supressing duplicate error messages
>> - refactor StringTable::verify_and_compare_entries() into two phases
>> for clarity:
>> - phase 1 verifies all entries in the StringTable
>> - phase 2 compares all entries in the StringTable
>
From volker.simonis at gmail.com Mon Sep 16 12:30:10 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 16 Sep 2013 21:30:10 +0200
Subject: RFR(L): 8024854: Basic changes and files to build the class library
on AIX
In-Reply-To:
References:
Message-ID:
Resending this to more lists as requested by Alan Bateman with the kind
request to anybody to review the parts for which he feels responsible:)
For those not up to date, this change is part of the ongoing PowerPC/AIX
Porting Project:
http://openjdk.java.net/projects/ppc-aix-port
https://wiki.openjdk.java.net/display/PPCAIXPort
http://openjdk.java.net/jeps/175
Please send reviews to all currently included recipients.
Thank you and best regards,
Volker
---------- Forwarded message ----------
From: *Volker Simonis*
Date: Monday, September 16, 2013
Subject: RFR(L): 8024854: Basic changes and files to build the class
library on AIX
To: "ppc-aix-port-dev at openjdk.java.net" ,
Java Core Libs
Hi,
could you please review the following webrev which contains the basic
changes and files needed in the 'jdk' repository in order to build the
OpenJDK on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/8024854
This change together with "8024265: Enable new build on AIX (jdk
part)"
allows it to configure and completely build the staging repository on AIX
5.3 and 7.1 with the following command:
configure --with-boot-jdk= --with-jvm-variants=core
--with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
--x-includes=/opt/freeware/include
Below you can find the changes and additions I've done, sorted by file.
Most of them are just additions which are only active during the AIX build
anyway or simple changes where AIX has been added to conditions which
already check for Linux and/or Solaris. The files with the biggest changes
which you're probably want to look on more thoroughly are
'src/solaris/native/java/net/NetworkInterface.c' and
'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change
anything on the current OpenJDK platforms as well.
Notice that there are still some files and some functionality missing from
the current change (notably NIO) but it still yields a running JDK which
can execute "HelloWorld" on the command line and as AWT application. I've
intentionally tried to keep this initial change as simple as possible (with
respect tot shared changes) in order to get it reviewed as fast as
possible. The missing parts can then be added later on, grouped by logical
topics, to simplify the review process.
Thank you and best regards,
Volker
src/share/bin/jli_util.h
- Define JLI_Lseek on AIX.
src/share/lib/security/java.security-aix
- Provide default java.security-aix for AIX.
src/share/native/sun/awt/medialib/mlib_sys.c
- malloc always returns 8-byte aligned pointers on AIX as well.
src/share/native/sun/awt/medialib/mlib_types.h
- Add AIX to the list of known platforms.
src/share/native/sun/font/layout/KernTable.cpp
- Rename the macro DEBUG to DEBUG_KERN_TABLE because DEBUG is too common
and may be defined in other headers as well as on the command line and
xlc bails out on macro redefinitions with a different value.
src/share/native/sun/security/ec/impl/ecc_impl.h
- Define required types and macros on AIX.
src/solaris/back/exec_md.c
- AIX behaves like Linux in this case so check for it in the Linux
branch.
src/solaris/bin/java_md_solinux.c,
src/solaris/bin/java_md_solinux.h
- On AIX LD_LIBRARY_PATH is called LIBPATH
- Always use LD_LIBRARY_PATH macro instead of using the string "
LD_LIBRARY_PATH" directly to cope with different library path names.
- Add jre/lib//jli to the standard library search path on AIX
because the AIX linker doesn't support the -rpath option.
- Replace #ifdef __linux__ by #ifndef __solaris__ because in this case,
AIX behaves like Linux.
src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties
- Provide basic fontconfig.propertiesfor AIX.
src/solaris/classes/java/lang/UNIXProcess.java.aix,
src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
src/solaris/classes/sun/tools/attach/AixVirtualMachine.java
- Provide AIX specific Java versions, mostly based on the corresponding
Linux versions.
src/solaris/demo/jvmti/hprof/hprof_md.c
- Add AIX support. AIX mostly behaves like Linux, with the one exception
that it has no dladdr functionality.
- Implement dladdr functionality for AIX.
src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
- Adapt for AIX (i.e. use libperfstat on AIX to query OS memory).
src/solaris/native/common/jdk_util_md.h
- Add AIX definitions of the ISNANF and ISNAND macros.
src/solaris/native/java/io/io_util_md.c
- AIX behaves like Linux in this case so check for it in the Linux
branch.
src/solaris/native/java/net/NetworkInterface.c
- Add AIX support into the Linux branch because AIX mostly behaves like
AIX for IPv4.
- AIX needs a special function to enumerate IPv6 interfaces and to query
the MAC address.
src/solaris/native/java/net/PlainSocketImpl.c
- On AIX (like on Solaris) setsockopt will set errno to EINVAL if the
socket is closed. The default error message is then confusing.
src/solaris/native/java/net/linux_close.c,
src/share/native/java/net/net_util.c
- Also use the file and socket wrappers on AIX.
- Add initialization of some previously uninitialized data structures.
- On AIX we don't have __attribute((constructor)) so we need to
initialize manually (from JNI_OnLoad() in
'src/share/native/java/net/net_util.c'
src/solaris/native/java/net/net_util_md.h
- AIX needs the same workaround for I/O cancellation like Linux and
MacOSX.
src/solaris/native/java/util/TimeZone_md.c
- Currently on AIX the only way to get the platform time zone is to read
it from the TZ environment variable.
src/solaris/native/sun/awt/awt_LoadLibrary.c
- There's no dladdr on AIX, but we can use the implementation from the
HotSpot in this case because libjvm.so will be always loaded before the
AWT.
src/solaris/native/sun/awt/fontpath.c
- Add AIX specific fontpath settings and library search paths for
libfontconfig.so.
src/solaris/native/sun/java2d/x11/X11SurfaceData.c
- Only define MIN and MAX if they're not already defined because xlc on
AIX fails on macro redefinitions.
src/solaris/native/sun/java2d/x11/XRBackendNative.c
- Handle AIX like Solaris.
src/solaris/native/sun/nio/ch/Net.c
- Add AIX-specific includes and constant definitions.
- On AIX "socket extensions for multicast source filters" support
depends on the OS version. Check for this and throw appropriate exceptions
if it requested but not supported. This is needed to pass
JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
src/solaris/native/sun/security/pkcs11/j2secmod_md.c
- Use RTLD_LAZY instead of RTLD_NOLOAD on AIX.
src/solaris/native/sun/tools/attach/AixVirtualMachine.c
- AIX version mostly derived from the corresponding Linux version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130916/59702a42/attachment.html
From ron.durbin at oracle.com Mon Sep 16 15:17:54 2013
From: ron.durbin at oracle.com (Ron Durbin)
Date: Mon, 16 Sep 2013 15:17:54 -0700 (PDT)
Subject: code review request for more StringTable verification code
(8019835)
In-Reply-To: <5237443B.6040703@oracle.com>
References: <52373B1C.3040705@oracle.com> <5237435B.6090305@oracle.com>
<5237443B.6040703@oracle.com>
Message-ID: <6a24c38d-aab2-49b2-b914-c0d66efdd421@default>
Dan it looks good,
Thx
Ron
> -----Original Message-----
> From: Daniel D. Daugherty
> Sent: Monday, September 16, 2013 11:48 AM
> To: Serguei Spitsyn
> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: code review request for more StringTable verification code (8019835)
>
> Thanks for quick re-review!
>
> Dan
>
>
> On 9/16/13 11:43 AM, serguei.spitsyn at oracle.com wrote:
> > Looks nice.
> >
> > Thanks,
> > Serguei
> >
> > On 9/16/13 10:08 AM, Daniel D. Daugherty wrote:
> >> Greetings,
> >>
> >> I have some new diagnostic code that I would like to add to the
> >> system that was developed during my hunt for this bug:
> >>
> >> 8019835 Strings interned in different threads equal but does not ==
> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019835
> >> https://bugs.openjdk.java.net/browse/JDK-8019835
> >>
> >> Here is the third round HSX-25 webrev URL:
> >>
> >> OpenJDK: http://cr.openjdk.java.net/~dcubed/8019835-webrev/2-hsx25/
> >> Internal:
> >> http://javaweb.us.oracle.com/~ddaugher/8019835-webrev/2-hsx25/
> >>
> >> This fix was reviewed internally by the following OpenJDK users:
> >> rdurbin, sspitsyn, and coleenp.
> >>
> >> Please note that while this code does detect StringTable corruption
> >> due to bad memory, that is not the primary purpose. The primary
> >> purpose of the new code is to verify all StringTable invariants.
> >>
> >> Testing:
> >> - JPRT build and test on all platforms with the default value of
> >> -XX:VerifyStringTableAtExit set to true
> >> - Aurora Adhoc testing on all platforms with product and fastdebug bits
> >> with the default value of -XX:VerifyStringTableAtExit set to true
> >> - Tested on the system with bad memory named in 8019835 and it nicely
> >> shows various types of StringTable corruptions.
> >>
> >> As always, comments, questions and suggestions are welcome.
> >>
> >> Dan
> >>
> >> P.S.
> >> Changes between second and third rounds:
> >> - removed the redundant code in compare_entries() that Coleen spotted
> >>
> >> Changes between first and second rounds:
> >> - add missing String oop check to StringTable::compare_entries(); only
> >> comes into play when an error happens
> >> - add mesg_mode parameter to verify_entry() to clarify when we should
> >> be supressing duplicate error messages
> >> - refactor StringTable::verify_and_compare_entries() into two phases
> >> for clarity:
> >> - phase 1 verifies all entries in the StringTable
> >> - phase 2 compares all entries in the StringTable
> >
>
From daniel.daugherty at oracle.com Mon Sep 16 15:19:14 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 16 Sep 2013 16:19:14 -0600
Subject: code review request for more StringTable verification code
(8019835)
In-Reply-To: <6a24c38d-aab2-49b2-b914-c0d66efdd421@default>
References: <52373B1C.3040705@oracle.com> <5237435B.6090305@oracle.com>
<5237443B.6040703@oracle.com>
<6a24c38d-aab2-49b2-b914-c0d66efdd421@default>
Message-ID: <523783E2.4080909@oracle.com>
Thanks for re-review!
Dan
On 9/16/13 4:17 PM, Ron Durbin wrote:
> Dan it looks good,
>
> Thx
> Ron
>
>> -----Original Message-----
>> From: Daniel D. Daugherty
>> Sent: Monday, September 16, 2013 11:48 AM
>> To: Serguei Spitsyn
>> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: code review request for more StringTable verification code (8019835)
>>
>> Thanks for quick re-review!
>>
>> Dan
>>
>>
>> On 9/16/13 11:43 AM, serguei.spitsyn at oracle.com wrote:
>>> Looks nice.
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 9/16/13 10:08 AM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I have some new diagnostic code that I would like to add to the
>>>> system that was developed during my hunt for this bug:
>>>>
>>>> 8019835 Strings interned in different threads equal but does not ==
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019835
>>>> https://bugs.openjdk.java.net/browse/JDK-8019835
>>>>
>>>> Here is the third round HSX-25 webrev URL:
>>>>
>>>> OpenJDK: http://cr.openjdk.java.net/~dcubed/8019835-webrev/2-hsx25/
>>>> Internal:
>>>> http://javaweb.us.oracle.com/~ddaugher/8019835-webrev/2-hsx25/
>>>>
>>>> This fix was reviewed internally by the following OpenJDK users:
>>>> rdurbin, sspitsyn, and coleenp.
>>>>
>>>> Please note that while this code does detect StringTable corruption
>>>> due to bad memory, that is not the primary purpose. The primary
>>>> purpose of the new code is to verify all StringTable invariants.
>>>>
>>>> Testing:
>>>> - JPRT build and test on all platforms with the default value of
>>>> -XX:VerifyStringTableAtExit set to true
>>>> - Aurora Adhoc testing on all platforms with product and fastdebug bits
>>>> with the default value of -XX:VerifyStringTableAtExit set to true
>>>> - Tested on the system with bad memory named in 8019835 and it nicely
>>>> shows various types of StringTable corruptions.
>>>>
>>>> As always, comments, questions and suggestions are welcome.
>>>>
>>>> Dan
>>>>
>>>> P.S.
>>>> Changes between second and third rounds:
>>>> - removed the redundant code in compare_entries() that Coleen spotted
>>>>
>>>> Changes between first and second rounds:
>>>> - add missing String oop check to StringTable::compare_entries(); only
>>>> comes into play when an error happens
>>>> - add mesg_mode parameter to verify_entry() to clarify when we should
>>>> be supressing duplicate error messages
>>>> - refactor StringTable::verify_and_compare_entries() into two phases
>>>> for clarity:
>>>> - phase 1 verifies all entries in the StringTable
>>>> - phase 2 compares all entries in the StringTable
From daniel.daugherty at oracle.com Mon Sep 16 15:20:45 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Mon, 16 Sep 2013 22:20:45 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 6986195: correctly identify Ubuntu as the
operating system in crash report instead of "Debian"
Message-ID: <20130916222047.EBFA662898@hg.openjdk.java.net>
Changeset: 4472884d8b37
Author: dcubed
Date: 2013-09-16 12:43 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4472884d8b37
6986195: correctly identify Ubuntu as the operating system in crash report instead of "Debian"
Summary: Cleanup and document how various Linux release info files are used by print_distro_info().
Reviewed-by: dcubed, dsamersoff, coleenp, iklam, omajid
Contributed-by: gerald.thornbrugh at oracle.com
! src/os/linux/vm/os_linux.cpp
From karen.kinnear at oracle.com Mon Sep 16 18:33:39 2013
From: karen.kinnear at oracle.com (karen.kinnear at oracle.com)
Date: Tue, 17 Sep 2013 01:33:39 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130917013346.008E16289E@hg.openjdk.java.net>
Changeset: 42863137168c
Author: acorn
Date: 2013-09-16 17:57 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/42863137168c
8024647: Default method resolution with private superclass method
Reviewed-by: kamg, minqi
! src/share/vm/classfile/defaultMethods.cpp
Changeset: 921967020b3b
Author: acorn
Date: 2013-09-16 15:24 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/921967020b3b
Merge
From yumin.qi at oracle.com Mon Sep 16 20:59:21 2013
From: yumin.qi at oracle.com (yumin.qi at oracle.com)
Date: Tue, 17 Sep 2013 03:59:21 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130917035928.3A1AA628A0@hg.openjdk.java.net>
Changeset: 621eda7235d2
Author: minqi
Date: 2013-09-16 15:35 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/621eda7235d2
7164841: Improvements to the GC log file rotation
Summary: made changes to easily identify current log file in rotation. Parameterize the input with %t for time replacement in file name.
Reviewed-by: ccheung, tschatzl, tamao, zgu
Contributed-by: yumin.qi at oracle.com
! src/share/vm/prims/jni.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/ostream.hpp
Changeset: 535973ddf22c
Author: minqi
Date: 2013-09-16 18:39 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/535973ddf22c
Merge
From david.holmes at oracle.com Mon Sep 16 22:27:18 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2013 15:27:18 +1000
Subject: jmx-dev Codereview request: 8023954 MBean*Info.equals: throw NPE
In-Reply-To: <52372F08.9060901@oracle.com>
References: <5229BB72.4060502@oracle.com> <5229CE47.7080802@oracle.com>
<5229D5CC.3030006@oracle.com> <52372F08.9060901@oracle.com>
Message-ID: <5237E836.6000202@oracle.com>
On 17/09/2013 2:17 AM, shanliang wrote:
> Hi,
>
> Still need OK from a code reviewer, thanks Daniel for the review.
Reviewed.
(I'd seen this one earlier by mistake :) )
David
> Web: http://cr.openjdk.java.net/~sjiang/jdk-8023954/01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8023954
>
> Thanks,
> Shanliang
>
> P.S.
> The bug id is 8023954, not 8023529, I put the wrong bug ID in the
> previous mails.
>
> Shanliang wrote:
>> Daniel Fuchs wrote:
>>> On 9/6/13 1:24 PM, shanliang wrote:
>>>> Hi,
>>>>
>>>> Thanks to review the following fix:
>>>>
>>>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023529/00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023954
>>>>
>>>> Shanliang
>>>>
>>>
>>> Hi Shanliang,
>>>
>>> Looks good - but it looks as if some hashCode() will suffer from the
>>> same issue (for instance MBeanOperationInfo.hashCode)
>>>
>>> Do you have an other defect to track that?
>> We have another bug JDK-8023669 and thank you for having done the code
>> review :) I am waiting a reviewer's review for push the fix
>>>
>>> I have to wonder why we allow to create an MBeanOperationInfo
>>> with a null name though... I wished the first implementation
>>> had thrown NPE at construction time.
>> I had same wondering, but I had no intention to modify it because that
>> is related to the specification.
>> The class OpenMBeanOperation does refuse a null or empty class name.
>>
>> Shanliang
>>>
>>> -- daniel
>>
>
From markus.gronlund at oracle.com Tue Sep 17 00:57:03 2013
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Tue, 17 Sep 2013 00:57:03 -0700 (PDT)
Subject: RFR: 8012923: [parfait] File Descriptor Leak in
jdk/src/windows/demo/jvmti/hprof/hprof_md.c
In-Reply-To: <29D33878-252C-4B34-A697-E9B9863045DF@oracle.com>
References: <29D33878-252C-4B34-A697-E9B9863045DF@oracle.com>
Message-ID: <2cf3e6c0-7713-4e08-97e9-e17009199bc3@default>
Peter,
Looks good (I'm not a Reviewer).
Thanks for fixing this.
Cheers
Markus
-----Original Message-----
From: Peter Allwin
Sent: den 16 september 2013 17:44
To: serviceability-dev at openjdk.java.net
Subject: RFR: 8012923: [parfait] File Descriptor Leak in jdk/src/windows/demo/jvmti/hprof/hprof_md.c
Hello!
Please review this simple fix for a potential socket handle leak in the hprof agent's windows implementation, as discovered by parfait.
bug: https://bugs.openjdk.java.net/browse/JDK-8012923
cr: http://cr.openjdk.java.net/~allwin/8012923/webrev.00/
Thanks!
/peter
From erik.helin at oracle.com Tue Sep 17 01:48:28 2013
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 17 Sep 2013 10:48:28 +0200
Subject: RFR: 8014659: NPG: performance counters for compressed klass space
In-Reply-To:
References: <20130910155657.GA12910@ehelin-thinkpad>
Message-ID: <20130917084828.GA2261@ehelin-thinkpad>
Hi Staffan,
On 2013-09-12, Staffan Larsen wrote:
> Looks good (I'll take your word that the nasty awk scripts are correct...).
thanks for the review!
On 2013-09-12, Staffan Larsen wrote:
> I think you should have included serviceability-dev on this review request.
Agree, I'm adding them as part this email to let everyone at
serviceability-dev have a look.
Thanks,
Erik
> /Staffan
>
>
> On 10 sep 2013, at 18:56, Erik Helin wrote:
>
> > Hi all,
> >
> > this is the JDK part of the fix for 8014659 [0]. I've added the output
> > of the compressed class space performance counters next to the metaspace
> > output. I've also updated the jstat and jstatd tests to take the new
> > output into account.
> >
> > Webrev:
> > http://cr.openjdk.java.net/~ehelin/8014659/webrev.00/
> >
> > Testing:
> > - jdk/test/sun/tools/jstat
> > - jdk/test/sun/tools/jstatd
> >
> > Thanks,
> > Erik
> >
> > [0]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014659
>
From lance.andersen at oracle.com Tue Sep 17 04:57:15 2013
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Tue, 17 Sep 2013 11:57:15 +0000
Subject: hg: jdk8/tl/jdk: 7097386: Correct error in Predicate javadoc example
Message-ID: <20130917115759.A0484628A9@hg.openjdk.java.net>
Changeset: 657482758408
Author: lancea
Date: 2013-09-17 07:56 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/657482758408
7097386: Correct error in Predicate javadoc example
Reviewed-by: alanb, shade
! src/share/classes/javax/sql/rowset/Predicate.java
From peter.allwin at oracle.com Tue Sep 17 08:44:13 2013
From: peter.allwin at oracle.com (Peter Allwin)
Date: Tue, 17 Sep 2013 17:44:13 +0200
Subject: RFR: 7196151: ParserTest SEGv on solaris
Message-ID:
Hello!
Please review this small fix for an issue where jio_snprintf may be called with a null argument causing SEGV on Solaris. This can occur if to_string is called on a GenDCmdArgument with no default value.
cr: http://cr.openjdk.java.net/~allwin/7196151/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-7196151
serviceability/ParserTest.java reproduces this issue and the fix has been verified with this test.
Thanks!
/peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130917/6f91b2c3/attachment.html
From christian.tornqvist at oracle.com Tue Sep 17 08:48:36 2013
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Tue, 17 Sep 2013 11:48:36 -0400
Subject: 7196151: ParserTest SEGv on solaris
In-Reply-To:
References:
Message-ID: <000301ceb3bd$5fc219b0$1f464d10$@oracle.com>
Looks good!
Thanks,
Christian
From: hotspot-runtime-dev-bounces at openjdk.java.net
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Peter
Allwin
Sent: Tuesday, September 17, 2013 11:44 AM
To: serviceability-dev at openjdk.java.net;
hotspot-runtime-dev at openjdk.java.net
Subject: RFR: 7196151: ParserTest SEGv on solaris
Hello!
Please review this small fix for an issue where jio_snprintf may be called
with a null argument causing SEGV on Solaris. This can occur if to_string is
called on a GenDCmdArgument with no default value.
cr: http://cr.openjdk.java.net/~allwin/7196151/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-7196151
serviceability/ParserTest.java reproduces this issue and the fix has been
verified with this test.
Thanks!
/peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130917/23061cae/attachment-0001.html
From staffan.larsen at oracle.com Tue Sep 17 10:38:19 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 17 Sep 2013 19:38:19 +0200
Subject: RFR: 7196151: ParserTest SEGv on solaris
In-Reply-To:
References:
Message-ID: <7DB60FA8-A925-415F-9FF9-7DC720E3CCC3@oracle.com>
Looks good!
/Staffan
On 17 sep 2013, at 17:44, Peter Allwin wrote:
> Hello!
>
> Please review this small fix for an issue where jio_snprintf may be called with a null argument causing SEGV on Solaris. This can occur if to_string is called on a GenDCmdArgument with no default value.
>
> cr: http://cr.openjdk.java.net/~allwin/7196151/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-7196151
>
>
> serviceability/ParserTest.java reproduces this issue and the fix has been verified with this test.
>
>
> Thanks!
> /peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130917/ef24dbb5/attachment.html
From coleen.phillimore at oracle.com Tue Sep 17 10:52:10 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 17 Sep 2013 13:52:10 -0400
Subject: RFR: 7196151: ParserTest SEGv on solaris
In-Reply-To:
References:
Message-ID: <523896CA.4000709@oracle.com>
This test also exposed an unhandled oop in the JVM, I thought the fix
for this bug would include this fix also (but the webrev is gone).
Never mind, it can also be fixed with 7195622.
This fix looks good.
Coleen
On 09/17/2013 11:44 AM, Peter Allwin wrote:
> Hello!
>
> Please review this small fix for an issue where jio_snprintf may be
> called with a null argument causing SEGV on Solaris. This can occur if
> to_string is called on a GenDCmdArgument with no default value.
>
> cr: http://cr.openjdk.java.net/~allwin/7196151/webrev.00/
>
> bug: https://bugs.openjdk.java.net/browse/JDK-7196151
>
>
> serviceability/ParserTest.java reproduces this issue and the fix has
> been verified with this test.
>
>
> Thanks!
> /peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130917/c5acc670/attachment.html
From christian.tornqvist at oracle.com Tue Sep 17 13:06:59 2013
From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com)
Date: Tue, 17 Sep 2013 20:06:59 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets
Message-ID: <20130917200709.B5FA0628C2@hg.openjdk.java.net>
Changeset: 88d6b9a1c27c
Author: mseledtsov
Date: 2013-09-17 20:09 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/88d6b9a1c27c
8016029: test runtime/6878713/Test6878713.sh failed
Summary: Rewrote test in Java; updated the test condition to reflect latest changes in the source
Reviewed-by: dholmes, ctornqvi
- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
+ test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java
+ test/runtime/ClassFile/testcase.jar
Changeset: 6f45933aef35
Author: mseledtsov
Date: 2013-09-17 20:20 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6f45933aef35
7149464: [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files after test
Summary: Re-wrote in Java, this also eliminated temporary result file; set upper limit on malloc'd memory
Reviewed-by: dcubed, dholmes, ccheung
- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar
+ test/runtime/ClassFile/JsrRewriting.java
+ test/runtime/ClassFile/JsrRewritingTestCase.jar
From dmitry.samersoff at oracle.com Tue Sep 17 14:00:26 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 18 Sep 2013 01:00:26 +0400
Subject: RFR: 7196151: ParserTest SEGv on solaris
In-Reply-To:
References:
Message-ID: <5238C2EA.5000705@oracle.com>
Peter,
Looks good for me.
But I would prefer to have brackets around c != NULL
-Dmitry
On 2013-09-17 19:44, Peter Allwin wrote:
> Hello!
>
> Please review this small fix for an issue where jio_snprintf may be
> called with a null argument causing SEGV on Solaris. This can occur if
> to_string is called on a GenDCmdArgument with no default value.
>
> cr: http://cr.openjdk.java.net/~allwin/7196151/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-7196151
>
>
> serviceability/ParserTest.java reproduces this issue and the fix has
> been verified with this test.
>
>
> Thanks!
> /peter
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From dmitry.samersoff at oracle.com Tue Sep 17 14:14:56 2013
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 18 Sep 2013 01:14:56 +0400
Subject: ATT! Re: RR(S): JDK-7133122 SA throws
sun.jvm.hotspot.debugger.UnmappedAddressException when it should not
In-Reply-To: <5235AF2F.7090105@oracle.com>
References: <5235AF2F.7090105@oracle.com>
Message-ID: <5238C650.3090901@oracle.com>
Need a second reviewer!
On 2013-09-15 16:59, Dmitry Samersoff wrote:
> Hi Everybody,
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
>
> Please review the small fix. This patch was contributed by Yasumasa Suenaga.
>
> -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 jonathan.gibbons at oracle.com Tue Sep 17 14:17:25 2013
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 17 Sep 2013 21:17:25 +0000
Subject: hg: jdk8/tl/langtools: 8024538: -Xdoclint + -Xprefer:source +
incremental compilation == FAIL
Message-ID: <20130917211728.84334628CD@hg.openjdk.java.net>
Changeset: fdfbc5f0c4ed
Author: jjg
Date: 2013-09-17 14:17 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fdfbc5f0c4ed
8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
+ test/tools/javac/doclint/implicitSource/ImplicitSourceTest.java
+ test/tools/javac/doclint/implicitSource/Other.java
From shanliang.jiang at oracle.com Tue Sep 17 23:52:08 2013
From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com)
Date: Wed, 18 Sep 2013 06:52:08 +0000
Subject: hg: jdk8/tl/jdk: 8023954: MBean*Info.equals: throw NPE
Message-ID: <20130918065258.B1348628EC@hg.openjdk.java.net>
Changeset: 8708569b5524
Author: sjiang
Date: 2013-09-18 08:51 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8708569b5524
8023954: MBean*Info.equals: throw NPE
Reviewed-by: dfuchs, dholmes
! src/share/classes/javax/management/MBeanAttributeInfo.java
! src/share/classes/javax/management/MBeanConstructorInfo.java
! src/share/classes/javax/management/MBeanFeatureInfo.java
! src/share/classes/javax/management/MBeanNotificationInfo.java
! src/share/classes/javax/management/MBeanOperationInfo.java
! src/share/classes/javax/management/MBeanParameterInfo.java
+ test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java
From weijun.wang at oracle.com Wed Sep 18 03:25:52 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 18 Sep 2013 10:25:52 +0000
Subject: hg: jdk8/tl/jdk: 8012615: Realm.getRealmsList returns realms list in
wrong
Message-ID: <20130918102712.42787628FD@hg.openjdk.java.net>
Changeset: ee8b292ee568
Author: weijun
Date: 2013-09-18 18:22 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee8b292ee568
8012615: Realm.getRealmsList returns realms list in wrong
Reviewed-by: valeriep, xuelei
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
! test/sun/security/krb5/ParseCAPaths.java
! test/sun/security/krb5/krb5-capaths.conf
From alan.bateman at oracle.com Wed Sep 18 06:18:05 2013
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 18 Sep 2013 13:18:05 +0000
Subject: hg: jdk8/tl/jdk: 8024883: (se) SelectableChannel.register throws NPE
if fd >= 64k (lnx)
Message-ID: <20130918131836.525DC62904@hg.openjdk.java.net>
Changeset: e92635d6834c
Author: alanb
Date: 2013-09-18 14:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e92635d6834c
8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx)
Reviewed-by: alanb, coffeys
Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com
! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java
! src/solaris/classes/sun/nio/ch/EventPortWrapper.java
! test/java/nio/channels/Selector/LotsOfChannels.java
! test/java/nio/channels/Selector/SelectorLimit.java
From joel.franck at oracle.com Wed Sep 18 06:27:33 2013
From: joel.franck at oracle.com (joel.franck at oracle.com)
Date: Wed, 18 Sep 2013 13:27:33 +0000
Subject: hg: jdk8/tl/langtools: 8024127: javac,
Code_attribute.exception_table_langth should be
Code_attribute.exception_table_length
Message-ID: <20130918132738.E8E6F62906@hg.openjdk.java.net>
Changeset: ac6ec071c2b2
Author: alundblad
Date: 2013-09-18 14:39 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac6ec071c2b2
8024127: javac, Code_attribute.exception_table_langth should be Code_attribute.exception_table_length
Summary: exception_table_langth renamed to exception_table_length
Reviewed-by: jfranck, jjg
! src/share/classes/com/sun/tools/classfile/Code_attribute.java
! src/share/classes/com/sun/tools/javap/CodeWriter.java
! test/tools/javac/T7093325.java
! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java
! test/tools/javac/multicatch/Pos05.java
From weijun.wang at oracle.com Wed Sep 18 06:39:51 2013
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Wed, 18 Sep 2013 13:39:51 +0000
Subject: hg: jdk8/tl/jdk: 8011402: Move blacklisting certificate logic from
hard code to data
Message-ID: <20130918134014.5492762907@hg.openjdk.java.net>
Changeset: 07d73060e0da
Author: weijun
Date: 2013-09-18 21:37 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07d73060e0da
8011402: Move blacklisting certificate logic from hard code to data
Reviewed-by: erikj, mullan
! make/java/security/Makefile
! makefiles/CopyFiles.gmk
! src/share/classes/java/security/cert/Certificate.java
! src/share/classes/sun/security/util/UntrustedCertificates.java
! src/share/classes/sun/security/x509/X509CertImpl.java
+ src/share/lib/security/BlacklistedCertsConverter.java
+ src/share/lib/security/blacklisted.certs
+ src/share/lib/security/blacklisted.certs.pem
+ test/lib/security/CheckBlacklistedCerts.java
From sundararajan.athijegannathan at oracle.com Wed Sep 18 07:37:36 2013
From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com)
Date: Wed, 18 Sep 2013 14:37:36 +0000
Subject: hg: jdk8/tl/nashorn: 2 new changesets
Message-ID: <20130918143741.268BA6290E@hg.openjdk.java.net>
Changeset: 1971c2d770ae
Author: sundar
Date: 2013-09-18 13:06 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1971c2d770ae
8024972: for (LeftHandSideExpression in Expression) crashes the compiler
Reviewed-by: lagergren, hannesw
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
+ test/script/basic/JDK-8024972.js
+ test/script/basic/JDK-8024972.js.EXPECTED
Changeset: a62172fe5bae
Author: sundar
Date: 2013-09-18 16:36 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a62172fe5bae
8024973: Using a different ScriptContext with a CompiledScript results in ScriptException
Reviewed-by: jlaskey, hannesw
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/internal/runtime/Source.java
! test/script/trusted/JDK-8008305.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
From chris.hegarty at oracle.com Wed Sep 18 07:13:40 2013
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 18 Sep 2013 14:13:40 +0000
Subject: hg: jdk8/tl/jdk: 8015762: TEST_BUG:
java/nio/channels/DatagramChannel/AdaptDatagramSocket.java
failing intermittently [win]
Message-ID: <20130918141403.6FA616290A@hg.openjdk.java.net>
Changeset: b3a506a30fda
Author: ewang
Date: 2013-09-18 15:13 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3a506a30fda
8015762: TEST_BUG: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failing intermittently [win]
Reviewed-by: chegar, alanb
! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java
From daniel.daugherty at oracle.com Wed Sep 18 10:47:37 2013
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Wed, 18 Sep 2013 17:47:37 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8019835: Strings interned in different
threads equal but does not ==
Message-ID: <20130918174742.DE06B62914@hg.openjdk.java.net>
Changeset: 63147986a428
Author: dcubed
Date: 2013-09-18 07:02 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/63147986a428
8019835: Strings interned in different threads equal but does not ==
Summary: Add -XX:+VerifyStringTableAtExit option and code to verify StringTable invariants.
Reviewed-by: rdurbin, sspitsyn, coleenp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
From coleen.phillimore at oracle.com Wed Sep 18 12:37:00 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Sep 2013 15:37:00 -0400
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <5228CB84.7010400@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
<5228B2D5.6060803@oracle.com> <5228CB84.7010400@oracle.com>
Message-ID: <523A00DC.9020905@oracle.com>
Hi, The new webrev is larger now. I found code where Method* can be
leaked because methodHandles are not freed, and have rewritten
JVM_GetClassDeclaredMethods and JVM_GetClassDeclaredConstructors to be
redefinition safe.
http://cr.openjdk.java.net/~coleenp/8022887_2/
Tested with internal vm.quick.testlist and mlvm tests.
Thanks,
Coleen
On 9/5/2013 2:20 PM, serguei.spitsyn at oracle.com wrote:
> Coleen,
>
> This is great finding, and also a nice catch by Dan.
> Waiting for a new webrev from you.
>
> Thanks,
> Serguei
>
> On 9/5/13 9:35 AM, Coleen Phillimore wrote:
>>
>> Dan,
>> Thank you for looking at this so quickly. You are right, we are not
>> only getting public methods, whose number cannot change right now
>> with redefine classes.
>> I have to rework this change.
>> Thanks,
>> Coleen
>>
>> On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
>>> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>>>> Summary: Need to refetch the methods array from InstanceKlass after
>>>> safepoint.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>>>
>>> The "frames" links are broken in this webrev. I had to
>>> write down the changed line numbers for jvm.cpp and then
>>> use the "new" link to see the context of the changes.
>>>
>>> src/share/vm/oops/instanceKlass.cpp
>>> Nice catch. The old code could return an 'm' value that
>>> referred to a method that wasn't a match. Ouch.
>>>
>>
>> yes, it was a bit of a red herring for a while.
>>
>>> src/share/vm/prims/jvm.cpp
>>> Nice catch of the use of potentially stale method array, but I
>>> think there might be more issues here.
>>>
>>> In JVM_GetClassDeclaredMethods:
>>>
>>> line 1865: ++num_methods;
>>>
>>>
>>>
>>> line 1871: objArrayOop r =
>>> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
>>> num_methods, CHECK_NULL);
>>>
>>>
>>>
>>> line 1876: methods = k->methods();
>>> line 1877: methods_length = methods->length();
>>>
>>>
>>>
>>> line 1885: result->obj_at_put(out_idx, m);
>>>
>>>
>>>
>>> line 1890: assert(out_idx == num_methods, "just checking");
>>>
>>> So num_methods is computed before the new_objArray() call that
>>> can result in a safepoint which can permit a RedefineClasses()
>>> operation to complete. You refresh methods and methods_length,
>>> but num_methods still has its pre-RedefineClasses value and
>>> the size of the result array is also at the pre-RedefineClasses
>>> size. Isn't it possible that we could overflow the result array
>>> here? And maybe fire that assert() on line 1890.
>>>
>>>
>>> In JVM_GetClassDeclaredConstructors(), similar concerns for these
>>> lines:
>>>
>>> line 1922: ++num_constructors;
>>>
>>>
>>>
>>> line 1928: objArrayOop r =
>>> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
>>> num_constructors, CHECK_NULL);
>>>
>>>
>>>
>>> line 1942: result->obj_at_put(out_idx, m);
>>>
>>>
>>>
>>> line 1947: assert(out_idx == num_constructors, "just checking");
>>>
>>>
>>> Yes, this RedefineClasses() stuff is a serious pain in the butt
>>> because it can change your assumed invariants in the middle of
>>> your function.
>>>
>>> Dan
>>>
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>>>
>>>> Tested with the test cases in the bug, and with internal SQE tests
>>>> (nsk.quick.testlist).
>>>>
>>>> thanks,
>>>> Coleen
>>>
>>
>
From daniel.daugherty at oracle.com Wed Sep 18 14:26:51 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 18 Sep 2013 15:26:51 -0600
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <523A00DC.9020905@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
<5228B2D5.6060803@oracle.com> <5228CB84.7010400@oracle.com>
<523A00DC.9020905@oracle.com>
Message-ID: <523A1A9B.8040306@oracle.com>
On 9/18/13 1:37 PM, Coleen Phillimore wrote:
>
> Hi, The new webrev is larger now. I found code where Method* can be
> leaked because methodHandles are not freed, and have rewritten
> JVM_GetClassDeclaredMethods and JVM_GetClassDeclaredConstructors to be
> redefinition safe.
>
> http://cr.openjdk.java.net/~coleenp/8022887_2/
>
Again, your 'frames' links are broken, but those "Previous File"
and "Next File" links look interesting... :-)
Short version: thumbs up
Longer version...
src/share/vm/runtime/handles.hpp
No comments.
src/share/vm/runtime/handles.inline.hpp
No comments.
src/share/vm/oops/instanceKlass.hpp
So this comment:
ConstantPool* _prev_constant_pool; // regular or weak reference
is stale, i.e., leftover from the pre-PermGenRemoval days.
And it looks like you're ripping out the PreviousVersionInfo
wrapper around PreviousVersionNode stuff because the constant
pool is no longer an oop so we don't need that extra layer of
protection anymore. I definitely like the cleanup.
src/share/vm/oops/instanceKlass.cpp
More CDE of stuff from the pre-PermGenRemoval days. Looks good.
And buried in all the CDE, is a critical fix from the previous
round:
*** 3518,3527 ****
--- 3511,3522 ----
m = methods()->at(index);
if (m->method_idnum() == idnum) {
return m;
}
}
+ // None found, return null for the caller to handle.
+ return NULL;
}
return m;
}
src/share/vm/prims/jvm.cpp
I like the refactoring into get_class_declared_method_helper().
Can you change:
1918 return get_class_declared_method_helper(env, ofClass, publicOnly,
false,
1919 SystemDictionary::reflect_Method_klass(), THREAD);
to:
1918 return get_class_declared_method_helper(env, ofClass, publicOnly,
1919 false /* want_constructor */,
1920 SystemDictionary::reflect_Method_klass(), THREAD);
And can you change:
1926 return get_class_declared_method_helper(env, ofClass, publicOnly,
true,
1927 SystemDictionary::reflect_Constructor_klass(), THREAD);
to:
1927 return get_class_declared_method_helper(env, ofClass, publicOnly,
1928 true /* want_constructor */,
1929 SystemDictionary::reflect_Constructor_klass(), THREAD);
src/share/vm/prims/jvmtiImpl.cpp
More CDE from the removal of PreviousVersionInfo. Looks good.
src/share/vm/prims/jvmtiRedefineClasses.cpp
More CDE from the removal of PreviousVersionInfo. Looks good.
So if I understand this change correctly:
1) fix Method* InstanceKlass::method_with_idnum(int idnum) {
to not return a mis-matched Method* value
2) refactor JVM_GetClassDeclaredMethods() and
JVM_GetClassDeclaredConstructors() to share common code and to
tolerate an interleaved JVM/TI RedefineClasses() call
3) CDE of PreviousVersionInfo and the cleanup of PreviousVersionWalker
that the CDE allows
Nicely done.
Dan
>
> Tested with internal vm.quick.testlist and mlvm tests.
>
> Thanks,
> Coleen
>
>
> On 9/5/2013 2:20 PM, serguei.spitsyn at oracle.com wrote:
>> Coleen,
>>
>> This is great finding, and also a nice catch by Dan.
>> Waiting for a new webrev from you.
>>
>> Thanks,
>> Serguei
>>
>> On 9/5/13 9:35 AM, Coleen Phillimore wrote:
>>>
>>> Dan,
>>> Thank you for looking at this so quickly. You are right, we are
>>> not only getting public methods, whose number cannot change right
>>> now with redefine classes.
>>> I have to rework this change.
>>> Thanks,
>>> Coleen
>>>
>>> On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
>>>> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>>>>> Summary: Need to refetch the methods array from InstanceKlass
>>>>> after safepoint.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>>>>
>>>> The "frames" links are broken in this webrev. I had to
>>>> write down the changed line numbers for jvm.cpp and then
>>>> use the "new" link to see the context of the changes.
>>>>
>>>> src/share/vm/oops/instanceKlass.cpp
>>>> Nice catch. The old code could return an 'm' value that
>>>> referred to a method that wasn't a match. Ouch.
>>>>
>>>
>>> yes, it was a bit of a red herring for a while.
>>>
>>>> src/share/vm/prims/jvm.cpp
>>>> Nice catch of the use of potentially stale method array, but I
>>>> think there might be more issues here.
>>>>
>>>> In JVM_GetClassDeclaredMethods:
>>>>
>>>> line 1865: ++num_methods;
>>>>
>>>>
>>>>
>>>> line 1871: objArrayOop r =
>>>> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
>>>> num_methods, CHECK_NULL);
>>>>
>>>>
>>>>
>>>> line 1876: methods = k->methods();
>>>> line 1877: methods_length = methods->length();
>>>>
>>>>
>>>>
>>>> line 1885: result->obj_at_put(out_idx, m);
>>>>
>>>>
>>>>
>>>> line 1890: assert(out_idx == num_methods, "just checking");
>>>>
>>>> So num_methods is computed before the new_objArray() call that
>>>> can result in a safepoint which can permit a RedefineClasses()
>>>> operation to complete. You refresh methods and methods_length,
>>>> but num_methods still has its pre-RedefineClasses value and
>>>> the size of the result array is also at the
>>>> pre-RedefineClasses
>>>> size. Isn't it possible that we could overflow the result
>>>> array
>>>> here? And maybe fire that assert() on line 1890.
>>>>
>>>>
>>>> In JVM_GetClassDeclaredConstructors(), similar concerns for these
>>>> lines:
>>>>
>>>> line 1922: ++num_constructors;
>>>>
>>>>
>>>>
>>>> line 1928: objArrayOop r =
>>>> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
>>>> num_constructors, CHECK_NULL);
>>>>
>>>>
>>>>
>>>> line 1942: result->obj_at_put(out_idx, m);
>>>>
>>>>
>>>>
>>>> line 1947: assert(out_idx == num_constructors, "just checking");
>>>>
>>>>
>>>> Yes, this RedefineClasses() stuff is a serious pain in the butt
>>>> because it can change your assumed invariants in the middle of
>>>> your function.
>>>>
>>>> Dan
>>>>
>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>>>>
>>>>> Tested with the test cases in the bug, and with internal SQE tests
>>>>> (nsk.quick.testlist).
>>>>>
>>>>> thanks,
>>>>> Coleen
>>>>
>>>
>>
>
From coleen.phillimore at oracle.com Wed Sep 18 15:13:06 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Sep 2013 18:13:06 -0400
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <523A1A9B.8040306@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
<5228B2D5.6060803@oracle.com> <5228CB84.7010400@oracle.com>
<523A00DC.9020905@oracle.com> <523A1A9B.8040306@oracle.com>
Message-ID: <523A2572.1020907@oracle.com>
Thank you Dan for the really quick review!
On 9/18/2013 5:26 PM, Daniel D. Daugherty wrote:
> On 9/18/13 1:37 PM, Coleen Phillimore wrote:
>>
>> Hi, The new webrev is larger now. I found code where Method* can be
>> leaked because methodHandles are not freed, and have rewritten
>> JVM_GetClassDeclaredMethods and JVM_GetClassDeclaredConstructors to
>> be redefinition safe.
>>
>> http://cr.openjdk.java.net/~coleenp/8022887_2/
>>
>
> Again, your 'frames' links are broken, but those "Previous File"
> and "Next File" links look interesting... :-)
>
Yes, one webrev version has these nice previous/next file links and the
other version of webrev gets frames correct. I like the latter better
but it's not maintained anymore. I updated the webrev with the other.
> Short version: thumbs up
>
> Longer version...
>
> src/share/vm/runtime/handles.hpp
> No comments.
>
> src/share/vm/runtime/handles.inline.hpp
> No comments.
>
>
> src/share/vm/oops/instanceKlass.hpp
> So this comment:
>
> ConstantPool* _prev_constant_pool; // regular or weak
> reference
I took out the comment.
>
> is stale, i.e., leftover from the pre-PermGenRemoval days.
> And it looks like you're ripping out the PreviousVersionInfo
> wrapper around PreviousVersionNode stuff because the constant
> pool is no longer an oop so we don't need that extra layer of
> protection anymore. I definitely like the cleanup.
>
Thanks! It's also taken out because it held a resource allocated array
of methodHandles whose destructors were never called, so were never
deleted off the thread->metadata_handles() list, so were always marked
as live on_stack, and never deleted.
> src/share/vm/oops/instanceKlass.cpp
> More CDE of stuff from the pre-PermGenRemoval days. Looks good.
>
> And buried in all the CDE, is a critical fix from the previous
> round:
>
> *** 3518,3527 ****
> --- 3511,3522 ----
> m = methods()->at(index);
> if (m->method_idnum() == idnum) {
> return m;
> }
> }
> + // None found, return null for the caller to handle.
> + return NULL;
> }
> return m;
> }
>
> src/share/vm/prims/jvm.cpp
> I like the refactoring into get_class_declared_method_helper().
>
> Can you change:
>
> 1918 return get_class_declared_method_helper(env, ofClass,
> publicOnly, false,
> 1919 SystemDictionary::reflect_Method_klass(), THREAD);
>
> to:
>
> 1918 return get_class_declared_method_helper(env, ofClass, publicOnly,
> 1919 false /*
> want_constructor */,
> 1920 SystemDictionary::reflect_Method_klass(), THREAD);
>
> And can you change:
>
> 1926 return get_class_declared_method_helper(env, ofClass,
> publicOnly, true,
> 1927 SystemDictionary::reflect_Constructor_klass(), THREAD);
>
> to:
>
> 1927 return get_class_declared_method_helper(env, ofClass, publicOnly,
> 1928 true /*
> want_constructor */,
> 1929 SystemDictionary::reflect_Constructor_klass(), THREAD);
>
>
Got it. The drawback of boolean arguments.
> src/share/vm/prims/jvmtiImpl.cpp
> More CDE from the removal of PreviousVersionInfo. Looks good.
>
>
> src/share/vm/prims/jvmtiRedefineClasses.cpp
> More CDE from the removal of PreviousVersionInfo. Looks good.
>
> So if I understand this change correctly:
>
> 1) fix Method* InstanceKlass::method_with_idnum(int idnum) {
> to not return a mis-matched Method* value
> 2) refactor JVM_GetClassDeclaredMethods() and
> JVM_GetClassDeclaredConstructors() to share common code and to
> tolerate an interleaved JVM/TI RedefineClasses() call
> 3) CDE of PreviousVersionInfo and the cleanup of PreviousVersionWalker
> that the CDE allows
Yes, but 3 was causing leaks also.
Thanks and thanks for the quick review!
Coleen
>
> Nicely done.
>
> Dan
>
>
>
>>
>> Tested with internal vm.quick.testlist and mlvm tests.
>>
>> Thanks,
>> Coleen
>>
>>
>> On 9/5/2013 2:20 PM, serguei.spitsyn at oracle.com wrote:
>>> Coleen,
>>>
>>> This is great finding, and also a nice catch by Dan.
>>> Waiting for a new webrev from you.
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 9/5/13 9:35 AM, Coleen Phillimore wrote:
>>>>
>>>> Dan,
>>>> Thank you for looking at this so quickly. You are right, we are
>>>> not only getting public methods, whose number cannot change right
>>>> now with redefine classes.
>>>> I have to rework this change.
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
>>>>> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>>>>>> Summary: Need to refetch the methods array from InstanceKlass
>>>>>> after safepoint.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>>>>>
>>>>> The "frames" links are broken in this webrev. I had to
>>>>> write down the changed line numbers for jvm.cpp and then
>>>>> use the "new" link to see the context of the changes.
>>>>>
>>>>> src/share/vm/oops/instanceKlass.cpp
>>>>> Nice catch. The old code could return an 'm' value that
>>>>> referred to a method that wasn't a match. Ouch.
>>>>>
>>>>
>>>> yes, it was a bit of a red herring for a while.
>>>>
>>>>> src/share/vm/prims/jvm.cpp
>>>>> Nice catch of the use of potentially stale method array, but I
>>>>> think there might be more issues here.
>>>>>
>>>>> In JVM_GetClassDeclaredMethods:
>>>>>
>>>>> line 1865: ++num_methods;
>>>>>
>>>>>
>>>>>
>>>>> line 1871: objArrayOop r =
>>>>> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
>>>>> num_methods, CHECK_NULL);
>>>>>
>>>>>
>>>>>
>>>>> line 1876: methods = k->methods();
>>>>> line 1877: methods_length = methods->length();
>>>>>
>>>>>
>>>>>
>>>>> line 1885: result->obj_at_put(out_idx, m);
>>>>>
>>>>>
>>>>>
>>>>> line 1890: assert(out_idx == num_methods, "just checking");
>>>>>
>>>>> So num_methods is computed before the new_objArray() call
>>>>> that
>>>>> can result in a safepoint which can permit a
>>>>> RedefineClasses()
>>>>> operation to complete. You refresh methods and
>>>>> methods_length,
>>>>> but num_methods still has its pre-RedefineClasses value and
>>>>> the size of the result array is also at the
>>>>> pre-RedefineClasses
>>>>> size. Isn't it possible that we could overflow the result
>>>>> array
>>>>> here? And maybe fire that assert() on line 1890.
>>>>>
>>>>>
>>>>> In JVM_GetClassDeclaredConstructors(), similar concerns for these
>>>>> lines:
>>>>>
>>>>> line 1922: ++num_constructors;
>>>>>
>>>>>
>>>>>
>>>>> line 1928: objArrayOop r =
>>>>> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
>>>>> num_constructors, CHECK_NULL);
>>>>>
>>>>>
>>>>>
>>>>> line 1942: result->obj_at_put(out_idx, m);
>>>>>
>>>>>
>>>>>
>>>>> line 1947: assert(out_idx == num_constructors, "just checking");
>>>>>
>>>>>
>>>>> Yes, this RedefineClasses() stuff is a serious pain in the butt
>>>>> because it can change your assumed invariants in the middle of
>>>>> your function.
>>>>>
>>>>> Dan
>>>>>
>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>>>>>
>>>>>> Tested with the test cases in the bug, and with internal SQE
>>>>>> tests (nsk.quick.testlist).
>>>>>>
>>>>>> thanks,
>>>>>> Coleen
>>>>>
>>>>
>>>
>>
>
From philip.race at oracle.com Wed Sep 18 15:22:32 2013
From: philip.race at oracle.com (Phil Race)
Date: Wed, 18 Sep 2013 15:22:32 -0700
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
build the class library on AIX
In-Reply-To:
References:
Message-ID: <523A27A8.404@oracle.com>
Volker,
I've skimmed the client related changes - mostly based on the descriptions.
I'll look in more detail as soon as I can after JavaOne. We also have some
engineers out on vacation who might want to look at these too.
A couple of things that stood out :
"On AIX, fontconfig is not a standard package supported by IBM."
I am surprised AIX does not support fontconfig.
That is something IBM should reconsider as its hard to imagine
a modern Unix based system working without it ..
Very basic start for AIX - feel free to complete ..
169 */
170 static char *fullAixFontPath[] = {
...
I'd really like to see it completed but these days
that's largely a fall back for no fontconfig.
/* AIX does not provide the 'dladdr' function. But fortunately, we've
42 * already implemented it in the HotSpot, because we need it there as
43 * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}).
Whilst this is in "ifdef AIX" this reliance on an exported hotspot
function sounds hacky. What actual requirement is there that the
AIX class libraries be so tightly-coupled with that VM?
There is no contract there.
-phil.
On 9/16/2013 12:30 PM, Volker Simonis wrote:
> Resending this to more lists as requested by Alan Bateman with the
> kind request to anybody to review the parts for which he feels
> responsible:)
>
> For those not up to date, this change is part of the ongoing
> PowerPC/AIX Porting Project:
> http://openjdk.java.net/projects/ppc-aix-port
> https://wiki.openjdk.java.net/display/PPCAIXPort
> http://openjdk.java.net/jeps/175
>
> Please send reviews to all currently included recipients.
>
> Thank you and best regards,
> Volker
>
>
> ---------- Forwarded message ----------
> From: *Volker Simonis*
> Date: Monday, September 16, 2013
> Subject: RFR(L): 8024854: Basic changes and files to build the class
> library on AIX
> To: "ppc-aix-port-dev at openjdk.java.net
> "
> >, Java Core Libs
> >
>
>
> Hi,
>
> could you please review the following webrev which contains the basic
> changes and files needed in the 'jdk' repository in order to build the
> OpenJDK on AIX:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8024854
>
>
> This change together with "8024265: Enable new build on AIX (jdk part)
> " allows
> it to configure and completely build the staging repository on AIX 5.3
> and 7.1 with the following command:
>
> configure --with-boot-jdk= --with-jvm-variants=core
> --with-jvm-interpreter=cpp --with-cups-include=/opt/freeware/include
> --x-includes=/opt/freeware/include
>
> Below you can find the changes and additions I've done, sorted by
> file. Most of them are just additions which are only active during the
> AIX build anyway or simple changes where AIX has been added to
> conditions which already check for Linux and/or Solaris. The files
> with the biggest changes which you're probably want to look on more
> thoroughly are 'src/solaris/native/java/net/NetworkInterface.c' and
> 'src/solaris/native/sun/nio/ch/Net.c' altough they shouldn't change
> anything on the current OpenJDK platforms as well.
>
> Notice that there are still some files and some functionality missing
> from the current change (notably NIO) but it still yields a running
> JDK which can execute "HelloWorld" on the command line and as AWT
> application. I've intentionally tried to keep this initial change as
> simple as possible (with respect tot shared changes) in order to get
> it reviewed as fast as possible. The missing parts can then be added
> later on, grouped by logical topics, to simplify the review process.
>
> Thank you and best regards,
>
> Volker
>
>
> src/share/bin/jli_util.h
>
> * Define |JLI_Lseek| on AIX.
>
>
> src/share/lib/security/java.security-aix
>
> * Provide default |java.security-aix| for AIX.
>
>
> src/share/native/sun/awt/medialib/mlib_sys.c
>
> * |malloc| always returns 8-byte aligned pointers on AIX as well.
>
>
> src/share/native/sun/awt/medialib/mlib_types.h
>
> * Add AIX to the list of known platforms.
>
>
> src/share/native/sun/font/layout/KernTable.cpp
>
> * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
> too common and may be defined in other headers as well as on the
> command line and |xlc| bails out on macro redefinitions with a
> different value.
>
>
> src/share/native/sun/security/ec/impl/ecc_impl.h
>
> * Define required types and macros on AIX.
>
>
> src/solaris/back/exec_md.c
>
> * AIX behaves like Linux in this case so check for it in the Linux
> branch.
>
>
> src/solaris/bin/java_md_solinux.c,
> src/solaris/bin/java_md_solinux.h
>
> * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
> * Always use |LD_LIBRARY_PATH| macro instead of using the string
> "|LD_LIBRARY_PATH|" directly to cope with different library path
> names.
> * Add |jre/lib//jli| to the standard library search path on
> AIX because the AIX linker doesn't support the |-rpath| option.
> * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
> this case, AIX behaves like Linux.
>
>
> src/solaris/classes/sun/awt/fontconfigs/aix.fontconfig.properties
>
> * Provide basic |fontconfig.properties|for AIX.
>
>
> src/solaris/classes/java/lang/UNIXProcess.java.aix,
> src/solaris/classes/sun/tools/attach/AixAttachProvider.java,
> src/solaris/classes/sun/tools/attach/AixVirtualMachine.java
>
> * Provide AIX specific Java versions, mostly based on the
> corresponding Linux versions.
>
>
> src/solaris/demo/jvmti/hprof/hprof_md.c
>
> * Add AIX support. AIX mostly behaves like Linux, with the one
> exception that it has no |dladdr| functionality.
> * Implement |dladdr| functionality for AIX.
>
>
> src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
>
> * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>
>
> src/solaris/native/common/jdk_util_md.h
>
> * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>
>
> src/solaris/native/java/io/io_util_md.c
>
> * AIX behaves like Linux in this case so check for it in the Linux
> branch.
>
>
> src/solaris/native/java/net/NetworkInterface.c
>
> * Add AIX support into the Linux branch because AIX mostly behaves
> like AIX for IPv4.
> * AIX needs a special function to enumerate IPv6 interfaces and to
> query the MAC address.
>
>
> src/solaris/native/java/net/PlainSocketImpl.c
>
> * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL|
> if the socket is closed. The default error message is then confusing.
>
>
> src/solaris/native/java/net/linux_close.c,
> src/share/native/java/net/net_util.c
>
> * Also use the file and socket wrappers on AIX.
> * Add initialization of some previously uninitialized data structures.
> * On AIX we don't have |__attribute((constructor))| so we need to
> initialize manually (from |JNI_OnLoad()| in
> 'src/share/native/java/net/net_util.c'
>
>
> src/solaris/native/java/net/net_util_md.h
>
> * AIX needs the same workaround for I/O cancellation like Linux and
> MacOSX.
>
>
> src/solaris/native/java/util/TimeZone_md.c
>
> * Currently on AIX the only way to get the platform time zone is to
> read it from the |TZ| environment variable.
>
>
> src/solaris/native/sun/awt/awt_LoadLibrary.c
>
> * There's no |dladdr| on AIX, but we can use the implementation from
> the HotSpot in this case because |libjvm.so| will be always loaded
> before the AWT.
>
>
> src/solaris/native/sun/awt/fontpath.c
>
> * Add AIX specific fontpath settings and library search paths for
> |libfontconfig.so|.
>
>
> src/solaris/native/sun/java2d/x11/X11SurfaceData.c
>
> * Only define |MIN| and |MAX| if they're not already defined because
> xlc on AIX fails on macro redefinitions.
>
>
> src/solaris/native/sun/java2d/x11/XRBackendNative.c
>
> * Handle AIX like Solaris.
>
>
> src/solaris/native/sun/nio/ch/Net.c
>
> * Add AIX-specific includes and constant definitions.
> * On AIX "socket extensions for multicast source filters" support
> depends on the OS version. Check for this and throw appropriate
> exceptions if it requested but not supported. This is needed to
> pass
> JCK-api/java_nio/channels/DatagramChannel/DatagramChannel.html#Multicast
>
>
> src/solaris/native/sun/security/pkcs11/j2secmod_md.c
>
> * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>
>
> src/solaris/native/sun/tools/attach/AixVirtualMachine.c
>
> * AIX version mostly derived from the corresponding Linux version.
>
>
From daniel.daugherty at oracle.com Wed Sep 18 15:21:11 2013
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 18 Sep 2013 16:21:11 -0600
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <523A2572.1020907@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
<5228B2D5.6060803@oracle.com> <5228CB84.7010400@oracle.com>
<523A00DC.9020905@oracle.com> <523A1A9B.8040306@oracle.com>
<523A2572.1020907@oracle.com>
Message-ID: <523A2757.2000103@oracle.com>
On 9/18/13 4:13 PM, Coleen Phillimore wrote:
>
> Thank you Dan for the really quick review!
No problem. I figured you wanted a quick review with JavaOne approaching
and all...
>
> On 9/18/2013 5:26 PM, Daniel D. Daugherty wrote:
>> On 9/18/13 1:37 PM, Coleen Phillimore wrote:
>>>
>>> Hi, The new webrev is larger now. I found code where Method* can
>>> be leaked because methodHandles are not freed, and have rewritten
>>> JVM_GetClassDeclaredMethods and JVM_GetClassDeclaredConstructors to
>>> be redefinition safe.
>>>
>>> http://cr.openjdk.java.net/~coleenp/8022887_2/
>>>
>>
>> Again, your 'frames' links are broken, but those "Previous File"
>> and "Next File" links look interesting... :-)
>>
>
> Yes, one webrev version has these nice previous/next file links and
> the other version of webrev gets frames correct. I like the latter
> better but it's not maintained anymore. I updated the webrev with
> the other.
I wonder if it is possible to merge the two... The one with the
links was Tom R's right?
>
>> Short version: thumbs up
>>
>> Longer version...
>>
>> src/share/vm/runtime/handles.hpp
>> No comments.
>>
>> src/share/vm/runtime/handles.inline.hpp
>> No comments.
>>
>>
>> src/share/vm/oops/instanceKlass.hpp
>> So this comment:
>>
>> ConstantPool* _prev_constant_pool; // regular or weak
>> reference
>
> I took out the comment.
Right. I could have been more clear.
>
>>
>> is stale, i.e., leftover from the pre-PermGenRemoval days.
>> And it looks like you're ripping out the PreviousVersionInfo
>> wrapper around PreviousVersionNode stuff because the constant
>> pool is no longer an oop so we don't need that extra layer of
>> protection anymore. I definitely like the cleanup.
>>
>
> Thanks! It's also taken out because it held a resource allocated
> array of methodHandles whose destructors were never called, so were
> never deleted off the thread->metadata_handles() list, so were always
> marked as live on_stack, and never deleted.
Right. In the pre-PermGenRemoval code, we keyed off the weak reference
to the constant pool. When the constant pool weak ref was no longer
valid, then we knew that the methodHandles were no longer valid and
they were cleaned up. So this leak was introduced as part of the
transition of the pre-PermGenRemoval code to the new world order.
Your fix here completes (and cleans up) that transition in this area.
Very nice work.
Dan
>
>> src/share/vm/oops/instanceKlass.cpp
>> More CDE of stuff from the pre-PermGenRemoval days. Looks good.
>>
>> And buried in all the CDE, is a critical fix from the previous
>> round:
>>
>> *** 3518,3527 ****
>> --- 3511,3522 ----
>> m = methods()->at(index);
>> if (m->method_idnum() == idnum) {
>> return m;
>> }
>> }
>> + // None found, return null for the caller to handle.
>> + return NULL;
>> }
>> return m;
>> }
>>
>> src/share/vm/prims/jvm.cpp
>> I like the refactoring into get_class_declared_method_helper().
>>
>> Can you change:
>>
>> 1918 return get_class_declared_method_helper(env, ofClass,
>> publicOnly, false,
>> 1919 SystemDictionary::reflect_Method_klass(), THREAD);
>>
>> to:
>>
>> 1918 return get_class_declared_method_helper(env, ofClass, publicOnly,
>> 1919 false /*
>> want_constructor */,
>> 1920 SystemDictionary::reflect_Method_klass(), THREAD);
>>
>> And can you change:
>>
>> 1926 return get_class_declared_method_helper(env, ofClass,
>> publicOnly, true,
>> 1927 SystemDictionary::reflect_Constructor_klass(), THREAD);
>>
>> to:
>>
>> 1927 return get_class_declared_method_helper(env, ofClass, publicOnly,
>> 1928 true /*
>> want_constructor */,
>> 1929 SystemDictionary::reflect_Constructor_klass(), THREAD);
>>
>>
>
> Got it. The drawback of boolean arguments.
>
>> src/share/vm/prims/jvmtiImpl.cpp
>> More CDE from the removal of PreviousVersionInfo. Looks good.
>>
>>
>> src/share/vm/prims/jvmtiRedefineClasses.cpp
>> More CDE from the removal of PreviousVersionInfo. Looks good.
>>
>> So if I understand this change correctly:
>>
>> 1) fix Method* InstanceKlass::method_with_idnum(int idnum) {
>> to not return a mis-matched Method* value
>> 2) refactor JVM_GetClassDeclaredMethods() and
>> JVM_GetClassDeclaredConstructors() to share common code and to
>> tolerate an interleaved JVM/TI RedefineClasses() call
>> 3) CDE of PreviousVersionInfo and the cleanup of PreviousVersionWalker
>> that the CDE allows
>
> Yes, but 3 was causing leaks also.
>
> Thanks and thanks for the quick review!
> Coleen
>
>>
>> Nicely done.
>>
>> Dan
>>
>>
>>
>>>
>>> Tested with internal vm.quick.testlist and mlvm tests.
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>> On 9/5/2013 2:20 PM, serguei.spitsyn at oracle.com wrote:
>>>> Coleen,
>>>>
>>>> This is great finding, and also a nice catch by Dan.
>>>> Waiting for a new webrev from you.
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 9/5/13 9:35 AM, Coleen Phillimore wrote:
>>>>>
>>>>> Dan,
>>>>> Thank you for looking at this so quickly. You are right, we are
>>>>> not only getting public methods, whose number cannot change right
>>>>> now with redefine classes.
>>>>> I have to rework this change.
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
>>>>>> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>>>>>>> Summary: Need to refetch the methods array from InstanceKlass
>>>>>>> after safepoint.
>>>>>>>
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>>>>>>
>>>>>> The "frames" links are broken in this webrev. I had to
>>>>>> write down the changed line numbers for jvm.cpp and then
>>>>>> use the "new" link to see the context of the changes.
>>>>>>
>>>>>> src/share/vm/oops/instanceKlass.cpp
>>>>>> Nice catch. The old code could return an 'm' value that
>>>>>> referred to a method that wasn't a match. Ouch.
>>>>>>
>>>>>
>>>>> yes, it was a bit of a red herring for a while.
>>>>>
>>>>>> src/share/vm/prims/jvm.cpp
>>>>>> Nice catch of the use of potentially stale method array, but I
>>>>>> think there might be more issues here.
>>>>>>
>>>>>> In JVM_GetClassDeclaredMethods:
>>>>>>
>>>>>> line 1865: ++num_methods;
>>>>>>
>>>>>>
>>>>>>
>>>>>> line 1871: objArrayOop r =
>>>>>> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(), num_methods,
>>>>>> CHECK_NULL);
>>>>>>
>>>>>>
>>>>>>
>>>>>> line 1876: methods = k->methods();
>>>>>> line 1877: methods_length = methods->length();
>>>>>>
>>>>>>
>>>>>>
>>>>>> line 1885: result->obj_at_put(out_idx, m);
>>>>>>
>>>>>>
>>>>>>
>>>>>> line 1890: assert(out_idx == num_methods, "just checking");
>>>>>>
>>>>>> So num_methods is computed before the new_objArray() call
>>>>>> that
>>>>>> can result in a safepoint which can permit a
>>>>>> RedefineClasses()
>>>>>> operation to complete. You refresh methods and
>>>>>> methods_length,
>>>>>> but num_methods still has its pre-RedefineClasses value and
>>>>>> the size of the result array is also at the
>>>>>> pre-RedefineClasses
>>>>>> size. Isn't it possible that we could overflow the result
>>>>>> array
>>>>>> here? And maybe fire that assert() on line 1890.
>>>>>>
>>>>>>
>>>>>> In JVM_GetClassDeclaredConstructors(), similar concerns for
>>>>>> these
>>>>>> lines:
>>>>>>
>>>>>> line 1922: ++num_constructors;
>>>>>>
>>>>>>
>>>>>>
>>>>>> line 1928: objArrayOop r =
>>>>>> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
>>>>>> num_constructors, CHECK_NULL);
>>>>>>
>>>>>>
>>>>>>
>>>>>> line 1942: result->obj_at_put(out_idx, m);
>>>>>>
>>>>>>
>>>>>>
>>>>>> line 1947: assert(out_idx == num_constructors, "just checking");
>>>>>>
>>>>>>
>>>>>> Yes, this RedefineClasses() stuff is a serious pain in the butt
>>>>>> because it can change your assumed invariants in the middle of
>>>>>> your function.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>>>>>>
>>>>>>> Tested with the test cases in the bug, and with internal SQE
>>>>>>> tests (nsk.quick.testlist).
>>>>>>>
>>>>>>> thanks,
>>>>>>> Coleen
>>>>>>
>>>>>
>>>>
>>>
>>
>
From bhavesh.x.patel at oracle.com Wed Sep 18 17:14:39 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 19 Sep 2013 00:14:39 +0000
Subject: hg: jdk8/tl/langtools: 8015249: javadoc fails to document static
final fields in annotation types
Message-ID: <20130919001444.EDE5062920@hg.openjdk.java.net>
Changeset: a2a5ad0853ed
Author: bpatel
Date: 2013-09-18 17:13 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a2a5ad0853ed
8015249: javadoc fails to document static final fields in annotation types
Reviewed-by: jjg
+ src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeFieldWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeFieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java
+ test/com/sun/javadoc/testAnnotationTypes/pkg/AnnotationTypeField.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
From david.holmes at oracle.com Wed Sep 18 19:07:46 2013
From: david.holmes at oracle.com (david.holmes at oracle.com)
Date: Thu, 19 Sep 2013 02:07:46 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 8024826: (s) : Remove alt-rt.jar,
used by +AggressiveOps
Message-ID: <20130919020751.72CDB6292D@hg.openjdk.java.net>
Changeset: dfae98867ee8
Author: dholmes
Date: 2013-09-18 20:08 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dfae98867ee8
8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps
Reviewed-by: alanb, chegar, dholmes, ksrini
Contributed-by: Mike Duigou
! src/share/vm/runtime/arguments.cpp
From david.holmes at oracle.com Wed Sep 18 20:51:30 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Sep 2013 13:51:30 +1000
Subject: RR(S): JDK-7133122 SA throws
sun.jvm.hotspot.debugger.UnmappedAddressException when it should not
In-Reply-To: <5236C832.3010907@oracle.com>
References: <5235AF2F.7090105@oracle.com>
<34F79189-6967-482A-ADBA-30BF96666771@oracle.com>
<5236C832.3010907@oracle.com>
Message-ID: <523A74C2.5090303@oracle.com>
Seems okay.
One nit: existed_map -> existing_map
David
On 16/09/2013 6:58 PM, Dmitry Samersoff wrote:
> Staffan,
>
> Thank you! Fixed (in-place).
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
>
> -Dmitry
>
> On 2013-09-16 10:04, Staffan Larsen wrote:
>> A couple of small nits:
>>
>> line 721: there is a superfluous + sign at the beginning of the line.
>>
>> line 729: confliction -> conflict
>>
>> line 734: to -> with
>>
>> line 735: overwrite to -> overwrote with
>>
>>
>> Otherwise looks good.
>>
>> /Staffan
>>
>> On 15 sep 2013, at 15:59, Dmitry Samersoff wrote:
>>
>>> Hi Everybody,
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7133122/webrev.01/
>>>
>>> Please review the small fix. This patch was contributed by Yasumasa Suenaga.
>>>
>>> -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 bhavesh.x.patel at oracle.com Wed Sep 18 22:47:32 2013
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Thu, 19 Sep 2013 05:47:32 +0000
Subject: hg: jdk8/tl/langtools: 8024096: some javadoc tests may contain false
positive results
Message-ID: <20130919054739.11EF662932@hg.openjdk.java.net>
Changeset: 8df12c315ea3
Author: bpatel
Date: 2013-09-18 22:47 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8df12c315ea3
8024096: some javadoc tests may contain false positive results
Reviewed-by: jjg
! test/com/sun/javadoc/lib/JavadocTester.java
! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java
! test/com/sun/javadoc/testEncoding/EncodeTest.java
! test/com/sun/javadoc/testEncoding/TestEncoding.java
! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java
! test/com/sun/javadoc/testProfiles/TestProfiles.java
From kevin.walls at oracle.com Wed Sep 18 23:50:20 2013
From: kevin.walls at oracle.com (kevin.walls at oracle.com)
Date: Thu, 19 Sep 2013 06:50:20 +0000
Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets
Message-ID: <20130919065040.582D062934@hg.openjdk.java.net>
Changeset: c1d7040a1183
Author: sgabdura
Date: 2013-09-18 16:48 +0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1d7040a1183
8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR
Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor()
Reviewed-by: dcubed, dsamersoff
! src/share/vm/prims/jvmtiEnvBase.hpp
Changeset: 8c84f04ff977
Author: kevinw
Date: 2013-09-18 19:50 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8c84f04ff977
Merge
Changeset: 6eb908998b32
Author: kevinw
Date: 2013-09-19 08:47 +0200
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6eb908998b32
Merge
From serguei.spitsyn at oracle.com Thu Sep 19 01:27:26 2013
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 19 Sep 2013 01:27:26 -0700
Subject: RFR 8022887: Assertion hit while using class and redefining it
with RedefineClasses s,imultaneously
In-Reply-To: <523A00DC.9020905@oracle.com>
References: <5228A43C.4000602@oracle.com> <5228B018.5000903@oracle.com>
<5228B2D5.6060803@oracle.com> <5228CB84.7010400@oracle.com>
<523A00DC.9020905@oracle.com>
Message-ID: <523AB56E.9070208@oracle.com>
Hi Coleen,
The fix is good, thank you for fixing this!
Just a few minor comments below.
I'll try to avoid commenting the same spots that Dan has already covered.
src/share/vm/oops/instanceKlass.hpp
1171 // A pointer to the current info object so we can handle the deletes.
1172 PreviousVersionNode* _current_p;
Stale comment: "info object" => "node object"
src/share/vm/oops/instanceKlass.cpp
Nice simplifications, the code became cleaner!
src/share/vm/prims/jvm.cpp
Nice refactoring!
Suggestion: rename the method:
get_class_declared_method_helper ->get_class_declared_methods_helper
src/share/vm/prims/jvmtiImpl.cpp
No comments
src/share/vm/prims/jvmtiRedefineClasses.cpp
No comments
src/share/vm/runtime/handles.hpp
No comments
src/share/vm/runtime/handles.inline.hpp
No comments
Thanks,
Serguei
On 9/18/13 12:37 PM, Coleen Phillimore wrote:
>
> Hi, The new webrev is larger now. I found code where Method* can be
> leaked because methodHandles are not freed, and have rewritten
> JVM_GetClassDeclaredMethods and JVM_GetClassDeclaredConstructors to be
> redefinition safe.
>
> http://cr.openjdk.java.net/~coleenp/8022887_2/
>
>
> Tested with internal vm.quick.testlist and mlvm tests.
>
> Thanks,
> Coleen
>
>
> On 9/5/2013 2:20 PM, serguei.spitsyn at oracle.com wrote:
>> Coleen,
>>
>> This is great finding, and also a nice catch by Dan.
>> Waiting for a new webrev from you.
>>
>> Thanks,
>> Serguei
>>
>> On 9/5/13 9:35 AM, Coleen Phillimore wrote:
>>>
>>> Dan,
>>> Thank you for looking at this so quickly. You are right, we are
>>> not only getting public methods, whose number cannot change right
>>> now with redefine classes.
>>> I have to rework this change.
>>> Thanks,
>>> Coleen
>>>
>>> On 9/5/2013 12:23 PM, Daniel D. Daugherty wrote:
>>>> On 9/5/13 9:33 AM, Coleen Phillimore wrote:
>>>>> Summary: Need to refetch the methods array from InstanceKlass
>>>>> after safepoint.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8022887/
>>>>
>>>> The "frames" links are broken in this webrev. I had to
>>>> write down the changed line numbers for jvm.cpp and then
>>>> use the "new" link to see the context of the changes.
>>>>
>>>> src/share/vm/oops/instanceKlass.cpp
>>>> Nice catch. The old code could return an 'm' value that
>>>> referred to a method that wasn't a match. Ouch.
>>>>
>>>
>>> yes, it was a bit of a red herring for a while.
>>>
>>>> src/share/vm/prims/jvm.cpp
>>>> Nice catch of the use of potentially stale method array, but I
>>>> think there might be more issues here.
>>>>
>>>> In JVM_GetClassDeclaredMethods:
>>>>
>>>> line 1865: ++num_methods;
>>>>
>>>>
>>>>
>>>> line 1871: objArrayOop r =
>>>> oopFactory::new_objArray(SystemDictionary::reflect_Method_klass(),
>>>> num_methods, CHECK_NULL);
>>>>
>>>>
>>>>
>>>> line 1876: methods = k->methods();
>>>> line 1877: methods_length = methods->length();
>>>>
>>>>
>>>>
>>>> line 1885: result->obj_at_put(out_idx, m);
>>>>
>>>>
>>>>
>>>> line 1890: assert(out_idx == num_methods, "just checking");
>>>>
>>>> So num_methods is computed before the new_objArray() call that
>>>> can result in a safepoint which can permit a RedefineClasses()
>>>> operation to complete. You refresh methods and methods_length,
>>>> but num_methods still has its pre-RedefineClasses value and
>>>> the size of the result array is also at the
>>>> pre-RedefineClasses
>>>> size. Isn't it possible that we could overflow the result
>>>> array
>>>> here? And maybe fire that assert() on line 1890.
>>>>
>>>>
>>>> In JVM_GetClassDeclaredConstructors(), similar concerns for these
>>>> lines:
>>>>
>>>> line 1922: ++num_constructors;
>>>>
>>>>
>>>>
>>>> line 1928: objArrayOop r =
>>>> oopFactory::new_objArray(SystemDictionary::reflect_Constructor_klass(),
>>>> num_constructors, CHECK_NULL);
>>>>
>>>>
>>>>
>>>> line 1942: result->obj_at_put(out_idx, m);
>>>>
>>>>
>>>>
>>>> line 1947: assert(out_idx == num_constructors, "just checking");
>>>>
>>>>
>>>> Yes, this RedefineClasses() stuff is a serious pain in the butt
>>>> because it can change your assumed invariants in the middle of
>>>> your function.
>>>>
>>>> Dan
>>>>
>>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8022887
>>>>>
>>>>> Tested with the test cases in the bug, and with internal SQE tests
>>>>> (nsk.quick.testlist).
>>>>>
>>>>> thanks,
>>>>> Coleen
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130919/c8ef08bd/attachment-0001.html
From volker.simonis at gmail.com Thu Sep 19 04:29:33 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 19 Sep 2013 13:29:33 +0200
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
build the class library on AIX
In-Reply-To: <523A27A8.404@oracle.com>
References:
<523A27A8.404@oracle.com>
Message-ID:
Hi Phil,
thank you for looking at the changes. Please find my answers inline:
On Thu, Sep 19, 2013 at 12:22 AM, Phil Race wrote:
> Volker,
>
> I've skimmed the client related changes - mostly based on the descriptions.
> I'll look in more detail as soon as I can after JavaOne. We also have some
> engineers out on vacation who might want to look at these too.
>
> A couple of things that stood out :
> "On AIX, fontconfig is not a standard package supported by IBM."
> I am surprised AIX does not support fontconfig.
> That is something IBM should reconsider as its hard to imagine
> a modern Unix based system working without it ..
>
I totally agree, but this is an OpenJDK port not a AIX renovation:)
That said, IBM offers fontconfig packages from a special "AIX Toolbox for
Linux Applications" OpenSource site. But these OpenSource packages are not
supported and users have to install them manually (i.e. they are not part
of the standard installation images and you can not rely on them beeing
installed).
>
> Very basic start for AIX - feel free to complete ..
> 169 */
> 170 static char *fullAixFontPath[] = {
> ...
>
I'd really like to see it completed but these days
> that's largely a fall back for no fontconfig.
>
>
Again, this can get quite complicated and AIX-version dependent. I think
the provided list is a good starting point.
> /* AIX does not provide the 'dladdr' function. But fortunately, we've
> 42 * already implemented it in the HotSpot, because we need it there as
> 43 * well (see hotspot/src/os/aix/vm/porting_**aix.{hpp,cpp}).
>
> Whilst this is in "ifdef AIX" this reliance on an exported hotspot
> function sounds hacky. What actual requirement is there that the
> AIX class libraries be so tightly-coupled with that VM?
> There is no contract there.
>
>
You're right, there is no contract. It's just pragmatic solution and I
think it should always work because the libjvm will always be loaded at the
point in AWT where it is used. Another solution would be to re-implement
the functionality in the class library and I don't like code duplication
either.
> -phil.
>
>
>
>
> On 9/16/2013 12:30 PM, Volker Simonis wrote:
>
>> Resending this to more lists as requested by Alan Bateman with the kind
>> request to anybody to review the parts for which he feels responsible:)
>>
>> For those not up to date, this change is part of the ongoing PowerPC/AIX
>> Porting Project:
>> http://openjdk.java.net/**projects/ppc-aix-port
>> https://wiki.openjdk.java.net/**display/PPCAIXPort
>> http://openjdk.java.net/jeps/**175
>>
>> Please send reviews to all currently included recipients.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> ---------- Forwarded message ----------
>> From: *Volker Simonis*
>> Date: Monday, September 16, 2013
>> Subject: RFR(L): 8024854: Basic changes and files to build the class
>> library on AIX
>> To: "ppc-aix-port-dev at openjdk.**java.net> ppc-aix-port-dev@**openjdk.java.net >"
>> > ppc-aix-port-dev@**openjdk.java.net >>,
>> Java Core Libs > core-libs-dev at openjdk.**java.net >>
>>
>>
>> Hi,
>>
>> could you please review the following webrev which contains the basic
>> changes and files needed in the 'jdk' repository in order to build the
>> OpenJDK on AIX:
>>
>> http://cr.openjdk.java.net/~**simonis/webrevs/8024854<
>> http://cr.openjdk.java.net/%**7Esimonis/webrevs/8024854
>> >
>>
>> This change together with "8024265: Enable new build on AIX (jdk part) <
>> http://cr.openjdk.java.net/%**7Esimonis/webrevs/8024265_jdk/
>> **>" allows it to configure and completely build the staging repository
>> on AIX 5.3 and 7.1 with the following command:
>>
>>
>> configure --with-boot-jdk= --with-jvm-variants=core
>> --with-jvm-interpreter=cpp --with-cups-include=/opt/**freeware/include
>> --x-includes=/opt/freeware/**include
>>
>> Below you can find the changes and additions I've done, sorted by file.
>> Most of them are just additions which are only active during the AIX build
>> anyway or simple changes where AIX has been added to conditions which
>> already check for Linux and/or Solaris. The files with the biggest changes
>> which you're probably want to look on more thoroughly are
>> 'src/solaris/native/java/net/**NetworkInterface.c' and
>> 'src/solaris/native/sun/nio/**ch/Net.c' altough they shouldn't change
>> anything on the current OpenJDK platforms as well.
>>
>> Notice that there are still some files and some functionality missing
>> from the current change (notably NIO) but it still yields a running JDK
>> which can execute "HelloWorld" on the command line and as AWT application.
>> I've intentionally tried to keep this initial change as simple as possible
>> (with respect tot shared changes) in order to get it reviewed as fast as
>> possible. The missing parts can then be added later on, grouped by logical
>> topics, to simplify the review process.
>>
>> Thank you and best regards,
>>
>> Volker
>>
>>
>> src/share/bin/jli_util.h
>>
>> * Define |JLI_Lseek| on AIX.
>>
>>
>> src/share/lib/security/java.**security-aix
>>
>> * Provide default |java.security-aix| for AIX.
>>
>>
>> src/share/native/sun/awt/**medialib/mlib_sys.c
>>
>> * |malloc| always returns 8-byte aligned pointers on AIX as well.
>>
>>
>> src/share/native/sun/awt/**medialib/mlib_types.h
>>
>> * Add AIX to the list of known platforms.
>>
>>
>> src/share/native/sun/font/**layout/KernTable.cpp
>>
>> * Rename the macro |DEBUG| to |DEBUG_KERN_TABLE| because |DEBUG| is
>>
>> too common and may be defined in other headers as well as on the
>> command line and |xlc| bails out on macro redefinitions with a
>> different value.
>>
>>
>> src/share/native/sun/security/**ec/impl/ecc_impl.h
>>
>> * Define required types and macros on AIX.
>>
>>
>> src/solaris/back/exec_md.c
>>
>> * AIX behaves like Linux in this case so check for it in the Linux
>> branch.
>>
>>
>> src/solaris/bin/java_md_**solinux.c,
>> src/solaris/bin/java_md_**solinux.h
>>
>> * On AIX |LD_LIBRARY_PATH| is called |LIBPATH|
>> * Always use |LD_LIBRARY_PATH| macro instead of using the string
>>
>> "|LD_LIBRARY_PATH|" directly to cope with different library path
>> names.
>> * Add |jre/lib//jli| to the standard library search path on
>>
>> AIX because the AIX linker doesn't support the |-rpath| option.
>> * Replace |#ifdef __linux__| by |#ifndef __solaris__| because in
>>
>> this case, AIX behaves like Linux.
>>
>>
>> src/solaris/classes/sun/awt/**fontconfigs/aix.fontconfig.**
>> properties
>>
>> * Provide basic |fontconfig.properties|for AIX.
>>
>>
>> src/solaris/classes/java/lang/**UNIXProcess.java.aix,
>> src/solaris/classes/sun/tools/**attach/AixAttachProvider.java,
>> src/solaris/classes/sun/tools/**attach/AixVirtualMachine.java
>>
>> * Provide AIX specific Java versions, mostly based on the
>> corresponding Linux versions.
>>
>>
>> src/solaris/demo/jvmti/hprof/**hprof_md.c
>>
>> * Add AIX support. AIX mostly behaves like Linux, with the one
>>
>> exception that it has no |dladdr| functionality.
>> * Implement |dladdr| functionality for AIX.
>>
>>
>> src/solaris/native/com/sun/**management/**
>> UnixOperatingSystem_md.c
>>
>> * Adapt for AIX (i.e. use |libperfstat| on AIX to query OS memory).
>>
>>
>> src/solaris/native/common/jdk_**util_md.h
>>
>> * Add AIX definitions of the |ISNANF| and |ISNAND| macros.
>>
>>
>> src/solaris/native/java/io/io_**util_md.c
>>
>> * AIX behaves like Linux in this case so check for it in the Linux
>> branch.
>>
>>
>> src/solaris/native/java/net/**NetworkInterface.c
>>
>> * Add AIX support into the Linux branch because AIX mostly behaves
>> like AIX for IPv4.
>> * AIX needs a special function to enumerate IPv6 interfaces and to
>>
>> query the MAC address.
>>
>>
>> src/solaris/native/java/net/**PlainSocketImpl.c
>>
>> * On AIX (like on Solaris) |setsockopt| will set errno to |EINVAL|
>>
>> if the socket is closed. The default error message is then confusing.
>>
>>
>> src/solaris/native/java/net/**linux_close.c,
>> src/share/native/java/net/net_**util.c
>>
>> * Also use the file and socket wrappers on AIX.
>> * Add initialization of some previously uninitialized data structures.
>> * On AIX we don't have |__attribute((constructor))| so we need to
>>
>> initialize manually (from |JNI_OnLoad()| in
>> 'src/share/native/java/net/**net_util.c'
>>
>>
>> src/solaris/native/java/net/**net_util_md.h
>>
>> * AIX needs the same workaround for I/O cancellation like Linux and
>> MacOSX.
>>
>>
>> src/solaris/native/java/util/**TimeZone_md.c
>>
>> * Currently on AIX the only way to get the platform time zone is to
>>
>> read it from the |TZ| environment variable.
>>
>>
>> src/solaris/native/sun/awt/**awt_LoadLibrary.c
>>
>> * There's no |dladdr| on AIX, but we can use the implementation from
>>
>> the HotSpot in this case because |libjvm.so| will be always loaded
>> before the AWT.
>>
>>
>> src/solaris/native/sun/awt/**fontpath.c
>>
>> * Add AIX specific fontpath settings and library search paths for
>> |libfontconfig.so|.
>>
>>
>> src/solaris/native/sun/java2d/**x11/X11SurfaceData.c
>>
>> * Only define |MIN| and |MAX| if they're not already defined because
>>
>> xlc on AIX fails on macro redefinitions.
>>
>>
>> src/solaris/native/sun/java2d/**x11/XRBackendNative.c
>>
>> * Handle AIX like Solaris.
>>
>>
>> src/solaris/native/sun/nio/ch/**Net.c
>>
>> * Add AIX-specific includes and constant definitions.
>> * On AIX "socket extensions for multicast source filters" support
>>
>> depends on the OS version. Check for this and throw appropriate
>> exceptions if it requested but not supported. This is needed to
>> pass
>> JCK-api/java_nio/channels/**DatagramChannel/**
>> DatagramChannel.html#Multicast
>>
>>
>> src/solaris/native/sun/**security/pkcs11/j2secmod_md.c
>>
>> * Use |RTLD_LAZY| instead of |RTLD_NOLOAD| on AIX.
>>
>>
>> src/solaris/native/sun/tools/**attach/AixVirtualMachine.c
>>
>> * AIX version mostly derived from the corresponding Linux version.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130919/1b07175e/attachment.html
From alexander.zuev at oracle.com Thu Sep 19 06:06:11 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Thu, 19 Sep 2013 13:06:11 +0000
Subject: hg: jdk8/tl/langtools: 8017248: Compiler Diacritics Issue
Message-ID: <20130919130614.CA5CB62947@hg.openjdk.java.net>
Changeset: 36e342dd57e2
Author: kizune
Date: 2013-09-19 17:05 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36e342dd57e2
8017248: Compiler Diacritics Issue
Reviewed-by: naoto
! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
From alexander.zuev at oracle.com Thu Sep 19 06:07:17 2013
From: alexander.zuev at oracle.com (alexander.zuev at oracle.com)
Date: Thu, 19 Sep 2013 13:07:17 +0000
Subject: hg: jdk8/tl/jdk: 8017248: Compiler Diacritics Issue
Message-ID: <20130919130827.594B262948@hg.openjdk.java.net>
Changeset: 22e9f0067b5a
Author: kizune
Date: 2013-09-19 17:04 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22e9f0067b5a
8017248: Compiler Diacritics Issue
Reviewed-by: naoto
! src/share/classes/sun/launcher/LauncherHelper.java
+ test/tools/launcher/8017248/ClassA??.java
+ test/tools/launcher/8017248/test.sh
From philip.race at oracle.com Thu Sep 19 06:53:35 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 19 Sep 2013 06:53:35 -0700
Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to
build the class library on AIX
In-Reply-To:
References: